login
AnalyzerThe login
analyzer inspects interactive login sessions
to extract username and password information, and monitors user
keystrokes and the text returned by the login server. It is one of
the most powerful Bro modules for detecting break-ins to Unix
systems because of the ability to look for particular commands that
attackers often execute once they have penetrated a Unix machine.
The analyzer is generic in the sense that it applies to more
than one protocol. Currently, Bro instantiates a login
analyzer for both Telnet [RFC-854] and Rlogin [RFC-1282]
traffic. In principle, it could do the same for other protocols such as
SSH [RFC-XXX] or perhaps X11 [RFC-1013], if one could write
the corresponding elements of the event engine to decrypt the
SSH session (naturally, this would require access to the encryption keys)
or extract authentication information and keystrokes from the
X11 event stream. Note: The analyzer does an exceedingly limited
form of SSH analysis; see hot_ssh_orig_ports
.
For Telnet, the event engine knows how to remove in-band Telnet option sequences [RFC-855] from the text stream, and does not deliver these to the event handlers, except for a few options that the engine analyzes in detail (such as attempts to negotiate authentication). Unfortunately, the Telnet protocol does not include any explicit marking of username or password information (unlike the FTP protocol, as discussed in ftp Analyzer). Consequently, Bro employs a series of heuristics that attempt to extract the username and password from the authentication dialog the session is presumed to begin with. The analysis becomes quite complicated due to the possible use of type-ahead and editing sequences by the user, plus the possibility that the user may be an attacker who attempts to mislead the heuristics in order to disguise the username they are accessing.
Analyzing Rlogin is nominally easier than analyzing Telnet because Rlogin
has a simpler in-band option scheme, and because the Rlogin protocol
explicitly indicates the username in the initial connection dialog.
However, this last is not actually a help to the analyzer, because
for most Rlogin servers, if the initial username fails authentication
(for example, is not present in the .rhosts
file local to
the server), then the server falls back on the same authentication
dialog as with Telnet
(prompting for username and then password, or perhaps just
for a password to go with the transmitted username).
Consequently, the event engine employs the same set of heuristics
as for Telnet.
Each connection processed by the analyzer is in a distinct state:
user attempting to authenticate, user has successfully authenticated,
analyzer is skipping any further processing, or the analyzer is
confused (See: login analyzer confusion). You can find out the state of
a given connection using get_login_state
.
The analyzer uses a capture filter of “tcp port 23 or tcp port 513
”
Filtering
. It annotates each connection
with the username(s) present in the authentication dialog. If
the username was authenticated successfully, then it encloses
the annotation in quotes. If the authentication failed, then
the name is marked as failed/
<
username>
.
So, for example, if user “smith” successfully authenticates,
then the connection's addl
field will have
"smith"
appended to it:
931803523.006848 254.377 telnet 324 8891 1.2.3.4 5.6.7.8 SF L "smith"
while if “smith” failed to authenticate, the report will look like:
931803523.006848 254.377 telnet 324 8891 1.2.3.4 5.6.7.8 SF L fail/smith
and if they first tried as “smith” and failed, and then succeeded as “jones”, the record would look like:
931803523.006848 254.377 telnet 324 8891 1.2.3.4 5.6.7.8 SF L fail/smith "jones"
Note: The event engine's heuristics can sometimes get out of synch such that it interprets a password as a username; in addition, users sometimes type their password when they should instead enter their username. Consequently, the connection logs sometimes include passwords in the annotations, and so should be treated as very sensitive information (e.g., not readable by any user other than the one running Bro).