[Bro-Dev] bro-2.1 IPv6, headers, evasion and other fun things

[Seth Hall]

On Feb 23, 2012, at 2:21 PM, Aashish Sharma wrote:

> 1) Evasion attack: Routing header can result in bro looking only

As far as I know, this extension has effectively been deprecated.  Once people realized that it was bad for all routers to obey this header all of the router vendors disabled handling of it by default.

> 2) Evasion attack using Extension header size:  could be 128K per
> header, and RFC doesn't dictate the sequence of the headers so these can
> be out of order. Bro needs to address the problem of parsing and
> processing these extension headers, taking in to account the full sized
> extension headers, else miscreants might put malicious contents at the
> end of these headers and evade the detection. 

Hm, not sure I understand this.

> 3) Mobility header issue:
> An Application of such attack is subverting geoip blocking - example
> youtube not allowing content viewing for IP's in Canada etc or avoid
> roaming charges when using a mobile phone. 

I don't think we can really worry about subverting geoip blocking as a concern since there are already a tons of ways to avoid it.  It works when it works, otherwise it doesn't.

> 4) IDS connection caching issue: Since IPv6 doesn't support
> fragmentation, a Sender has to keep a copy of the packet in the IP stack
> because  application doesn’t know if routers are going to fragment or
> not and sender has to account for a possible ICMP error with frag bit
> set. IDS has to be able to account for such situations and
> re-transmissions.  

Hm.  IPv6 does support fragmentation but routers won't perform the fragmentation, it has to be done by the end point after doing PMTU with ICMPv6 (which we are going to support).  Could you explain more about what you meant?

> 5) Neighbor discovery attack: ICMP6 can broadcast address for someone
> else. It assumes that network is secure.  Also given ICMP6 messages are
> routable where as with  ARP this was not a problem because ARP is/was
> local to a subnet only. 

We'll be able to detect this with the ICMPv6 analyzer.  I suppose there could be some issue with this if people are monitoring outside of their router and we start doing scripts that do things with neighbor discovery packets.  With the interest in internal network monitoring it wouldn't surprise me if eventually we get to the point where the location of each monitoring node in a cluster is configured so that we can deal with packets that are internal or external to the network since something could conceivably be spoofed on the outside of your network (your address space as the source for an externally sourced packet).

> 6) Address Priority issues: It is possible that part of attack uses a
> link local address and other part uses the site address. BRO needs to
> maintain a  state which can account for all the IP's assigned and used
> by the host to assemble a connection/attack etc. 

You should only be able to see link local addresses if you are monitoring within a broadcast domain but even in that case I expect that over time people will figure out how to start profiling hosts and compiling lists of addresses that are all used by the same host.

> 7) IPv6 allows multiple routers allocate multiple address - one from
> each router. Can we flag on rogue router broadcasts or new address
> allocation other then the ones which are predefined in the networks.cfg 

That should just be a script that needs to be written once we integrate the ICMPv6 analyzer.

> Crome can use v6 while safari v4. How do we know both of
> these connections are part of the same attack ? 

Could give a more concrete scenario that you are thinking of?  

> 9) DNS resolution - Any IPv6 host takes upon itself to resolve DNS for
> any query which it sees. So if an attacker chooses to use broadcast
> address ff02::1 for DNS query resolution all hosts are going to resolve.

Not sure I follow here.  Presumably only hosts providing recursion will resolve.

> 10) Collusion attack - because of the vastness of IPv6 address space, it
> is possible for two hosts to use a new IP address for every packet to
> communicate between them. 

This is mostly a script level issue in my opinion.  We would have to watch for sudden increases in address utilization for internal subnets.

> 11) IPv6 also brings isolation problem

That doesn't sound like a Bro issue (although it's going to be a huge pain in the ass for a lot of teams I'm sure).

> 12) Offcourse Teredo which encapsulates protocol and provides globally
> reachable IPv6 address - enabled by win7 and win8.rc2 by default but
> only works when ipv4 address is not available.


We have a decapsulator and are discussing how to fit it into the analysis model.

>From the Bro perspective, I don't see anything here that is a huge obstacle.

  .Seth

--
Seth Hall
International Computer Science Institute
(Bro) because everyone has a network
http://www.bro-ids.org/