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]
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


Powered by blists - more mailing lists