Fake shell break-ins -- How do you prevent?
Morten Soerensen
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!
Greetings --
Morten Soerensen
Network Manager
Macalester College
soer...@macalstr.edu
Joe Doupnik
This is one of the oldest chestnuts in the security locker. The
solution is to normally never trust a client machine which is powered on.
Maybe you should purchase one of the O'Reilly Publisher's Unix security books,
the nutshell series, to review the tried and true ways folks seek to deceive.
Joe D.
don provan
>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).
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
notoriously trusting...
don provan
do...@novell.com
Eric J. Schwertfeger
)
) In article <soerensen.3...@macalstr.edu> soer...@macalstr.edu (Morten Soerensen) writes:
) >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).
)
) 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.
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
Richard Brett Frankenberger
>In article <1993Apr15.0...@novell.com>, do...@novell.com (don provan) writes:
>)
>) In article <soerensen.3...@macalstr.edu> soer...@macalstr.edu (Morten Soerensen) writes:
>) >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).
>
>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)
Rich Braun
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
secure environment.
This is perhaps one of the strongest arguments in favor of X terminals
and diskless PCs.
-rich
Warren Mcivor
: Fellow Novellers;
: 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
to.
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.
R.v.Kampen
>In article <1993Apr15.0...@unlv.edu> man...@lil-ed.cs.unlv.edu (Eric J. Schwertfeger) writes:
>>In article <1993Apr15.0...@novell.com>, do...@novell.com (don provan) writes:
>>)
>>) In article <soerensen.3...@macalstr.edu> soer...@macalstr.edu (Morten Soerensen) writes:
>>) >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).
>>
>>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.
>
create an object with security 00 (world writable/readable)
and write all information you want stored when not logged in in that
object.
willem
Bob Matsuoka
>
>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
>notoriously trusting...
> don provan
> do...@novell.com
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
to avoid...
--B
--------------------------------------------------------------------------
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