Command Injection on a D-Link Router
During the COVID-19 pandemic, I wanted to extend the local WiFi in my home to reach all the floors. The goal was to have full connectivity from every location in the house.
As excited as I was to deploy the device and extend my network, eventually we decided to keep the top floor WiFi free, and I was left with a spare router.
I decided to dive into some research on the device.
Starting off
To connect to its default access point (AP), you need to type the hardcoded token listed on the bottom of the device, as well as the user name, password, and the gateway address into the device's web interface. Once loaded, I started to browse the user interface. It looked like many other D-LINK products related to home networks, so I was in comfortable territory.
DAP-1360 - overview
The D-Link DAP-1360, according to the company's documentation, can "provide your wired network with wireless connectivity or upgrade your existing wireless network and extend its coverage."
The vulnerability I discovered was found in H/W Ver. A1, F/W Ver. 2.5.5, within the ping functionality of the web interface.
The ping utility
I ran a quick scan of the UI, looking for a weak spot that might be exploitable. I found a built-in function acting as a potential exploit vector - the ping utility.
The ping utility lets you check the availability of a host from a local or global network. On the device, the ping utility sends echo requests to a specified host and receives echo replies.
What happens when I enter an IP address and hit start? The IP is inserted into a GET request query parameter, with a JSON format along with other parameters required in order for the OS (script or listener) to respect the request.
For example:
GET
/index.cgi?v2=y&proxy=y&rq=y&res_json=y&res_data_type=json&res_config_action=3&res_config_id=18&res_buf={%22host%22:%22192.168.0.5%22,%22count%22:1}&res_struct_size=0&res_pos=-1&tokenget=1268&&_=1593893639702 HTTP/1.1
Host: 192.168.0.5
I see the position of the parameter inside the payload. With that information, I turned to Burp Suite, a collection of security tools used for vulnerability assessments and penetration testing.
Within Burp Suite, I positioned the §p1val§ around the index of the IP and loaded it with payloads.
I used several known CMDi lists from PayloadsAllTheThings.
Fortunately, the device did not ban me after multiple attempts, so I managed to find a format that responds with a valid status and retrieves a valid payload. To do this quickly, I had set special regex to extract the data from the response so it would appear in the main results window, instead of opening each response separately.
Another useful tip for penetration testers would be to check the size of the response, bigger size sometimes means we got a valid or different response from the server which is worth expanding if no extracts were applied.
Results
If you add '| ls -l'" to the hardcoded ping, encoded to %7c%20ls%20-l%22 (pipe <command>), the ping will run as expected, before my injected command. In this case, ls -l is the directory listing command.
Here's a snapshot of the response in Burp Suite:
How a malicious request looks
GET /index.cgi?v2=y&proxy=y&rq=y&res_json=y&res_data_type=json&res_config_action=3&res_config_id=18&res_buf={%22host%22:%22192.168.0.52%7c%20ls%20-l%22,%22count%22:1}&res_struct_size=0&res_pos=-1&tokenget=1268&&_=1593893639702 HTTP/1.1
Host: 192.168.0.52
Implications
Because the utility of the D-Link router will accept any command, an attacker can view, edit, or create any folder or file on the device. This opens the door to a number of attacks.
Let's say I login as "user" and the permissions on this account mean I can browse and manage the device, but I'm unable to login to the filesystem. In this example, the ping utility is in the OS and runs under a higher privileged account when compared to 'user'. This is a simple example of privilege escalation.
In the same scenario, a malicious user would be able to implement a persistent backdoor, allowing them to access the machine, with a higher privileged user on a regular basis, hidden from the conventional traffic logged by the device.
Disclosure
Discovering a vulnerability, requires a strict protocol of ethical disclosure. Once my findings were confirmed, I worked with the D-Link security team to address the issues by disclosing it to them directly. They were able to confirm the vulnerabilities and release a patch to fix them.
The fixes were released in Firmware update 3.0.1.
Timeline
4/07/2020: Report to d-link
5/07/2020: D-link security team response - waiting for their verification
15/07/2020: D-link confirms CMDi, providing a firmware for me to test the fix
18/07/2020: Tested the latest provided firmware, the vulnerability does no longer exist.
06/10/2020: CVE-2020-26582 assigned
DLINK's Confirmation:
