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.

**SUMMARY**

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.

**CONFIRMED VULNERABLE VERSIONS**

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

**PRODUCT URLS**

RT-AX82U - https://www.asus.com/us/Networking-IoT-Servers/WiFi-Routers/ASUS-Gaming-Routers/RT-AX82U/

**CVSSv3 SCORE**

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

**CWE**

CWE-119 - Improper Restriction of Operations within the Bounds of a Memory Buffer

**DETAILS**

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.

**Crash Information**

    $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'
    

**TIMELINE**

2022-08-23 - Vendor Disclosure  
2022-11-16 - Vendor Patch Release  
2023-01-10 - Public Release

Discovered by Lilith >\_> of Cisco Talos.

CVE-2022-38105: TALOS-2022-1590 || Cisco Talos Intelligence Group

Lilith >_> of Cisco Talos discovered these vulnerabilities.
Cisco Talos recently discovered three vulnerabilities in Asus router software.
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 other routers, it is configurable via

Tuesday, January 10, 2023 11:01

_Lilith >\_> of Cisco Talos discovered these vulnerabilities._

Cisco Talos recently discovered three vulnerabilities in Asus router software.

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 other routers, it is configurable via an HTTP server running on the local network. However, it can also be configured to support remote administration and monitoring in more of an IOT style.

Talos has identified TALOS-2022-1586 (CVE-2022-35401), an authentication bypass vulnerability that can lead to full administrative privileges. An attacker would need to send a series of HTTP requests to exploit this vulnerability.

TALOS-2022-1590 (CVE-2022-38105) is an information disclosure vulnerability in the opcode of the router’s configuration service that can lead to a disclosure of sensitive information. An attacker can send a network request to trigger this vulnerability.

TALOS-2022-1592 (CVE-2022-38393) is a denial of service vulnerability, also in the opcode of the configuration service. A specially crafted network packet can lead to denial of service. An attacker can send a malicious packet to trigger this vulnerability.

Cisco Talos worked with Asus to ensure that these issues were resolved and an update is available for affected customers, all in adherence to Cisco’s vulnerability disclosure policy.

Users are encouraged to update this affected product as soon as possible: Asus RT-AX82U 3.0.0.4.386\_49674-ge182230. Talos tested and confirmed this version of Asus could be exploited by these vulnerabilities.

The following Snort rules will detect exploitation attempts against these vulnerabilities: 60394 and 60473. Additional rules may be released in the future and current rules are subject to change, pending additional vulnerability information. For the most current rule information, please refer to your Firepower Management Center or Snort.org.

Vulnerability Spotlight: Asus router access, information disclosure, denial of service vulnerabilities discovered

Categories: News
Tags: polite WiFi

Tags:  WiPeep

Tags:  triangulation

Tags:  battery drain

Researchers have found that the WiFi protocol is a bit too polite when acknowledging received packets from outside the own network.



(Read more...)




The post Polite WiFi loophole could allow attackers to drain device batteries appeared first on Malwarebytes Labs.

Posted: January 10, 2023 by

Researchers at the University of Waterloo in Ontario have further researched a loophole in the WiFi protocol that was dubbed “polite WiFi”.

Last year the researchers published a study in which they showed someone could use this loophole to triangulate the location of any WiFi enabled device. Now, they've followed up that study to say that someone could also drain the batteries of such device. A further study may involve privacy threats based on interference of the usage of the device with the response time.

**Polite WiFi**

A MAC address (media access control address) is a unique identifier assigned to a network interface controller (NIC) for use as a network address in communications within a network segment. This use is common in most IEEE 802 networking technologies, including Ethernet, WiFi, and Bluetooth.

The “polite WiFi” loophole is based on the fact that a WiFi enabled device responds to every correct packet it receives, as long as it is directed at its own MAC address. This means the sending device does not have to be on the same network.

**Wi-Peep**

Based on this knowledge and knowing the response time, the researchers built a drone equipped with some readily available parts and sent it out on a scouting mission. Because the drone is on the move it can use triangulation to pinpoint the location of the responding devices.

Within seconds, a burglar equipped with such a device would know with an accuracy of a meter/yard where your WiFi enabled devices like phones, tablets, TVs and other “smart” devices can be found in your home. And, in a similar fashion a criminal could track the movements of security guards inside a bank by following the location of their phones or smartwatches.

**Drained batteries**

The goal of the battery draining attack is to drain the battery of a WiFi device by forcing the device to transmit WiFi frames continuously. To execute such an attack, an attacker could send back to back fake 802.11 frames to the target device. This forces the target devices to continuously transmit acknowledgment packets, draining its battery. This could be used in a coordinated attack at CCTV cameras that switch to batteries when the power has been cut.

