Rupture on IPv6 targets

IPv6 Support for Rupture framework is almost completed. The Rupture attack is based on controlling the victim’s browser, while he visits websites that do not provide encrypted communication (HTTP connections). This situation creates the opportunity for an adversary to send arbitrary requests to HTTPS websites and as a result of that to allow him measure the compressed response.

This technique requires from an adversary to perform a Man in the Middle (MitM) attack in order to inject javascript code to the victim's browser and ultimately send crafted requests to targeted endpoints. This is performed by the usage of Bettercap framework, a Ruby gem that enables various MitM attacks, along with PacketFu, a mid-level packet manipulation library for Ruby.
However current versions of Bettercap as well as PacketFu, only support IPv4 protocol. That being said, Rupture cannot target popular IPv6 endpoints such as Google, Youtube or Facebook, making the extension of Bettercap for IPv6 protocol mandatory.

We have recently made two pull requests to Bettercap and PacketFu to add IPv6 support to Rupture. Our Bettercap patch adds IPv6 support to Bettercap, while our PacketFu patch adds IPv6 packet crafting support to PacketFu. Once these patches are merged, Rupture will have full IPv6 support, and Bettercap will also be able to work on IPv6 end-points independently of Rupture.
Below are described the complete steps for this extension.

The first part of the attack involves user input parsing. One of the most important changes in Bettercap patch is to enable the gem to manage IPv6 addresses. IPv6 protocol uses a different address scheme, making address manipulation challenging. As a result of that, the extension needs to validate IPv6 addresses and exclude those with wrong format. This gap is filled by the IPv6 validator with the appropriate regex matching patterns.
An IPv6 address is represented as eight groups of four hexadecimal digits, each group representing 16 bits (two octets). The groups are separated by colons (:). An example of an IPv6 address is:

                  2001:0db8:85a3:0000:0000:8a2e

One or more consecutive groups of zero values may be replaced with a single empty group using two consecutive colons (::).
IPv6-enabled network interfaces usually possess more than one type of address: Global Unicast, Link-local and Unique Local.
The first two types are mainly used for end-to-end IPv6 routing. On the other hand the last one has a limited use in private networks.
* Global Unicast Addresses are similar to IPv4 public addresses and they are used for one to one communication by exchanging unicast messages. This mode dictates that the sender’s outgoing packets are destined to a single host. Global Addresses can be acquired with three different ways, either by DHCPv6, SLAAC or Static Configuration.
DHCPv6 is the equivalent protocol of IPv4, DHCP, dynamically configuring hosts with IPv6 addresses, IP prefixes and other configuration data required to operate on the network.
Stateless Address Autoconfiguration (SLAAC) protocol gives the ability to hosts to configure themselves automatically when connected to an IPv6 network. SLAAC is the most preferable method in IPv6 configuration, unless an application imposes otherwise.
Static Configuration is executed manually in order to assign a host with a static IPv6 Global Address that cannot be changed by DHCPv6 or SLAAC protocols.
* Link-local Address is a network address that is valid only for communication within the network segment that the host is connected to. They are not guaranteed to be unique beyond a single network segment. Therefore, routers do not forward packets with Link-local addresses outside a LAN. This type of address consists of two main components. The first part is generated by adding the prefix 0xFE80 to a sequence of 48-bits of 0. The second part is called Interface ID and it is created by splitting the interface’s MAC address in half and adding the 16-bit Hex value 0xFFFE between the two halves. An example of Link-local Address is:

                     fe80::ca78:abff:fevc:12df

Link-local addresses can be used in multicast messaging mode, meaning that a packet can be destined to multiple hosts. All hosts interested in that multicast information, need to join that multicast group first. All interfaces which have joined the group receive the multicast packet and process it, while other hosts not interested in that type of packet ignore the information.
*Unique Local Addresses is globally unique, but it should be used in local communication, limiting their scope to an organization’s boundary.

One of the most important part of MitM attack in Bettercap extension is the Neighbor Discovery Spoofer. The Neighbor Discovery Protocol (NDP) is used with IPv6 protocol and it operates in the Data Link Layer of OSI model. It is responsible for address autoconfiguration, discovery of other nodes on the link, duplicate address detection, finding available routers and maintaining reachability information. The protocol defines five different ICMPv6 packet types to perform functions for IPv6 similar to the Address Resolution Protocol (ARP), Router Discovery as well as Router Redirection:

  • ROUTER SOLICITATION
    Hosts inquire with Router Solicitation messages to locate router on an attached link. Routers which receive the solicited packets will generate Router Advertisements immediately upon receipt of this message rather at their next scheduled time.
  • ROUTER ADVERTISEMENT
    Routers advertise their presence together with various link parameters either periodically, or in response to a Router Solicitation message.
  • NEIGHBOR SOLICITATION
    Neighbor solicitations are used by nodes to determine the link layer address of a neighbor, or to verify that a neighbor is still reachable via a cached link layer address.
  • NEIGHBOR ADVERTISEMENT
    Neighbor advertisements are used by nodes to respond to a Neighbor Solicitation message.
  • REDIRECT
    Router may inform hosts of a better first hop router for a destination.

IPv6 hosts can configure themselves automatically (SLAAC) when connected to an IPv6 network following the Neighbor Discovery Protocol, by using Router Discovery messages. When first connected to a network, a host has to send a Router Solicitation multicast request for its configuration parameters. The message is received by all nodes but only routers are the ones to process it. When the default gateway receives the Solicitation message, it has to respond immediately with a Router Advertisement informing the sender about its Link-local address, MAC address as well as Internet Layer configuration parameters. Routers present a special case of requirements for address configuration, as they often are sources of autoconfiguration information, such as router and prefix advertisements. This leads to the host configuring its own IPv6 addresses , as well as discovering the IPv6 and MAC address of the gateway.

