bro-2.1 IPv6, headers, evasion and other fun things

Development
1

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

2

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

3

Cool, thanks Aashish, that's good food for thought and I'll make sure
we have it at hand as we work on the code. The first step is making
sure we're extracting the right information at the protocol level and
for that, such sample application are very helpful to have in mind.

Everbody else, please feel free to chime in with more thoughts (thanks
Jim!).

Robin

4

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

5

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?

The stack doesn't have to cache the packet. Does it really do that? For TCP the stack can just rely on TCP retransmissions. Other IP packets are best effort anyways. And, as Seth pointed out, the sender should do PMTU first anyways.

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.

Neighbor discovery is limited to the the local subnet only as well. The multicast address used has link-local scope. Routers should never forward these packages. So it should be just as (in-)secure as ARP.

OTOH, forged router advertisement message can become a problem, since it allows for an incredible easy way to redirect traffic. However, this too is a link-local problem.

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.

Well, you can have multiple globally routable IPv6 addresses per host (cf. router advertisements). But in this case the 64 host bits uniquely identify a host even across prefixes (since they are based on the MAC address). (However, I can't recall how the privacy extension for creating the host part work -- they might change that)

In any ways, this will only affect attacks that span multiple connections since you can't change the destination IP within a connection.

cu
Gregor