**Prevention**

The attacks based on polite WiFi are based on the fact that WiFi devices have to reply with an Acknowledgment (ACK) signal. The ACK signal is sent by the receiving station (destination) back to the sending station (source) after the receipt of a recognizable block of data of specific size. This is usually the start of a more meaningful conversation, but it doesn’t have to be.

To prevent WiFi devices from responding to signals with a malicious intent the device would have to verify if the frame is legitimate before sending an ACK. Unfortunately, this is not possible due to the WiFi standard timing requirements.

The researchers propose some future changes to the WiFi protocol that make it possible to establish whether a frame is legitimate before the ACK is sent.

And they recommend that WiFi chip manufacturers introduce an artificial, randomized variation in device response time, which would make calculations such as those performed by the Wi-Peep inaccurate.

**We don’t just report on threats—we remove them**

Cybersecurity risks should never spread beyond a headline. Keep threats off your devices by downloading Malwarebytes today.

**RELATED ARTICLES**

Polite WiFi loophole could allow attackers to drain device batteries

By Owais Sultan
There are certain degrees to which digital security matters for your digital signs. This article is going to…
This is a post from HackRead.com Read the original post: The Importance of Data Security for Digital Signage

There are certain degrees to which digital security matters for your digital signs. This article is going to cover some of the most common. Do try to use a secure Wi-Fi network, use a secure digital signage app, and make sure your hardware is protected from tampering. Do these simple things and you make it difficult for nefarious parties to ruin your digital signs.

**Digital Signage**

Digital signage is a type of electronic display that can be used to communicate information to customers or visitors. It is typically used in public areas such as retail stores, corporate offices, schools, and hospitals. Digital signage can be used for a variety of purposes including providing directions and advertising products or services.

Digital signage consists of hardware such as LCDs, projectors, TVs, or video walls which are connected to a media player. The media player is responsible for displaying content on digital displays which can include images, videos, web pages and text messages.

Further, the Content can also be updated remotely via an internet connection allowing it to be changed quickly and easily from anywhere in the world. Digital signage also offers businesses the ability to gather analytics about their customers such as how long they view certain content or what content they interact with most often.

**A Hard Wired Digital Sign**

Let’s say you have a digital sign that isn’t connected to a network. It runs its content because you have loaded it into the device, or it is on a hard drive being played on a loop. In these circumstances, all you have to do is secure your digital sign hardware from anybody trying to turn it off or trying to add a different hard drive to change your content.

**A Digital Sign With Poster Images**

Let’s say that you have a digital sign, but you use it to replace your paper posters. As a result, you have still images, perhaps running on a PowerPoint display, and your digital signs are not in very high traffic or notable areas. This is another low-security situation where you will probably not be targeted.

**A Digital Sign in a High-Traffic Area**

Let’s say your digital sign shows video content in a pretty high-traffic area. It may be at a vital point in a mall, or perhaps somewhere important over a busy highway. In these cases, you are at risk from people tampering with the hardware, and from people trying to hack the system to gain access to your signs.

In these cases, they want access so they can display their content. If their content is in some way damaging, then you can be criminally charged if you do not take all care and due diligence to secure your devices and your network.

**A Digital Sign That Accepts Customer Information**

As they say, “if you are not paying for a product, then you are the product.” If people are entering their information into your digital signs, perhaps to sign into your system or use your signs to make orders or get directions. In these cases, you are at very high risk from hackers.

They probably won’t bother tampering with your hardware and will work more on hacking your systems or your network. They want the email addresses and personal details of the people using the digital signs, so you will need to protect your network and their information within the boundaries of the law under the data protection act.

**Digital Signs That Accept Payments**

Outside of the digital signs that are famous in the USA, like Time Square, and the large popular ones in China, Hong Kong and London and the USA, outside of those, the most highly targeted digital signs are the ones that take payments.

They are vulnerable simply because hackers and tamperers are so eager to gain access to the money being spent, to the bank information being passed across and so forth. Digital signs that receive payments will be attacked from all angles.

People will tamper with the hardware and may even place cloning devices on the digital signs. People will attack the network and try to hijack it, and they will try to hack the systems themselves. They will install malware on the digital sign, on its streaming device, and on the PCs of whoever is controlling the digital signs.

**Many Different Signs**

In many cases, the dangers posed to your signs are relative to how much impact they have on the public, or how much data they collect on the public. A hard-wired sign, possibly controlled by a hard drive, is of little value to a criminal.