Similar to default gateway address resolution, the MAC address of a local host can be discovered by sending Neighbor Solicitation messages requiring the MAC address of the receiver, for the given IPv6 address. The response is sent by the form of a Neighbor Advertisement message, containing all the appropriate information about the inquired host.
Every pair of IPv6/MAC addresses, originated from a neighbor, is saved locally as a new entry in the neighbor discovery cache. When communication between two nodes is required, hosts will inquire the appropriate origin of the table, about their IPv6/MAC pairs, in order to maintain an up to date discovery cache. The reachability of a neighbor node is determined by monitoring the state of the neighboring node’s entry in the cache. RFC 2461 defines the following states:

INCOMPLETE
IPv6 address resolution, which is using a solicited-node multicast Neighbor Solicitation message, is in progress. The INCOMPLETE state is entered when a neighbor cache entry is created but does not yet have the node’s corresponding Link-layer address.
REACHABLE
Reachability has been confirmed by receipt of a solicited unicast Neighbor Advertisement message. The neighbor cache entry stays in the REACHABLE state until the number of milliseconds indicated in the Reachable Time field in the Router Advertisement message elapses.
STALE
Reachable time (the duration since the last reachability confirmation was received) has elapsed. The neighbor cache entry enters the STALE state after the number of milliseconds in the Reachable Time field in the Router Advertisement message (or a host default value) elapses, and the entry remains in this state until a packet is sent to the neighbor. The entry also enters the STALE state when the host receives an unsolicited Neighbor Advertisement message that is advertising the Link-layer address.
DELAY
To allow time for upper layer protocols to provide reachability confirmation before sending Neighbor Solicitation messages, the neighbor cache entry enters the DELAY state and waits a configurable period of time after sending a packet. If reachability is not confirmed by the delay time, then the entry enters the PROBE state, and a unicast Neighbor Solicitation message is sent.
PROBE
Reachability confirmation is in progress for a neighbor cache entry that was in the STALE or DELAY state. Unicast Neighbor Solicitation messages are sent at intervals corresponding to a retransmission timer field in the Router Advertisement message that this host received. A configurable variable determines the number of Neighbor Solicitation messages sent before the reachability detection process is abandoned and the neighbor cache entry is removed.

The NDP spoofing algorithm consists of two parts:
* The adversary sends Neighbor Advertisement messages to the victim with a certain frequency, informing him that he is the default gateway. This is achieved by crafting a Neighbor Advertisement packet with gateway's Link-local address as the source, paired with the adversary’s MAC address. In addition to this, Neighbor Advertisement packet contains three flag bits R,S,O. R-bit indicates that the sender is a router, S-bit indicates that the advertisement was sent in response to a Neighbor Solicitation from Destination address and O-bit indicates that the advertisement should override an existing cache entry. By enabling R/O-bits on the Advertisement message the victim updates his cache entry representing the gateway, with the adversary’s MAC address. Since the S-bit is also enabled the victim doesn’t send a revalidation Neighbor Solicitation message to verify the IPv6/MAC pair and marks its entry as REACHABLE. This results into the victim forwarding all of his IPv6 traffic to the adversary.
* The adversary listens for Neighbor Solicitation messages sent from the victim and responds falsely with its own MAC address by sending crafted Neighbor Advertisements. Combined with the spoof loop, this technique ensures that during an Unsolicited Router Advertisement, router’s accurate IPv6/MAC entry will not be cached for a considerable amount of time, leading the victim into directing all of its traffic to the right direction instead of the adversary.

IPv6 extension on Bettercap has a specific algorithm for discovering matches between IP and MAC addresses (including gateway's MAC in case of an error at the lookup). NDP discovery agent is responsible for activating this procedure. First, it performs a lookup into the neighbor discovery cache and if no entry is found matching the specific address, it then sends a Neighbor Solicitation message on the wire, seeking for a proper response. The message consists of a multicast IPV6 address. This address is created by the prefix ff02::1:ff plus the 24 least significant bits of the destination address. An example is:

Prefix : ff02::1:ff
Target Address: 2001:0db8:85a3:0000:00bd:8a2e
Multicast Address: ff02::1:ffbd:8a2e

When the targeted host receives the message, it responds to the sender so he can update his cache entry with the valid data.

The current Ruby implementations on low level packet crafting (with PacketFu library being the most famous among them and the one Bettercap is using) do not provide the ability to create Neighbor Discovery packets. PacketFu’s ICMPv6 old packet formats only provide error reporting and network diagnostics. However NDP extended those capabilities on RFC 4861 by adding multiple header fields serving the protocol’s purposes. So in order to extend Bettercap capabilities, we created a PacketFu patch supporting NDP packet manipulation.

As an adversary, being in the middle of a host and a router, requires a proper grouping of the victim's traffic in order to inject the desired javascript code. The HTTP responses of the majority of the websites are directed to the receiver's port number 80. By using the ip6tables library we create a firewall redirecting the incoming packets with the victim's address source and port number 80, to a locally deployed proxy.
The proxy’s core role is collect every packet sent by ip6tables rules and create readable HTML source code out of the HTTP responses. Then the proxy injects the javascript code at the top of the tag of the HTML page. As a result of that, the HTTP proxy sends an HTML response with injected javascript code to the victim, ready to be executed by the victim's browser.

This concludes the attack on IPv6 endpoints using Bettercap. Here is a short demo video of Bettercap working on an IPv6 network and attacking an IPv6-only site (you can see the adversary running Bettercap on the left and the victim's IPv6 page being injected with Javascript content on the right):