bugtraq - Windows IPSec Vulnerabilty

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>] [day] [month] [year] [list]

Message-ID: <Pine.NEB.4.58.0405071527150.14878@alpha.wh-stuttgart.de>
Date: Fri, 7 May 2004 15:28:48 +0200 (CEST)
From: Steffen Pfendtner <steffen@...netz.de>
To: bugtraq@...urityfocus.com
Subject: Windows IPSec Vulnerabilty

Hello,

After recent experiment I noticed that there is a man-in-the-middle
vulnerability in Microsoft Windows IPSec implementation when using
certificates for authentication. This also includes the Windows
L2TP/IPSec VPN.

It seems that this is a known problem as there where posts mentioning this
on bugtraq before.
(see: http://www.securityfocus.com/archive/1/347392)
However nobody seems to care about this, and it's nearly nowhere mentioned
on the well-known VPN howtos.

Windows is verifying the authenticity of an IPSec Gateway by checking the
gateway certificate against its trusted CA public key. Thus only
a gateway with a valid certificate is accepted. But it DOES NOT check
the subject of the certificate e.g. the CN field.
As a matter of fact every other member of the VPN network with a valid
client certificate can setup a IPSec Gateway. The fouled clients will accept
the attackers certificate because it has a valid signature. They will not
notice that the attacker is not the real gateway but an other client.

On further investigation on this topic I took a look on the EAP/TLS 802.1x
stuff for authentication WPA WLAN links which is also using certificates.
Microsoft has introduced two OID's which are coupled with certificates
and which define the purpose - either gateway for server or client.
As a result when using 802.1x the attack does not work because a client will
not accept another clients certificate as its not valid for gateway usage.

I tried to use these OID's for IPSec Authentication as well. The result:
it does not help either. Client certificates are still accepted as valid
gateway certificates.

I've not found any statement from Microsoft on this topic or any official
security advisory. However I think this could easily be fixed by enabling
the usage of the EAP/TLS OIDs for IPSec authentication.

Workaround:
You can use this workaround if you use a Linux IPSec implementation as IPSec
Gateway and OpenSSL for certificates.
Generate a single CA for each pair of Gateway/Client certificates. Configure
your gateway to use another certificate/CA for each client.
The single clients won't accept each other as gateways because their
certificates are signed by different CA's.

Greetings,
Steffen Pfendtner

--
Steffen Pfendtner <steffen@...netz.de>
GPG Key fingerprint = DF91 11BB 498F 573B 8002  6E0B 3AE3 FF88 EADD B3BC