DHCP Games with Smart Router Devices

During a recent engagement, we identified a recurring and interesting scenario involving smart router devices. We define smart router devices as devices with functionality that requires them to provide services beyond basic routing to an internal LAN network, and relies on a WAN interface that uses DHCP to obtain an IP configuration for an uplink connection. These internal LAN networks could be exposed outside of the device (your traditional router style device) or be an embedded device using an entirely internal Ethernet network for intra-component connections. In the case of an embedded device, the use of an internal Ethernet network maybe completely unknown to the end user!

Here are few examples of smart routers:

• A site-to-site VPN device
• A router with network attached storage (NAS) services
• A security system with DVR capabilities that host their own network for cameras and other remote sensors
• A router with HTTP admin pages
• A router with Proxy Servers
• An embedded device using an internal Ethernet network to connect components

  

Assuming the posture of an adversary, we consider: What happens if a malicious DHCP server on the WAN port serves IP configurations intended to actively collide with the network space of the internal LAN network? How does this affect the routing decisions made by the smart router? With a malicious DHCP server, can we convince the smart router to route packets destined for the internal LAN out the WAN port?

 

In our experience, the answer to the last question is usually yes! We have collected several techniques to influence the routing table of the smart router and unless the smart router has explicit defenses, we usually can cause packets intended for the LAN network to be routed out the WAN port.

Why the emphasis on smart routers? Because with a simple router, an attacker who is in position to spoof a DHCP server would most likely already be able to intercept any WAN traffic and so would not gain much by creating network configurations that collide with the internal LAN. But with a smart router, packets that did not exist on the WAN port travel from the router to hosts on the internal LAN network. Examples include video streams when the router is acting as a DVR for security cameras, decrypted site-to-site VPN packets, file sharing packets, etc. Those packets are our target.

It should be noted that this blog post is about malicious DHCP servers and smart router devices - devices that people plug into their existing home or business networks. Most routers connected to ISPs use other protocols for IP configuration such as PPPoE and not DHCP (although if your ISP/upstream provider utilizes DHCP, these techniques could apply). We also assume that you, posing as an adversary, have somehow gained access to your home or business network.

Isn’t this so 1990s?

Malicious DHCP servers are nothing new. Section 7, Security Considerations, RFC 2131 from 1997 clearly states they can be spoofed and false information sent:

Unauthorized DHCP servers may be easily set up. Such servers can then send false and potentially disruptive information to clients such as incorrect or duplicate IP addresses, incorrect routing information (including spoof routers, etc.), incorrect domain nameserver addresses (such as spoof nameservers), and so on.

Even with that warning 20+ years ago, many current systems discount the threat of a malicious DHCP server and simply ignore the issue.

DHCP methods to control routes

We have come up with several methods a malicious DHCP server can use to control routing of smart router device:

• Assign a More Specific Subnet - By default, routers usually prioritize the route with the longest subnet mask. The smaller/more specific the subnet, the higher the priority.
• Use the Classless Static RouteOption (DHCP Option 121) - This DHCP option allows the DHCP server to specify static routes for hosts and networks in the routing table on the client. In many cases, router devices will apply these routes without first checking if they conflict with the internal LAN.
• Use the Static Route Option (DHCP Option 33) - This older DHCP option only allows static routes to hosts (not networks, as the previous option allows). Depending on the age and configuration of the DHCP client, it may support this option instead of or in addition to Classless Static Routes.
• Specify a Default Gateway (DHCP Option 3) - When all else fails, assign a default gateway with the same IP address as a device on the internal LAN. Depending on how the DHCP client configures routes, this may configure a route that redirects packets to that internal host out onto the WAN interface.

What is the impact?

So understanding that we can redirect internal LAN packets out the WAN port, how can we, as an adversary, take advantage of this?

