bugtraq - Re: Insecure IKE Implementations Clarification

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20031212214537.GA18282@deneb.enyo.de>
Date: Fri, 12 Dec 2003 22:45:37 +0100
From: Florian Weimer <fw@...eb.enyo.de>
To: Thor Lancelot Simon <tls@....tjls.com>
Cc: Aaron Adams <aadams@...urityfocus.com>, bugtraq@...urityfocus.com
Subject: Re: Insecure IKE Implementations Clarification

Thor Lancelot Simon wrote:

> The second problem is generic to *any* IKE that can be configured to
> use a "group password" and then send a second authenticator using XAUTH.
> 
> *This is probably the *most common* configuration of the Cisco "VPN client"
> implementation that you will find deployed in the field*.  That's no
> surprise, because Cisco consultants, Cisco-trained consultants, and Cisco
> sales engineers push it on customers heavily as a panacea for bootstrapping
> a VPN using only a legacy authentication database.

There's also a PSIRT statement regarding this issue, and it's at best
embarrassing for Cisco engineering folks:

  <http://www.cisco.com/warp/public/707/cisco-sn-20030422-ike.html>

I know several people work on XAUTH MITM attacks; I guess it will fall
in a couple of weeks.  (Just sniffing the user password is easy, the
group password is typically public anyway; the remaining challenge
consists of putting together several tools to transparently fake a Cisco
VPN concentrator).