But, even under those circumstances, what if you had 200 hard-wired signs set to create a massive cinema screen? In that case, criminals will target your signs because of the impact they have on the public. 

Your single sign, controlled by a computer over a wireless network, may not generate much interest from criminals. However, if you have ten signs in each of your ten stores across the country, then your signs become a big target again. Under most circumstances, the more signs you have, the more digital security/data security matters.

The Importance of Data Security for Digital Signage

Check Point Research (CPR) releases new data on 2022 cyberattack trends. The data is segmented by global volume, industry and geography. Global cyberattacks increased by 38% in 2022, compared to 2021. These cyberattack numbers were driven by smaller, more agile hacker and ransomware gangs, who focused on exploiting collaboration tools used in work-from-home environments, targeting of education institutions that shifted to e-learning post COVID-19. This increase in global cyberattacks also stems from hacker interest in healthcare organizations, which saw the largest increase in cyberattacks in 2022, when compared to all other industries. CPR warns that the maturity of AI technology, such as CHATGPT, can accelerate the number of cyberattacks in 2023. 

Check Point Research (CPR) has released new data on last year’s cyberattack trends. The data is segmented by global volume, industries, continents and countries.

**Key Statistics:** 

*   Global volume of cyberattacks reached an all-time high in Q4 with an average of 1168 weekly attacks per organization
*   Top 3 most attacked industries in 2022 were Education/Research, Government and Healthcare
*   Geography of Africa experienced the highest volume of attacks with 1875 weekly attacks per organization, followed by APAC with 1691 weekly attacks per organization
*   North America (+52%), Latin America (+29%) and Europe (+26%) showed largest increases in cyberattacks in 2022, compared to 2021
*   USA saw a 57% increase in overall cyberattacks in 2022, UK saw a 77% increase and Singapore saw a 26% increase

Cyberattacks are increasing world-wide, with 38% more cyberattacks per week on corporate networks in 2022, compared to 2021. Several cyber threat trends are all happening at once.

For one, the ransomware ecosystem is continuing to evolve and grow with smaller, more agile criminal groups that form to evade law enforcement. Second, hackers are widening their aim to target business collaboration tools such as Slack, Teams, OneDrive and Google Drive with phishing exploits. These make for a rich source of sensitive data given that most organizations’ employees continue to work remotely.

Third, academic institutions have become a popular feeding ground for cybercriminals following the rapid digitization they undertook in response to the COVID-19 pandemic. In fact, the education/research sector was the number one most attacked industry globally, seeing a 43% increase in 2022 compared to 2021, with an average of 2,314 attacks per organisation every week. Many education institutions have been ill-prepared for the unexpected shift to online learning, creating ample opportunity for hackers to infiltrate networks through any means necessary. Schools and universities also have the unique challenge of dealing with children or young adults, many of which use their own devices, work from shared locations, and often connect to public WiFi without thinking of the security implications.

Looking back at cyberattacks for the healthcare sector in 2022, healthcare organizations in the US suffered an average of 1410 weekly cyberattacks per organization, which is 86% higher than the number we saw in 2021, with the healthcare sector ranking second out of all sectors for the most cyberattacks in the US.

Hackers like to target hospitals because they perceive them as short on cyber security resources with smaller hospitals particularly vulnerable, as they are underfunded and understaffed to handle a sophisticated cyberattack.

The healthcare sector is so lucrative to hackers as they aim to retrieve health insurance information, medical records numbers and, sometimes, even social security numbers with direct threats from ransomware gangs to patients, demanding payment under threats of having patient records released. Ransomware gangs also find the attention gained from attacking a hospital as an attractive plus-point for their notoriety.

Unfortunately, we expect the increase in cyberattack activity to only increase. With AI technologies such as ChatGPT readily available to the public, it is possible for hackers to generate malicious code and emails at a faster, more automated pace.

To protect yourself, it is imperative to think about prevention first, not detection. There are several best practices and actions an organization can take to minimize their exposure to the next attack or breach, such as cyber security training, keeping patches up-to-date and implementing anti-ransomware technology.”

**Cyber Safety Tips:** 

1.  **Cyber Awareness Training**: Frequent cybersecurity awareness training is crucial to protecting the organization against ransomware. This training should instruct employees to do the following:
    1.  Not click on malicious links
    2.  Never open unexpected or untrusted attachments
    3.  Avoid revealing personal or sensitive data to phishers
    4.  Verify software legitimacy before downloading it
    5.  Never plug an unknown USB into their computer
    6.  Use a VPN when connecting via untrusted or public Wi-Fi
