Next: , Previous: ident Analyzer, Up: Analyzers and Events



7.19 The login Analyzer

The 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 513Filtering. 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).