Re: Cracking preshared keys

From: Michael Thumann (mlthumann@ids-guide.de)
Date: 04/24/03

  • Next message: Frank Tegtmeyer: "Re: DNS vulnerabilities in shared host environments" 
    Date: Thu, 24 Apr 2003 20:31:48 +0100
From: Michael Thumann <mlthumann@ids-guide.de>
To: daw@mozart.cs.berkeley.edu (David Wagner), bugtraq@securityfocus.com

    Noone was talkig about that IPSec isn't secure because of this attack
    scenario. We gave recommendations how to configure IPSec in a secure way
    with a proof of concept what might happen, if you don't. The described
    attack won't work too, if aggressive mode can be disabled as for example in
    Checkpoint FW-1, so it doens't depend only on a crackable PSK.

    Using this attack every PSK is crackable, but good ones aren't crackable in
    an acceptable amount of time. I don't want to start another discussion
    about how to choose good password or preshared keys, I totally agree that
    you get a lot of security when you choose strong ones, but if you take a
    look at SANS TOP 20 ( http://www.sans.org/top20/ ) you can see that's still
    one of the most common problems in praxis.

    So I think, that you can see that we don't have different point of views
    how to configure secure VPNs ;-)

    At 00:08 24.04.03 +0000, David Wagner wrote:
    >Michael Thumann wrote:
    > >we would like to announce the publication of a proof of concept paper 'PSK
    > >cracking using IKE Aggressive Mode'. Paper can be downloaded from
    > >www.ernw.de/download/pskattack.pdf .
    >[...]
    > >4. Of course the psk must be weak to crack it in an acceptable amount of
    > time
    >
    >Well, what did you expect? In your example, the pre-shared key was
    >derived from the ``secret'' string "cisco". Of course, if you choose
    >a key that the attacker can guess, the system won't be secure. Surprise!
    >
    >What do you expect IPSec to do if you give it an insecure, guessable key?
    >Noone claimed it would be secure in such a situation.
    >
    >I find your recommendations hard to take seriously. This is not a
    >vulnerability in IPSec, a good reason to disable vpn access, or anything
    >like that. Just use some common sense in how you use the crypto. If you
    >must use pre-shared keys, choose strong keys; or, use public keys instead
    >of pre-shared keying. Surely you agree?
    >
    >User: "Doctor, doctor, it hurts when I use insecure crypto keys."
    >Doctor: "Don't do that, then."

    ----------------------------------------------------------------------------------------------------
    Michael Thumann mlthumann@ids-guide www.ids-guide.de
    Public Key available at http://www.ids-guide.de/MichaelThumann.asc
    ----------------------------------------------------------------------------------------------------
    The only secure computer is one that's unplugged, locked in a safe,
    and buried 20 feet under the ground in a secret location...and i'm not
    even too sure about that one
                                                                        --Dennis
    Huges, FBI.

  • Next message: Frank Tegtmeyer: "Re: DNS vulnerabilities in shared host environments"

    Relevant Pages

    • Re: How 2 secure PC-PC data transfer
      ... The assumption that you are going to open your machine to attack is one of the worst ideas ... I have no idea what you mean by "not that secure". ... connecting a parallel port cable from PC to PC will work. ... If you have a front-end software that blocks all incoming FTP requests from the WAN (look ...
      (microsoft.public.vc.mfc)
    • Re: Ask EU - Norton AV 2006
      ... >>It is true that an attacker could reprogram a network card so that his ... >>knowledge of your network setup before he could construct his attack. ... When you are on a secure site, ... from a "certificate authority" as a means of getting your browser to ...
      (uk.media.radio.archers)
    • Re: My little something...
      ... Its more unlikely that attack on 1024 ECC to subvert it to weaker than ... More secure ofcourse. ... Dont give BS about two cascading ciphers not neccessarely being more ... 10101 as hash. ...
      (sci.crypt)
    • Re: strengthening /dev/urandom
      ... While it may use crypto to "mix the pool" and to ... distill entropy in the input it should not depend on ... If I can use this data in an attack, ... assume that AES whatever is NOT secure. ...
      (sci.crypt)
    • Re: In order to cross platform, Ruby is designed to be interpreted in runtime, so Ruby code is expo
      ... |> I'm not going to bother with code injection. ... these packages have to be written safe, sane, and secure. ... (I currently work on a Rails app that I wouldn't dare putting online, ... The attack vector more depends on what the application ...
      (comp.lang.ruby)
    • Quantcast