2.  **Up-to-Date Patches:** Keeping computers and servers up-to-date and applying security patches, especially those labeled as critical, can help to limit an organization’s vulnerability to ransomware attacks.
3.  **Keep your software updated.** Ransomware attackers sometimes find an entry point within your apps and software, noting vulnerabilities and capitalizing on them. Fortunately, some developers are actively searching for new vulnerabilities and patching them out. If you want to make use of these patches, you need to have a patch management strategy in place—and you need to make sure all your team members are constantly up to date with the latest versions.
4.  **Choose Prevention over detection:** Many claim that attacks will happen, and there is no way to avoid them, and therefore the only thing left to do is to invest in technologies that detect the attack once it has already breached the network and mitigate the damage as soon as possible. This is not true. Not only can attacks be blocked, but they can be prevented, including zero-day attacks and unknown malware. With the right technologies in place, most attacks, even the most advanced ones, can be prevented without disrupting the normal business flow.

Check Point Research Reports a 38% Increase In 2022 Global Cyberattacks

There is an unauthorized buffer overflow vulnerability in Tenda AX12 v22.03.01.21 _ cn. This vulnerability can cause the web service not to restart or even execute arbitrary code. It is a different vulnerability from CVE-2022-2414.

**Tenda AX12 unauthorized Buffer overflow vulnerability****Overview**

*   Manufacturer's website information：https://www.tenda.com.cn/
*   Firmware download address ：https://www.tenda.com.cn/download/detail-3237.html

**Vulnerability information**

There is an unauthorized buffer overflow vulnerability in tenda ax12v22.03.01.21 \_ cn, which can cause httpd to crash. Using this vulnerability can cause the web service not to restart or even execute arbitrary code. It is a different vulnerability from CVE-2022-2414.

**Affected version**

Figure shows the latest firmware ：V22.03.01.21\_cn of the router

**Vulnerability details**

open telnet http://192.168.0.1/goform/telnet telnet admin/password is root/ Fireitup

using ida to analysis httpd, in function sub\_4335C0, the corresponding function field is fast\_setting\_wifi\_set.

The program passes the contents obtained by the ssid parameter to V2 Then, format the matching content of V2 through the sprintf function into V19. There is no size check, so there is a vulnerability that can cause buffer overflow through ssid field.

**Vulnerability exploitation condition**

However, there are certain utilization conditions here, and it can be found in the function sub\_417D94 that the field fast\_setting\_wifi\_set will be checked.

The corresponding function of fast\_setting\_wifi\_set is to initialize the network function when the device is started, and this function can only be triggered when the device is started initially or after reset. The data packet sent with this function during the normal operation of the device will not be processed, because it is filtered by the function in the above figure.

When the device is initially started, the web password is empty, so it can be used without authorization.

The functional data packets are as follows, and we will use this to construct poc.

POST /goform/fast\_setting\_wifi\_set HTTP/1.1
Host: 192.168.0.1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:106.0) Gecko/20100101 Firefox/106.0
Accept: \*/\*
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
X-Requested-With: XMLHttpRequest
Content-Length: 111
Origin: http://192.168.0.1
Connection: close
Referer: http://192.168.0.1/index.html

ssid=Tenda\_FDDE58&wrlPassword=mima1234&power=high&timeZone=%2B08%3A00&loginPwd=70ebc4f9c9d22827a5874d1bb6f06abd

**Recurring vulnerabilities and POC**

In order to reproduce the vulnerability, the following steps can be followed:

1.  Connect physical devices
2.  Attack with the following POC

The reproduction results are as follows:

Figure shows POC attack effect, the binary httpd restarts.

Running exp without logging in can also attack, and several more attacks will cause httpd to restart all the time.

Finally, through observation, we found that httpd will not restart after several attacks.

**CVE-ID**

unsigned

CVE-2022-45995: public_bug/tenda/ax12/1 at main · bugfinder0/public_bug

In Boa, there is a possible command injection due to improper input validation. This could lead to remote escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation. Patch ID: A20220026; Issue ID: OSBNB00144124.

**January 2023 Product Security Bulletin**

Published 2023-01-03

The MediaTek Product Security Bulletin contains details of security vulnerabilities affecting MediaTek Smartphone, Tablet, AIoT, Smart display, Smart platform, OTT and Wi-Fi chipsets. Device OEMs have been notified of all the issues and the corresponding security patches for at least two months before publication.

The severity of the identified vulnerabilities was conducted based on the Common Vulnerability Scoring System version 3.1 (CVSS v3.1).

****Summary****

Severity

**CVEs**

High

CVE-2022-32635, CVE-2022-32636, CVE-2022-32637

Medium

