I have been following the debate regarding security with interest, but I
haven't seen anyone address the problem of fake shell break-ins!
I bet a very bright computer science undergraduate (who works for our
computing department) that he couldn't break into our file-server --
after all, passwords are encrypted and the file server is in a secure
location. 24 hours later, the computer science student came back with
a text file FULL of usernames and passwords. One beer poorer, I asked
him to explain how he had done it. Very simple, he explained:
1. He logged into one of my workstations (a diskless one, even).
1. He ran a Pascal program which mimicked TO PERFECTION what my users
normally see when they log in (I use a nice banner with colors, etc,
executed via a file called login.bat).
2. When the user (unsuspectingly) entered his user-name and password,
the program wrote the user-name and password to a file, informed the
user that the password was entered incorrectly (again, using exactly
the same screen lay-out that I did), and then executed my login.bat.
Since the computer science student is a monitor in one of our labs, he
was able to gather a large number of passwords quickly. Since he was on
duty, he was also able to assess how many got suspicious by the failed
first login: Noone! Everyone just assumed they had mistyped their password.
Now, the program is specific to my circumstances only in what it displays
on the screen. It could easily be modified to simulate any other non-
graphic screen, and could thus be run against any system.
What do you do to prevent fake shell logins?
Thank you very much for any assistance!
Ah, yes. The old facade attack. The first time this was done in
history was probably half a day after the first login program was
written for some long forgotten operating system.
>What do you do to prevent fake shell logins?
In this case, the easiest solution is to teach all your users to start
out each session by hitting the reset button on the computer to reboot
it. With a system that boots from disk, things are a little hairier
since the facade could be put right into the autoexec.bat file. In
fact, i'm not sure there's any simple way to avoid that approach.
There have been other solutions throughout history, but none i can
think of that apply to this case.
By the way, it's quite likely he would have acheived almost the same
results if rather than mimicking your login, his program had just said
"What's your user name?", "Ok, now what's your password?". Users are
Now there's an idea. I've seen lots of REBOOT.COM programs, and you can set
it up so that REBOOT is executed on logout. Still not perfect, but unless
he's got rights to someplace to get his own logout.bat file executed before
yours, the machine will reboot. Not very nice to the regular users with
a local hard disk, but it should help :-)
Eric J. Schwertfeger, man...@cs.unlv.edu
There are LOTS of ways to get around that. First, presumably the hacker did
not logout anyway, as it was a diskless workstation, so he would have to remain
logged in to be able to save the passwords to a file. (NOT-LOGGIN-IN does
not have write access to any drive). He simply got the info, displayed
INVALID PASSWORD and then ran the real login, which, if it is like Novell's
login, will effectively log the original user out first.
Any even if he was logging out, it's easy to get around LOGOUT.BAT ...
one of the most obvious is simply get your own copy of LOGOUT.EXE and
put it in your home directory (or anywhere else you have write access to), and
then run it from there. Anything in the current directory overrides anything
in the path, and anyone can change his/her path anyway.
- Brett (rfra...@cs.umr.edu)
Step 2. Remove the hard drive from each of your lab's public PCs.
Step 3. Learn serenity.
Step 4. Put everything back so everyone can get their work done.
The idea is that if anyone can modify the software used to login to the
network, without being physically caught doing this, you don't have a
This is perhaps one of the strongest arguments in favor of X terminals
and diskless PCs.
: I have been following the debate regarding security with interest, but I
: haven't seen anyone address the problem of fake shell break-ins!
There are a number of things one can do to make it harder for password traps
We have our own shell which calls Login.exe and feeds information in the form of
parameters (Screen type, Default printer), This means they have to write windowing
stuff in order to emulate what students see. This keeps the real kiddies out.
We don't allow access to the login directory once users are logged on. This also
makes it harder to write shell programs as they have to get a copy of Login.exe
from somewhere else.
We have a little util called bye which logs users out and reboots the machine.
This also wipes memory and any passwords left lying around by login.
Most of our machines are diskless which also helps.
We also make students sign good behavior type thingies when they start the
courses to so they have a clear picture of what is good and what is bad :-)
It doesn't make the problem goaway, but it does make much more easy to detect.
Or, as did a student at my school, he could have used a bios keycapture
TSR that records keystrokes to a text file. That one is a bit tricker
Bob Matsuoka, Network Manager bm...@cunixf.colmbia.edu
New Lab for Teaching and Learning ph. (212) 722-5160 x152
The Dalton School fax (212) 348-5885