• Denial of Service - The easiest and most obvious impact is a denial of service (DoS). By redirecting LAN packets out the WAN the smart router is no longer able to communicate with LAN hosts. Usually this is just annoying, but there can be more serious impacts. For example, if the smart router is acting as DVR for security cameras, the system may no longer record video streams, leaving the premises without surveillance coverage.
• Snooping Router Responses - If the smart router is hosting a service, redirecting the internal LAN network out the WAN interface would cause any responses from the router to be redirected out to the WAN network where a waiting adversary could capture the response packets and the data within. The data being transferred at the time of the attack could contain sensitive data. For instance, a user may be copying a sensitive file from a router acting as a NAS, using a site-to-site VPN to secure an unencrypted network connection, etc.
• Spoofing Internal LANHosts & InjectingData - Lastly, depending on the smart router’s firewall configuration, an attacker may be able to take over communication streams and inject data. This can happen in several ways:
  • Smart Router Initiated Connections - Unless the router has bound the socket to the internal LAN interface before attempting to connect, a smart router that connects out to an internal LAN host will redirect and cause the connection to be made using the WAN interface. This will use the WAN interface’s IP address as the source address and establish a connection through the firewall. At this point an attacker on the WAN network can spoof the internal LAN host’s IP address, respond to the connection request, and complete the session establishment.
  • Internal LAN Host-Initiated Connections - When an internal LAN host initiates the connection, say a TCP connection, it sends the TCP SYN to the smart router. Since the routes are redirected, the smart router sends the TCP SYN-ACK out the WAN interface. Unlike a smart router initiated connection, the source and destination IP address are from the internal LAN interface. In order to capture the session, the attacker on the WAN network will have to wait for an internal LAN host to start a connection, capture the TCP SYN-ACK, manually finish the TCP three-way handshake, and maintain the TCP sequence numbers using RAW sockets. The same steps must be followed if UDP communication is being used, only it is easier as the attacker does not need to maintain TCP sequence numbering.
    
    The smart router may have firewall rules that could block these packets, but in our experience most devices allowed established connections on the WAN and the above sequence would satisfy those firewall rules (Linux’s conntrack module does not track interfaces, just IPs and ports). The conntrack tool can be used to display the existing entries and the information used to identify the connection:

    $ conntrack -L
    tcp 6 431999 ESTABLISHED src=10.10.10.23 dst=10.10.10.25 sport=61544 dport=80 src=10.10.10.25 dst=10.10.10.23 sport=80 dport=61544 [ASSURED] mark=0 use=1
    

  • Existing Connections - An attack against an existing connection is similar to the internal LAN host-initiated connections except the attacker must pick up the communication mid-stream, and manually sync TCP sequence and acknowledgement numbers, and application level responses. This approach maintains the session and injects data.

Redirection Examples

To demonstrate the DHCP methods to control routes described above, we begin with some setup steps:

• Set up an OpenWRT-based smart router (OpenWRT Version 21.02.0-rc1) with a WAN configured to obtain an IP address via DHCP.
• Set up an internal LAN network (10.10.10.0/24) running a DHCP server for internal LAN hosts.
• Install a number of services to provide additional functionality to LAN hosts (site-to-site VPN, NAS, etc.).

For the malicious DHCP server, we used dnsmasq and some carefully crafted configuration files.

A more specific subnet

Route specificity is the first deciding factor when selecting a route. A class A (/24) route has priority over a class B (/16) route. So what happens if our malicious DHCP configures the WAN to sit inside the LAN network?

For this example we have an internal LAN network of 10.10.10.0/24 and we configured the WAN to have a network of 10.10.10.0/25 using the following dnsmasq configuration:

dhcp-range=10.10.10.2,10.10.10.100,255.255.255.128

On our victim router, we can see the effects in the routing table, with the 10.10.10.0/25 entry routing the more specific subnet out the WAN interface:

# netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         10.10.10.1      0.0.0.0         UG        0 0          0 wan
10.10.10.0      0.0.0.0         255.255.255.128 U         0 0          0 wan
10.10.10.0      0.0.0.0         255.255.255.0   U         0 0          0 lan

If our router attempts to reach out to a device on the LAN, say at IP 10.10.10.23, it will be routed out via the WAN interface. We can verify this using the ip route get command to see what the routing decision would be:

$ ip route get 10.10.10.23
10.10.10.23 dev wan src 10.10.10.7 uid 0 

Classless Static Route

The Classless Static Route option (DHCP Option 121) allows the DHCP server to configure additional routes on the client. If the router does not check if the route conflicts with the internal network, we can use this option to add a route to redirect the LAN traffic out the WAN port.

 

The following dnsmasq configuration demonstrates the issue. It uses the force flag to ensure this option is always included, even if the DHCP client did not request additional routes:

dhcp-range=192.168.57.100,192.168.57.200,255.255.255.0
dhcp-option-force=121,10.10.10.1/24,192.168.57.1

DHCP clients are not supposed to respond to any option that it did not request. However should not is not the same as does not.

In the routing table, we can see the effects with a 10.10.10.0/24 route using 192.168.57.1 and wan as the interface:

$ netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         192.168.57.1    0.0.0.0         UG        0 0          0 wan
10.10.10.0      192.168.57.1    255.255.255.0   UG        0 0          0 wan
10.10.10.0      0.0.0.0         255.255.255.0   U         0 0          0 lan
192.168.57.0    0.0.0.0         255.255.255.0   U         0 0          0 wan

