In the snippet above, we can find a similar structure as in the GET handler: a cascade-like series of blocks. In Block A, we have the following:

Block B does the following:

It calls the strcmp function (30) with the result of find_val from Block A as the first parameter (31). The second parameter is the string “reboot” (29). If the op parameter has the value reboot, then it moves to Block C:

It first calls a function I renamed get_cookie_sid (32), passes the returned value to dml_dms_ucmd (33) and calls it (34). Then it moves on:

For instance, when no SID cookie is specified, we observe the following response from the server.

Request without any cookie:    
  

•         Receive POST request ‘/op=<name>’
•          Call get_cookie_sid
•         Call dms_dms_ucmd  

First, we check to see what get_cookie_sid does:

The returned value then passes as the first parameter when calling dml_dms_ucmd (implemented in the libdml.so library). The authentication check surely must be in this function, right? Let’s have a look:

Response:

Yes, it does mean that whatever SID cookie value you provide, the router will accept it as proof that you’re an authenticated user!

From Admin to Root

•          Provide any SID cookie value
•         Read the system logs and use the listed admin SID cookie values
•         Use the hardcoded hidden 700000000000000 SID cookie value

Our next step is to try elevating our privileges from admin to root user.

We have analyzed the POST request handler and understood how the op requests were processed, but the POST handler can also handle XML requests:

When receiving a request with a content type (45) containing text/xml (46), the POST handler retrieves the SID cookie value (47) and calls dml_dms_uxml (48), implemented in libdml.so. Somehow, dml_dms_uxml is even nicer than dml_dms_ucmd:

The function dml_dms_uxml is responsible for parsing the XML in the request body and finding the corresponding callback function. For instance, when receiving the following XML request:

The function dml_dms_uxml will check the cmd parameter and find the function handling the traceroute command. The traceroute handler is defined in libdml.so as well, within the function dl_cmd_traceroute:

First, dl_cmd_traceroute tries to retrieve the value of the parameter named address or addr (54) in the XML data (52) by calling conf_find_value (53) and stores it in s0 (55).

Moving forward:

Let’s have a look at dl_cmd_traceroute_th:

Using our previous request, dl_cmd_traceroute_th will execute the following:

As you may have already determined, there is absolutely no sanitization of the XML address value, allowing an OS command injection. In addition, the command runs with root privileges:

When accessing:

At this point, we can do anything:

• Eavesdrop the traffic on the router using tcpdump
• Modify the configuration to redirect traffic wherever we want
• Insert a persistent backdoor
• Brick the device by removing critical files on the router

For instance, on boot the BHU WiFi uRouter enables SSH by default:

It also rewrites its hardcoded root-user password every time the device boots:

It’s installed on the uRouter:

The BHU WiFi uRouter is using Privoxy with a configured filter that I would not describe as “enhancing privacy” at all:

Sadly, the above URL is no longer accessible. The domain hosting the JS file does not respond to non-Chinese IP addresses, and from a Chinese IP address, it returns a 404 File Not Found error.

Nevertheless, a local copy of ad.js can be found on the router under /usr/share/ad/ad.js. Of course, the ad.js downloaded from the Internet could do anything; yet, the local version does the following:

• Injects a DIV element at the bottom of the page of all websites the victim visits, except bhunetworks.com.
• The DIV element embeds three links to different BHU products:
  • http://bhunetworks.com/BXB.asp  
  • http://bhunetworks.com/bms.asp
  • http://bhunetworks.com/planview.asp?id=64&classid=3/

In addition, uRouter loads a very suspicious kernel module on startup: