ARP reloaded: The IPv6 ping replay attack

I've been thinking about my neighbour solicitation replay concept today, and thought I would clarify a few points

1. Sometimes (more rarely than on IPv4) these are sent to multicast/broadcast, and this can be detected by checking the destination MAC (FFFFFFFF for broadcast, 33:33:xx:xx:xx:xx for multicast)
2. Unicast neighbour solicitation and neighbour advertisement packets can't be distinguished just from packet length (although if an obvious exchange of 2 packets occurs this can be inferred)
3. Neighbour advertisement packets don't elicit replies
4. The ICMPv6 packet does LOTS of things, some of which also demand a reply.

So I had a look at RFC4443 again, checked my dumps, and realised that the neighbour advertisement packets are far from useless. Let's have a look at the NA packet format:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |     Code      |          Checksum             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |R|S|O|                     Reserved                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      |                                                               |
      +                       Target Address                          +
      |                                                               |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Options ...
      +-+-+-+-+-+-+-+-+-+-+-+-

And then compare this to the echo request packet format

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |     Code      |          Checksum             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Identifier          |        Sequence Number        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Data ...
      +-+-+-+-+-

The NA packet has type=136, code=0 and a checksum which is merely a sum of the packet as a set of 16-bit words. The echo request has type=128, code=0, same checksum style. It also has an identifier (can be anything) and a sequence number (can be anything) and room for any amount of data afterwards.

What does this mean? This means changing the type field from 136 to 128 (flipping bit 4) and adding 0x800 to the checksum converts this packet from a neighbour advertisement packet destined to a node which specifically requested it, into an echo request packet aimed at a node which we know to be alive and which is obliged to respond!

It works fine in plaintext, but what extra challenges are added when manipulating WEP encrypted packets?

1. The ICV is a value appended to the end of a WEP encrypted packet. It is essentially the CRC-32 of the packet's contents, and due to its calculation by interpreting the packet data as polynomials rather than integers, this can be easily altered by XORing it with the CRC-32 of the changes made to the packet.
2. The ICMPv6 checksum is slightly harder than this. Because the packet has been XORed against the keystream, an addition of 0x800 to the checksum may require flipping more than just bit 12. For example, if the checksum was 0x3800, an addition of 0x800 would result in a value of 0x4000, which requires bits 12, 13, 14 and 15 be flipped. Since the checksum is a ones-compliment sum, the worst case of a checksum initially being 0xFFFF would require 17 flips (with bit 12 being flipped once at the start and at the end). Fortunately this is unlikely, and in actual fact 50% of the time only 1 bit would need to be flipped, so one could easily discard half the NA packets, or could continue flipping bits until replies are sent.

I haven't tested this yet, but will try to get some code together soon. If nothing else, this just shows how easy it is to modify existing attacks for WEP, but it also shows the advantage (from an attacker's point of view) of having ARP functionality built into IPv6.