Re: (Fwd) Multiple vulnerabilites in vendor IKE implementations,

Using X.509 enabled FreeS/WAN it is of utmost importance to
differentiate between the VPN client and VPN gateway applications.

The X.509 certificate vulnerability as described by Thor Lancelot Simon
in his BugTrag posting can be exploited in remote access scenarios if VPN
clients do not explicitly define the identity of the gateway but indicate
a preference for a trusted certification authority (CA), only.

As mentioned correctly by Thor in his follow-up posting

   http://www.securityfocus.com/archive/1/347392

the Windows 2000/XP IPsec implementation has this vulnerability.
A connection definition allowing a VPN client to access a VPN
gateway looks as follows:

# Windows 2000/XP VPN client

conn client-to-gateway
      left=%any   # my IP, taken from network interface card
      right=<IP address of VPN gateway>
      rightsubnet=<subnet behind VPN gateway>
      rightca="<DN of CA that issued both the client and gateway certs>"
      auto=start

I'm using here Marcus Müller's notation which is closely modeled on
a Linux FreeS/WAN ipsec.conf file, but the same behaviour results
if the Microsoft Management Console (mmc) and the graphical IPsec
snap-in is used instead.

If there are several roadwarrior clients with a certificate issued
by the same CA then a rogue client could spoof the VPN gateway's
IP address and present its own client certificate in place of the
gateway certificate - and would be accepted! Thus a man-in-the-middle
attack becomes possible.

The situation is radically different if you set up a FreeS/WAN VPN
client. Since a roadwarrior is always usually the initiator of an
IKE negotiation, the IP address of the VPN gateway must be defined:

# Linux FreeS/WAN VPN client

conn client-to-gateway
      left=%defaultroute  # my IP
      leftcert=<my certificate>
      right=<IP address of VPN gateway>
      rightsubnet=<subnet behind VPN gateway>
      rightid=<distinguished name of VPN gateway>
      rightca=%same       # the gateway's CA must be the same as mine
      auto=start          # client is the initiator but could also be
                            responder

A rogue VPN client cannot spoof the VPN gateway since rightid requires
the distinguished name of the gateway to be contained in the peer
certificate. If the rightid parameter is missing then

      rightid = right = <IP address of VPN gateway>

is automatically assumed by FreeS/WAN. In order for the peer
certificate to be accepted, the VPN gateway's IP address would
have to be included as a subjectAltName in the peer certificate
which is clearly never the case.

Thus it is evident that a FreeS/WAN client is not vulnerable to
the attack described in the BugTraq article!

--------------------------------------------------------------------

On a FreeS/WAN VPN gateway the rightca wildcard is used
*on purpose* to handle an unlimited number of roadwarrior
clients with a single connection definition:

# Linux FreeS/WAN VPN gateway

conn roadwarrior
      left=%defaultroute  # gateways's IP
      leftsubnet=<subnet behind VPN gateway>
      leftcert=<gateway certificate>  # leftid is set to gateway's DN
      right=%any          # peer IP does not matter, any accepted
      rightca=%same       # the peer's CA must be the same as the gateway's
      auto=add            # gateway is always responder

Any client presenting a valid certificate issued by the trusted CA
is accepted. A periodically updated certificate revocation list (CRL)
can be used to exclude clients that have lost the right to connect to the
gateway. FreeS/WAN 2.0x supports the dynamical fetching of CRLs using
http or ldap URLs. As an alternative, OCSP (Online Certificate Status Protocol)
queries will be supported in the forthcoming version 1.5.0 of the X.509 patch.

  My whitepaper "Virtual Private Networks - Coping with Complexity"

   http://security.zhwin.ch/DFN_VPN.pdf

shows how roadwarrior access can be selectively restricted using
ID wildcards as e.g. with

      rightid="C=CH, O=ACME, OU=R&D, CN=*"

which restricts VPN access to R&D folks only.

I hope that I have clearly demonstrated that FreeS/WAN's
X.509 implementation does not suffer from the vulnerability
described in the BugTraq article.

Kind regards

Andreas

Nels Lindquist wrote:
> This was on BugTraq mid last week.  Surprised I haven't seen a 
> discussion here yet!
> 
> What are the ramifications of this for FS/SFS users?  I'm assuming 
> only the first issue is of concern, and only when using RW + x509 
> configurations with rightcert=%same directives.

=======================================================================
Andreas Steffen                   e-mail: [email protected]
strongSec GmbH                    home:   http://www.strongsec.com
Alter Zürichweg 20                phone:  +41 1 730 80 64
CH-8952 Schlieren (Switzerland)   fax:    +41 1 730 80 65
==========================================[strong internet security]===