CVE-2022-32638, CVE-2022-32639, CVE-2022-32640, CVE-2022-32641, CVE-2022-32644, CVE-2022-32645, CVE-2022-32646, CVE-2022-32647, CVE-2022-32648, CVE-2022-32649, CVE-2022-32650, CVE-2022-32651, CVE-2022-32652, CVE-2022-32653, CVE-2022-32623, CVE-2022-32657, CVE-2022-32658, CVE-2022-32659, CVE-2022-32664, CVE-2022-32665

****Details****

CVE

**CVE-2022-32635**

Title

Improper input validation in gps

Severity

High

Vulnerability Type

EoP

CWE

CWE-20 Improper Input Validation

Description

In gps, there is a possible out of bounds write due to a missing bounds check. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.

Affected Chipsets

MT6580, MT6735, MT6739, MT6753, MT6757, MT6761, MT6762, MT6763, MT6765, MT6768, MT6769, MT6771, MT6779, MT6781, MT6785, MT6789, MT6833, MT6853, MT6853T, MT6855, MT6873, MT6875, MT6877, MT6879, MT6891, MT6893, MT6895, MT6983, MT8167, MT8168, MT8173, MT8185, MT8321, MT8362A, MT8365, MT8385, MT8666, MT8667, MT8675, MT8765, MT8766, MT8768, MT8786, MT8788, MT8789, MT8791, MT8791T, MT8797

Affected Software Versions

Android 10.0, 11.0, 12.0, 13.0

CVE

**CVE-2022-32636**

Title

Improper input validation in keyinstall

Severity

High

Vulnerability Type

EoP

CWE

CWE-20 Improper Input Validation

Description

In keyinstall, there is a possible out of bounds write due to an integer overflow. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation.

Affected Chipsets

MT6580, MT6731, MT6735, MT6737, MT6739, MT6753, MT6757, MT6757C, MT6757CD, MT6757CH, MT6761, MT6762, MT6763, MT6765, MT6768, MT6769, MT6771, MT6779, MT6781, MT6785, MT6789, MT6833, MT6853, MT6853T, MT6855, MT6873, MT6875, MT6877, MT6879, MT6883, MT6885, MT6889, MT6891, MT6893, MT6895, MT6983, MT8185, MT8321, MT8385, MT8666, MT8667, MT8765, MT8766, MT8768, MT8786, MT8788, MT8789, MT8791, MT8791T, MT8797

Affected Software Versions

Android 10.0, 11.0, 12.0, 13.0

CVE

**CVE-2022-32637**

Title

Improper input validation in hevc decoder

Severity

High

Vulnerability Type

EoP

CWE

CWE-20 Improper Input Validation

Description

In hevc decoder, there is a possible out of bounds write due to a missing bounds check. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation.

Affected Chipsets

MT6781, MT6785, MT6833, MT6853, MT6853T, MT6873, MT6883, MT6885, MT6889, MT8185, MT8789

Affected Software Versions

Android 10.0, 11.0

CVE

**CVE-2022-32638**

Title

Time-of-check time-of-use (toctou) race condition in isp

Severity

Medium

Vulnerability Type

EoP

CWE

CWE-367 Time-of-check Time-of-use (TOCTOU) Race Condition

Description

In isp, there is a possible out of bounds write due to a race condition. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation.

Affected Chipsets

MT6781, MT6833, MT6853, MT6855, MT6873, MT6877, MT6885, MT6893, MT8167, MT8167S, MT8168, MT8173, MT8175, MT8185, MT8321, MT8362A, MT8365, MT8385, MT8666, MT8675, MT8765, MT8766, MT8768, MT8786, MT8788, MT8789, MT8791, MT8791T, MT8797

Affected Software Versions

Android 11.0, 12.0, 13.0

CVE

**CVE-2022-32639**

Title

Exposure of sensitive information to an unauthorized actor in watchdog

Severity

Medium

Vulnerability Type

EoP

CWE

CWE-200 Exposure of Sensitive Information to an Unauthorized Actor

Description

In watchdog, there is a possible out of bounds read due to a missing bounds check. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation.

Affected Chipsets

MT6739, MT6768, MT6771, MT6781, MT6785, MT6833, MT6853, MT6873, MT6877, MT8167, MT8167S, MT8362A, MT8385, MT8518S, MT8532, MT8765, MT8786, MT8791

Affected Software Versions

Android 11.0, 12.0

CVE

**CVE-2022-32640**

Title

Improper input validation in meta wifi

Severity

Medium

Vulnerability Type

EoP

CWE

CWE-20 Improper Input Validation

Description

In meta wifi, there is a possible out of bounds write due to a missing bounds check. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation.

Affected Chipsets

MT6580, MT6731, MT6735, MT6737, MT6739, MT6753, MT6757, MT6757C, MT6757CD, MT6757CH, MT6761, MT6762, MT6763, MT6765, MT6768, MT6769, MT6771, MT6779, MT6781, MT6785, MT6789, MT6833, MT6853, MT6853T, MT6855, MT6873, MT6875, MT6877, MT6879, MT6883, MT6885, MT6889, MT6891, MT6893, MT6895, MT6983, MT8167, MT8168, MT8173, MT8185, MT8321, MT8362A, MT8365, MT8385, MT8666, MT8675, MT8765, MT8766, MT8768, MT8781, MT8786, MT8788, MT8789, MT8791, MT8791T, MT8797

Affected Software Versions

Android 11.0, 12.0

CVE

**CVE-2022-32641**

Title

Improper input validation in meta wifi

Severity

Medium

Vulnerability Type

EoP

CWE

CWE-20 Improper Input Validation

Description

In meta wifi, there is a possible out of bounds read due to a missing bounds check. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation.

Affected Chipsets

MT6580, MT6731, MT6735, MT6737, MT6739, MT6753, MT6757, MT6757C, MT6757CD, MT6757CH, MT6761, MT6762, MT6763, MT6765, MT6768, MT6769, MT6771, MT6779, MT6781, MT6785, MT6789, MT6833, MT6853, MT6853T, MT6855, MT6873, MT6875, MT6877, MT6879, MT6883, MT6885, MT6889, MT6891, MT6893, MT6895, MT6983, MT8167, MT8168, MT8173, MT8185, MT8321, MT8362A, MT8365, MT8385, MT8666, MT8675, MT8765, MT8766, MT8768, MT8781, MT8786, MT8788, MT8789, MT8791, MT8791T, MT8797

Affected Software Versions

Android 11.0, 12.0, 13.0

CVE

**CVE-2022-32644**

Title

Improper synchronization in vow

Severity

Medium

Vulnerability Type

EoP

CWE

CWE-662 Improper Synchronization

Description

In vow, there is a possible use after free due to a race condition. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation.

Affected Chipsets

MT6789, MT6833, MT6853, MT6855, MT6873, MT6875, MT6877, MT6879, MT6883, MT6885, MT6891, MT6893, MT6895, MT6983, MT8781, MT8791, MT8791T, MT8797

Affected Software Versions

Android 11.0, 12.0, 13.0

CVE

**CVE-2022-32645**

Title

Improper synchronization in vow

Severity

Medium

Vulnerability Type

ID

CWE

CWE-662 Improper Synchronization

Description

In vow, there is a possible information disclosure due to a race condition. This could lead to local information disclosure with System execution privileges needed. User interaction is not needed for exploitation.

Affected Chipsets

MT6789, MT6833, MT6853, MT6855, MT6873, MT6875, MT6877, MT6879, MT6883, MT6885, MT6891, MT6893, MT6895, MT6983, MT8781, MT8791, MT8791T, MT8797

Affected Software Versions

Android 11.0, 12.0, 13.0

CVE

**CVE-2022-32646**

Title

Improper input validation in gpu drm

Severity

Medium

Vulnerability Type

EoP

CWE

CWE-20 Improper Input Validation

Description

In gpu drm, there is a possible stack overflow due to a missing bounds check. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation.

Affected Chipsets

MT6761, MT6765, MT6768, MT6779, MT6781, MT6785, MT6789, MT6833, MT6853, MT6855, MT6873, MT6877, MT6879, MT6883, MT6885, MT6889, MT6893, MT6895, MT6983, MT8675, MT8766, MT8781, MT8791

Affected Software Versions

Android 11.0, 12.0, 13.0

CVE

**CVE-2022-32647**

Title

Improper input validation in ccu

Severity

Medium

Vulnerability Type

EoP

CWE

CWE-20 Improper Input Validation

Description

In ccu, there is a possible out of bounds write due to improper input validation. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation.

Affected Chipsets

MT6879, MT6895, MT6983

Affected Software Versions

Android 12.0, 13.0

CVE

**CVE-2022-32648**

Title

Improper synchronization in disp

Severity

Medium

Vulnerability Type

EoP

CWE

CWE-662 Improper Synchronization

Description

In disp, there is a possible use after free due to a race condition. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation.

Affected Chipsets

MT6735, MT6737, MT6739, MT6753, MT6757, MT6761, MT6763, MT6765, MT6768, MT6771, MT6779, MT6785, MT6789

Affected Software Versions