In this case, two routes actually have the same specificity: one using the wan interface, the other out the lan. In order to break the tie, administrative distance is used. On Linux, a static route has a higher priority than a dynamically generated link route, so the static route configured by the malicious DHCP server wins and the packets are routed out the wan interface.

The ip route get command again shows that internal hosts are being routed out the wan interface:

$ ip route get 10.10.10.23
10.10.10.23 dev wan src 10.10.10.7 uid 0 

Static Route

The Static Route option (DHCP Option 33) specifies a list of static routes that a client should add to its routing table. This option predates the Classless Static Route option (DHCP Option 121) we just reviewed which is now the preferred method for configuring static routes.

The Static Route option has some limitations. It is obsolete so the targeted router may not support this feature. In addition, this option allows for specifying a static route only for hosts, not networks, so each targeted host requires an entry.

The following dnsmasq configuration configures the WAN to be in the 192.168.57.1/24 network, and forcibly includes a Static Route (DHCP Option 33) to redirect 10.10.10.23 to a WAN IP:

dhcp-range=192.168.57.100,192.168.57.200,255.255.255.0
dhcp-option-force=33,10.10.10.23,192.168.57.1

Default gateway

What if none of the routing tricks above work? Then you can try the method of last resort: Configure the default gateway to collide with an internal LAN device. When configuring the routing tables, the victim router may create a host route to the default gateway.

If the DHCP client requires the default gateway to be in the same subnet as the WAN network, then the malicious DHCP server can overlap the WAN network with the internal LAN. This sample configuration specifies a WAN that includes the entire 10.0.0.0/8 private network address space and sets the default gateway (DHCP Option 3) with the same IP address as one of the LAN devices:

dhcp-range=10.10.10.2,10.10.10.100,255.0.0.0
dhcp-option=3,10.10.10.23

A trick that works on some routers is to specify a route that is outside the WAN network. Some configuring scripts think the routing needs a bit more help and will add a host route to the default gateway in addition to the 0.0.0.0/0 default gateway route.

 

 

The dnsmasq configuration for this scenario:

dhcp-range=192.168.57.100,192.168.57.200,255.255.255.0
dhcp-option=3,10.10.10.23

The resulting host route can be seen in the routing table:

$ netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         10.10.10.23     0.0.0.0         UG        0 0          0 wan
10.10.10.0      0.0.0.0         255.255.255.0   U         0 0          0 lan
10.10.10.23     0.0.0.0         255.255.255.255 UH        0 0          0 wan
192.168.57.0    0.0.0.0         255.255.255.0   U         0 0          0 wan

Since the most specific route wins, IP packets destined to 10.10.10.23 now get routed out the wan interface.

$ ip route get 10.10.10.23
10.10.10.23 dev wan src 192.168.57.126 

Practical uses

So we can spoof a DHCP server and redirect traffic from an internal LAN network out the WAN, what can we do with it? Here are couple of examples:

• Attack a Site-to-Site VPN and disclose response packets
• Disclose data from a Network Attached Storage (NAS) file transfer

Site-to-site VPN

In this example the smart router device is configured with a site-to-site VPN to a remote office and tunnels any traffic from the internal LAN to the remote office through the VPN. We then started pinging a host on the other side of the VPN from a LAN host. Sniffing on the WAN interface, we can see the encrypted Wireguard VPN packets containing the pings:

When the router’s DHCP lease expired, our malicious DHCP server slipped in a Classless Static Route to route the internal LAN network 10.10.10.1/24 out to a WAN IP address:

Once the Classless Static Route has been applied, we can see an outgoing encrypted packet, an incoming encrypted packet containing a response for an internal LAN host, and then the decrypted packet being redirected out the WAN interface!

The sensitivity of the data being disclosed is obviously dependent on what is being transferred and whether the communication streams within the VPN are further encrypted with TLS/SSL.

Network Attached Storage

Connected a USB to your router as a Network Attached Storage (NAS) device. That’s safe right?

We used the Classless Static Route option to redirect the internal LAN when the DHCP lease expired.

The smart router device is running an SMB server to provide Network Attached Storage services to the internal LAN hosts. The response from the router device to the internal hosts is redirected out of the WAN port, disclosing potentially sensitive information.

While it was nice to receive a few packets of the sensitive file, but how about the rest of the file? We would need to preform a TCP MiTM style attack and spoof proper TCP ACK packets. To demonstrate this we built a basic Scapy script:

#!/usr/bin/env python
import argparse
from scapy.all import *

parser = argparse.ArgumentParser()
parser.add_argument("port", type=int)
parser.add_argument("--iface", default=None)
args = parser.parse_args()

def on_packet(pkt):
    eth = pkt
    ip = eth.payload
    tcp = ip.payload
    data = tcp.payload
    if tcp.flags.A and isinstance(data, NoPayload):
        pass # didn't receive any data no need to send an ack
    # build our response
    rsp_eth = Ether(dst=eth.src, src=eth.dst)
    rsp_ip = IP(dst=ip.src, src=ip.dst)
    # lets ack whatever we have received...
    rsp_tcp = TCP(dport=tcp.sport, sport=tcp.dport, window=0xffff, flags="A")
    rsp_tcp.seq = tcp.ack
    rsp_tcp.ack = tcp.seq + len(data)
    sendp(rsp_eth/rsp_ip/rsp_tcp, iface=args.iface)

sniff(filter=f"tcp and src port {args.port}", iface=args.iface, prn=on_packet)

By spoofing the ACK packets, the rest of the file transfer can be captured:

The above scenario only works if the smart router’s firewall is configured in such a way to allow TCP ACKs on the WAN interface. As mentioned earlier, Linux’s conntrack only tracks IP addresses, ports, and state, not interfaces. Most Linux based smart routers have a rule to allow established connections on the WAN interface, so packets related to an established connection will pass the firewall.

Remediation and mitigation

In order to protect against malicious DHCP servers , smart router devices need to protect their internal LAN networks against hostile IP configurations or reduce the potential impact with methods such as:

• IP Configuration Sanitization
• Firewall Rules
• TLS/SSL/End-to-End Encryption

IP configuration sanitization

A smart router can perform several checks to prevent a malicious DHCP server from interfering with the internal LAN network:

• If the IP network assigned to the WAN collides with the internal LAN there should be a strategy to handle the situation. Depending on the device, this could be shifting the internal LAN to another network, or rejecting the IP configuration and alerting the user to the problem.
• Default gateways that land inside the internal LAN networks should be rejected.
• Attempts to configure static routes that collide with internal LAN networks should be rejected.

Firewall rules

The smart router’s firewall configuration should also contain egress and anti-spoofing rules:

• Egress filtering to prevent internal LAN network IPs from going out any interface other than the internal LAN interface.
• Anti-spoof filters that drop incoming packets destined to internal LAN networks that arrive on non-internal LAN interfaces.

An example iptables configuration:

INTERNAL_NET=10.10.10.1/24
INTERNAL_IF=lan
# Egress filtering
iptables -A OUTPUT -d ${INTERNAL_NET} ! -o ${INTERNAL_IF} -j DROP
iptables -A OUTPUT -s ${INTERNAL_NET} ! -o ${INTERNAL_IF} -j DROP
iptables -A FORWARD -d ${INTERNAL_NET} ! -o ${INTERNAL_IF} -j DROP
iptables -A FORWARD -s ${INTERNAL_NET} ! -o ${INTERNAL_IF} -j DROP
# anti-spoof
iptables -A INPUT -d ${INTERNAL_NET} ! -o ${INTERNAL_IF} -j DROP
iptables -A INPUT -s ${INTERNAL_NET} ! -o ${INTERNAL_IF} -j DROP

The above rules will not stop a malicious DHCP server from creating a denial of service condition, but will prevent the exposure of data.

TLS/SSL/end-to-end encryption

Developers tend to be loose about using encryption when communicating on internal networks, believing other controls make it unnecessary. As shown here, that is not always a safe assumption. Use of encryption/TLS would help mitigate some of the impacts of DHCP attacks. While encryption cannot prevent the attack from happening, encryption would make the contents of the network communications unreadable and prevent injection of data. Of course, proper verification of encryption certificates would still be required.

Conclusion

In this research, we explored a key question: With a malicious DHCP server, could we, posing as an adversary, convince the smart router to route packets destined for the internal LAN out the WAN port?

We reviewed some methods a malicious DHCP server can use to control the routing of a smart router device and later provided examples:

• Assign a More Specific Subnet
• Use the Classless Static Route Option
• Use the Static Route Option
• Specify a Default Gateway

We also described potential impacts of such a compromise including:

• Denial of Service
• Snooping Router Responses
• Spoofing Internal LAN Hosts and Injecting Data

Next we discussed how an adversary could practically use these weaknesses to disclose packets from a site-to-site VPN and a router acting as a NAS.

Finally, we touched upon several ways to avoid such attacks or reduce the potential impact with:

• IP Configuration Sanitization
• Firewall Rules
• TLS/SSL/End-to-End Encryption