mhw@wittsend.syntrex.com (Michael H. Warfield (Mike)) (09/20/90)
In article <8354@helios.TAMU.EDU> peram@cs.tamu.edu (Suresh B Peram) writes: >Is it possible to break passwords so >easily in Unix Systems ? Is it >possible to "catch" passwords while >they are being typed at the terminal ? Answer is wwweeelll yes and no. There are techniques which can crack the encrypted password entry given sufficient horse power and time to do the job. Some newer implimentations of the encryption algorithm are efficient enough to make the brute force approach practical on a decent mini that your not going to use for anything else for a while. This is to say nothing of the standard hackers "short cuts". Many common passwords are all to easy to crack before resorting to the brute force method. They are a direct result of people choosing simple passwords that others can systematically guess easily. It is possible to "catch" passwords while they are being typed at a terminal, but this generally requires intimate knowledge of the system and often requires superuser priviledges. A typical "trogan horse" attach would be to leave a dummy "login" program on the line to catch the next guy's login. You give him a bogus "Incorrect login" and drop out to let getty give him a legitimate shot at loging in. Normal system security for terminal devices and honest, diligent system administrators can prevent most of this or make it so difficult, it's not worth the effort. Michael H. Warfield | (404) 551-7870 | mhw@WittsEnd.SYNTREX.COM (The Mad Wizard) | NIC: MHW-9 | gatech.edu!galbp!wittsend!mhw An optimist believes we live in the best of all possible worlds. A pessimist is sure of it!
lush@EE.MsState.Edu (Edward Luke) (09/21/90)
In article <11133@galbp.LBP.HARRIS.COM> mhw@wittsend.syntrex.com (Michael H. Warfield (Mike)) writes: > It is possible to "catch" passwords while they are being typed at a >terminal, but this generally requires intimate knowledge of the system and >often requires superuser priviledges. A typical "trogan horse" attach would >be to leave a dummy "login" program on the line to catch the next guy's login. >You give him a bogus "Incorrect login" and drop out to let getty give him >a legitimate shot at loging in. Normal system security for terminal devices >and honest, diligent system administrators can prevent most of this or make it >so difficult, it's not worth the effort. Unfortunately this is not true. Trojan Horses are very easy to implement, and they don't require super user access. All an evil trojan horse writer would need is access to that terminal... Log in, run login program that looks identical to the normal login procedure. This proceduer would snarf up the passwd, tell the user "Sorry wrong password", and then exit back to the real login procedure. If your terminal is in a highly accessible location, a trojan horse is certainly an option for obtaining passwords. Edward Luke lush@ee.msstate.edu Mississippi State University NSF Engineering Research Center for Complex Field Simulation
cgy@cs.brown.edu (Curtis Yarvin) (09/24/90)
In article <LUSH.90Sep21083625@athena0.EE.MsState.Edu> lush@EE.MsState.Edu (Edward Luke) writes: >In article <11133@galbp.LBP.HARRIS.COM> mhw@wittsend.syntrex.com >(Michael H. Warfield (Mike)) writes: >>Normal system security for terminal devices >>and honest, diligent system administrators can prevent most of this or make it >>so difficult, it's not worth the effort. >Unfortunately this is not true. Trojan Horses are very easy to >implement, and they don't require super user access. All an evil >trojan horse writer would need is access to that terminal... Log in, >run login program that looks identical to the normal login procedure. >This proceduer would snarf up the passwd, tell the user "Sorry wrong >password", and then exit back to the real login procedure. You should be able to prevent this. SunOS (and thus likely BSD as well, though I don't know) make the first login prompt "<hostname> login:", and switch to plain "login:" if an incorrect password is entered. This disables login trojans by making them unconcealable. Alternatively, on at least some SysV machines, you can change the first prompt from the soft underbelly of "login:" by mucking with /etc/gettydefs (I think /etc/gettytab on BSD is the same). -Curtis Yarvin cgy@cs.brown.edu "Now you can go where people are one, Now you can go where they get things done." -The Dead Kennedys, "Holiday in Cambodia"
jeenglis@alcor.usc.edu (Joe English Muffin) (09/24/90)
cgy@cs.brown.edu (Curtis Yarvin) writes: >In article <LUSH.90Sep21083625@athena0.EE.MsState.Edu> lush@EE.MsState.Edu (Edward Luke) writes: >>Unfortunately this is not true. Trojan Horses are very easy to >>implement, and they don't require super user access. All an evil >>trojan horse writer would need is access to that terminal... Log in, >>run login program that looks identical to the normal login procedure. >>This proceduer would snarf up the passwd, tell the user "Sorry wrong >>password", and then exit back to the real login procedure. >You should be able to prevent this. SunOS (and thus likely BSD as well, >though I don't know) make the first login prompt "<hostname> login:", and >switch to plain "login:" if an incorrect password is entered. This disables >login trojans by making them unconcealable. Yeah, but by the time you realize that login isn't displaying the right prompt, it's too late to do anything. The password- snarfer could also exec /bin/login instead of exiting, which would make everything look right (it's getty that displays the hostname, etc., not login.) Of course, getting into the habit of always typing a bogus username & password when you first sit down at a terminal will defeat most simple-minded login trojans, if you want to be paranoid about it. --Joe English jeenglis@alcor.usc.edu
mathisen@dali.cs.montana.edu (Jaye Mathisen) (09/24/90)
In article <12165@chaph.usc.edu> jeenglis@alcor.usc.edu (Joe English Muffin) writes: |cgy@cs.brown.edu (Curtis Yarvin) writes: | |>You should be able to prevent this. SunOS (and thus likely BSD as well, |>though I don't know) make the first login prompt "<hostname> login:", and |>switch to plain "login:" if an incorrect password is entered. This disables |>login trojans by making them unconcealable. | |Yeah, but by the time you realize that |login isn't displaying the right prompt, |it's too late to do anything. The password- |snarfer could also exec /bin/login instead of |exiting, which would make everything look |right (it's getty that displays the hostname, |etc., not login.) I haven't been following this whole discussion, but I though I'd mention that DEC is now providing with Ultrix 4.0, a "Trusted Path" feature. If a user hits <break> on a system with tpath enabled, then the user is guaranteed to be getting a real login session... I may be not quite on the mark with the details, but I would guess it's something as simple as when getty sees a <break>, it kills itself off, and let's init start up a new getty, thus aborting any processes (spoofers) on the line. I haven't tried it here yet, because we have too many DECServer 200's that are configured to use BREAK for all the special functions.
slfields@uokmax.ecn.uoknor.edu (Scott L Fields) (09/24/90)
In article <12165@chaph.usc.edu> jeenglis@alcor.usc.edu (Joe English Muffin) writes: >>though I don't know) make the first login prompt "<hostname> login:", and >>switch to plain "login:" if an incorrect password is entered. This disables >>login trojans by making them unconcealable. > >Yeah, but by the time you realize that >login isn't displaying the right prompt, >it's too late to do anything. The password- >snarfer could also exec /bin/login instead of >exiting, which would make everything look >right (it's getty that displays the hostname, >etc., not login.) > >Of course, getting into the habit of always >typing a bogus username & password when >you first sit down at a terminal will defeat >most simple-minded login trojans, if you >want to be paranoid about it. The point in the previous case is to immediately change your password if you spot the trojan after logging in. A better idea might be to hit break before logging in. Always the possibility of landing in the trojans account.
guy@auspex.auspex.com (Guy Harris) (09/24/90)
>You should be able to prevent this. SunOS (and thus likely BSD as well, >though I don't know) make the first login prompt "<hostname> login:", 4.1cBSD did that, as I remember; 4.2BSD and later stick other stuff before the "login:" prompt (which, in 4.2BSD or later, starts at column 1). Sun left it the way it was in 4.1c. >and switch to plain "login:" if an incorrect password is entered. This >disables login trojans by making them unconcealable. Err, what's to stop the trojan horse program from exhibiting the same behavior as "getty" (which issues the first prompt indicated above) and "login" (which issues the subsequent ones)? >Alternatively, on at least some SysV machines, you can change the first >prompt from the soft underbelly of "login:" by mucking with >/etc/gettydefs (I think /etc/gettytab on BSD is the same). It is; that's where the "<hostname> " comes from in SunOS: default:\ :ap:lm=\r\n%h login\72 :sp#9600: and the other stuff comes from in 4.[2andup]BSD: default:\ :ap:fd#1000:im=\r\n\r\n4.3 BSD UNIX (%h) (%t)\r\n\r\r\n\r:sp#1200:
d87-man@sm.luth.se (Mikael Adolfsson) (09/25/90)
guy@auspex.auspex.com (Guy Harris) writes: >>and switch to plain "login:" if an incorrect password is entered. This >>disables login trojans by making them unconcealable. >Err, what's to stop the trojan horse program from exhibiting the same >behavior as "getty" (which issues the first prompt indicated above) and >"login" (which issues the subsequent ones)? What's to stop the trojan horse program from executing "getty" itself. I have planned to write such a beast (just to test the idea of course :-) and here's how I would do it. First I would write a pseudo-device interface (similar to rlogin). This interface would resemble script(1) in that it could save on a file all characters passed between a child process and the tty. Then this program should just simply call "getty" and watch for keywords (sent from the child process "getty", "login" or whatever) of the form "*login: " ...followed by: "Password:" This parsing would make it possible to save only those parts of the login session that had to do with "logging in". And furthermore it would be possible to make sure that the password is correct. -- Mikael Adolfsson # d87-man@sm.luth.se University of Lulea, Sweden # ...{uunet,mcsun}!sunic!sm.luth.se!d87-man
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (09/25/90)
In article <4086@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: > >and switch to plain "login:" if an incorrect password is entered. This > >disables login trojans by making them unconcealable. > Err, what's to stop the trojan horse program from exhibiting the same > behavior as "getty" (which issues the first prompt indicated above) and > "login" (which issues the subsequent ones)? And what if it imitates getty and login in all respects? After all, there's no reason it can't check your password for you and then log in as you if you provide the right password. And what if, to be somewhat more subtle, it simply intercepts all the I/O and connects you to a telnetd or login on a pseudo-tty? You cannot reliably *detect* a Trojan Horse unless you can reliably *avoid* a Trojan horse. That's why the system has to provide a trusted path. ---Dan
cedman@golem.ps.uci.edu (Carl Edman) (09/25/90)
In article <1990Sep24.151824.30714@uokmax.ecn.uoknor.edu> slfields@uokmax.ecn.uoknor.edu (Scott L Fields) writes:
...
The point in the previous case is to immediately change your password if you
spot the trojan after logging in. A better idea might be to hit break before
logging in. Always the possibility of landing in the trojans account.
Even on danger of nit-picking: You would NOT land in the account of the
trojan. You are the trojan. If anything you would land in the account of
the greek. :-)
Theorectial Physicist,N.:A physicist whose | Send mail
existence is postulated, to make the numbers | to
balance but who is never actually observed | cedman@golem.ps.uci.edu
in the laboratory. | edmanc@uciph0.ps.uci.edubrnstnd@kramden.acf.nyu.edu (Dan Bernstein) (09/25/90)
In article <1132@tau.sm.luth.se> d87-man@sm.luth.se (Mikael Adolfsson) writes: > What's to stop the trojan horse program from executing "getty" itself. > I have planned to write such a beast (just to test the idea of course :-) > and here's how I would do it. Gee, here's my translation of your solution: % pty -0 tee script | pty sh -c 'echo "`hostname` ";exec login' Not that I encourage anyone do this, but no system administrator should be deluded into thinking that it's difficult to write a Trojan Horse. ---Dan
tims@uunet.uu.net (Tim Sesow (SSDS Rocky Mntn)) (09/25/90)
Curtis Yarvin <cgy@cs.brown.edu> writes: >You should be able to prevent this. SunOS (and thus likely BSD as well, >though I don't know) make the first login prompt "<hostname> login:", and >switch to plain "login:" if an incorrect password is entered. This disables >login trojans by making them unconcealable. Alternatively, on at least some >SysV machines, you can change the first prompt from the soft underbelly of >"login:" by mucking with /etc/gettydefs (I think /etc/gettytab on BSD is the >same). IMHO, I don't believe there is any way on a terminal (as opposed to TELNET) to have the UNIX O/S deter a dedicated trojan horse writer. You can increase the levels of interaction for the trojan horse program to simulate, but writing a trojan horse to capture passwords for any given system is relatively easy. A hardware scheme to shut down the terminal session might work IF (1) every user turns off the terminal and (2) the SIGHUP cannot be caught. One way out: stick to TELNET sessions and ALWAYS disconnect and reconnect before logging on. Tim Sesow SSDS Inc. Rocky Mountain Region Littleton, CO
ram@attcan.UUCP (Richard Meesters) (09/25/90)
In article <50845@brunix.UUCP>, cgy@cs.brown.edu (Curtis Yarvin) writes: > In article <LUSH.90Sep21083625@athena0.EE.MsState.Edu> lush@EE.MsState.Edu (Edward Luke) writes: > >In article <11133@galbp.LBP.HARRIS.COM> mhw@wittsend.syntrex.com > >(Michael H. Warfield (Mike)) writes: > >>Normal system security for terminal devices > >>and honest, diligent system administrators can prevent most of this or make it > >>so difficult, it's not worth the effort. > > >Unfortunately this is not true. Trojan Horses are very easy to > >implement, and they don't require super user access. All an evil > >trojan horse writer would need is access to that terminal... Log in, > >run login program that looks identical to the normal login procedure. > >This proceduer would snarf up the passwd, tell the user "Sorry wrong > >password", and then exit back to the real login procedure. > > You should be able to prevent this. SunOS (and thus likely BSD as well, > though I don't know) make the first login prompt "<hostname> login:", and > switch to plain "login:" if an incorrect password is entered. This disables > login trojans by making them unconcealable. Alternatively, on at least some > SysV machines, you can change the first prompt from the soft underbelly of > "login:" by mucking with /etc/gettydefs (I think /etc/gettytab on BSD is the > same). That's true, but the user will, of course, have to _notice_ that the login prompt has not changed from <hostname> login: to login:, something which you can't depend on a user to do, anymore than you can depend on the same user to pick a good password. It falls to the administrator of the system to check for such security violations, the users can't be relied upon to do security checks. Regards, ------------------------------------------------------------------------------ Richard A Meesters | Technical Support Specialist | Insert std.logo here AT&T Canada | | "Waste is a terrible thing ATTMAIL: ....attmail!rmeesters | to mind...clean up your act" UUCP: ...att!attcan!ram | ------------------------------------------------------------------------------
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (09/26/90)
In article <24590@adm.BRL.MIL> ssds!tims@uunet.uu.net (Tim Sesow (SSDS Rocky Mntn)) writes: > One way out: stick to TELNET sessions and ALWAYS disconnect and reconnect > before logging on. Even this isn't good enough. Despite popular myth, there is a way to sneak a Trojan Horse under a pseudo-tty (under BSD, at least). Please, kids, don't bother sending me mail asking how to do this; learn to read your own man pages. And what do you propose to do about public terminals? Too many terminal concentrators don't provide a trusted path. Many communications programs are just a bit too configurable. Some universities (like MIT) have an atmosphere of trust where nobody would take advantage of such problems; some universities (like NYU) have an atmosphere of trust where we'll draw and quarter any student who misbehaves and stick his head on a pike in front of the building. But it's still an issue to think about. Disclaimer: I've never been personally involved in sticking anyone's head on a pike. :-) ---Dan
martin@mwtech.UUCP (Martin Weitzel) (09/26/90)
In article <3346:Sep2422:01:3090@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: [about how to avoid getting trapped by a trojan horse] > >And what if it imitates getty and login in all respects? [...] >You cannot reliably *detect* a Trojan Horse unless you can reliably >*avoid* a Trojan horse. [...] Agreed. You cannot do it ... at least not before login, but I think there are some ways to know really soon if you have been trapped by a trojan login, and even to find out who installed it. [Small sidenote: According to the excellent book "UNIX System Security" (Kochan + Wood), what we are speaking about is not a "trojan horse", but a "spoof". But to avoid confusion, for this thread I'll stay with the term "trojan".] The key for the following ideas is that a trojan getty can never look allright in the ps-list (except the one who installed it has allready access as root, but in this case he wouldn't need a trojan any more :-/). If the trojan manages to show up as "getty" in the ps-list, it can be easily detected as its UID is not 0. If the trojan has an ordinary name in the ps-list, it can be detected by looking at the terminals for which *no* gettys are active. If such a terminal shows a login- screen, it's a trojan. In this case it should even be easy to find the person who installed it by reading the login-history (provided the system has no guest account, which IMHO is allways a bad idea ...). Based on the above, it should be feasible to have a daemon process running permanently in the background, that every minute or so snapshots the ps-list and remembers the names of the tty-lines where the "real" gettys are running. After someone has logged in, the .profile could contain a command to query the daemon how long the getty has been active for this terminal before. If it turns out that no getty has been active in the last minutes before login though there was apparently nobody working at this terminal, you have been trapped by a trojan and can immediatly change your password. Furthermore, the system administrator can now look who used this terminal immediatly before you, and so find the one who installed the trojan. I can see few changes to circumvent these security barriers. Especially it would hard for the trojan to correctly simulate the behaviour that occurs *after* your login without knowing your .profile. Hence it can not tell you "every thing's O.K., the terminal was 10 minutes ununsed before your login" and then continue how you would expect it. -- Martin Weitzel, email: martin@mwtech.UUCP, voice: 49-(0)6151-6 56 83
peter@ficc.ferranti.com (Peter da Silva) (09/27/90)
In article <50845@brunix.UUCP> cgy@cs.brown.edu (Curtis Yarvin) writes: > You should be able to prevent this. SunOS (and thus likely BSD as well, And most UNIX systems, these days... > make the first login prompt [special] and switch to plain "login:" if an incorrect password is entered. Yes, so you have to be smarter about your response. One that I saw a decade or so ago had a whole array of plausible error messages... Trojan horse login programs still live. A rather clumsy way of working, I think. There are lots more interesting places to put trojans, especially if there's a public bin directory out there... -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com
bote@csense.uucp (John Boteler) (09/27/90)
cgy@cs.brown.edu (Curtis Yarvin) claimed: >In article <LUSH.90Sep21083625@athena0.EE.MsState.Edu> lush@EE.MsState.Edu (Edward Luke) writes: >>This proceduer would snarf up the passwd, tell the user "Sorry wrong >>password", and then exit back to the real login procedure. > >You should be able to prevent this. SunOS (and thus likely BSD as well, >though I don't know) make the first login prompt "<hostname> login:", and >switch to plain "login:" if an incorrect password is entered. This disables >login trojans by making them unconcealable. Yes, you're right. No programmer in the world could possibly defeat this. Especially without superuser access. -- John Boteler bote@csense.uucp {uunet | ka3ovk}!media!csense!bote SkinnyDipper's Hotline: 703-241-BARE | VOICE only, Touch-Tone(TM) signalling
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (09/28/90)
In article <936@mwtech.UUCP> martin@mwtech.UUCP (Martin Weitzel) writes: > In article <3346:Sep2422:01:3090@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: > >You cannot reliably *detect* a Trojan Horse unless you can reliably > >*avoid* a Trojan horse. > Agreed. You cannot do it ... at least not before login, but I think > there are some ways to know really soon if you have been trapped by > a trojan login, and even to find out who installed it. Uh-uh. If a process gets your password, it can start an su to completely switch to your uid, exec the su shell into a special program, pass the tty file descriptors and any other relevant state to that program, and finally have the program exec your login shell. The system is in *exactly* the same state as it would be if you had talked to the normal login. If su doesn't do the trick, there's always rsh and rlogin and even ftp to put in a fake mail server that you then execute. And none of what you mentioned will work against a solution that uses ptys. Looking at the login history doesn't work since the most effective attacks manage to keep tty access after the attacker has long logged out. > I can see few changes to circumvent these security barriers. Especially > it would hard for the trojan to correctly simulate the behaviour that > occurs *after* your login without knowing your .profile. Ummm, I really am talking about a Trojan Horse, not a spoof; a program can run a shell under your uid within a fraction of a second after it knows your password. ---Dan
bzs@world.std.com (Barry Shein) (09/28/90)
One simple and non-intrusive defense against most such attacks would
be if, on successful login, the system would just tell you how many
unsuccessful login attempts there have been on your account.
This could be accomplished via a database only writeable by root. Of
course, the printout could just be the output of a simple program run
in your login script (itself somewhat secure, reporting only on the
real uid, but that's not so critical as it's the ability to increment
the count or zero it out which must be secure, not just report it.)
Being as most of these programs would tell you you mistyped your
password (after squirreling it away) seeing "Unsuccessful logins: 0"
would indeed be suspicious a moment later. You would change your
password immediately and report it if appropriate.
Such a program would also let you know if someone has been trying to
guess your password (Unsuccessful logins: 123).
Of coure, if they broke into that db then who cares, they have root
access, you're dead meat anyhow.
--
-Barry Shein
Software Tool & Die | {xylogics,uunet}!world!bzs | bzs@world.std.com
Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLDbrnstnd@kramden.acf.nyu.edu (Dan Bernstein) (09/28/90)
In article <BZS.90Sep28014217@world.std.com> bzs@world.std.com (Barry Shein) writes: > One simple and non-intrusive defense against most such attacks would > be if, on successful login, the system would just tell you how many > unsuccessful login attempts there have been on your account. That only defends against login spoofs. (I actually prefer somewhat more information: the current login session number, recent weird activity, and last couple of logins in a readable format like ``two hours ago.'') It does absolutely nothing for the sort of Trojan Horse that we're discussing. ---Dan
mjr@hussar.dco.dec.com (Marcus J. Ranum) (09/28/90)
In article <BZS.90Sep28014217@world.std.com> bzs@world.std.com (Barry Shein) writes: >One simple and non-intrusive defense against most such attacks would >be if, on successful login, the system would just tell you how many >unsuccessful login attempts there have been on your account. This can be done with the trivial addition of a single field to the lastlog file. I did this once, as a lunchtime hack, with a check to see if the counter got over a certain value, at which point the login was disabled until root reset the user's entry. Needless to say, the root login's counter wasn't checked (root uses a secure tty, anyhow). It requires some trivial mods to login, and (unfortunately) breaks compatibility between utmp and lastlog (unless you want useless fields in your utmp). mjr.
lfk@key.key.com (Lynn Kerby) (09/29/90)
In article <1990Sep26.215430.10523@csense.uucp> bote@csense.uucp (John Boteler) writes: > cgy@cs.brown.edu (Curtis Yarvin) claimed: > >You should be able to prevent this. SunOS (and thus likely BSD as well, > >though I don't know) make the first login prompt "<hostname> login:", and > >switch to plain "login:" if an incorrect password is entered. This disables > >login trojans by making them unconcealable. > > Yes, you're right. > > No programmer in the world could possibly defeat this. Actually it should be pretty trivial to defeat, login will accept the user name in argv[1], so the user would never see the difference. Perhaps I missed something in the previous discussion.... -- Lynn Kerby, Amdahl Corporation: lfk@key.amdahl.com or {...}amdahl!key!lfk <<<<---------------------------- DISCLAIMER ---------------------------->>>> <<<< Any and all opinions expressed herein are my own. My >>>> <<<< employer doesn't pay me for my opinion! >>>>
bzs@world.std.com (Barry Shein) (09/29/90)
Dan Bernstein responding to me... >> One simple and non-intrusive defense against most such attacks would >> be if, on successful login, the system would just tell you how many >> unsuccessful login attempts there have been on your account. > >That only defends against login spoofs. Um, that's what we were talking about. But it also warns about a lot of bad login attempts. Both of these are basic and nicely and easily side-step a lot of the much harder defenses people were suggesting. >It does absolutely nothing for the sort of Trojan Horse that we're >discussing. What were "we" discussing? I thought we were discussing login spoofs? It would be easy enough (and certainly not mutually exclusive) to add the other info you mention. In fact, most of the additional info you suggest is already available via the "last" command on most systems and could easily be reformatted in a login script with a shell on-liner (ok, maybe a few-liner, but nothing hairy.) But currently the number of bad attempts at your account is largely unavailable (getty does log it to the console/syslog on some systems, so that might do it if this were universally accepted, just grovel thru a log file.) A lot of it does come down to not fatiguing the one thing all this relies on: The person logging in. It's only useful if they look at the info and think for a moment. I think if a half a screenful of info were spewed at you on every login you'd start to ignore it real fast (maybe not you personally, but most people, how many people seem to have stopped reading the motd on your system long ago? Try putting a line in your motd to mail to you if they read this and see how many actually notice it.) That's why I like, at least, the very short: term = (vt100)? No new messages. 3 bad login attempts since last successful login. % let's see your output. -- -Barry Shein Software Tool & Die | {xylogics,uunet}!world!bzs | bzs@world.std.com Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD
nagle@well.sf.ca.us (John Nagle) (10/01/90)
The "trusted path" approach, as in ULTRIX, is the way to go, but
it does present problems in the presence of dial-up lines, port selectors,
and such. We used it in KSOS (a late 70s vintage high-security UNIX-like
system), but that system was for environments where all terminals were
hard-wired.
We had two paths to the terminal, switched in the kernel. The main
path was used for all user programs. The trusted path was used only by
the "secure initiator", which handled logins and other security-related
functions. Pushing "break" switched the terminal to the trusted path,
and the terminal stayed on the trusted path until the secure initiator
(a privileged application program) made a system call to switch it back.
The user could push break at any time to force this switch, and there
was no way a user program could prevent it.
You can't do it in "getty"; it has to be in the kernel. There
must be something the user can (and must) do that can't be intercepted
by any user program.
John Naglegt0178a@prism.gatech.EDU (Jim Burns) (10/01/90)
in article <20849@well.sf.ca.us>, nagle@well.sf.ca.us (John Nagle) says: > The "trusted path" approach, as in ULTRIX, is the way to go, but > it does present problems in the presence of dial-up lines, port selectors, > and such. Why? -- BURNS,JIM Georgia Institute of Technology, Box 30178, Atlanta Georgia, 30332 uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt0178a Internet: gt0178a@prism.gatech.edu
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (10/01/90)
In article <20849@well.sf.ca.us> nagle@well.sf.ca.us (John Nagle) writes: [ trusted paths ] > You can't do it in "getty"; it has to be in the kernel. There > must be something the user can (and must) do that can't be intercepted > by any user program. No to the first; yes to the second. You can keep the user away from the physical terminal device without changing the kernel. Steve Bellovin's session manager paper elaborates upon this. (Well, his design required a few extensions to System V facilities, but all the necessary features are already in BSD.) ---Dan
jlf@mirsa.inria.fr (Louis Faraut) (10/02/90)
Hello interns !
Here is my little contribution to the logins Trojan issue . It seems
to me that the problem happens because authentication is one-way only,
user -> computer . In the present login protocol, user could possibly
be a bad guy, computer is always "a good guy" . This is clearly a
false assumption :-(
What about a two-ways authentication, modifying the getty program to
oblige the computer to authenticate itself ?
This could be achieved the following way, by use of a secret keyword,
sort of secondary passwd :
- CPU prompts "login:"
- type your login name
- CPU uncrypts your secret keyword and display it on screen .
(Each user keeps up his own secret keyword encrypted in a personal file ;
only the owner and root can read/modify this file )
- CPU prompts "passwd:"
- Now you can either type your usual passwd if the secret
keyword was right, or do anything else possibly aborting the session .
So, is there an easy way to attack this protocol ?
@
, ,, ,,_._.
/ // // Jean-Louis Faraut
/ // //--
// / // // Administrateur Systeme
((_._' ((_._. // de l'ESSI
E-mail : +-----------------------------------------------------+
jlf@cerisi.cerisi.fr | ESSI (Ecole Superieure des Sciences Informatiques) |
jlf@mirsa.inria.fr | Sophia-Antipolis (France) |
Tel. : 93 95 44 37 +-----------------------------------------------------+
Sorry for bad English, I'm French, nobody is perfect :-)brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (10/03/90)
In article <8685@mirsa.inria.fr> jlf@mirsa.inria.fr (Jean-Louis Faraut) writes: > What about a two-ways authentication, modifying the getty program to > oblige the computer to authenticate itself ? Fails. As I've said before, you can't reliably *avoid* a Trojan Horse unless you can reliably *detect* a Trojan Horse. If you don't have a trusted path, the intruder can masquerade as you, forwarding enough of the responses you supply to authenticate itself and then taking control of your account. ---Dan
mikep@dirty.csc.ti.com (Michael A. Petonic) (10/03/90)
In article <8685@mirsa.inria.fr> jlf@mirsa.inria.fr (Louis Faraut) writes: >What about a two-ways authentication, modifying the getty program to >oblige the computer to authenticate itself ? > >This could be achieved the following way, by use of a secret keyword, >sort of secondary passwd : > >- CPU prompts "login:" >- type your login name >- CPU uncrypts your secret keyword and display it on screen . >(Each user keeps up his own secret keyword encrypted in a personal file ; >only the owner and root can read/modify this file ) >- CPU prompts "passwd:" >- Now you can either type your usual passwd if the secret >keyword was right, or do anything else possibly aborting the session . > >So, is there an easy way to attack this protocol ? How about watching over someone's shoulder to observe their "secret" password. >Sorry for bad English, I'm French, nobody is perfect :-) Uh, no comment. -MikeP
cedman@lynx.ps.uci.edu (Carl Edman) (10/04/90)
In article <MIKEP.90Oct3103420@dirty.csc.ti.com> mikep@dirty.csc.ti.com (Michael A. Petonic) writes: In article <8685@mirsa.inria.fr> jlf@mirsa.inria.fr (Louis Faraut) writes: >What about a two-ways authentication, modifying the getty program to >oblige the computer to authenticate itself ? > >This could be achieved the following way, by use of a secret keyword, >sort of secondary passwd : > >- CPU prompts "login:" >- type your login name >- CPU uncrypts your secret keyword and display it on screen . >(Each user keeps up his own secret keyword encrypted in a personal file ; >only the owner and root can read/modify this file ) >- CPU prompts "passwd:" >- Now you can either type your usual passwd if the secret >keyword was right, or do anything else possibly aborting the session . > >So, is there an easy way to attack this protocol ? How about watching over someone's shoulder to observe their "secret" password. Why go to such lengths as watching over peoples shoulders ? Simply 'login' and type the username. Then you get the password. You can even automate this and add a 'secret'(!) password database file to your trojan horse. Nice try, but , of course, is far to easy to circumvent. Carl Edman Theorectial Physicist,N.:A physicist whose | Send mail existence is postulated, to make the numbers | to balance but who is never actually observed | cedman@golem.ps.uci.edu in the laboratory. | edmanc@uciph0.ps.uci.edu
jgreco@archimedes.math.uwm.edu (Joe Greco) (10/05/90)
In comp.unix.internals article <50845@brunix.UUCP>, cgy@cs.brown.edu (Curtis Yarvin) wrote: :You should be able to prevent this. SunOS (and thus likely BSD as well, :though I don't know) make the first login prompt "<hostname> login:", and :switch to plain "login:" if an incorrect password is entered. This disables :login trojans by making them unconcealable. Alternatively, on at least some :SysV machines, you can change the first prompt from the soft underbelly of :"login:" by mucking with /etc/gettydefs (I think /etc/gettytab on BSD is the :same). Well, I whipped up the following in about 15 seconds (thought-time that is): this works very nicely under BSD 4.3. #!/bin/csh echo `hostname` " - Dept of Mathematics - U.W. Milwaukee" echo -n "(tty01) login: " set name=$< echo -n "Password ... if you dare: " set passwd=$< echo Login incorrect exec /bin/login Now, a real program would be written in C, block all signals, turn off tty echo during the password entry... as a matter of fact, you could just get login.c itself and gut it. Then you could even (easily) make it check the password. The ideal trojan would probably wait until a valid user/pass combination was entered before passing off to the Real Thing. It's always a good idea to not log onto a terminal that's already on.... that's the way this kind of stuff is prevented at UWM, for the most part. That's not always possible at other sites. :-( Disclaimer: I am neither a subversive nor an account cracker. I was just showing a practical example to disprove the above statement. ... Joe ------------------------------------------------------------------------------- Joe Greco - University of Wisconsin, Milwaukee - Department of Mathematics jgreco@archimedes.math.uwm.edu USnail: Joe Greco Voice: 414/321-6184 9905 W. Montana Ave. Data: 414/321-9287 (Happy Hacker's BBS) West Allis, WI 53227-3329 ICBM: 43 05 20 N 87 53 10 W #include <witty_and_humorous_saying.h> Disclaimer: I don't speak for the Math Department, the University, or myself.
jgreco@archimedes.math.uwm.edu (Joe Greco) (10/05/90)
In comp.unix.internals article <BZS.90Sep28014217@world.std.com>, bzs@world.std.com (Barry Shein) wrote: : :One simple and non-intrusive defense against most such attacks would :be if, on successful login, the system would just tell you how many :unsuccessful login attempts there have been on your account. : :This could be accomplished via a database only writeable by root. Of :course, the printout could just be the output of a simple program run :in your login script (itself somewhat secure, reporting only on the :real uid, but that's not so critical as it's the ability to increment :the count or zero it out which must be secure, not just report it.) Hold on! Then what point is served? The "printout" would have to be performed by login itself. Having a suid program or some similar "external" program would be useless - it could just as easily be called by a spoofer. ... Joe ------------------------------------------------------------------------------- Joe Greco - University of Wisconsin, Milwaukee - Department of Mathematics jgreco@archimedes.math.uwm.edu USnail: Joe Greco Voice: 414/321-6184 9905 W. Montana Ave. Data: 414/321-9287 (Happy Hacker's BBS) West Allis, WI 53227-3329 ICBM: 43 05 20 N 87 53 10 W #include <witty_and_humorous_saying.h> Disclaimer: I don't speak for the Math Department, the University, or myself.
paj@mrcu (Paul Johnson) (10/05/90)
>In article <8685@mirsa.inria.fr> jlf@mirsa.inria.fr (Jean-Louis Faraut) writes: >> What about a two-ways authentication, modifying the getty program to >> oblige the computer to authenticate itself ? > >Fails. As I've said before, you can't reliably *avoid* a Trojan Horse >unless you can reliably *detect* a Trojan Horse. If you don't have a >trusted path, the intruder can masquerade as you, forwarding enough of >the responses you supply to authenticate itself and then taking control >of your account. > No it does not. What M. Faraut originally wrote was: > - CPU prompts "login:" > - type your login name > - CPU uncrypts your secret keyword and display it on screen . > (Each user keeps up his own secret keyword encrypted in a personal file ; > only the owner and root can read/modify this file ) > - CPU prompts "passwd:" > - Now you can either type your usual passwd if the secret > keyword was right, or do anything else possibly aborting the session . You do not type your password until the computer has given you your secret keyword. The only problem with this is that someone might be looking over your shoulder. There are ways around this, but they start getting too complicated for humans to use: for example the user could challenge the computer with one of a range of keywords to which the computer would have to respond with a corresponding word (eg donald-duck, micky-mouse, brian-kernighan) Computer: Login: User: paj C: Your challenge: U: [no echo] micky C: My response is "mouse". Your password: U: [no echo] secret C: paj logged in at.... This will prevent problems with someone looking over your shoulder on one occasion, but if they can watch you repeatedly then it starts becoming easier. A plain trojan could not make the correct response: all it could collect would be the user's challenge. It would not be able to make the response (unless the villain had managed to deduce the list by prolonged observation) and hence would fail. Paul. -- Paul Johnson UUCP: <world>!mcvax!ukc!gec-mrc!paj --------------------------------!-------------------------|------------------- GEC-Marconi Research is not | Telex: 995016 GECRES G | Tel: +44 245 73331 responsible for my opinions. | Inet: paj@uk.co.gec-mrc | Fax: +44 245 75244
paj@mrcu (Paul Johnson) (10/05/90)
Sorry, forgot to talk about trusted paths in my previous message. If you are worried about physical line security then use encryption. There are ways in which your terminal and computer can authenticate each other. If you are using a public terminal then you need a smart card device to provide keys. -- Paul Johnson UUCP: <world>!mcvax!ukc!gec-mrc!paj --------------------------------!-------------------------|------------------- GEC-Marconi Research is not | Telex: 995016 GECRES G | Tel: +44 245 73331 responsible for my opinions. | Inet: paj@uk.co.gec-mrc | Fax: +44 245 75244
bzs@world.std.com (Barry Shein) (10/05/90)
>Hold on! Then what point is served? The "printout" would have to be >performed by login itself. Having a suid program or some similar "external" >program would be useless - it could just as easily be called by a spoofer. You missed my point. The scenario: Trojan horse or whatever that grabs your password, notes it, reports "Login incorrect" and then cycles the real login program. User thinks s/he just typo'd and enters it again. If there were a program in your .login or .profile, call it logbad, which queried the number of bad attempts and printed something like: 0 bad logins since last successful on Nov 9, 1965 20:06 you would be able to say "hmm, I just got a login incorrect WHY IS THAT COUNT ZERO!!!" Now, I guess the spoofer could walk over to another terminal and cause one bad login to occur. Perhaps a "logbad -l" should be run by hand when suspicions arise which would report the exact time and terminal each bad login occurred (it would be easy to store such info.) This sort of scheme does work, its only flaw is that it relies on a user who cares to think. But there are only a few strange conditions that people would really need to pay attention to (zero bad logins right after a known bad, or dozens of them at any time.) -- -Barry Shein Software Tool & Die | {xylogics,uunet}!world!bzs | bzs@world.std.com Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD
skdutta@cs.tamu.edu (Saumen K Dutta) (10/06/90)
In article <BZS.90Oct5105801@world.std.com> bzs@world.std.com (Barry Shein) writes:
->
->>Hold on! Then what point is served? The "printout" would have to be
->>performed by login itself. Having a suid program or some similar "external"
->>program would be useless - it could just as easily be called by a spoofer.
->
->You missed my point.
->
-> .........
->If there were a program in your .login or .profile, call it logbad,
->which queried the number of bad attempts and printed something like:
->
-> 0 bad logins since last successful on Nov 9, 1965 20:06
->
->you would be able to say "hmm, I just got a login incorrect WHY IS
->THAT COUNT ZERO!!!"
->
->Now, I guess the spoofer could walk over to another terminal and cause
->one bad login to occur. Perhaps a "logbad -l" should be run by hand
->when suspicions arise which would report the exact time and terminal
->each bad login occurred (it would be easy to store such info.)
->
I am wondering what can happen if the trojan program before exiting
or before exec'ing runs a bad login anyway just to make sure that
the user records one bad login. The time will not be much different
for the user to suspect!
--
_ ||Internet: skdutta@cssun.tamu.edu
( /_ _ / --/-/- _ ||Bitnet : skd8107@tamvenus.bitnet
__)_/(_____(_/_(_/_(_(__(_/_______ ||Uucp : uunet!cssun.tamu.edu!skdutta
.. ||Yellnet: (409) 846-8803mjr@hussar.dco.dec.com (Marcus J. Ranum) (10/06/90)
In article <651@puck.mrcu> paj@uk.co.gec-mrc (Paul Johnson) writes: [challenge/password scheme deleted] >This will prevent problems with someone looking over your shoulder on >one occasion, but if they can watch you repeatedly then it starts >becoming easier. Actually, all it takes is once, if the watcher has a decent video camera and a vcr with decent slow-motion. Spiffy computer rooms with big glass windows are especially good targets, if the operator's console is visible. mjr.
meissner@osf.org (Michael Meissner) (10/06/90)
In article <651@puck.mrcu> paj@mrcu (Paul Johnson) writes: | No it does not. What M. Faraut originally wrote was: | | > - CPU prompts "login:" | > - type your login name | > - CPU uncrypts your secret keyword and display it on screen . | > (Each user keeps up his own secret keyword encrypted in a personal file ; | > only the owner and root can read/modify this file ) | > - CPU prompts "passwd:" | > - Now you can either type your usual passwd if the secret | > keyword was right, or do anything else possibly aborting the session . | | | You do not type your password until the computer has given you your | secret keyword. The only problem with this is that someone might be | looking over your shoulder. There are ways around this, but they | start getting too complicated for humans to use: for example the user | could challenge the computer with one of a range of keywords to which | the computer would have to respond with a corresponding word (eg | donald-duck, micky-mouse, brian-kernighan) | | Computer: Login: | User: paj | C: Your challenge: | U: [no echo] micky | C: My response is "mouse". Your password: | U: [no echo] secret | C: paj logged in at.... | | This will prevent problems with someone looking over your shoulder on | one occasion, but if they can watch you repeatedly then it starts | becoming easier. A plain trojan could not make the correct response: | all it could collect would be the user's challenge. It would not be | able to make the response (unless the villain had managed to deduce | the list by prolonged observation) and hence would fail. It reminds of one of the internal systems at Data General back in far more trusting days of yore... At that time, many of the internal systems had a guest account (X.PUB) that had limited rights -- initially normal access rights, later it was only allowed on non-sensitive directory trees. One system decided to change it's X.PUB's initial shell to ask certain DG trivia questions. If you got three right in a row before missing any three answers you were allowed to log on. The triva was things like where is building 14B and the answer was 'webo' (building 14B was at the time where most of the Mass. developers worked, 14A was headquarters). In any case, the questions were selected randomly. Getting back to the above topic, something like this can be used to autheticate a user, providing you have a large enough base of questions (maybe a one time pad...). Where such things break down is other servers like FTP which grant rights to people but don't go through the extra shell. This technique was used for example to break into a system using a privledged account which did not have logon privledges, but was used by the mail system for upding the system databases. After I and others pointed this out, the mail servers were eventually changed to use more secure means of updating records. -- Michael Meissner email: meissner@osf.org phone: 617-621-8861 Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142 Do apple growers tell their kids money doesn't grow on bushes?
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (10/06/90)
In article <651@puck.mrcu> paj@uk.co.gec-mrc (Paul Johnson) writes: > >In article <8685@mirsa.inria.fr> jlf@mirsa.inria.fr (Jean-Louis Faraut) writes: > >> What about a two-ways authentication, modifying the getty program to > >> oblige the computer to authenticate itself ? > >Fails. As I've said before, you can't reliably *avoid* a Trojan Horse > >unless you can reliably *detect* a Trojan Horse. If you don't have a > >trusted path, the intruder can masquerade as you, forwarding enough of > >the responses you supply to authenticate itself and then taking control > >of your account. > No it does not. Let's settle on some terminology here. A login spoof pretends to be login, but isn't connected to the real login program. Barry's solution works here; Jean-Louis's solution works here; even the dumb strategy of putting a hostname before the login: lets the user detect a login spoof. But I'm not talking about a spoof. I'm talking about a Trojan Horse. A Trojan Horse pretends to be a *connection directly to your computer*, but is actually a *connection through a hostile program to your computer*. Read the paragraph of mine quoted above. Challenge sequences don't work against a ``proper'' Trojan Horse. Encryption doesn't work---though it can limit the damage that certain types of Trojan Horses can do. *Nothing works*. Unless every communications link provides explicit verification that you're talking to who you think you're talking to, you *cannot* avoid a Trojan Horse. > A plain trojan could not make the correct response: > all it could collect would be the user's challenge. That's a spoof. Read the paragraph quoted above that you're responding to: I'm not talking about a spoof. ---Dan
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (10/06/90)
In article <652@puck.mrcu> paj@uk.co.gec-mrc (Paul Johnson) writes: > If you are worried about physical line security then use encryption. > There are ways in which your terminal and computer can authenticate > each other. If you are using a public terminal then you need a smart > card device to provide keys. Unnecessary, unnecessary, and unnecessary. This is the flip side of what I've said before. It's actually rather easy to *avoid* all Trojan Horses. All you need is some way to make sure you're talking to the right object---and no intermediate object---on each communications link. Say, for example, that a terminal is connected directly to a terminal concentrator, which has direct connections to ttys of a computer. All that's necessary is that the concentrator and the computer accept some key sequence (such as break) to unconditionally mean ``I want to talk to someone I can trust, so gimme a proper prompt and shove any middlemen out of the way.'' That's it. ---Dan
cgy@cs.brown.edu (Curtis Yarvin) (10/07/90)
In article <21948:Oct606:29:2890@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >In article <651@puck.mrcu> paj@uk.co.gec-mrc (Paul Johnson) writes: >> A plain trojan could not make the correct response: >> all it could collect would be the user's challenge. > >That's a spoof. Read the paragraph quoted above that you're responding >to: I'm not talking about a spoof. > >---Dan Forgive me if I am ignorant. But the problem here seems to be that a trojan is possible at all. In order to be a true trojan (not a spoof), a program must call setreuid(2). Thus its euid must be root. A trojan can do this by execing /bin/login, because login is setuid. But why should login be setuid? Seems to me it only really needs to be executed by getty, which runs as root anyway. Flame me if I am completely confused. -Curtis "I tried living in the real world Instead of a shell But I was bored before I even began." - The Smiths
bzs@world.std.com (Barry Shein) (10/07/90)
>But why should >login be setuid? Seems to me it only really needs to be executed by >getty, which runs as root anyway. Flame me if I am completely confused. you're not completely confused, only a little :-) People run "login user" directly to re-login as another user, similar to using su but killing the previous environment. One good reason for doing this is you want the new environment and logging out/in would drop a modem connection, not uncommon. This gets around this (there are other possible situations, of course, but I figured I'd head off "give me one good reason why...") -- -Barry Shein Software Tool & Die | {xylogics,uunet}!world!bzs | bzs@world.std.com Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD
avg@hq.demos.su (Vadim G. Antonov) (10/07/90)
Hi! I think the problem of login trojan horses has a quite simple solution: 1) There should be UNMASKABLE method of killing all programs reading this terminal. It may be a predefined sequence of characters or a special hardware signal like BREAK or CARRIER DROP. This feature should be hard-coded in TTY driver. 2) All processes, associated with a TTY should be killed (as SIGHUP does) andprotected processes should be RE-ASSOCIATED with an unique TTY-id (which actually does not exist). Each user SHOULD should enter unmaskable sequence before login (I think the login program must check that this seq was entered to force lusers to use it). Seems to me an appropriate hack is about 20 lines in a kernel and getty. Vadim Antonov DEMOS, Moscow, USSR (It is NOT a joke!)
wemmp@cutmcvax.OZ (Peter Wemm) (10/08/90)
Just a thought on all this trojan/spoofing stuff... what about if the
spoffer opens a tty/pty that just transfers characters between master/slave
and the process catches all data passing through containing the lines
'login:' or 'password'. I think it can. That way it could run a fake
getty/REAL login or perhaps even both of the real programs!! It would
be in-detectable except that if the user typed 'tty' they would
be on ttyp? instead of the normal line. Again, this requires physical access
to the terminal or line.
Just a thought.......
-Peter
--
-----------------------------------------------------------------------
ACSnet: wemmp@cutmcvax.oz
ARPA: wemmp%cutmcvax.oz.au@uunet.uu.net
UUCP: {uunet,hplabs,ukc}!munnari!cutmcvax.oz.au!wemmp
-----------------------------------------------------------------------
------- Who me?? That?? No, That is just terminal line noise!! --------
-----------------------------------------------------------------------sarima@tdatirv.UUCP (Stanley Friesen) (10/09/90)
In article <22024:Oct606:35:1090@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >In article <652@puck.mrcu> paj@uk.co.gec-mrc (Paul Johnson) writes: >> If you are worried about physical line security then use encryption. >All that's necessary is that the concentrator and the computer accept some >key sequence (such as break) to unconditionally mean ``I want to talk to >someone I can trust, so gimme a proper prompt and shove any middlemen >out of the way.'' That's it. This does *not* deal with *physical* line security. A *physical* *tap* on the line between the computer and the terminal cannot be bypassed by simple software means. Just because you know that you are talking to login (or whatever) does *not* mean nobody is listening passively on the same com link! For physical line security encryption and physical access restriction are the *only* two possible solutions. -- --------------- uunet!tdatirv!sarima (Stanley Friesen)
libes@cme.nist.gov (Don Libes) (10/09/90)
In article <162@cutmcvax.OZ> wemmp@cutmcvax.oz.au (Peter Wemm) writes: > What if the spoofer opens a tty/pty that just transfers characters > between master/slave and the process catches all data passing through > containing the lines 'login:' or 'password'. I think it can. That > way it could run a fake getty/REAL login or perhaps even both of the > real programs!! It would be indetectable except that if the user typed > 'tty' they would be on ttyp? instead of the normal line. Again, this > requires physical access to the terminal or line. Just a thought....... Here's a short expect script to do exactly this. Just thought you'd be amused. It connects the input and output of 'login' to a tty. Whenever it sees the strings "password" or "login" come from the login process, it begins recording everything up to the next output from the login process. set log /tmp/spoof.log spawn tip /dev/ttya ;# open a connection to tty to be spoofed set tty $spawn_id expect *connected* ;# throw away tip's "connected" msg spawn login ;# open a connection to a login process set login $spawn_id for {} 1 {} { set ready [select $tty $login] for {set i 0} {$i < [length $ready]} {set i [expr $i+1]} { set spawn_id [index $ready $i] if {$spawn_id == $login} { expect {*password* *login*} {log_file $log} \ eof {close $tty; exit} \ * {log_file} set spawn_id $tty } if {$spawn_id == $tty} { expect eof {close $login; exit} \ * set spawn_id $login } send $expect_match } }
boyd@necisa.ho.necisa.oz (Boyd Roberts) (10/09/90)
In article <1990Oct7.155203.13283@hq.demos.su> avg@hq.demos.su (Vadim G. Antonov) writes: > > Seems to me an appropriate hack is about 20 lines in a kernel > and getty. > `Hack' is the right word. Sure, you could `hack' all sorts of mess into the kernel/getty/login but it wouldn't be UNIX. The machine is supposed to allow you to get things done. The kernel should not be cluttered with junk to cope with paranoid end cases. The problem with these `hacks' is that they're more easily implemented than fixing the `problem' the right way. The semantics are always wrong and your 20 line `hack' may well turn out to be a serious problem. Think about the problem. Solve the problem. Code the algorithm. Because it's simple and `cheap' doesn't mean it's right. Boyd Roberts boyd@necisa.ho.necisa.oz.au ``When the going gets wierd, the weird turn pro...''
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (10/09/90)
In article <13@tdatirv.UUCP> sarima@tdatirv.UUCP (Stanley Friesen) writes: > In article <22024:Oct606:35:1090@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: > >In article <652@puck.mrcu> paj@uk.co.gec-mrc (Paul Johnson) writes: > >> If you are worried about physical line security then use encryption. > >All that's necessary is that the concentrator and the computer accept some > >key sequence (such as break) to unconditionally mean ``I want to talk to > >someone I can trust, so gimme a proper prompt and shove any middlemen > >out of the way.'' That's it. > This does *not* deal with *physical* line security. A *physical* *tap* > on the line between the computer and the terminal cannot be bypassed by > simple software means. We're only talking about stopping trojan horses. Not about password security. Nor about login spoofs. It's not my fault that if someone videotapes your keyboard then he gets your password. Can people stop changing the problem here? Under the assumption I made---that each communications line is direct and has some unconditional way to remove any middlemen---Trojan Horses are stopped. There's no need for encryption to solve this problem. ---Dan
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (10/09/90)
In article <1849@necisa.ho.necisa.oz> boyd@necisa.ho.necisa.oz (Boyd Roberts) writes: > The semantics are always wrong and your 20 line `hack' may well turn out > to be a serious problem. Think about the problem. Solve the problem. > Code the algorithm. Because it's simple and `cheap' doesn't mean it's right. Good advice... The problem is to always be able to cut off any middlemen, specifically on a physical tty (really modem) line. There's no good way under UNIX to enforce new access permissions on an object. Once a program is talking to the tty, it has it, forever. Rather than kludging a wimpy vhan---uh, rather than half-as---uh, let's assume that there's no way to get around this. This means that the processes can't be talking to the modem device directly. There has to be an extra level of indirection. Processes are grouped within a ``session,'' which may or may not be associated with a ``connection'' to the outside world. The connection between the session and the modem is controlled by a system program, which drops the connection when it receives a BREAK. That's it! The Trojan Horse problem is basically solved. For full details on how this might be made to work in practice, read Steve Bellovin's excellent session management paper, available from inet.att.com as dist/sessext.ps. If you want a real, working BSD program that implements these security features right now, just ... whoops, promised myself I wouldn't mention it this time. [grin] ---Dan
griffith@eecs.cs.pdx.edu (Michael Griffith) (10/09/90)
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >In article <13@tdatirv.UUCP> sarima@tdatirv.UUCP (Stanley Friesen) writes: >> In article <22024:Oct606:35:1090@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >> >In article <652@puck.mrcu> paj@uk.co.gec-mrc (Paul Johnson) writes: >> >> If you are worried about physical line security then use encryption. >> >All that's necessary is that the concentrator and the computer accept some >> >key sequence (such as break) to unconditionally mean ``I want to talk to >> >someone I can trust, so gimme a proper prompt and shove any middlemen >> >out of the way.'' That's it. >We're only talking about stopping trojan horses. Not about password >security. Nor about login spoofs. >Under the assumption I made---that each communications line is direct >and has some unconditional way to remove any middlemen---Trojan Horses >are stopped. There's no need for encryption to solve this problem. And what, pray tell, guarantees that the line is clear? If the break key clears the line and prevents processes from accessing it, I sure as hell don't want users bumping into the break key and losing processes because they can't attach to the tty file. If it doesn't then my process just goes ahead and does what ever despite the fact that the line is supposed to be clear. If the signal is only recognized when when a process such as getty is running then I just prevent getty from running and emulate the response myself. | Michael Griffith | If I had an opinion it certainly | | griffith@eecs.ee.pdx.edu | wouldn't be the same one as | | ...!tektronix!psueea!eecs!griffith | Portland State University anyways. |
bzs@world.std.com (Barry Shein) (10/10/90)
Wouldn't an uncatchable (except by a root process) SIGTSTOP character
solve a lot of this relatively harmlessly? The only real problem with
such a thing (that comes up commonly) is the ability to put the
terminal back into line mode when the process is suspended (e.g. full
screen applications.)
Or even a character similar to the TOPS-20 ^T command which printed a
line on the screen about session status.
That way you could type ^T or whatever it is and it might echo:
/bin/login (PID=2833) running as UID=0
And, again, ^xyz couldn't be trapped.
I would opt for BREAK soas not to lose another control char. And, even
if you have a noisy line sending some breaks at worst you have to
suffer a few unwanted messages to your screen.
Heck, something like this could even be otherwise useful.
--
-Barry Shein
Software Tool & Die | {xylogics,uunet}!world!bzs | bzs@world.std.com
Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLDbrnstnd@kramden.acf.nyu.edu (Dan Bernstein) (10/10/90)
In article <278@pdxgate.UUCP> griffith@eecs.cs.pdx.edu (Michael Griffith) writes: > brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: > >Under the assumption I made---that each communications line is direct > >and has some unconditional way to remove any middlemen---Trojan Horses > >are stopped. There's no need for encryption to solve this problem. > And what, pray tell, guarantees that the line is clear? If the break key > clears the line and prevents processes from accessing it, I sure as hell > don't want users bumping into the break key and losing processes because > they can't attach to the tty file. Yes, I really do mean ``unconditional'' when I say ``unconditional.'' It's a user interface problem if people accidentally bump into the break key. One solution is to have a harder-to-accidentally-type break sequence. Another is to let the user reconnect to a session later if it was accidentally cut off; pty lets you do this. ---Dan
jlf@mirsa.inria.fr (Louis Faraut) (10/10/90)
Well, I think that the break-driven signaling mechanism is a good way to prevent Trojan login problems, but I'm not yet convinced it does not exist other solutions than those involving Unix kernel/driver modifications or special hardware. The protocol I proposed in my previous posting was of course too simple to work efficiently (many of you have found easy ways to attack it), thus I would like to suggest you a more elaborated scheme to manage the secret key . The challenge is "How could the system display my private key at login while avoiding a bad guy to use this key ?" . I believe I have got an answer . Let's try once again ... Suppose you have a daemon to manage users's key -call it "keyd"- and a program to query the keyd -call it "query"- . Suppose the following scenario (-- introduces comments): Login:foo -- at this point a request is made to the keyd to choose a new key for -- user foo. -- keyd picks a word at random in /usr/dict/words and displays it on -- screen, then it remembers the user/key pair . Password:<something> -- Here, if the person who has typed foo is a bad guy, he does -- not know foo's passwd yet, thus the login fails and a notification is -- made by root to the keyd forcing it to forget the pair -- foo/foo's key and the bad guy has just got an obsolete key ! -- Else, for the good guy, a plain login occurs : -- < login in progress > -- < .profile executing > -- In the first line of his .profile, user foo queries the keyd daemon for -- his key . User foo can check this key against the previous displayed -- key knowing immediately if he has been a victim of Trojan login . KNOWN BUGS: Of course this does not prevent Trojan, you *cannot* stop someone from writing "Login:" on a screen, but it warns you quickly of problems . Also, it is a bit annoying to visually compare both occurrence of your key on screen, but they are some benefits of this protocol (no encryption no driver hacks no special hardware) I'm not sure this can prevent the pty hack (?) -- Thus, should I missed something important here ? If so, please let me know . Thanks in advance . Jean-Louis Faraut (ESSI Sophia-Antipolis, France) English always bad, idea better ?
avg@hq.demos.su (Vadim G. Antonov) (10/11/90)
In article <1849@necisa.ho.necisa.oz> boyd@necisa.ho.necisa.oz (Boyd Roberts) writes: >In article <1990Oct7.155203.13283@hq.demos.su> avg@hq.demos.su (Vadim G. Antonov) writes: >> Seems to me an appropriate hack is about 20 lines in a kernel >> and getty. > >`Hack' is the right word. Sure, you could `hack' all sorts of mess into >the kernel/getty/login but it wouldn't be UNIX. The machine is supposed >to allow you to get things done. The kernel should not be cluttered with >junk to cope with paranoid end cases. The problem with these `hacks' is >that they're more easily implemented than fixing the `problem' the right way. > >Boyd Roberts boyd@necisa.ho.necisa.oz.au I do not understand why such a remedy was not included in vanilla Unix from the very beginning. May be we should fix it for good? Hey, Unix fathers! Anyway it's better than ugly vhangup stuff (at least this syscall can be throwed out). And (of course) if Boyd thinks that 20 lines is 'a hack' he can implement it with very haired security system containing some thousands lines of source code :-) "Keep It Simple, ..." Vadim Antonov DEMOS, Moscow, USSR (It is a joke!)
avg@hq.demos.su (Vadim G. Antonov) (10/11/90)
In article <BZS.90Oct9150046@world.std.com> bzs@world.std.com (Barry Shein) writes: >Wouldn't an uncatchable (except by a root process) SIGTSTOP character >solve a lot of this relatively harmlessly? Most of peoples will not to do it beacuse of laziness... etc. I'm quite sure the protection is effective only when it's unavoidable (but reasonably suitable in use, of course). Thus the system should force the user to pass through security procedure before entering system. (Curiousily, but I've inserted ^T in v6 tty driver, but later I removed it - ps produces more readable output :-) Vadim Antonov DEMOS, Moscow, USSR (It is a joke!)
poc@sun.com (10/11/90)
Vadim G. Antonov <avg@hq.demos.su> writes: > 1) There should be UNMASKABLE method of killing all programs > reading this terminal. It may be a predefined sequence > of characters or a special hardware signal like BREAK or > CARRIER DROP. This feature should be hard-coded in TTY > driver. A simpler solution is this: any non-privileged process writing a BEL (Ctrl-G) to the terminal has it duplicated in the tt output queue, i.e. write (1, "\007", 1); has the effect of write (1, "\007\007", 2); Privileged processes on the other hand do not suffer this modification. Now include a (single) BEL in e.g. the 'Password: ' prompt, y voila! (Maybe you want it optional e.g. only in response to a BREAK). This idea was used in the secure CAP operating system built at Cambridge in the 70's. Credit goes (I think) to Chris Slinn. Patrick O'Callaghan "The secret is to bang the rocks together, folks" Departamento de Computacion, Universidad Simon Bolivar, Caracas, Venezuela
rang@cs.wisc.edu (Anton Rang) (10/12/90)
In article <24752@adm.BRL.MIL> emsca!usb!poc@sun.com writes: >A simpler solution is this: any non-privileged process writing a BEL >(Ctrl-G) to the terminal has it duplicated in the tt output queue, i.e. > write (1, "\007", 1); >has the effect of > write (1, "\007\007", 2); >Privileged processes on the other hand do not suffer this modification. Eesh. Seems like an even worse hack to me. For one thing, every time the computer beeps at me it'll do it twice now. More importantly, the terminal I'm using at this very instant doesn't distinguish a single beep and two beeps in a row, at high baud rates.... Anton +---------------------------+------------------+-------------+ | Anton Rang (grad student) | rang@cs.wisc.edu | UW--Madison | +---------------------------+------------------+-------------+
bzs@world.std.com (Barry Shein) (10/12/90)
Although doubling a magic character like BEL seems clever it has the
problem of requiring all the file transfer programs (uucp, kermit,
xyzmodem) to be modified to deal with this.
--
-Barry Shein
Software Tool & Die | {xylogics,uunet}!world!bzs | bzs@world.std.com
Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLDdnichols@uunet.uu.net (Donald Nichols) (10/14/90)
"Anton Rang says:" > > In article <24752@adm.BRL.MIL> emsca!usb!poc@sun.com writes: > >A simpler solution is this: any non-privileged process writing a BEL > >(Ctrl-G) to the terminal has it duplicated in the tt output queue, i.e. > > write (1, "\007", 1); > >has the effect of > > write (1, "\007\007", 2); > >Privileged processes on the other hand do not suffer this modification. > > Eesh. Seems like an even worse hack to me. For one thing, every > time the computer beeps at me it'll do it twice now. More > importantly, the terminal I'm using at this very instant doesn't > distinguish a single beep and two beeps in a row, at high baud > rates.... > > Anton Not only this, it will also mess up anything that is sending binary data to the terminal (Which may be another computer). If a file is being transferred using xmodem protocol (or any of many others) it will fail when any `007` is doubled, causing the checksum not to match. (Even if it is a text file, there is a good chance that the checksum will be '\007' once in a while.) Also, it will mess up graphics going to some devices like a Tek 4014, or other device that does not use purely printing chars for graphics. (I may misremember, but I think that the Tek does not bias the chars representing plot positions by adding 0x20 to them.) It will certainly mess up any raster graphics being sent to something like a HP Laserjet using a serial port. What about cursor positioning sequences on some terminals? I'm not sure what kind of data is sent to a terminal running x-windows or such, since I don't have access to one to play with. If it can be turned off by ioctl, it is no good against a trojan, since the trojan can turn off the behavior, then simualte it as necessary. If it CAN'T be turned off, it will break the above types of activity. This might be practical in a system running only ONE type of terminal which has been designed or selected to avoid all these pitfalls, and on which NO ONE may connect anything else. (This means no dial-in modem connections either.) -- Donald Nichols (DoN.) | Voice (Days): (703) 664-1585 D&D Data | Voice (Eves): (703) 938-4564 Disclaimer: from here - None | Email: <dnichols@ceilidh.beartrack.com> --- Black Holes are where God is dividing by zero ---
nick@kralizec.fido.oz.au (Nick Andrew) (10/22/90)
jlf@mirsa.inria.fr (Louis Faraut) writes: >Hello interns ! >Here is my little contribution to the logins Trojan issue . >What about a two-ways authentication, modifying the getty program to >oblige the computer to authenticate itself ? So far so good. I have written a modem-smart getty, and I think I'll include an anti-trojan concept of some sort before posting. >This could be achieved the following way, by use of a secret keyword, >sort of secondary passwd : > - CPU prompts "login:" > - type your login name > - CPU uncrypts your secret keyword and display it on screen . >(Each user keeps up his own secret keyword encrypted in a personal file ; >only the owner and root can read/modify this file ) > - CPU prompts "passwd:" > - Now you can either type your usual passwd if the secret >keyword was right, or do anything else possibly aborting the session . BEEP! You lose ... anybody can type your name at the "login:" prompt, so the trojan author will know what to print out when you login. Maybe you meant "type your login name, then your 'secret-keyword-encryption- key'(tm)", and the getty uses the key to decrypt your secret keyword. The caveat with the method is that the user should expect the s-k-e-k(tm) to be compromised if there is a trojan running, but not the user's password (the user detects the compromise and does not type the password). This leads to a meta-problem ... the trojan author can collect the s-k-e-k(tm) from several users and feed them back into the getty program. It seems that the s-k-e-k must be a one-time pad, so the trojan author cannot collect s-k-e-k/response pairs to fool the user. I would suggest a file in $HOME filled with at least 1000 s-k-e-k/response tuples. Each tuple is only usable once. The tuples need not be encrypted - as it is the user doing the verification, I don't see that encryption would be any benefit (see the problem above). But obviously the tuples must be protected. Cheerio, Nick.
nick@kralizec.fido.oz.au (Nick Andrew) (10/22/90)
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >In article <8685@mirsa.inria.fr> jlf@mirsa.inria.fr (Jean-Louis Faraut) writes: >> What about a two-ways authentication, modifying the getty program to >> oblige the computer to authenticate itself ? >Fails. As I've said before, you can't reliably *avoid* a Trojan Horse >unless you can reliably *detect* a Trojan Horse. If you don't have a >trusted path, the intruder can masquerade as you, forwarding enough of >the responses you supply to authenticate itself and then taking control >of your account. Yes, I see what you mean. What if the trojan were basically a filter to a proper getty routine. It could be done in the traditional sense (using pipes user=trojan=getty), or on a multi-line system, the trojan could talk to the author (currently logged in on another line) and the author's system (if it had 2 lines) could call the host on some other line and use the output from the real getty to spoof the fake one! Weird, what a concept! Nick.