Android 11.0, 12.0

CVE

**CVE-2022-32649**

Title

Incorrect calculation of buffer size in jpeg

Severity

Medium

Vulnerability Type

EoP

CWE

CWE-131 Incorrect Calculation of Buffer Size

Description

In jpeg, there is a possible use after free due to a logic error. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation.

Affected Chipsets

MT6895, MT6983

Affected Software Versions

Android 12.0

CVE

**CVE-2022-32650**

Title

Incorrect calculation of buffer size in isp

Severity

Medium

Vulnerability Type

EoP

CWE

CWE-131 Incorrect Calculation of Buffer Size

Description

In mtk-isp, there is a possible use after free due to a logic error. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation.

Affected Chipsets

MT6879, MT6895, MT6983

Affected Software Versions

Android 12.0, 13.0

CVE

**CVE-2022-32651**

Title

Incorrect calculation of buffer size in mtk-aie

Severity

Medium

Vulnerability Type

EoP

CWE

CWE-131 Incorrect Calculation of Buffer Size

Description

In mtk-aie, there is a possible use after free due to a logic error. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation.

Affected Chipsets

MT6879, MT6983

Affected Software Versions

Android 12.0

CVE

**CVE-2022-32652**

Title

Improper input validation in isp

Severity

Medium

Vulnerability Type

EoP

CWE

CWE-20 Improper Input Validation

Description

In mtk-aie, there is a possible use after free due to a logic error. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation.

Affected Chipsets

MT6833, MT6853, MT6877, MT6893, MT8791

Affected Software Versions

Android 11.0, 12.0, 13.0

CVE

**CVE-2022-32653**

Title

Improper input validation in isp

Severity

Medium

Vulnerability Type

EoP

CWE

CWE-20 Improper Input Validation

Description

In mtk-aie, there is a possible use after free due to a logic error. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation.

Affected Chipsets

MT6789, MT6855, MT6879, MT6983, MT8781

Affected Software Versions

Android 12.0, 13.0

CVE

**CVE-2022-32623**

Title

Improper check or handling of exceptional conditions in mdp

Severity

Medium

Vulnerability Type

EoP

CWE

CWE-703 Improper Check or Handling of Exceptional Conditions

Description

In mdp, there is a possible out of bounds write due to incorrect error handling. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation.

Affected Chipsets

MT6789, MT6855, MT6879, MT6895, MT6983, MT8168, MT8365, MT8781

Affected Software Versions

Android 12.0

CVE

**CVE-2022-32657**

Title

Improper input validation in Wi-Fi driver

Severity

Medium

Vulnerability Type

EoP

CWE

CWE-20 Improper Input Validation

Description

In Wi-Fi driver, there is a possible undefined behavior due to incorrect error handling. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation.

Affected Chipsets

MT7603, MT7613, MT7615, MT7622, MT7628, MT7629, MT7915, MT7916, MT7981, MT7986

Affected Software Versions

7.6.6.0

CVE

**CVE-2022-32658**

Title

Improper input validation in Wi-Fi driver

Severity

Medium

Vulnerability Type

EoP

CWE

CWE-20 Improper Input Validation

Description

In Wi-Fi driver, there is a possible undefined behavior due to incorrect error handling. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation.

Affected Chipsets

MT7603, MT7613, MT7615, MT7622, MT7628, MT7629, MT7915, MT7916, MT7981, MT7986

Affected Software Versions

7.6.6.0

CVE

**CVE-2022-32659**

Title

Improper input validation in Wi-Fi driver

Severity

Medium

Vulnerability Type

EoP

CWE

CWE-20 Improper Input Validation

Description

In Wi-Fi driver, there is a possible undefined behavior due to incorrect error handling. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation.

Affected Chipsets

MT7603, MT7613, MT7615, MT7622, MT7628, MT7629, MT7915, MT7916, MT7981, MT7986, MT8518S, MT8532

Affected Software Versions

7.6.6.0, and Yocto 3.1, 3.3

CVE

**CVE-2022-32664**

Title

Improper input validation in Config Manager

Severity

Medium

Vulnerability Type

EoP

CWE

CWE-20 Improper Input Validation

Description

In Config Manager, there is a possible command injection due to improper input validation. This could lead to remote escalation of privilege with User execution privileges needed. User interaction is needed for exploitation.

Affected Chipsets

EN7516, EN7528, EN7529, EN7561, EN7562, EN7580

Affected Software Versions

Linux SDK versions less than TLM-7.3.293.0

CVE

**CVE-2022-32665**

Title

Improper input validation in Boa

Severity

Medium

