Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Encryption Security

SSH Vulnerability and the Future of SSL 290

Posted by CmdrTaco from the stuff-to-think-about dept.
iamchris writes "Growing complacent in regards to security is dangerous. I've become more and more dependant on the SSL-type tools for my security... ssh itself, ssl for my web content, scp, sftp, etc... We all know nothing is 100% secure (or if you don't, God help you). An article on Security Focus cites a vulnerability with SSH and passwords. We usually type them in letter-by-letter. A lot of information can be gleaned from the timing of the keystrokes and some (relatively simple) packet decoding. Is there a better alternative to SSL based tools (Perhaps TLS)? Is there anything that can be done with the clients help with the small packet issue?"
This discussion has been archived. No new comments can be posted.

SSH Vulnerability and the Future of SSL More

SSH Vulnerability and the Future of SSL

Comments Filter:

  • Right... (Score:3, Funny)

    by Anonymous Coward on Wednesday August 22, 2001 @03:10PM (#2204947)
    and even more information can be gleaned from looking over someone's back when they type. Let's be serious, guys. ;-)

    • re: Right... (Score:4, Interesting)

      by Auckerman ( 223266 ) on Wednesday August 22, 2001 @05:05PM (#2205503)
      "and even more information can be gleaned from looking over someone's back when they type. Let's be serious, guys. ;-)"


      Although funny, it does seem to miss the point, which isn't clearly outlined. Picture it this way......


      There are Hundreds of thousands, if not Millions to 10's of Millions of computers out there that use encryption to transmit very important data. Sometimes that data is a trade secret, sometimes that data is Finacial Results that SEC rules say you can't publish yet, sometimes its internal company communication...almost all of which is being sent by Dilbert clones. Sometimes the admin, who may just be a High School teacher (they can't afford admins), chooses to use encryption over the entire network to allow kids to use dictionary passwords.


      Anyhow, rule number 1 of security, the overall security of your network is only as good as your weakest link. So maybe the corporate exchanges within the network are all secure, but an employee on a low profile, unimporatant computer uses ssh to access his personal email and not only that it's a dictionary password, it's just email afterall. Now some clever cracker packet sniffs his email typing patterns, and does a brute force attack on his password...Now all that is needed is patience and one person to send the wrong info to that email account. Not only that, but by reading his email, one might be able to know how the company works and then call up one day and socially engineer important information. This COULD happen and if encryption in general and SSH in particular doesn't immediatly change to prevent this sort of attack, it will happen.


      In the old days, crackers went through the garbage of a target, before attacking it. (Hell, that is still done.) Now a days, the word "garbage" means different things. It could be a note to a family member that the boss is out of town for the weekend, that the company is moving to Linux next week or maybe even a Dilbert protype emailing himself his own password to the corporate network. At anyrate, this kind of thing is a bit more serious than it sounds at first glance and should be fixed immediately.

      • "Their second weakness is that in an interactive mode, each keystroke that a user types is sent to a remote machine in separate IP packets immediately after the key is pressed. According to the researchers, this leaks the inter-keystroke timing information of the users' typing."


        (from the Securityfocus article)

        I see how packet capturing could lead to a vulnerability in this. What I *don't* see, is why in the HELL anyone would want to send each letter of the password in a single packet!! I don't see any security benefit to it, and it would seem to make cracking the password slightly easier. It would seem that sending your entire password in one chunk would be more secure.

        Can anyone explain to me WHY ssh would do this?

        -Kasreyn
        • Because interactive shells always send individual keystrokes (until Nagle makes them batch up). That's why they're interactive.

          Remember, they're not referring to the password used to establish the SSH session. They're talking about passwords entered during the SSH session.

          Give the SSH people some credit. :-)
          • I thought everyone was making such a fuss because one could sniff the timing on the SSH session password. Any other passwords you send while connected would seem likely to be more secure to me, since an interceptor would have to first figure out which part was a password, and which part was just text and command line entries entered during the session. ("Hey, I've got it!! His password's 'pine-iqylogout'!!") =P

            -Kasreyn

  • SSH2 and Public Key Authentication (Score:4, Informative)

    by undie ( 140711 ) on Wednesday August 22, 2001 @03:11PM (#2204950) Homepage
    If you use SSH2 protocol and Public key authentication only, you're no longer vulnerable to the password-guessing or Monkey-in-the-middle attacks as they exist today.

    • If the SSH client generates a tinygram for each character entered in the password, it would seem a simpler fix would be to buffer the entire password and only send it once the user hits Enter/Return/whatever. Instead of x tinygrams for an x-character password (more if you need to fix a typo), you would have just one with the entire password. Making all packets with passwords the same size (fill the dead space with noise) ought to help. You still can't do much to protect keystrokes once the session is going...using vi/emacs/trn/etc. in line-buffered mode would suck. Still, it would make passwords a little more secure.

      (Then again, the above could be completely off-base...I do graphics software, not security software. :-) )

  • The best way I can think of is to use the RSA key authentication method. A RSA key pair is used to authenticate, rather than a password. This way, the password is never typed over the network connection.
    • Argh! This has *nothing* to do with ssh password authentication. It's about typing passwords via ssh after the connection is established. Ssh2 does have a 'keyboard-interactive' mode of authentication, but it's the least preferred so it doesn't get used much.

      Try running tcpdump to capture a password-based ssh login. You won't see one-packet-per-key unless you happen to be in that unfortunate keyboard-interactive mode.

      Ssh password authentication does not leak timing information.

  • TeraTerm (Score:2, Insightful)

    by Hyperbolix ( 214002 )
    Teraterm (available for free download here [vector.co.jp]) has several SSH extensions. I beleive one of them has you type in the password all at once and then sends it as a single string, which means that key timing can't be determined. Just my 2 cents.
    - Hyperbolix
    • Bad idea. Last time i checked TTSSH was still SSH1 only, which is prone to man-in-the-middle attacks.

      There are lots of script-kiddie tools which can do this, even over a switched LAN etc. Better dont use SSH1.
      • Bad idea. Last time i checked TTSSH was still SSH1 only, which is prone to man-in-the-middle attacks.

        I use PuTTY (which supports SSH2) if I need to access stuff on the Linux server at home, but I'm currently using TTSSH to do VNC-over-SSH to access a Win2K workstation behind the server. I know SSH1 has its issues, as you mention...but is there an SSH2 client (preferably at least "free as in beer") for Windows that does port forwarding? I'd rather not give the schmucks who closed off the original SSH my money if I can avoid it. PuTTY is good (small enough to suck down from my server to a remote computer if I need it), but it doesn't do the port forwarding needed to get VNC to work.

      • SSH2 is also vulnerable to MITM attacks if you don't know the server key or key fingerprint. OTOH, if you do have the server key, then in SSH1 clients (such as TTSSH) a MITM attack will trigger a warning that the "host key has changed". In TTSSH the default option in such a situation is to disconnect.

        SSH2 doesn't have any magic that makes PKI easy. Anyone who tells you otherwise is trying to sell you something.

    • I think that most Windows terminal emulators have similar functionality. It seems like a very simple step to take to help preserve passwords. I also find that it's convenient because I like to use a long password and it's easier to correct mistakes that way.

      That still doesn't invalidate the general comment, though, which is that SSH and similar protocols are still subject to traffic analysis. Padding with null information, deliberately introducing some timing jitter into keystrokes being sent, etc. can certainly help in that regard. The big thing to remember is that security is relative; you can always find some way of making it a little bit better.

    • don't most GUI terminal packages (including MacSSH, etc) all send it as a single string (SecureCRT)?
  • Sooner or later someone will patch an SSH client
    to go to linemode, where the client sends only
    one packet for each section of the session
    between carriage returns.

    Problem solved.
    • Sooner or later someone will patch an SSH client
      to go to linemode, where the client sends only
      one packet for each section of the session
      between carriage returns.

      Thats fine for the comand line, but it doesn't work so well for interactive editors.
      • Let the user choose to toggle line-at-a-time mode
        with a hotkey on the ssh client side. Just say in
        the manual - your password will be more secure if you type ctrl-meta-dingbat-thwirble-whoops-wheres-my-thribb le before your password, and then again afterward.

  • So what? (Score:4, Insightful)

    by Reality Master 101 ( 179095 ) <<moc.liamg> <ta> <101retsaMytilaeR>> on Wednesday August 22, 2001 @03:13PM (#2204963) Homepage Journal

    The article pretty much says that keystroke timing can help increase the efficiency of dictionary searches.

    Big deal. If your paswords are vulnerable to dictionary searches, then you have bigger problems than keystroke timing vulnerability.

    This sounds like a non-issue to me.

    • It also says that it can be used to guess the lenght of the password, which could make a brute force MUCH quicker

      • No it wouldn't.
        Brute force would try shorter passwords first. Assuming passwords match \w+, that's 63^letters^. If you check letters-1 passwords first, you've only wasted 1/63rd more time than if you knew the length (well, 1/63 + 1/(63^2) + ..., but that's tiny).

        Besides, it's trivial to modify SSH clients to check for password prompts and obscure password timing and length (add in backspaces...).
      • The article says:
        The researchers studied user dynamics and determined that the timing information of the keystrokes leak information about the key sequences typed at about 1 bit of information about the content per keystroke pair. Because the entropy of passwords is only 4-8 bits per character, this 1 bit per keystroke pair information can reveal significant information about the content typed.
        So, let's say you have an 8 character password now. That's 7 key pairs (1-2, 2-3...7-8). So, you lost 7 bits of "randomness" in your password. Add two more randomish characters, and, assuming that you get 4 bits of entropy per character, you're now better off than you were before. And the brute force is now harder than it was before this attack was considered. 10 characters isn't that much worse than 8.
  • It can't be easily used to guess a password. Using a Dvorak keyboard would defeat it if they thought you were using querty, and vice versa. So would putting a timing loop with a good randomizer in the packet transmitting code. Unless you're trying to keep your data safe from the NSA/GCHQ there's little reason to worry.
  • A lot of information can be gleaned from the timing of the keystrokes and some (relatively simple) packet decoding.


    Well, if you use RSA you don't need to type a password so that would solve that particular problem. But if you really want to be paranoid about it, the technology exists to capture your keystrokes. I believe it works by detecting the charge released from depressing each keystroke(the keyboard uses capacitance to send specific characters if I'm not mistaken). So you really need to work behind lead walls or something else that will block that signal from being transmitted.


    Again, using RSA would prevent the password from being transmitted. But they could just keep listening, and gather sensitive data as you type away.

    • Well, if you use RSA you don't need to type a password so that would solve that particular problem.


      Just to be clear, you should use a password with RSA keys (otherwise, for instance, root on the system that has your RSA key can impersonate you on the remote system). However, as I understand it, the password used is used to decrypt the RSA key prior to use, and then the decrypted RSA key is used. So yes, it should protect against this (very theoretical) attack.



      But then, you were already using RSA keys so that knowing your password on the remote system wasn't sufficient, right?



      As an aside, I've found that those cute little credit-card CD-ROMs are excellent for storing your RSA key, and they're usable with just about everything but TiBooks and iMacs - and with the extra space, you can keep known-good SSH binaries for Windows, Mac, and any Unix systems you commonly use on there as well.

  • Instead of password auth, use something like s/key, so it really won't matter if the evil cracker gets:

    SEWN LULU PIN HOUR PRY YEAR

    OpenBSD [openbsd.org] supports s/key right out of the box, which is spiffy. Or use Public Key authentication, expensive crypto cards, or any of the other alternative authentication techniques out there.

  • complete non-issue (Score:2, Interesting)

    by Ender Ryan ( 79406 )
    While entering passwords, simply type with 1 finger, and randomly pause between each keystroke.

    But if you need to worry THAT much about security, then I'd assume you have much bigger problems than that to deal with, such as the FBI or CIA or whoever it is going to such great lengths to figure out your password...

    • Humans aren't very good at "random" typing. Instead it is much better to type to some rhythm. I personally like "Shave and a hair cut TWO BITS" repeated over and over again. But hat is mostly because it scares the other people in my office when they hear me sing.

      Scaring your co-workers is an important part of any decent security scheme.

    • Select a password over 7 characters in length, using mixed case, both characters and numbers ... oh yeah - and pause between each character entered.
  • If you are using key based authentication then they are going to need more than just your password.

    As I understand it, the password just allows you to decrypt the private key w/ a symmetrical cipher. Then the connection is encrypted w/ the public/private key pair. This means they actually have to have physical acess (with read filesystem permissions) to the private key as well as the password.

  • When I connect to a remote box from Windows, I use the free ttssh [zip.com.au] extension to the freeware terminal program Tera Term [vector.co.jp]. When it asks you for a password, it captures everything in a dialog box, and sends the password as one chunk.

    For those using a command-line version, who are really paranoid, you can just vary the rhythm of your strokes (type along with your music!). Or use RSA authentication. :D

    But in general, I don't think anyone needs to worry about this unless they've got a bulls-eye on their backs.

  • Include some control characters in your passwords... For a start, none of your script kiddies will be able to figure out how to type a ^V character. Secondly, it screws type speed typing. Thirdly, a few control characters (Ctrl+C, and NULL?) are impossible to send from many Windows clients. Security through impossible passwords :)

  • In terms of security, there are some things that *are* perfectly secure. The one-time cipher is an example of this. Unfortunately, the pad of keys must be synchronized at either end of the communication -- and of course you can't transmit these, so practically-speaking, it's not really an option.

    There's a neat document outlining "snake-oil" signs in encryption software here [interhack.net].

  • a friend of mine used to include backspaces in his typing of his password (on purpose, not just because he typed with 2 fingers).
  • The best thing to do is a security audit, you need to determine whether or not you are really vunerable, or if you are a target. We have learned time and again, that security cannot depend on a single method or product. If you only depend on a firewall, and it gets hacked, you are toast. Conversely, if you are using SSH with passwords, and your passwords are weak, then what it is the point... If you really are concerned a great deal about security, you need a multi-tiered approach, where the goal is to minimize risk, you can never get rid of it, with out pulling the plugs.
  • Just for the record, SSH and SSL are unrelated, i.e. SSH is not implemented over SSL.
  • I would think that unless you are a terribly slow typist that the NAGLE algorithm in TCP would defeat packet sniffing and analyzing the timing of the keystrokes.

    For thos who are wondering what nagle is, it's an algorithm that helps TCP avoid sending a packet for every key stroke on telnet connections among other things.
    • I would think that unless you are a terribly slow typist that the NAGLE algorithm in TCP would defeat packet sniffing and analyzing the timing of the keystrokes.


      Yes, but the SSH server may have been compiled
      with the NAGLE algorithm explicitly disabled, or
      (with SSH2 at least), it can be disabled at run
      time in the
      config file with the NoDelay keyword.

  • "A lot of information can be gleaned from the timing of the keystrokes and some (relatively simple) packet decoding"

    This can be avoided by altering your key timing. How do you do this? Don't use a Qwerty keyboard :P Sense I've switched to a Dvorak key map my finger movements have been diminished by >60%. This change in finger movements has got to also translate into different keystroke timings.

    Takahashi
  • A lot of information can be gleaned from the timing of the keystrokes and some (relatively simple) packet decoding.

    So, take the time to learn Dvorak. You'll save minutes each day in typing, and you're hands will feel better, and it should effectively screw up any timing-based password sniffers!

    Quick dvorak "graphic":
    ' , . p y f g c r l / = \
    a o e u i d h t n s -
    ; q j k x b m w v z

  • if you use a set pace pausing between each keystroke of password entry, no keystrokes can be discovered!

    RickB
  • I think the best way to avoid this sort of password cracking is to somehow impair your motor skills.


    This is why I always type drunk.


    Ratguy

  • Well, while maybe a vulnerability, I don't see it as an issue. When I type what I'm thinking, i.e. passwords, code, etc, it almost doesn't matter what it is, my fingers know where to go and usually in about the same speed as any other word.

    Anyways, even though I might not care, others might. Well, for everyone else, the solution seems pretty simple to me. Have the client read the whole password, then send the response to the server. Now, no matter how slowly you type, as soon as the client gets the password it'll zip it away as fast as possible.

  • I think this applies only to passwords typed during an SSH session, not the password during the authentication phase. As far as I know, during password authentication the password is collected and sent as a single unit, not character by character. Finding information about passwords by watching character timing's not a new attack, and there's one major problem with it: during an encrypted session, how do you tell when the user's typing a password, as opposed to moving around in an editor or something?

    • during an encrypted session, how do you tell when the user's typing a password, as opposed to moving around in an editor or something?


      Because when you type in a password (using su, anyway), echo is turned off. su has a fairly strong signature. Command prompt received, two characters sent and echoed, another character sent, then 11 characters (or so, CR+Password: ) sent, then characters being sent without any echo. Surely you could sniff that with a fairly high hit/miss ratio.

  • Defeat the nagle-disabling, and use public keys! (Score:5, Informative)

    by Kaz Kylheku ( 1484 ) on Wednesday August 22, 2001 @03:34PM (#2205066) Homepage
    The measurements of keystroke timing can be done on a broad, high-latench internet only if the Nagle algorithm is disabled. Some SSH implementations defeat the use of Nagle, in order to provide better interactive response. This can be taken out in the source code (or maybe with a configuration parameter: I'm not familiar with all SSH implementations).

    When you have Nagle enabled, your keystrokes are aggregated into larger packets, because the next packet is not sent until an ACK for the previous one is received---or you type enough to send a full segment. Or something like that; I leave it to the reader to verify the details of Nagle. In any case, it's clear that Nagle can obscure the timing of individual keystrokes if the latency is high enough to cause aggregation of several characters into one packet.

    Secondly, if you use public key authentication, then you won't be typing your SSH password over the network. Of course, other sensitive information may be typed, such as passwords to other systems logged into within the SSH sessions. But the SSH key itself can't be compromised by this timing attack.
  • When you can break into their house and install a keyboard bug? As has been noted, RSA is the way to go, at least with SSH authentication (I do DSA with OpenSSH.)


    But when you come right down to risks, passwords are well and good until the information that's password (or passphrase) protected is worth a lot of money to someone or is incriminating to someone else or something like that. You can extract a lot of information from a person with a pair of needle nose pliers. Or the bolt cutters. Cut off a fellows' big toe and threaten to do other body parts. How many here would last even one more toe? Security is relative. Your live goat porn collection is probably pretty safe. A Mafia Don's financial records probably aren't. Especially if the Godfather thinks said Don has been crossing him...

  • Sounds very tricky to me. What if I was typing with one hand because the other is busy? The timing algorithm would not be able to figure this one out.
  • It's a research paper that exposes a vulnerability and the fixes to deal with it.

    Don't get upset, get used to it. Expect to see of these in the coming millenium.

    BTW, keystroke timing is a pretty old attack. In the past, it's been used for two basic operations: One, who is it? and two, what are they typing.

    Everyone has a distinct typing style that can be used as a fingerprint to identify them. If you have an audio recording of someone typing, and a database of recordings of typists with access to the machine, you can figure out which person was at the keyboard.

    The more difficult problem is discovering what was typed, but with a little thought and analysis, you can probably get a good idea.

    This vulnerability decreases the time for a dictionary search by about a factor of fifty. Congrats to the researchers for exposing this weakness.

  • An extreme technique (Score:5, Informative)

    by jd ( 1658 ) <imipak@yahoGINSBERGo.com minus poet> on Wednesday August 22, 2001 @03:54PM (#2205152) Homepage Journal
    A technique I developed for a company I worked at previously was -reasonably- secure. (NOTE: "Reasonably" is entirely subjective, but being paranoid, I'm fairly sure it isn't too bad.)


    The technique was as follows:


    Person A logs into the client, using a username/password pair. The client then generates an RSA keypair, using hashes of the username and the password as seeds for the random number generator.


    The client then contacts a key exchange server. This takes the client public key and the server public key, generates a fresh set of keys for both client and server, encrypts them using the appropriate public key, and sends the keys back as appropriate. (eg: The client gets the client's private key and the server's public key.)


    This establishes the link between the client and the server. Each then generates a secret key, using one of a selection of algorithms. (I used Serpent and Rijndael). The secret keys are then exchanged, using the public keys.


    The client then uses the original username and password to connect to a Kerberos server, for a ticket.


    Only at this point is data allowed to be exchanged between the server and the client, and only for the duration authorised for that ticket.


    After random intervals, the secret keys are regenerated, though not necessarily with the same algorithm as before. The new keys are again exchanged with the public keys.


    Once the Kerberos ticket expires, the public and private keys are replaced, using the key server. Once the keys are replaced, the Kerberos server can be contacted to refresh the ticket.


    The reason for this amazingly convoluted system? I wanted a system that could run on an untrusted network, with an untrusted client AND an untrusted server.


    The challange was to devise a system that provided sufficient checks that a compromise at ANY point would not yield useful information.


    In practice, that's very hard to do. Compromise the database, and you have the data. There's not a lot you can do about that. Compromise the front-end server, and you can mimic anything. Again, there's not a lot you can do to stop that.


    The way I approached this (and PLEASE remember that this is NOT my field, and others will have vastly superior techniques) was to insist on all data, at both ends, being encrypted as far back in the system as possible, using keys with very limited lifespans.


    The idea here is to reduce the window of opportunity by as much as possible. The idea of using multiple algorithms, public-key encryption, etc, was to soak-off as much of the window as possible with trying possibilities out.


    (Note to non-Wargamers: Soak-offs are where you use a trivial piece to divert a much more significant piece of your opponent, so that you can defeat what's left with relative ease. In this case, I used the "trivial" problem of picking the right algorithm to soak-off the processing power of the opponent. My "main forces" (encryption, intrusion detection, etc) could then walk right over whatever was left.)


    Wargaming and computer security, IMHO, are very closely related. However, legal issues prevent me from applying my favourite tactic in "Squad Leader" and "Advanced Squad Leader" -- steamroller one flank, setting fire to everything behind me so I can't be encircled. I'd love to see a Black Hat vs. 3 stacks of 3 x 8-4-3's with HMG's, and a 10-2 leader, but I suspect that would be considered excessive by The Powers That Be.


  • to be REALLY paranoid, I'd like a terminal client that waited for the enter/return key to be pressed before sending the packets - collect each command locally and only transmit upon completion. BUT the actual keypresses shoudl be immediately encrypted as they are typed in RAM - so there is never a plaintext version of the password (or in factm anything you type!)

    I think Stephenson invented this idea in Cryptonomicon - it was secureEmacs or something like that...

  • ssh compression (Score:2, Informative)

    by NynexNinja ( 379583 )
    using compression (ssh -C) will increase entropy in traffic analysis attacks against ssh.

  • Saying this is a vulnerability in ssh is like saying PGP is vulverable because someone can brake your fingers until you give them the key.
    Or calling any security system vulnerable because if someone sees you type the password, that can 'crack' the security.
    Also, it seems to me you would have to know a lot about the person typing the password.Everything from typing speed, to state of there mind at the time of typing the password.

  • This is a serious attack (Score:2, Informative)

    by rtj ( 36746 )
    There seems to be some confusion as to the nature of this attack on ssh. Some facts may be enlightening:

    I am not one of the authors. Everything I write here is the result of informative discussions with Dawn Song, one of the authors on the ssh paper.

    All ssh implementatons send your password in one packet (when using password authentication). However, if you ssh from A to B, and then from B to C, the fact that your password is sent from B to C in one packet isn't helping you a whole lot, since it was sent one character at a time from A to B. Using RSA authentication doesn't help, since you have to enter a password to access the key stored on B. This password will be sent one character at a time from A to B. This multihop ssh-ing is a common practice, so this is a serious threat.

    Sombody else claimed that it was only effective against passwords which were susceptible to a dictionary attack. This is a non-sensical statement. The best way to describe what the attack does is in terms of bits of information gained, but I'll simply say that, with this attack, you usually only have to search about 1% of the possible passwords to find the right one.

    Others have suggested using one finger to type, or using a dvorak keyboard, or deliberately typing in a random fashion. Using one finger or typing randomly will work. However, a dvorak keyboard would only change the keyboard model. The attacker could still perform the same attack, but using that model instead of the qwerty one.

    As for remedies, inserting random jitter in ssh is not effective. By watching several logins, an attacker could average out the jitter to get the real timings. Changing ssh to send packets at regular intervals, or using line mode, will eliminate all timing information.

    Although this attack was presented in terms of gathering passwords, it's also effective (perhaps even more effective) for recovering english text. In fact, the information recovered is about 1.2 bits/keypair, and english only has about 1.2 bits/letter of entropy. So in essence, because of this attack, YOU SHOULD CONSIDER SSH TO BE EFFECTIVELY EQUIVALENT TO NO ENCRYPTION AT ALL. You should not make light of this attack unless you would be willing to use telnet.

    Somebody also said that this was extreme paranoia because one could just park a tempest van outside your window to get the text you type. But tempest vans are expensive and hard to operate. Breaking into routers is easy. This attack could easily be scripted, but I know of no tempest-van scripts in wide use. So the threat here is tremendous.

    The best solution is to randomize your typing until ssh is modified to send packets at regular intervals.

    Best,
    Rob
    • YOU SHOULD CONSIDER SSH TO BE EFFECTIVELY EQUIVALENT TO NO ENCRYPTION AT ALL.
      Well, not exactly. See, I don't really care if people can recover the English text that I type in an ssh session, since it's generally email which will be sent out unencrypted anyway. But I do care that they don't recover my password. And since my password isn't English, it has more than 1.2 bits of entropy per character. (let's see, upper+lower+num+puct... about 6 bits per character).

      So while I wholeheartedly agree with you that this is a serious attack, I don't agree that it reduces the security of ssh to that of telnet.

    • One question, though: how do you determine which packets in the session are part of a password? And if you can't do that, how do you decide which timing information is to be used in breaking a password?


      Seems to me this is not exactly a trivial job, and makes the attack fairly useless except in special situations where the attacker has knowledge of the exact sequence the user will be following.

      • how do you determine which packets in the session are part of a password?

        Not too hard, provided you limit your attack fodder to newly initialized SSH sessions.

        If user logs in from A to B, then starts a new session to C, you can tell that session started because you see the initial traffic from B to C's port 22.

        It's not that hard to then time all traffic from A to B's port 22, until such time as another packet (the complete password) goes from B to C's port 22. And as a bonus, you know that last packet from A to B/22 was enter, so you can use that in your timing.
    • Here are my problems with what you say:
      1) If your passwords are dictionary crackable you have problems even without keytiming sniffing. You can crack a dictionary password using the WHOLE dictionary in less than 10 seconds, why should eliminating 95% of the keyspace be that valuable in this case?

      2) If your passwords are not dictionary crackable than the keyspace is HUMONGOUS and eliminating 99% of that keyspace (multiplying by a constant) will leave you with another HUMONGOUS keyspace. Multiplying by constants is never a good way to reduce keyspace size, even if it is .01 (1%).

      3) No, one-handed random blindfolded two-finger backwards DVORAK standing-on-your-head typing will NOT help. NO ONE WILL DO IT.

      4) No, this is not as horrible as Telnet. A VERY VERY small percentage of people that might be sniffing your network have the skills, motivation and time necessary to analyze your keystroke timing and use that information to any useful extent.

      5) Yes, random jitter WOULD be effective. Random jitters don't even come close to averaging out to the real timings unless someone sits there and types there password over and over for several thousand iterations.

      Now, for unrelated points of interest:

      Anyone that types with any sizeable ammount of speed will not show enough difference in keystroke timings for it to be helpful in any useful way. And I would guess that most people that SSH on a regular basis are pretty good touch typists.

      Fine, sending packets at regular intervals, and, more importantly, grouping keystrokes together, is a good solution. However, the situation is not nearly as dire as you would have us believe.

      Justin Dubs
  • "It exposes partial information about passwords, but the whole point of using SSH is that you don't need to authenticate through the firewall with passwords, so attackers

    have no launch point," adds Rose.

    Login is not the only application of passwords. Many people enter passwords for su or sudo. Such passwords are vulnerable to this attack, in the sense that it would make it 50x easier to crack a stolen password file.

  • Typing (Score:3, Funny)

    by Swaffs ( 470184 ) <swaff AT fudo DOT org> on Wednesday August 22, 2001 @04:20PM (#2205247) Homepage
    "We usually type them in letter-by-letter."

    I usually just mash the keyboard with my fist in one shot. Sure, it takes a little longer than normal typing to get the right password, but no one's going to be guessing MY password.

    • I usually just mash the keyboard with my fist in one shot. Sure, it takes a little longer than normal typing to get the right password, but no one's going to be guessing MY password.

      I just cut and paste my password from a text file - good luck trying to glean information out of the keystroke timing, guys!
  • The problem isn't really the SSL based tools, so much as the fact that they do a lot to help you but they don't make it impossible to do traffic analysis. The security focus writeup refers to a much longer paper [openwall.com] on the subject, and though that paper is specifically about SSH (and password guessing, and guessing at the commands you're entering over a secured session), the authors also note that:
    It should be noted that, despite their simplicity, traffic analysis attacks such as those presented in this advisory haven't been well researched. We expect that similar attacks are possible against most other "secure" (encrypted) remote login protocols. We also expect additional traffic analysis attacks on SSH to be discovered. In particular, there may be recognizable patterns in X11 connections forwarded over SSH, but these are out of the scope of this advisory.

    So in other words, the strategies they describe here for attacking SSH could be equally effective for most any asynchronous network protocol where you could try to infer information from the rhythm of the rate of data transfer. Further, there is ultimately no general solution, only incremental defenses against the general strategy:

    Solving traffic analysis vulnerabilities not related to password information would increase the protocol overhead significantly, and thus doesn't seem practical for many current uses of SSH.

    So, as is often the case, if you want perfect security you can only have it at the expense of tremendous overhead, and ultimately you have to decide how far you want to take your defense against chaos theory before deciding that you just have to accept a certain degree of risk. Ultimately, there is no defense and you always have to accept that risk.

  • SSH public keys (Score:3, Insightful)

    by MSG ( 12810 ) on Wednesday August 22, 2001 @04:30PM (#2205299)
    I'm preparing a contribution to policy where I work which includes several stipulations on the use of SSH.

    First, password authentication should be disabled, in favor of public key authentication. Second, only encrypted private keys are allowed for login sessions; an ssh agent will be recommened to minimize the inconvenience of repeatedly typing pass phrases. *Long* pass phrases will be recommended. (Note that you can't actually enforce the last two, they're just a matter of procedure.) In cases such as automated scripts which can not use encrypted private keys, a key pair will be generated *for each task*. The public key, when installed, will have the command specified so that the key pair can be used to execute *ONLY* one command.

    In addition, all authorized public keys will be kept in a document on an HTTP server. A cron job (python script) will run at least once a day to fetch that list, and compare all of the private keys installed on the system to the authorized list. Any key which isn't in the master list will be removed from the system, and the network admin will be alerted.

    Maybe similar procedures would benefit others. Does anyone see holes in this procedure?
  • ....is to use the dvorak keyboard. Or another alternative configuration. Or probably hunt-and-peck typing would be ok too. Or don't type in english (japanese?). Or use speech recognition. I did not read the research report, but herbivore apparently works by constructing a detailed model of an individual's typing patterns. They can probably get pretty good at cracking an individual's password, if they have a really good model of that individual's own typing. It would probably generalize OK from one touch-typist to another, if they were typing in the same language, keyboard, etc. But, anything that mixes up the transition probabilities, and/or Herbivore's mapping of keys onto letters, will probably increase its cracking times to be greater than brute-force search, because you are providing it with 'misleading' information. And by entertaining more than one model, (e.g., QWERTY/ DVORAK, ENGLISH/FRENCH/JAPANESE/GERMAN, TOUCH-TYPING/HUNT-AND-PECK, ETC),its efficiency would be reduced, maybe to the level of brute-force search if the attacker knew nothing about his target.

    Probably, a lot of the gain in cracking efficiency is due to simply the character transition probabilities (e.g., 'q' is almost always followed by 'u'), independent of their timing. In that case, simply obfuscating the timing might not help all that much.

  • SSH sends the whole password at once (in SSH 1.2.31, sshconnect.c, lines 1786-1794). The issue is when you are typing something over an SSH connection. At this point, each keystroke (approx) gets sent in a separate packet to the machine you're connected to. So an attacker gets ~1 bit of info/character as you type.

    If the attacker knows when to look, they have some chance of guessing a password you type over an SSH connection, either for the next hop, for su, or for something else like that.

    In the case of connecting to a 3rd host, they get tipped off as to when to look by the 2nd connection; you form the 2nd connection, and then type your password over the 1st connection. Note that this attack requires that they detect both connections, and make timing measurements on the 1st one to get the password on the 2nd.
  • Is the password prompt on SSH actually a two-way connection? I always thought that the client buffered up the password, and then sent it in a single packet. That would help with some SSH connections (just connecting from one to another), but not when you connect to one system, then jump to another, and another.

    Secure connections could send random amounts of null data at random times. To make it a lesser bandwidth problem, only have this excess data be produced when the client is sending stuff (ie, keep sending junk for a few seconds, then go quiet until the next keypress). It wouldn't be recommended for slow connections (like with modems) though..

    Also, you could try to use different keyboard layouts (dvorak or other) to make it harder to guess what key is being pressed at a particular time.

  • It's easy to say that, I know, but it's true. :-)

    When I first started using ssh, I thought of this. I mentioned the idea as a security vulnerability to a friend, and he dismissed it. I should've written it up, but I felt I should do tests first.

    A good way to defeat this is to have ssh send packets every tenth of a second unless it hasn't gotten any data to send in more than 15 seconds, or if it has a lot of data to send. In the first case (no data for 15 seconds) it should stop sending, and in the second case it should send as soon as it has x (where x is probably something like 256) bytes of data to send.

    This will add latency, up to a whole 100 milliseconds worth, but that would greatly reduce the problem.

  • Geez, the makers of these unix products are so stupid. When asked what they were going to do about this vulnerability, they responded that they were going to try to do what they can to increase the computational infeasibility of this security hole. Just like those unix people to resort to security through obscurity, as always.

  • Not about login password (Score:5, Insightful)

    by crucini ( 98210 ) on Wednesday August 22, 2001 @05:46PM (#2205717)
    This is not about intercepting the ssh login password. It's about interceping passwords entered during an ssh session. Here is the relevant code from sshconnect1.c in OpenSSH:
    for (i = 0; i < options.number_of_password_prompts; i++) {
    if (i != 0)
    error("Permission denied, please try again.");
    password = read_passphrase(prompt, 0);
    packet_start(SSH_CMSG_AUTH_PASSWORD);
    ssh_put_password(password);
    memset(password, 0, strlen(password));
    xfree(password);
    packet_send();
    packet_write_wait();
    type = packet_read(&payload_len);
    if (type == SSH_SMSG_SUCCESS)
    return 1;
    if (type != SSH_SMSG_FAILURE)
    packet_disconnect("Protocol error: got %d in response to
    passwd auth", type);
    }

    Many people do not understand this. Some believe they are protecting themselves from this risk via RSA authentication. Of course they're not, because the risk only affects passwords in session:
    1. gorf: My solution is simply not to use passwords at all; I use RSA keys exclusively...
    2. SagSaw: The best way I can think of is to use the RSA key authentication method. A RSA key pair is used to authenticate, rather than a password. This way, the password is never typed over the network connection.
    3. Pinball Wizard: Well, if you use RSA you don't need to type a password so that would solve that particular problem.
    4. subsolar2: I use RSA authentication for remote access, and have since day one. So the only real worry is somebody getting a copy of my private key...
    5. Greyfox: As has been noted, RSA is the way to go, at least with SSH authentication...
    Others think that a GUI client is more secure entering a password in a dialog box suggests batch processing:
    1. stripes: My Java ssh client happens to have "gotten it right" not because I'm smarter then other ssh client authors but because I had a dialog box to ask for the password.
    2. Hyperbolix: Teraterm ... has several SSH extensions. I beleive one of them has you type in the password all at once and then sends it as a single string, which means that key timing can't be determined.
    3. rgmoore: I think that most Windows terminal emulators have similar functionality. It seems like a very simple step to take to help preserve passwords.
    4. garcia: don't most GUI terminal packages (including MacSSH, etc) all send it as a single string (SecureCRT)?
    5. Rimbo: ...I use the free ttssh extension to the freeware terminal program Tera Term. When it asks you for a password, it captures everything in a dialog box, and sends the password as one chunk.
    6. Jormundgard: Also, every SSH program I've used in windows takes in the whole password before sending it along.
    The very few who got it:
    1. Ethan: It's a moot point with SSH anyway, because SSH transmits the password in one chunk as far as I know...
    2. Todd Knarr: I think this applies only to passwords typed during an SSH session, not the password during the authentication phase.
    3. rtj: There seems to be some confusion as to the nature of this attack on ssh...All ssh implementatons send your password in one packet
  • Who in their right minds allows for password authentication over SSH? That's one of the first things I disable when setting up SSHD.

    If you don't have a private/public key pair, and if your public key isn't in the authorized_keys file of the target machine, then you don't deserve to log on. Tunneling passwords over the system is neither needed nor safe, and not just because of this article's hack.

    If you allow SSH to do password authentication, then SSH is little better than Telnet in terms of protecting you from a poorly chosen password. While a sniffer might not be able to extract the password, you can still try a dictionary attack.

    Force your users to use a keypair. Force them to put a passphrase on the keypair so that just stealing the key isn't enough.

    Remember, the best security is something you are (restriction by host IP), something you have (posession of the private key), and something you know (the passphrase for the key.)

  • I can understand but why? (Score:3)

    by Lumpy ( 12016 ) on Wednesday August 22, 2001 @08:56PM (#2206288) Homepage
    Ok, for a bank or the NSA, I can see needing Nth level encryption and other secret-spy stuff.. bot for joe webmaster or taco logging into the slashnet servers we dont need military grade security. Yes, fixing a hole is a great idea. but we dont need to be running around screaming OMG!!!OMG!!! ssh is insecure!!!! WEll it was insecure when it came out, and it will be forever insecure. you want secure? lock your box in a safe with all drives and ports filled with cement. and not on a network.

    That is the only way you can call something secure.

Slashdot Top Deals

Lots of folks confuse bad management with destiny. -- Frank Hubbard

Close