1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Cisco VPN Client 4.0.3 w/RVS4000

Discussion in 'Cisco Small Business Routers and VPN Solutions' started by tfiorda, Aug 16, 2006.

  1. tfiorda

    tfiorda LI Guru Member

    Just curious. Has anyone configured a Cisco VPN Client to work with the RVS4000 VPN router? If so how is it configured?

    As a side note, will the Quick VPN client work if you have the Cisco VPN client installed on the same system?

    Thanks,

    Tony...
     
  2. eric_stewart

    eric_stewart Super Moderator Staff Member Member

    The Cisco VPN Client will not work since it uses Cisco-proprietary "mode configuration" in IKE Phase I to inform the client of its parameters (IP, DNS, WINS, etc.). Short answer is that it will work with only Cisco VPN devices which support it.

    I've had both the QuickVPN client and the Cisco VPN client installed on the same system successfully but this goes against Cisco's and Linksys' advice. Since they both re-write / add policies to your local IPSec policies on your Windows PC it might be a problem in some instances.

    /Eric
     
  3. Toxic

    Toxic Administrator Staff Member

    eric just out of curiousity, does the Cisco VPN handle authentication in a similar way? since an exploit in QuickVPN has been found just wondering if Ciscos is similar.
     
  4. eric_stewart

    eric_stewart Super Moderator Staff Member Member

    No. The Cisco client uses an RFC-compliant Diffie-Hellman key exchange to create a secure channel between the VPN peers before authentication parameters (either hashed pre-shared keys or digital certificates) are exchanged. Nothing cleartext is ever exchanged during the authentication dialogue.

    This whole controversy has my interest piqued. I commented before (seems like eons ago) that the Linksys VPN client uses SSL via HTTPS to create a secure link in which the authentication dialogue occurs. I'm looking at a sniffer trace right now and it looks like this:

    Steps Observed (C = Client; S = Server)
    ================================
    1. C-to-S: HTTPS - TLSv2 Client Hello -- ie: client knocks on server door;
    2. S-to-C: HTTPS: Server Hello, Certificate Exchange w/ client
    3. C-to-S: HTTPS: Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message
    4. S-to-C: HTTPS: Change Cipher Spec, Encrypted Handshake Message (basically an ACK)
    5. S-to-C: ISAKMP: Identity Protection (Main Mode)
    6. S-to-C: ISAKMP: Identity Protection (Main Mode)
    7. C-to-S: HTTPS: Application Data (ie: username/password [?])
    8. S-to-C: HTTPS: Application Data
    9. C-to-S: HTTPS: Encrypted Alert
    10. C-to-S / S-to-C: ISAKMP: several more Identity Protection (Main Mode) messages
    11. C-to-S / S-to-C: ISAKMP: agree to switch to Quick Mode --probably agreeing on ciphers for Phase II
    12. -- IKE Phase I Established --
    13. -- IKE Phase II Established -- using ESP (ie: protocol 50)
    14: Lots of ESP (S-to-C and C-to-S) as encrypted data moves in VPN between peers.

    Executive summary:
    ===============
    This behaviour was observed from the perspective of a MiM (Man-in-the-Middle) attacker on a common network segment with the client and the server. I personally don't see anything anywhere in the HTTP/TLS (HTTPS), or IKE exchanges that imply cleartext information being exchanged. I looked at the raw data in the packet payload and didn't see my passwords or usernames both viewed in ascii and hex. It seems to me like both the client and the server are properly negotiating a secure channel (even if QuickVPN doesn't use DH) before authenticators are being exchanged.

    I'm very interested in Cisco's viewpoint on this "exploit".

    /Eric
     
  5. Toxic

    Toxic Administrator Staff Member

    well I am sure you have seen the replies I had from linksys product manager, he seemed adamant that this is a problem since his team were now aware of the problem. this is why i was witholding my support of this find until someone could confirm it.

    now i have my doubts again:)
     
  6. eric_stewart

    eric_stewart Super Moderator Staff Member Member

    Well, you know I should really be careful before I advance an opinion. I read (the very poorly worded and extremely scanty scholarly diatribe) posting by the Moshe Valenci. Admittedly, I threw it to the side (I'm too darn busy) when I first read it because of the poor english and the generally ranting/posturing nature of the writing. It seemed arrogant and sparse so I wasn't that interested in reading it through.

    Someone much smarter than me once said, "Look past the messenger if you want to get the message". That voice echoing in the back of my mind, I actually read the darn thing and you know what?....I think he's on to something if what he says is correct.

    What he's saying can be boiled down to something very simple. The QuickVPN client will accept any box's site certificate. It's that trusting. The client will trust to the point of coughing up it's own username/password to anyone. Whether it's in the clear (it isn't) or not is immaterial as he proposes that you can setup a MiM attack where you can fool the QuickVPN client into showing you its private parts on a TLS-encrypted link. That would be in step (3) below [the trace below is a summary of an actual QuickVPN session being established and is observed by a box on a common subnet]

    What this means is that if the user hasn't misspelled his username and password an attacker can now login to the VPN gateway with these credentials. He then muddies the waters by suggesting a broader, but tangential, issue where all Linksys boxes of same make/model have the same certificate installed on them. You cannot easily replace the certificate. I suspect that the certificate is only replaced when you do a firmware upgrade. But who cares? The issue remains that the QuickVPN client trusts everyone. Gullible git software!

    This is a very specialized attack by a motivated attacker. As someone pointed out in a separate post there are a lot juicier exploits that a potential attacker will sink their teeth into before attacking your QuickVPN connection. Should you be worried? Yes. But first a caveat: I suspect that the threat level is similar to the likelihood of being killed in a terrorist attack. If you are doing a bunch of simple things like using switched infrastructure with no port mirroring on a campus network the chance that an attacker will intercept and use your credentials is incredibly small.

    ================================
    Summary Trace of QuickVPN Session Establishment (C = Client; S = Server)
    ================================
    1. C-to-S: HTTPS - TLSv2 Client Hello -- ie: client knocks on server door;
    2. S-to-C: HTTPS: Server Hello, Certificate Exchange w/ client
    3. C-to-S: HTTPS: Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message
    4. S-to-C: HTTPS: Change Cipher Spec, Encrypted Handshake Message (basically an ACK)
    5. S-to-C: ISAKMP: Identity Protection (Main Mode)
    6. S-to-C: ISAKMP: Identity Protection (Main Mode)
    7. C-to-S: HTTPS: Application Data (ie: username/password [?])
    8. S-to-C: HTTPS: Application Data
    9. C-to-S: HTTPS: Encrypted Alert
    10. C-to-S / S-to-C: ISAKMP: several more Identity Protection (Main Mode) messages
    11. C-to-S / S-to-C: ISAKMP: agree to switch to Quick Mode --probably agreeing on ciphers for Phase II
    12. -- IKE Phase I Established --
    13. -- IKE Phase II Established -- using ESP (ie: protocol 50)
    14: Lots of ESP (S-to-C and C-to-S) as encrypted data moves in VPN between peers.

    I will post this in the sticky thread too. I think it's very important to realize that this attack's efficacy is a bit overstated but nevertheless demonstrates a vulnerability that needs to be addressed.


    /Eric
     
  7. Toxic

    Toxic Administrator Staff Member

    Thanks eric for the explanation, It is without doubt a rant since you have explained the exploit in less than half the documents contents. I really wonder why the author did not just say this in the first place and keep the ranting to his on web blog.
     
  8. tfiorda

    tfiorda LI Guru Member

    Eric,

    Thanks, that is what I thought and I am glad you've had both clients on the same machine. That is what I am planning to do.

    Just as an FYI, I asked Linksys support the same question. They replied that it WILL work. However, they gave no configuration information. I've asked for that. If I get the information and get it working, I'll post that here for all.

    Thanks again,

    Tony...
     
  9. mvalenci

    mvalenci LI Guru Member

    time has passed - nothing changed ... ;)

    Few years after, I Google my name and find this funny thread.
    I guess some people are arrogant enough to "rewrite" what I have first found and mock my English (I am so sorry I had to explain to you guys, in your language what's "obvious" to you... too bad you didn't found this yourself ;) ).
    To make things clear. The document bluntly describes an attack which was never fixed properly until this day (late 2008). You may be too arrogant to understand this, even if this is written in refurbished English ;)
    why do I bother using this Linksys's controlled site... there are plenty of sites that appreciate this materia.
     
  10. levelup3

    levelup3 Addicted to LI Member

    Thanks for all your post, I have the same problem and now it has been sorted!
     

Share This Page