Vulnerability Type

EoP

CWE

CWE-20 Improper Input Validation

Description

In Boa, there is a possible command injection due to improper input validation. This could lead to remote escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.

Affected Chipsets

EN7528, EN7580

Affected Software Versions

Linux SDK versions less than TLB7.3.258.100-P1-1555

****Vulnerability Type Definition****

Abbreviation

**Definition**

RCE

Remote Code Execution

EoP

Elevation of Privilege

ID

Information Disclosure

DoS

Denial of Service

N/A

Classification not available

****Versions****

**Version**

**Date**

**Description**

1.0

January 3, 2023

Bulletin published.

****Notes****

Information above is generated only at the time of creation of this Security Bulletin. The list of affected chipsets could be not complete. For any further information, device OEMs can reach your MediaTek contact person if needed.

If you want to report a security vulnerability in MediaTek chipsets or products, please go to Report Security Vulnerability page on MediaTek website.

CVE-2022-32665: January 2023

By Deeba Ahmed
The issue was caused by the software architecture used in Google Home devices.
This is a post from HackRead.com Read the original post: Google Home Vulnerability: Eavesdropping on Conversations

Matt Kunze, an ethical hacker, reported wiretapping bugs in Google Home Smart Speakers, for which he received a bug bounty worth $107,500.

Google Assistant is currently more popular among smart homeowners than Amazon Alexa and Apple Siri, given its superior intuitiveness and capability to conduct lengthy conversations. However, according to the latest research, a vulnerability in **Google Home Smart speakers** could allow attackers to control the smart device and eavesdrop on user conversations indoors.

**Findings Details**

The vulnerability was identified by Matt Kunze, a security researcher using the moniker DownrightNifty Matt. The researchers revealed that if exploited, the vulnerability could allow the installation of backdoors and convert Google Home Smart speakers into wiretapping devices. Moreover, Google fixed the issue in April 2021 following responsible disclosure on 8 January 2021 and developing a Proof-of-Concept for the company.

**Possible Dangers**

The vulnerability could let an adversary present within the device’s wireless proximity install a backdoor account on the device and start sending remote commands, access the microphone feed, and initiate arbitrary HTTP requests. All of this could be possible if the attacker is within the user’s LAN range because making malicious requests **exposes the Wi-Fi password** of the device and provides the attacker direct access to all devices connected to the network.

**What Caused the Issue?**

Matt discovered that the problem was caused by the software architecture used in Google Home devices as it let an adversary add a rogue Google user account to their target’s smart home devices.

A threat actor would trick the individual into installing a malicious Android application to make the attack work. It will detect a Google Home automation device connected to the network and stealthily start issuing HTTP requests to link the threat actor’s account to the victim’s device.

In addition, the attacker could stage a Wi-Fi de-authentication attack to disconnect the Google Home device from the network and force the appliance to initiate a setup mode and create an open Wi-Fi network. Subsequently, the attacker can connect to this network and request additional details such as device name, certificate, and cloud\_device\_id. They could use the information and connect their account to the victim’s device.

According to Matt’s **blog post**, the attacker could perform a range of functions, such as turning the speaker’s volume down to zero and making calls to any phone number apart from spying on the victim via the microphone. The victim won’t suspect anything because just the device’s LED turns blue when the exploitation happens, and the user would think the firmware is being updated.

Matt successfully connected an unknown user account to a Google Home speaker. He created a **backdoor account** on the targeted device and obtained unprecedented privileges that let him send remote commands to the Home mini smart speaker, access its microphone feed, etc. Watch the demo shared by the researcher:

It is worth noting that there’s no evidence this security loophole was misused since its detection in 2021. Being an ethical hacker, the researcher notified Google about the issue, and it was patched. Matt received a **bug bounty** worth $107,500 for detecting this security flaw.

1.  **Google Home Mini Secretly Recorded Conversations**
2.  **Voice assistant devices manipulated with ultrasonic waves**
3.  **Comcast voice remote control could be turned into a spying tool**
4.  **Using laser on Alexa and Google home to unlock your front door**
5.  **DolphinAttack: Voice Assistant Apps Siri and Alexa Can Be Hacked**

Google Home Vulnerability: Eavesdropping on Conversations

TRENDnet TEW755AP 1.13B01 was discovered to contain a stack overflow via the user_edit_page parameter in the wifi_captive_portal function.

CVE-2022-46580

TRENDnet TEW755AP 1.13B01 was discovered to contain a stack overflow via the qcawifi.wifi%d_vap%d.maclist parameter in the kick_ban_wifi_mac_allow (sub_415B00) function.

Tag

#wifi