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: <20031212215419.GA25675@rek.tjls.com>
Date: Fri, 12 Dec 2003 16:54:19 -0500
From: Thor Lancelot Simon <tls@....tjls.com>
To: Florian Weimer <fw@...eb.enyo.de>
Cc: aadams@...urityfocus.com, bugtraq@...urityfocus.com
Subject: Re: Insecure IKE Implementations Clarification

On Fri, Dec 12, 2003 at 10:45:37PM +0100, Florian Weimer wrote:
> 
> 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>

Whoever wrote that statement seems to have the fundamental XAUTH
vulnerability and the recently-much-discussed possibility of brute-forcing
Phase 1 preshared keys using Aggressive Mode pretty seriously mixed up.

> 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).

For what it's worth, the possibility of this general type of attack was
repeatedly discussed in the IPsec working group and is a major reason
why XAUTH was abandoned.  The particular password-stealing attack that I 
describe as been widely discussed among IKE implementors for at least two
years; other implementors probably independently noticed it at least as
early as I did, which was three years ago.

What's pretty disturbing is that there is wide understanding of this
issue among actual protocol implementors, but that Cisco field personnel
continue to quite plainly tell customers that it does not exist at all,
even when the risk to those customers is huge.  Indeed, I'd say that
including support for this mode in their VPN client, at this point, is
pretty irresponsible -- recommending it is just plain awful.

-- 
 Thor Lancelot Simon	                                      tls@....tjls.com
   But as he knew no bad language, he had called him all the names of common
 objects that he could think of, and had screamed: "You lamp!  You towel!  You
 plate!" and so on.              --Sigmund Freud