> 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:
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).
> 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).
[ reply ]