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

[Jim Mellander]

Thanks Aashish,

I might add an additional thing to think about:

Per RFC 5722, overlapping fragments are explicitly forbidden in IPv6
(more info at http://blog.si6networks.com/2012/02/ipv6-nids-evasion-and-improvements-in.html
)
It probably would be good to flag such attempts as hostile.  I don't
know what the rfcs say about ipv6 fragments that are retransmitted
with differing contents, but those also would likely be hostile.

We've thought about dropping packets containing extension headers on
the floor, at least until more is known about the threat surface.

Jim

On Thu, Feb 23, 2012 at 11:21 AM, Aashish Sharma <asharma at lbl.gov> wrote:
> Hello brodevs:
>
> Since effort to get bro IPv6 ready is ongoing, I thought there are some
> IPv6 security issues to bring to attention. May be you already have
> plans to  handle these or otherwise I think these are somethings to pay
> attention to. Offcourse, I realize all this is easier said then done:
>
> One thing I would really like is ability to log optional headers at
> minimum. Here is some situations why it is important.
>
> 1) Evasion attack: Routing header can result in bro looking only
> at the IP header and not the routing header which dictates where the
> packet goes next. So IDS things that packet is going to host A but ends
> up going to host B and then C which are included in the routing header.
> So unless we parse these headers we shall not know what actually is the
> ultimate destination of the packet.
>
> 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.
>
> Even tcpdump only looks at the next header only and not the routing
> header unless  you specify protochain 6 in the filter.
>
> 3) Mobility header issue: With this one can use your internal IP address
> anywhere else in the world. RFC dictates to use IPSec but there is still
> trust issues - check out RFC4487.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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
>
>
> 8) IPv4 and IPv6 co-existence issues: Its not only that hosts have
> affinity to IPv6, but applications also do.  Crome prefers using v6
> (it tries connecting on v6 for 300mS and then falls back to v4) while
> safari prefers to pick up the IP from OS X stack. Depending on the latency
> and/or other situation host and applications may be using different
> addresses - Crome can use v6 while safari v4. How do we know both of
> these connections are part of the same attack ?
>
> 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.
>
> 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.
>
> 11) IPv6 also brings isolation problem: Address scheme allows assigning a
> Unicast local IP which doesn't have to be globally routable to a network
> device such as printer. However when a work station gets both local and
> global address, an external IP can bounce off this work station to
> access the network device which has unicast local IP. Likewise the
> network device can use a workstation (with dual address) as proxy to
> communicate to the outside world.
>
> 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.
>
> Aashish
>
>
> --
> Aashish Sharma  (asharma at lbl.gov)
> Cyber Security, Information Technology Division
> Lawrence Berkeley National Laboratory
> http://www.lbl.gov/cyber/pgp-aashish.txt
> Office: (510)-495-2680  Cell: (510)-457-1525
>
> _______________________________________________
> bro-dev mailing list
> bro-dev at bro-ids.org
> http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
>