[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Modefg considered harmful



Van Aken Dirk <VanAkenD@thmulti.com> writes:

> If this can happen then I would say that the design of this IPSec VPN node
> is inherently insecure !

It's not the road-warrior node; it's the gateway.  If the GATEWAY is
not involved in the address configuration of the road-warrior, then it
cannot protect the network.  By routing around IPsec (which is exactly
what you are proposing by selecting DHCP outside IKE), you are in
effect REMOVING the ip address protections from the tunnel.

> In this context, you might have a look at RFC2547 (BGP/MPLS VPNs):
> - this kind of VPN uses the concept of virtual routers such that traffic
> from one VPN cannot leak into another VPN

I've looked at this.  Unfortunately your analysis is incorrect -- it
is possible to leak information from one vpn to another in a BGP/MPLS
VPN if you share an entry point to the MPLS network, which maps quite
nicely into the attack I'm worried about.

> - it defines the VPN-IPv4 address family such that identical address pools
> can be used per VPN.
> Consequently a VPN client can execute the aforementioned attacks but within
> its own VPN; not in a "neighbor" VPN.

It depends completely on the implementation.  If there is a shared
wire between my network edge, your network edge, and the MPLS fabric,
then packets can bleed across.  MPLS "fixes" this problem by requiring
physical point-to-point links between the edge node and the MPLS
gateway.  That way it can differentiate the traffic based on which
physical interface it arrived on.

The EXACT SAME THING is true for IPsec -- if IPsec knew the allocated
address then it can act in the same way.  If the IPsec gateway knows
that you are only allowed 1.2.3.4, then if it sees a packet claiming
to be from 1.2.3.5 it can drop it.  

However, if the gateway is not involved in the road-warrior
configuration, if it does NOT know what addresses are configured, the
is has NO CLUE what addresses are allowed to traverse the tunnel.  In
effect, it's the same as if you used an ethernet rather than
point-to-point links between the edge gateways and MPLS.  Sure, the
traffic is encrypted, but there is no guarantee it is correct.

This is why you MUST include the IPsec gateway in your address
configuration.

> I assume there is a misunderstanding here: I agree that the IPSec gateway
> MUST be involved but it must not necessarily be done directly by the IKE
> module and it does not necessarily impacts existing IPSec code.
> 
> My reasoning is the following:
> 1) IKE takes care of the identification/authentication of the client and
> allows it to set-up an RFC3456 phase2
> 2) the client issues DHCP requests in the RFC3456 tunnel
> 3) a DHCP server responds as it can assume that the client went through the
> IKE identification/authentication procedure
> 4) a module (such as a DHCP relay that is outside the IPSec code) analyses
> these DHCP responses and via an API such as PF_Key or PF_Policy it injects
> the necessary entries into the SPD
> 5) in addition, depending on the IPSec implementation, the DHCP relay uses
> the PF_Route API to add the necessary routes into the forwarding information
> base
> 6) finally the client establishes a second SA and announces its IP address
> via IDci
> 7) IDci must match the entries added to the SPD and/or FIB in the previous
> step

UMM, your steps 4 and 5 here have just proven my point.  If you are
going to require a "special" DHCP relay that knows about IPsec, why
not just make that IKE?

> BTW Derec, the attacks you mentioned can be launched successfully against
> most existing IKEModeCfg solutions for two reasons:

My name is "Derek", thank you...

> - IPSec clients must be able to operate behind NAT/NAPT routers hence a VPN
> gateway must tolerate multiple modecfg requests from the same peer address
> which makes attack a) quite easy

Operating from behind a NAT has nothing to do with this.  We're
talking about tunnel-mode address configuration.  The fact that the
outer address is natted has nothing to do with it.  Indeed, this just
proves my argument.  You necessarily WANT to tie the phase-1 IKE
identity to the phase-2 tunnel addresses (i.e. the INSIDE address).

Even through a NAT you can still differentiate flows.  A gateway ties
Flow A to IKE-ID A and ties Flow B to IKE-ID B.  When a packet arrives
at the gateway on Flow A, the gateway needs to know which address(es)
were configured to client-A to make policy acceptance decisions.  But
you necessarily want to make those policy decisions with full
knowledge of the ike id.

This is exactly the same problem that MGCP has using IPsec for
security.  MGCP has in-band endpoint identifiers that name the end
points.  The problem is that this identifier is NOT tied to the IPsec
security, so just because a flow is protected by IPsec does NOT imply
that you can believe the MGCP identifier.  As a real-world example,
your neighbor could connect to your neighborhood MGCP gateway but
claim to be you within MGCP.  Sure, IPsec would know its your
neighbor, but MGCP would not.

This is why you need to tie the identifiers together.  In MGCP you
need to tie the MGCP identifier into IKE/IPsec.  In the IPsec VPN you
need to tie the Tunneled IP Addresses to the IKE ID.  This means that
the IKE policy (on the gateway) needs to know what address(es) are
assigned to the road-warrior client.

> - most IPSec clients are able to operate with a static IP address which
> opens possibilities for attack b)

In which case the IPsec Gateway should know which address the client
is connecting from, and that becomes part of the policy.

> You might do a few experiments on this it will confirm my findings ...

I have performed these experiments, and they don't confirm your
findings.  Perhaps there are some (broken) implementation of IPsec
that have these failings, but this is a bug.  A working IPsec
implementation is easily capable of protecting against these attacks.

> Cheers - Dirk

-derek

-- 
       Derek Atkins
       Computer and Internet Security Consultant
       derek@ihtfp.com             www.ihtfp.com