Four OS command injection vulnerabilities exists in the web interface /action/wirelessConnect functionality of Abode Systems, Inc. iota All-In-One Security Kit 6.9X and 6.9Z. A specially-crafted HTTP request can lead to arbitrary command execution. An attacker can make an authenticated HTTP request to trigger these vulnerabilities.This vulnerability focuses on the unsafe use of the `ssid_hex` HTTP parameter to construct an OS Command at offset `0x19afc0` of the `/root/hpgw` binary included in firmware 6.9Z.

**SUMMARY**

Four OS command injection vulnerabilities exists in the web interface /action/wirelessConnect functionality of Abode Systems, Inc. iota All-In-One Security Kit 6.9X and 6.9Z. A specially-crafted HTTP request can lead to arbitrary command execution. An attacker can make an authenticated HTTP request to trigger these vulnerabilities.

**CONFIRMED VULNERABLE VERSIONS**

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

abode systems, inc. iota All-In-One Security Kit 6.9X  
abode systems, inc. iota All-In-One Security Kit 6.9Z

**PRODUCT URLS**

iota All-In-One Security Kit - https://goabode.com/product/iota-security-kit

**CVSSv3 SCORE**

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

**CWE**

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

**DETAILS**

The iota All-In-One Security Kit is a home security gateway containing an HD camera, infrared motion detection sensor, Ethernet, WiFi and Cellular connectivity. The iota gateway orchestrates communications between sensors (cameras, door and window alarms, motion detectors, etc.) distributed on the LAN and the Abode cloud. Users of the iota can communicate with the device through mobile application or web application.

These vulnerabilities are reminiscent of a vulnerability identified and reported previously by Bitdefender. The vulnerability was tracked as CVE-2020-8105. From screenshots, the version of the firmware they tested appears to be 6.8E. Abode released firmware version 6.9X on December 15th, 2021 as the patch for CVE-2020-8105.

As brief background, CVE-2020-8105 was identified in the function responsible for handling HTTP requests destined for /action/wirelessConnect on the local web interface of the device. The vulnerability was an OS Command Injection that could be exploited through any of three parameters: ssid, wpapsk and key. It is our belief that the released patch for this vulnerability was to disable the web interface by default and encode the ssid and wpapsk parameters as hex-ascii in order to neutralize them before injecting into the OS command. Included in this patch were two new parameters, ssid_hex and wpapsk_hex, which are treated as if they have already been encoded as hex-ascii.

The web interface, now disabled-by-default, can be re-enabled through the use of either TALOS-2022-1552 or TALOS-2022-1553 in order to make these vulnerabilities accessible over the network.

The vulnerable web_wireless_connect function is located at offset 0x19AC94 in the /root/hpgw binary included in firmware version 6.9Z. For brevity, we have included only the relevant portions of the decompiled function below, with annotations.

    int __fastcall wirelessConnect(mg_connection *conn, mg_request_info *ri)
    {
      int payload_len;
      int v5;
      const char *v6;
      int decoded_ssid_len;
      int bufflen;
      const char *cmd;
      int count;
      int success;
      int error_len;
      const char *error;
      const char *err_str;
      const char *task;
      const char *v17;
      int wireless_enabled;
      xstrbuf_t decoded_ssid;
      xstrbuf_t decoded_wpapsk;
      char cmd_buffer[128];
      char cmd_output[128];
      char scratchpad[128];
      char ssid[192];
      char ssid_hex[192];
      char wpapsk_hex[192];
      char auth_mode[192];
      char wpapsk[192];
      char encryp_type[192];
      char default_key_id[192];
      char key[192];
      char payload[544];
    
      log(7, 1, "\x1B[33mweb_wireless_connect ri->uri:[%s]\x1B[0m", ri->uri);
      wireless_enabled = 0;
    
      // [1] Ensure that wireless is enabled, otherwise exit early
      get_config_as_integer("WL_Enable", (int)&wireless_enabled);
      if ( !wireless_enabled )
        goto LABEL_38;
    
      ...
    
      // [2] Extract the first 512 bytes of the POST body and extract all necessary parameters
      payload_len = http_collect_payload(conn, ri, payload, 512);
      memset(ssid, 0, sizeof(ssid));
      memset(ssid_hex, 0, sizeof(ssid_hex));
      memset(wpapsk_hex, 0, sizeof(wpapsk_hex));
      memset(auth_mode, 0, sizeof(auth_mode));
      memset(wpapsk, 0, sizeof(wpapsk));
      memset(encryp_type, 0, sizeof(encryp_type));
      memset(default_key_id, 0, sizeof(default_key_id));
      memset(key, 0, sizeof(key));
      mg_get_var(payload, payload_len, "ssid", ssid, 191);
      mg_get_var(payload, payload_len, "ssid_hex", ssid_hex, 191);
      mg_get_var(payload, payload_len, "auth_mode", auth_mode, 191);
      mg_get_var(payload, payload_len, "wpapsk", wpapsk, 191);
      mg_get_var(payload, payload_len, "wpapsk_hex", wpapsk_hex, 191);
      mg_get_var(payload, payload_len, "encryp_type", encryp_type, 191);
      mg_get_var(payload, payload_len, "default_key_id", default_key_id, 191);
      mg_get_var(payload, payload_len, "key", key, 191);
    
      // [3] Ensure that one of `ssid` or `ssid_hex` is provided, all other parameters appear optional
      if ( !ssid[0] )
      {
        v5 = (unsigned __int8)ssid_hex[0];
        if ( !ssid_hex[0] )
        {
          log(7, 1, "No SSID!");
          v6 = strtable_get("WEB_ERR_PARAM_EMPTY", 19);
          return web_error(conn, v5, v6, "ssid and ssid_hex");
        }
      }
    
      memset(cmd_buffer, 0, sizeof(cmd_buffer));
      memset(v22, 0, sizeof(v22));
      xstrbuf(&decoded_ssid);
      mg_urldecode(ssid, &decoded_ssid);
    
      // [4] Identify whether the SSID was provided via the `ssid` or `ssid_hex` parameter
      if ( ssid_hex[0] )
      {
        // [5] If via `ssid_hex`, inject directly into OS command without neutralization
        log(7, 31, "with hex string");
        vsnprintf_nullterm(cmd_buffer, 0x7Fu, "driver/wpa_cli -i %s set_network 0 ssid %s", "wlan0", ssid_hex);
      }
      else
      {
        // [6] If via `ssid`, neutralize the value before injecting into OS command
        memset(scratchpad, 0, sizeof(scratchpad));
        decoded_ssid_len = strlen(decoded_ssid.buff);
        hexlify(decoded_ssid.buff, decoded_ssid_len, scratchpad);
        log(7, 31, "with ascii string");
        vsnprintf_nullterm(cmd_buffer, 0x7Fu, "driver/wpa_cli -i %s set_network 0 ssid '\"%s\"'", "wlan0", scratchpad);
      }
      xstrbuf_free_d(&decoded_ssid, (int)"web_wireless_connect");
      log(7, 1, cmd_buffer);
    
      // [7] Execute the command constructed at [5] or [6]
      popen_write(cmd_buffer);
    
      memset(cmd_buffer, 0, sizeof(cmd_buffer));
      if ( strcmp(auth_mode, "WPA") && strcmp(auth_mode, "WPA2") )
      {
    
        // [8] If `auth_mode` is WPAPSK_HEX or WPA2PSK_HEX
        if ( !strcmp(auth_mode, "WPAPSK_HEX") || !strcmp(auth_mode, "WPA2PSK_HEX") )
        {
    
          // [9] then inject `wpapsk_hex` directly into the command without neutralization
          vsnprintf_nullterm(cmd_buffer, 0x7Fu, "driver/wpa_cli -i %s set_network 0 psk %s", "wlan0", wpapsk_hex);
    LABEL_16:
          log(7, 1, cmd_buffer);
    
          // [10] Execute the command constructed at [9]
          popen_read(cmd_buffer, cmd_output, 127);
    
          if ( strlen(cmd_output) > 1 && !strncmp(cmd_output, "OK", 2u) )
            log(7, 1, "web_wireless_connect set_network 0 psk OK");
          goto LABEL_25;
        }
    
        // [11] Otherwise, if `auth_mode` is WPAPSK or WPA2PSK
        if ( !strcmp(auth_mode, "WPAPSK") || !strcmp(auth_mode, "WPA2PSK") )
        {
          // [12] Then neutralize `wpapsk` before injecting it into the command
          xstrbuf(&decoded_wpapsk);
          mg_urldecode(wpapsk, &decoded_wpapsk);
          memset(scratchpad, 0, sizeof(scratchpad));
          bufflen = strlen(decoded_wpapsk.buff);
          hexlify(decoded_wpapsk.buff, bufflen, scratchpad);
          vsnprintf_nullterm(cmd_buffer, 0x7Fu, "driver/wpa_cli -i %s set_network 0 psk '\"%s\"'", "wlan0", scratchpad);
          xstrbuf_free_d(&decoded_wpapsk, (int)"web_wireless_connect");
          goto LABEL_16;
        }
        if ( strcmp(auth_mode, "SHARED") && strcmp(auth_mode, "WEP") )
        {
          log(7, 1, "driver/wpa_cli -i wlan0 set_network 0 key_mgmt NONE");
          cmd = "driver/wpa_cli -i wlan0 set_network 0 key_mgmt NONE";
          goto LABEL_24;
        }
    
        log(7, 1, "driver/wpa_cli -i wlan0 set_network 0 key_mgmt NONE");
        popen_write("driver/wpa_cli -i wlan0 set_network 0 key_mgmt NONE");
    
        // [12]  If `auth_mode` is SHARED or WEP then inject `default_key_id` and `key` into the command directly
        vsnprintf_nullterm(
          cmd_buffer,
          0x7Fu,
          "driver/wpa_cli -i %s set_network 0 wep_key%s '\"%s\"'",
          "wlan0",
          default_key_id,
          key);
        log(7, 1, cmd_buffer);
    
        // [13] Execute the command constructed at [12]
        popen_write(cmd_buffer);
        memset(cmd_buffer, 0, sizeof(cmd_buffer));
    
        // [14] Construct a final command using only the unsanitized `default_key_id`
        vsnprintf_nullterm(
          cmd_buffer,
          0x7Fu,
          "driver/wpa_cli -i %s set_network 0 wep_tx_keyidx %s",
          "wlan0",
          default_key_id);
        log(7, 1, cmd_buffer);
    
        // [15] Execute the final vulnerable command constructed at [14]
        popen_write(cmd_buffer);
        if ( !strcmp(auth_mode, "SHARED") )
        {
          log(7, 1, "driver/wpa_cli -i wlan0 set_network 0 auth_alg SHARED");
          cmd = "driver/wpa_cli -i wlan0 set_network 0 auth_alg SHARED";
    LABEL_24:
          popen_write(cmd);
        }
      }
    ...
    }
    

We observe at [1], these vulnerabilities are only exploitable if wireless functionality has been enabled. This is not particularly hard to configure as a remote attacker via TALOS-2022-1552, but most devices will not be immediately exploitable. If WL_Enable is true, then at [3] the first 512 bytes of the request body are extracted into the payload variable and eight parameters are extracted from the POST body—ssid, ssid_hex, auth_mode, wpapsk, wpapsk_hex, encryp_type, default_key_id and key. A value _must_ be supplied for one, or both, of ssid and ssid_hex. All other parameters appear to be optional.

**CVE-2022-33204 - Authenticated OS Command Injection via ssid_hex parameter**

The conditional referenced at [4] is responsible for determining whether the supplied ssid* parameter needs to be encoded prior to injection: The ssid parameter will be neutralized, but the ssid_hex parameter will be injected directly. There is nothing to enforce that the ssid_hex parameter has already been safely neutralized. At [7] the vulnerable command constructed using ssid_hex at [5] is executed by the root user via a call to popen.

A maliciously-formatted ssid_hex parameter successfully submitted via authenticated HTTP request to the /action/wirelessConnect endpoint will result in arbitrary command execution.

**CVE-2022-33205 - Authenticated OS Command Injection via wpapsk_hex parameter**

The conditionals referenced at [8] and [11] are responsible for determining whether the supplied wpapsk* parameter needs to be encoded prior to injection. If auth_mode is “WPAPSK” OR “WPA2PSK” then the wpapsk parameter will be neutralized, but if the auth_mode is “WPAPSK\_HEX” or “WPA2PSK\_HEX” then wpapsk_hex parameter will be used directly. There is nothing to enforce that the wpapsk_hex parameter has already been safely neutralized. At [10], the vulnerable command constructed using wpapsk_hex at [9] is executed by the root user via a call to popen.

A maliciously-formatted wpapsk_hex parameter successfully submitted via authenticated HTTP request to the /action/wirelessConnect endpoint will result in arbitrary command execution.

**CVE-2022-33206 - Authenticated OS Command Injection via key and default_key_id parameters**

If the conditional referenced at [12] identifies that auth_mode is “SHARED” or “WEP”, then at [13] both the key and default_key_id are injected directly into an OS command. There is nothing to enforce that either of these parameters have been safely neutralized prior to use. At [14], the vulnerable command is executed via a call to popen.

A maliciously-formatted key or default_key_id parameter successfully submitted via authenticated HTTP request to the /action/wirelessConnect endpoint will result in arbitrary command execution.

**CVE-2022-33207 - Authenticated OS Command Injection via default_key_id parameters**

If the conditional referenced at [12] identifies that auth_mode is “SHARED” or “WEP”, then at [15] the default_key_id parameter will be injected directly into an OS command. There is nothing to enforce that the default_key_id has already been safely neutralized. At [16], the vulnerable command is executed by the root user via a call to popen.

A maliciously-formatted default_key_id parameter successfully submitted via authenticated POST request to the /action/wirelessConnect endpoint will result in arbitrary command execution.

**TIMELINE**

2022-07-14 - Vendor Disclosure  
2022-10-20 - Public Release

Discovered by Matt Wiseman of Cisco Talos.

CVE-2022-33204: TALOS-2022-1568 || Cisco Talos Intelligence Group

Four format string injection vulnerabilities exist in the web interface /action/wirelessConnect functionality of Abode Systems, Inc. iota All-In-One Security Kit 6.9Z and 6.9X. A specially-crafted HTTP request can lead to memory corruption, information disclosure and denial of service. An attacker can make an authenticated HTTP request to trigger these vulnerabilities.This vulnerability arises from format string injection via the `default_key_id` and `key` HTTP parameters, as used within the `/action/wirelessConnect` handler.

**SUMMARY**

Four format string injection vulnerabilities exist in the web interface /action/wirelessConnect functionality of Abode Systems, Inc. iota All-In-One Security Kit 6.9Z and 6.9X. A specially-crafted HTTP request can lead to memory corruption, information disclosure and denial of service. An attacker can make an authenticated HTTP request to trigger these vulnerabilities.

**CONFIRMED VULNERABLE VERSIONS**

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

abode systems, inc. iota All-In-One Security Kit 6.9X  
abode systems, inc. iota All-In-One Security Kit 6.9Z

**PRODUCT URLS**

iota All-In-One Security Kit - https://goabode.com/product/iota-security-kit

**CVSSv3 SCORE**

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

**CWE**

CWE-134 - Use of Externally-Controlled Format String

**DETAILS**

The iota All-In-One Security Kit is a home security gateway containing an HD camera, infrared motion detection sensor, Ethernet, Wi-Fi and Cellular connectivity. The iota gateway orchestrates communications between sensors (cameras, door and window alarms, motion detectors, etc.) distributed on the LAN and the Abode cloud. Users of the iota can communicate with the device through mobile application or web application.

The iota device generates a significant volume of diagnostic logs, which it displays on its read-only physical UART console. These logs are formatted and put on the serial line inside of a function (located at offset 0xA3270) which we refer to simply as log. The log function operates as a wrapper to vsnprintf and puts with the added functionality of prefixing supplied log messages with severity and task strings. The log function is variadic and crafts the final log message by passing the supplied format and variadic arguments to vsnprintf. If an attacker can inject content into the format parameter, they could potentially leak stack memory and write arbitrary memory.

    /* Examples:
            log(6, 13, "Initialized SSL");  ->  [DBG!][NET ]Initialized SSL
            log(3, 13, "SSL init error: %d", error);  ->  [ERR!][NET ]SSL init error: {error}
    */
    void log(unsigned int severity, unsigned int task, const char *format, ...)
    {
      char log_buffer[520];
      va_list var_args;
    
      va_start(var_args, format);
      if ( severity <= g_LOG_LEVEL && ((g_TASK_LOGGING_ENABLED_BITFIELD >> task) & 1) != 0 )
      {
        // Prefix the message with the SEVERITY tag
        if ( severity >= MAX_SEVERITY )
          severity = MAX_SEVERITY;
        memcpy(log_buffer, g_SEVERITY_PREFIX[severity], 6u);
    
        // Prefix the message with the TASK tag
        if ( task >= MAX_TASK )
          task = MAX_TASK;
        memcpy(&log_buffer[6], g_TASK_PREFIX[task], 0xCu);
    
        // Populate remainder of message with format and var_args
        vsnprintf(&log_buffer[12], 499u, format, var_args);
    
        // Put crafted message on to UART
        puts(log_buffer);
      }
    }
    

It is important to note that all output from format string injections stemming from misuse of the log function will only be available to a physically present attacker who has partially disassembled the device and connected to the UART console.

This log function is misused in four locations within the /action/wirelessConnect HTTP handler, web_wireless_connect, located at offset 0x19AC94 within the hpgw binary included in firmware 6.9Z.

The web interface, now disabled-by-default, can be re-enabled, and the web interfaces’ administrator account’s password may be changed through the use of TALOS-2022-1552 and TALOS-2022-1553 in order to make these vulnerabilities accessible over the network.

**CVE-2022-35884 - ssid_hex**

The first misuse of the log function occurs when logging the construction of an OS command meant to configure the device’s Wi-Fi AP SSID. The SSID can be provided via either the ssid or ssid_hex HTTP parameter, with ssid_hex taking priority if both are provided. The logic for constructing the log message when using the ssid parameter sufficiently sanitizes the controllable input, so we focus on the logic for handling the ssid_hex parameter. Below is a partial decompilation of the web_wireless_connect function, with annotations.

    int __fastcall web_wireless_connect(mg_connection *conn, mg_request_info *ri)
    {
      ...
      memset(ssid, 0, sizeof(ssid));
      memset(ssid_hex, 0, sizeof(ssid_hex));
      ...
      mg_get_var(payload, payload_len, "ssid", ssid, 191);
     
      // [1] Extract the `ssid_hex` parameter
      mg_get_var(payload, payload_len, "ssid_hex", ssid_hex, 191);
      ...
      if ( !ssid[0] )
      {
        if ( !ssid_hex[0] )
        {
          log(7u, 1u, "No SSID!");
          v6 = strtable_get("WEB_ERR_PARAM_EMPTY", 19);
          return web_error(conn, 0, v6, "ssid and ssid_hex");
        }
      }
      memset(cmd_buffer, 0, sizeof(cmd_buffer));
      ...
      if ( ssid_hex[0] )
      {
        log(7u, 0x1Fu, "with hex string");
        // [2] Craft the OS Command using user-supplied `ssid_hex` parameter
        snprintf(cmd_buffer, 0x7Fu, "driver/wpa_cli -i %s set_network 0 ssid %s", "wlan0", ssid_hex);
      }
      ...
    
      // [3] Call `log` with the injected `cmd_buffer` variable as `format`
      log(7u, 1u, cmd_buffer);
      ...
    }
    

First, at [1], the ssid_hex parameter is extracted from the request and stored in a local variable. If the ssid_hex parameter has content, then at [2] the content of that parameter is used to construct an OS command. At [3], prior to execution of that command, the command string is logged, with the cmd_buffer containing the attacker-controlled ssid_hex parameter being passed to the log function as its format parameter. This results in an attacker-controlled format string being passed to vsprintf.

As an example, supplying an ssid_hex parameter of %x.%x.%x.%x.%x.%x.%x.%x results in the following log being generated:

    [DBG ][WEB ]driver/wpa_cli -i wlan0 set_network 0 ssid 1.727fd5a0.0.0.1.0.0.0.0.0.0.76697264.772f7265
    

**CVE-2022-35885 - wpapsk_hex**

This misuse of the log function occurs when logging the construction of an OS command meant to configure the WPAPSK of the wireless network. The password can be provided via either the wpapsk or wpapsk_hex HTTP parameters, with wpapsk_hex taking priority if both are provided. The logic for constructing the log message when using the wpapsk parameter sufficiently sanitizes the controllable input, so we focus on the logic for handling the wpapsk_hex parameter. Below is the relevant portion of a decompilation of the web_wireless_connect function, with annotations.

    int __fastcall web_wireless_connect(mg_connection *conn, mg_request_info *ri)
    {
      ...
      memset(wpapsk, 0, sizeof(wpapsk));
      memset(wpapsk_hex, 0, sizeof(wpapsk_hex));
      memset(auth_mode, 0, sizeof(auth_mode));
      ...
      mg_get_var(payload, payload_len, "auth_mode", auth_mode, 191);
      mg_get_var(payload, payload_len, "wpapsk", wpapsk, 191);
      
      // [1] Extract the `wpapsk_hex` parameter
      mg_get_var(payload, payload_len, "wpapsk_hex", wpapsk_hex, 191);
      ...
      // [2] Validate that `auth_mode` is WPAPSK_HEX or WPA2PSK_HEX
      if ( !strcmp(auth_mode, "WPAPSK_HEX") || !strcmp(auth_mode, "WPA2PSK_HEX") )
      {
          // [3] Craft the OS Command using user-supplied `wpapsk_hex` parameter
          snprintf(cmd_buffer, 0x7Fu, "driver/wpa_cli -i %s set_network 0 psk %s", "wlan0", wpapsk_hex);
          // [4] Call `log` with the injected `cmd_buffer` variable as `format`
          log(7u, 1u, cmd_buffer);
          ...
      }
    }
    

First, at [1], the wpapsk_hex parameter is extracted from the request and stored in a local variable. It is then confirmed at [2] that the auth_mode parameter is either WPAPSK_HEX or WPA2PSK_HEX. If so, then at [3] the content of that parameter is used to construct an OS command. At [4], prior to execution of that command, the command string is logged, with the cmd_buffer containing the attacker-controlled wpapsk_hex parameter being passed to the log function as its format parameter. This results in an attacker-controlled format string being passed to vsprintf.

Supplying %x.%x.%x.%x.%x.%x... as the wpapsk_hex parameter results in the following log message being generated:

    [DBG ][WEB ]driver/wpa_cli -i wlan0 set_network 0 psk 723fd3a0.723fd660.76b6ecf4.0.1.0.0
    

**CVE-2022-35886 - default_key_id / key**

This misuse of the log function occurs when logging the construction of an OS command meant to configure WEP key management for the wireless network. The WEP key is provided via the key HTTP parameter and the key identifier is provided via the default_key_id HTTP parameter. The WEP key management functionality is only triggered if the auth_mode HTTP parameter is one of WEP or SHARED. Below is the relevant portion of a decompilation of the web_wireless_connect function, with annotations.

    int __fastcall web_wireless_connect(mg_connection *conn, mg_request_info *ri)
    {
      ...
      memset(default_key_id, 0, sizeof(default_key_id));
      memset(key, 0, sizeof(key));
      memset(auth_mode, 0, sizeof(auth_mode));
      ...
      mg_get_var(payload, payload_len, "auth_mode", auth_mode, 191);
      
      // [1] Extract the `default_key_id` and `key` HTTP parameters
      mg_get_var(payload, payload_len, "key", key, 191);
      mg_get_var(payload, payload_len, "default_key_id", default_key_id, 191);
      ...
      
      // [2] Validate that `auth_mode` is SHARED or WEP
      if ( !strcmp(auth_mode, "SHARED") || !strcmp(auth_mode, "WEP") )
      {
        log(7u, 1u, "driver/wpa_cli -i wlan0 set_network 0 key_mgmt NONE");
        popen_write("driver/wpa_cli -i wlan0 set_network 0 key_mgmt NONE");
        
        // [3] Craft the OS Command using user-supplied `default_key_id` and `key` parameters
        snprintf_nullterm(
          cmd_buffer,
          0x7Fu,
          "driver/wpa_cli -i %s set_network 0 wep_key%s '\"%s\"'",
          "wlan0",
          default_key_id,
          key);
          
        // [4] Call `log` with the injected `cmd_buffer` variable as `format`
        log(7u, 1u, cmd_buffer);
      }
      ...
    }
    

First, at [1], the default_key_id and key parameters are extracted from the request and stored in local variables. It is then confirmed at [2] that the auth_mode parameter is either WEP or SHARED. If so, then at [3] the content of the vulnerable parameters are used to construct an OS command. At [4], prior to execution of that command, the command string is logged, with the cmd_buffer containing the attacker-controlled parameters being passed to the log function as its format parameter. This results in an attacker-controlled format string being passed to vsprintf.

Supplying %x.%x.%x.%x.%x.%x... as both the default_key_id and key parameters will result in the following log message being generated:

    [DBG ][WEB ]driver/wpa_cli -i wlan0 set_network 0 wep_key7237d3c0.7237d960.7237da20.6d61535f.1.0.0 '"0.22303122.4c220a2c.35657669.76697264.772f7265.635f6170.2d20696c."'  
    

**CVE-2022-35887 - default_key_id**

The final misuse of the log function within web_wireless_connect occurs almost immediately after the previous vulnerability, when logging the construction of an OS command meant to configure WEP key management for the wireless network. The WEP key index is provided via the default_key_id HTTP parameter. The WEP key management functionality is only triggered if the auth_mode HTTP parameter is one of WEP or SHARED. Below is the relevant portion of a decompilation of the web_wireless_connect function, with annotations.

    int __fastcall web_wireless_connect(mg_connection *conn, mg_request_info *ri)
    {
      ...
      memset(default_key_id, 0, sizeof(default_key_id));
      memset(auth_mode, 0, sizeof(auth_mode));
      ...
      mg_get_var(payload, payload_len, "auth_mode", auth_mode, 191);
      
      // [1] Extract the `default_key_id` and `key` HTTP parameters
      mg_get_var(payload, payload_len, "default_key_id", default_key_id, 191);
      ...
      
      // [2] Validate that `auth_mode` is SHARED or WEP
      if ( !strcmp(auth_mode, "SHARED") || !strcmp(auth_mode, "WEP") )
      {
        ...
        
        memset(cmd_buffer, 0, sizeof(cmd_buffer));
        snprintf_nullterm(cmd_buffer, 0x7Fu, "driver/wpa_cli -i %s set_network 0 wep_tx_keyidx %s", "wlan0", default_key_id);
        log(7u, 1u, cmd_buffer);
      }
      ...
    }
    

First, at [1], the default_key_id parameter is extracted from the request and stored in a local variable. It is then confirmed at [2] that the auth_mode parameter is either WEP or SHARED. If so, then at [3] the content of the default_key_parameter parameter is used to construct an OS command. At [4], prior to execution of that command, the command string is logged, with the cmd_buffer containing the attacker-controlled parameters being passed to the log function as its format parameter. This results in an attacker-controlled format string being passed to vsprintf.

Supplying %x.%x.%x.%x.%x.%x... as the default_key_id parameter will result in the following log message being generated:

    [DBG ][WEB ]driver/wpa_cli -i wlan0 set_network 0 wep_tx_keyidx 7237d3aa.7237d960.7237da20.6d61535f.1.0.0 
    

**TIMELINE**

2022-07-20 - Vendor Disclosure  
2022-10-20 - Public Release

Discovered by Matt Wiseman of Cisco Talos.

CVE-2022-35886: TALOS-2022-1585 || Cisco Talos Intelligence Group

Ursnif, a one-time banking Trojan also known as Gozi, becomes the latest codebase to be repurposed as a more general backdoor, as malware developers trend toward modularity.

Threat groups continue to recycle code from older tools into more generalized frameworks, a trend that will continue as the codebases incorporate more modularity, security experts said this week.

In the latest example, the threat group behind Ursnif — aka Gozi — recently moved the tool away from a focus on financial services to more general backdoor capabilities, cybersecurity services firm Mandiant stated in an analysis. The new variant, which the company has dubbed LDR4, is likely intended to facilitate the spread of ransomware and the theft of data for extortion.

The modular malware joins Trickbot, Emotet, Qakbot, IcedID, and Gootkit, among others, as tools that started as banking Trojans but have been repurposed as backdoors, without requiring the development effort of creating an entirely new codebase, says Jeremy Kennelly, senior manager for financial crime analysis at Mandiant.

"The developers working on banking Trojans have taken multiple approaches to retooling their malware as a backdoor to support intrusion operations, though a major code rewrite hasn’t generally been deemed necessary," he says. "These malware families — at their core — are just modular backdoors that have historically loaded secondary components enabling 'banker' functionality."

Mandiant's analysis of Ursnif points out that maintaining multiple codebases is a challenging task for malware developers, especially when one mistake could give defenders a way to block an attack and investigators a way to hunt down the attacker. Maintaining a single modular codebase is much more scalable, the company's analysis this week stated.

**A Malware Movement Toward Backdoor Modularity**

It's unsurprising that malware developers are moving to more general and modular code, says Max Gannon, a senior intelligence analyst at Cofense.

"In some cases, a purpose-built remote access Trojan (RAT), traditionally viewed as a backdoor, may be more conducive to the threat activity," he says. "However, a lot of threat actors want more than just a backdoor, and many commodity malware families have morphed to become multipurpose tools that simply include backdoor access."

The specialization of tools in the cybercriminal underground is also a reason why older codebases are being repurposed. By focusing specific tools on areas of attack — such as initial access, lateral movement, or data exfiltration — the developers of these tools are able to differentiate themselves against competitors and offer a unique set of features. Using existing codebases also saves time, and making such projects modular allows the tool to be customized for the customer's — read, "attacker's" — needs, says Jon Clay, vice president of threat intelligence at Trend Micro.

"The coders behind many of these toolkits create them and sell them within the cybercriminal underground markets, as they offer newbies and other malicious actors with a ready-made kits for executing attacks," he says. "Many of these offer automations now as well as GUI interfaces to manage the attacks and victim information/data."

The original Ursnif code appeared in the mid-2000s. The Zeus banking Trojan — used in thefts of tens of millions, and likely hundreds of millions, of dollars — has had a similar trajectory, with its adoption accelerated by a source code leak. Another banking Trojan, Emotet, has now become a general backdoor, allowing its development group to offer access as a service to other cybercriminals, a business relationship also demonstrated by Qakbot, another Trojan initially created as a banking Trojan.

All of these programs had the benefit of modularity, says Mandiant's Kennelly.

"All bankers that have been broadly repurposed as backdoors were already modular, which has the added benefit of limiting the complexity of the core malware while providing significant operational flexibility," he says. "These established malware families also had a proven track record and general familiarity to the actors using them."

**Swiss Army Knife Malware Delivery**

Rather than changes in functionality, a lot of the evolution in categorizing attackers tools has come about because labeling has had to catch up to changes in the malware design. By redesigning the codebases to be modular, defining a tool as a single thing — whether a banking Trojan, a spam bot, or a worm — becomes much more difficult. Adding a single new module would change the label for the code.

In the past, for example, computer viruses spread by infecting files, while worms used automated scanning and exploitation to spread quickly and more widely. However, a number of Trojans incorporated either or both functionality, leading to a more general term: malicious software, or malware.

A similar evolution has happened around the classification of attacker tools. Programs that were originally considered to be banking Trojans, RATs, or a scanning tools are now capabilities of more general frameworks, says Codefense's Gannon.

"If we think of a backdoor as software that sits on a machine to provide access that skirts normal security measures, banking Trojans inherently act as backdoors in order to perform their usual functions, so almost any banking Trojan can be used as one without the need for many changes," he says. "The difference is often simply in the intent of the user."

**How to Protect Against Modular Malware**

To combat the threat, companies should have tools that look for telltale signs that a backdoor or RAT are being used inside their network. Since phishing attacks are a common way to compromise end user's systems, multifactor authentication (MFA) and employee training can also help harden businesses against attacks.

Overall, having visibility into change to systems and anomalous traffic on the network can help immensely, Trend Micro's Clay says.

"The main thing to know is that in many cases there are early signs of these tools being used within the organization and that if seen," he says, "they should be taken very seriously that there is likely an active campaign against them."

Threat Groups Repurpose Banking Trojans into Backdoors

Cybersecurity pros discuss a trio of lessons from the Equifax hack and how to prevent similar attacks in the enterprise.

On the morning of Sept. 7, 2017, US credit bureau giant Equifax announced hackers had infiltrated its network and exfiltrated customer names, Social Security numbers, birthdates, and addresses. The news of the breach — which compromised the private records of 147.9 million Americans (almost 50% of the entire US population), 15.2 million Britons, and almost 19,000 Canadians — immediately created pandemonium across organizations, forcing many business leaders to reconsider their security postures. Much has changed over the past five years, but the lessons from the Equifax breach are still relevant for enterprises.

Equifax didn't reveal the breach as soon as it discovered it — the company sat on the information for more than a month. It was the perfect antithesis: A business known to provide credit score rating, fraud solutions, financial marketing, and analytical services had been hacked. The attackers had gotten in through an unpatched vulnerability in Apache Struts. The worst part? Apache had already warned about the flaw and a patch was available.

"The Equifax breach is a unique attack in that a conscious decision was made by a company and its leadership: not to patch the vulnerability when the software vendor announced the vulnerability and provided the patch," says James Turgal, vice president of cyber risk, strategy, and board relations at Optiv.

The attack, now linked to four hackers from the Chinese military, represents one of the most sweeping attacks conducted against US businesses by foreign nationals. Industry experts discuss with Dark Reading what lessons to draw from the breach and how organizations can prevent similar threats in their environments.

**Data Management Is Still an Enterprise Problem**

"Equifax shows that organizations need to focus on data management," Adam Marrè, CISO at Arctic Wolf and former FBI special agent/cyber investigator, tells Dark Reading.

"With so many different IT and security priorities, companies aren't thinking about data management in the right ways. Most organizations only think about how best to monetize data or how to use it to serve their customers, but they often miss the significant increase in risk that storing the data brings."

Turgal agrees, noting that enterprises and individuals are at risk of data exfiltration and identity theft.

"Every day, companies large and small fall victim to identity theft," he says. "Both the high volume of activity and large transactions occurring at the corporate level attract threat actors, using data that typically has been exfiltrated from another breach by a separate threat actor and sold to the highest bidder to impersonate the identity of a business to commit fraud."

Gartner estimates that until 2025, "80% of organizations seeking to scale digital business will fail because they do not take a modern approach to data governance." That's a lot of businesses, and it's a figure that Marrè agrees with.

"In my experience, most companies don't have a comprehensive picture of how they collect, store, and manage data," he says. "Especially from a security standpoint, most businesses have no idea who has access to what data, how to properly classify it, how to protect it, and even how to set up data retention policies to properly get rid of it. By focusing on these aspects, businesses can transform their data strategies and further protect themselves and their customers."

Turgal suggests that organizations can safeguard data and identity by doing the following:

*   Include artificial intelligence and machine-learning technologies into the business processes to quickly spot anomalous behavior.
*   Review and update access permissions and utilize data encryption when the data is in transit and at rest.
*   Establish protocols for user provisioning and deprovisioning of regular and privileged access holders.
*   Continually educate employees on how to minimize risk.

**Enterprises Aren't Paying Attention to the Basics**

The fundamentals of cybersecurity are still lacking in several enterprise efforts at securing user data. Leaning on his experience in the FBI and private sector, Marrè says he has seen so many organizations that are not adequately prioritizing security. With security incidents at high-profile businesses and rampant ransomware and extortion attacks worldwide, organizations can no longer afford to ignore or sideline their security, he says.

"Although there are new and exciting technologies that are aimed at solving different attack vectors, focusing on successfully executing the fundamentals of cybersecurity remains the most effective strategy," Marrè says. "When it comes to protecting your organization and your data, prevention is good, but detection is a must."

Many attacks can be avoided by implementing zero-trust architecture to the letter. In hindsight, for example, the Equifax attack could have been prevented if the organization had paid more attention to the multiple threat warnings the company had received before the hack.

The Equifax breach was "a strong example of why enterprises should evaluate their data to understand the business need and ensure it is classified appropriately," says Andrew Bayers, head of threat intelligence at Resilience, adding that data should be stored and transmitted securely — and ultimately retained for only the amount of time needed.

**Cyber Resilience Needs Action, Not Reaction**

While it's true that some players in the enterprise are investing heavily in cybersecurity, several others are still lagging — giving malicious actors an opening to capitalize on discrepancies and take control of critical data assets. Although its activities are not immediately noticeable, a proactive cybersecurity team is worth its weight in gold.

"Having a skilled security team is the backbone of a sound cybersecurity strategy," Marrè says. "Whether it's a world-class team from a partner or in-house experts, this should be a priority for all companies."

To become cyber resilient, Bayers adds, organizations should identify vulnerabilities in their systems and prioritize patching according to the risks they pose.

Equifax's Lessons Are Still Relevant, 5 Years Later

Led by NTTVC, the funding enables further development of Cloud Native Intrusion Prevention from the team that invented Network Intrusion Prevention Systems.

AUSTIN, Texas, Oct. 25, 2022 /PRNewswire-PRWeb/ — Spyderbat, a cloud native runtime security company, today announced it has raised $10 million in Series A funding. The funding was led by NTTVC with participation from LiveOak Venture Partners, Benhamou Global Ventures and John McHale to fuel product development and go-to-market activities.

The Enterprise shift-left trend toward a more embedded approach to security in the continuous integration and continuous delivery (CI/CD) pipeline requires new innovation. While organizations adopt strategies to reduce exploitable vulnerabilities in cloud native environments, it has proven insufficient to defend against breaches. The rate of change enabled by cloud provisioning and microservice architectures increase the probability of misconfigurations and missed known and unknown vulnerabilities. Additionally, the dependencies on third-party components increase the probability of supply chain compromises and zero-day attacks. Spyderbat addresses these needs with capabilities that integrate runtime security throughout the lifecycle.

CEO Marc Willebeek-LeMair and CTO Brian Smith, co-founders of Spyderbat, are no strangers to intrusion prevention systems (IPS). As the original founders of TippingPoint, Willebeek-LeMair and Smith invented the network IPS in the early 2000s.

"As we grew closer to understanding the fundamental security concerns in cloud native environments, we recognized the need for a brand-new approach," states Willebeek-LeMair. "Traditional detection methods, along with the rate of change found in cloud native environments, create inaccurate findings that require teams to investigate each with limited data. This leads to high volumes of interrupt-driven efforts that are inconclusive. DevOps and Platform Engineering teams need an accurate understanding of what is happening before automation can occur and a broader protection solution."

The Spyderbat SaaS platform boasts three critical capabilities for detecting and blocking intrusions attacking known and unknown vulnerabilities:

*   Runtime Visibility -Spyderbat generates live detailed mapping and historic contextual visibility across Kubernetes, container and VM  
    environments to enable DevOps and Platform Engineering teams' immediate visibility to the root cause of security and operational issues. 
*   Runtime Delta - Armed with the ability to capture runtime activities with causal context, Spyderbat's Runtime Delta enables development teams to rapidly and securely iterate within guard rails, using an automated understanding of runtime behavior differences between builds and environments.
*   Runtime Intrusion Prevention - Spyderbat provides the industry's broadest form of protection that blocks attacks against cloud-native  
    workloads throughout the software development lifecycle, including supply-chain attacks, compromised credentials, ransomware, and  
    cryptojacking.

In addition to the platform's core capabilities, Spyderbat Labs produces continuous actionable intelligence updates to the Spyderbat platform by performing threat research for cloud native environments. Spyderbat Labs creates Shields to stop attacks against known vulnerabilities, packaged baseline policies to built-in Linux and Kubernetes services, and Attack Detections mapped to MITRE ATT&CK techniques.

"Spyderbat opens the doors to a new level of security and operational awareness," states Aldo Gonzalez, CTO at Client Support Software. "It identifies previous unknowns that require my attention, allowing me to easily see the whole picture and take action."

"It is not about detecting individual activities that may or may not indicate a compromise," adds Smith. "What separates Spyderbat is a complete understanding of runtime activities to recognize new workload behaviors or connect threat indicators to each other and their root cause. This context enables early detection and accuracy, with a thorough understanding of the intrusion that enables automation to block it."

"Spyderbat's platform offers early cloud-native intrusion prevention, which is critical for enterprises in today's complex and high-threat environment," said Fay Hazaveh Costa, Partner at NTTVC. "We are looking forward to supporting the Spyderbat team and helping to fuel their next phase of growth."

In addition to its core offering, Spyderbat separately announced today its Open-Source program. Spyderbat is exhibiting at KubeCon+CloudNativeCon October 26th through October 28th. Learn more about Spyderbat's solution for cloud native runtime security by visiting their booth #SU45.

**About Spyderbat**

  
Spyderbat delivers cloud native runtime security to customers with unprecedented precision in intrusion prevention and mitigation. Founded in 2019 on the recognition that the manual processes of traditional security operations are completely ineffective in rapidly changing cloud environments, Spyderbat is making threat prevention and security operation automation available with a platform for early, accurate, and thorough recognition of attacks. To learn more about Spyderbat's solutions, open-source projects, career opportunities, or to begin using Spyderbat's free tier, visit http://www.spyderbat.com.

Spyderbat Raises Series A to Deliver Runtime Security Throughout Cloud Native Software Development Environments

New report shows 75% of MSPs will invest in security threat intelligence services in the next 12 months to help businesses combat increased threats.

**MIAMI, FL / ACCESSWIRE / October 25, 2022** — Lumu, the creator of the Continuous Compromise Assessment cybersecurity model that empowers organizations to measure compromise in real-time, has partnered with Enterprise Management Associates (EMA) to conduct an independent survey exploring why MSPs are focusing on growing their cybersecurity practices, cites their most pressing concerns when it comes to threats and offers guidance on how MSPs can build a security stack effectively.

"There's been a monumental shift in threat actors' operations, which have led SMBs to face a higher risk of targeted security breaches," said Ricardo Villadiego, Founder and CEO of Lumu. "Now more than ever, entrepreneurs and small business leaders need to understand the heightened need for cybersecurity. With that awareness comes the need to implement a comprehensive cybersecurity program, but not every small business has the means to do so in-house. MSPs that can effectively meet the current needs of SMBs will gain market share and see significant growth opportunities."

The "MSP Cybersecurity Market Opportunity Blueprint" study found that:

*   In the next 12 months, 75% of MSPs are planning to invest in security and threat intelligence, 66.2% in threat detection and response, 66.2% in real-time attack visibility and 50% in forensics and incident response.
*   The most important concerns of MSPs when it comes to protecting customers from cyber threats are malware (77.9%), ransomware (70.6%), business email compromise (64.7%), and phishing (69.1%).
*   More simplistic malware techniques are enough for cyber-criminals to compromise SMBs, while larger organizations must employ more sophisticated and scalable techniques. Cyberattacks on small businesses consist mainly of malware (60%).
*   The top fears MSPs are around when/if customers experience a cyberattack are operational downtime (69.1%), losing the trust of your customers (64.7%), financial losses (63.2%), and reputational losses (61.8%).

Based on the findings of the report, EMA recommends five steps that MSPs should follow to start or evolve their cybersecurity practice:

*   **Customers' network-level threat visibility is vital:** MSPs should develop methods to identify any and all traces of compromise in the network because it will help MSPs minimize damage and avoid disruption.
*   **Ensure scalability through effective tools:** MSPs should favor SaaS-based commercially available solutions that can grow effectively with the MSP - tools built to effectively use cybersecurity talent, so they spend their time effectively.
*   **Leverage response automation:** MSPs achieve great levels of efficiency by combining real-time attack monitoring with integration capabilities that use out-of-the box or API techniques for data exchange and touchless response.
*   **Understand the pricing thoroughly:** MSPs need flexible pricing that matches the services delivered to their customers to not get locked into unfavorable long-term contracts which are undesirable considering the changing threat landscape.
*   **Protect the human element:** With phishing and other social engineering techniques increasing in sophistication and effectiveness, MSPs should train their staff and users across their customer base to identify and report these threats.

"We foresee that more than half of SMBs will part ways with MSPs that fail to address cybersecurity needs effectively and seek out alternative solutions," said Chris Steffen, Managing Research Director at EMA. "There's a huge opportunity for MSPs to get ahead of this and invest in security areas that are most prevalent to SMBs in the next 12 months such as security threat intelligence services, threat detection and response, real-time attack visibility, and forensic and incident response. The MSPs that prioritize these areas will be at an advantage over competitors and will be better equipped to grow their customer base."

To view the full findings of the MSP Cybersecurity Market Opportunity Blueprint report please download https://lumu.io/msp-growth-blueprint/.

**About Lumu**  
Headquartered in Miami, Florida, Lumu is a cybersecurity company focused on helping enterprise organizations illuminate threats and isolate confirmed instances of compromise. Applying principles of Continuous Compromise Assessment, Lumu has built a powerful closed-loop, self-learning solution that helps security teams accelerate compromise detection, gain real-time visibility across their infrastructure, and close the breach detection gap from months to minutes. Learn more about how Lumu illuminates network blindspots at www.lumu.io.

**About EMA**  
Founded in 1996, Enterprise Management Associates (EMA) is a leading industry analyst firm that specializes in going "beyond the surface" to provide deep insight across the full spectrum of IT management technologies. EMA analysts leverage a unique combination of practical experience, insight into industry best practices, and in-depth knowledge of current and planned vendor solutions to help its clients achieve their goals.

Learn more about EMA research, analysis, and consulting services for enterprise IT professionals, and IT vendors at www.enterprisemanagement.com or follow EMA on Twitter or LinkedIn.

MSP Market Opportunity Report Finds Cybersecurity as Primary Growth Driver as SMBs Lack Resources to Develop Security Program In-House

BILBAO, Spain, Oct. 25, 2022 /PRNewswire/ — SealPath, a leading provider of zero-trust data-centric security and enterprise digital rights management, announced the launch of SealPath Data Classification powered by Getvisibility, leveraging the latest Artificial Intelligence and Machine Learning technologies to provide their customers with an advanced standard of visibility, protection, control, and a dynamic understanding of their data as it is being created.

This innovative AI-enhanced data classification solution provides the insights and continuous automated protection that enterprise customers need to securely and accurately classify data over its entire lifecycle. Thus, organisations across multiple business verticals gain the ability to prevent data leaks and achieve compliance with the strictest data protection regulations.

With SealPath's classification, the user receives suggestions about the classification level when creating and editing a document. The software learns and adapts to different document types, continuously improving accuracy through AI, and allows organisations to classify unstructured information with unprecedented confidence.

SealPath's information protection is 100% integrated with the new intelligent data classification system so that those files labeled with a certain classification level or subject to a specific regulation can be protected automatically and without user intervention.

"SealPath Data Classification powered by Getvisibility was born in response to the outdated technologies most modern companies currently utilise to classify and manage their data. The solution's machine learning models have been pre-trained for years via data containing a wide array of data types – from personal information, medical and financial to defense data. Combined with robust software specialised in data classification, these thoroughly trained models minimize human error, costs, and time in labelling corporate information. We expect this new AI-powered approach will transform how organisations classify and protect their data," Luis Angel del Valle, CEO of SealPath, stated.

SealPath Data Classification deploys a flexible approach, considering different dimensions such as data sensitivity, associated regulations, data types, and scope of dissemination. Consequently, the system can adapt the classification to the organisation based on the aforementioned dimensions, enabling the automated protection of tagged data via AI/ML algorithms.

SealPath's protection, coupled with the AI and Machine Learning-powered classification system, streamlines an organization's efforts to avoid sensitive information data classification errors quickly and cost-effectively.

**About SealPath**

SealPath is a European leader in Zero-Trust Data-Centric Security and Enterprise Digital Rights Management, working with major companies in more than 25 countries. SealPath has been helping organisations across multiple business verticals, such as Manufacturing, Oil & Gas, Retail, Finance, Healthcare, and Public Administrations, protect their data for over a decade. SealPath's client portfolio includes organisations within the Fortune 500 index and Eurostoxx 50. SealPath makes it easy to avoid costly mistakes, lower the risk of data leaks, ensure security for confidential information and protect data assets.

SealPath Data Classification Powered by Getvisibility Applies Artificial Intelligence to Improve Accuracy and Efficiency of Data Labelling and Protection

The Hive ransomware-as-a-service (RaaS) group has claimed responsibility for a cyber attack against Tata Power that was disclosed by the company less than two weeks ago.
The incident is said to have occurred on October 3, 2022. The threat actor has also been observed leaking stolen data exfiltrated prior to encrypting the network as part of its double extortion scheme.
This allegedly comprises

The Hive ransomware-as-a-service (RaaS) group has claimed responsibility for a cyber attack against Tata Power that was disclosed by the company less than two weeks ago.

The incident is said to have occurred on October 3, 2022. The threat actor has also been observed leaking stolen data exfiltrated prior to encrypting the network as part of its double extortion scheme.

This allegedly comprises signed client contracts, agreement documents, as well as other sensitive information such as emails, addresses, phone numbers, passport numbers, taxpayer data, among others.

The Mumbai-based firm, which is India's largest integrated power company, is part of the Tata Group conglomerate.

Tata Power had previously disclosed in a filing with the National Stock Exchange (NSE) of India that an intrusion on the company's IT infrastructure impacted "some of its IT systems."

According to further details shared by security researcher Rakesh Krishnan, the leak contains personally identifiable information (PII), including Aadhaar identity numbers, permanent account numbers (PAN), drivers' license, salary specifics, and engineering drawings.

The latest development is also indicative of the fact that Tata Power likely refused to pay a ransom, prompting the cybercrime gang to publish the siphoned data on its HiveLeaks dark web portal.

According to statistics published by Digital Shadows and Intel 471, Hive was the third-most prevalent ransomware family observed in Q3 2022, coming only behind LockBit 3.0 and Black Basta and surpassing the likes of AvosLocker, BlackByte, BlackCat, and Vice Society.

Found this article interesting? Follow THN on Facebook, Twitter __ and LinkedIn to read more exclusive content we post.

Hive Ransomware Hackers Begin Leaking Data Stolen from Tata Power Energy Company

Chinese and Russian cyber-spies actively targeting security vulnerability

Chinese and Russian cyber-spies actively targeting security vulnerability

Fortinet is urging customers to patch a critical authentication bypass vulnerability that has already been exploited in the wild.

Earlier this month, the networking vendor patched the bug, CVE-2022-40684, found in its FortiOS network operating system, FortiProxy secure web proxy, and FortiSwitchManager management platform projects.

The vulnerability allows an unauthenticated attacker to add an SSH key to the admin user, enabling potential miscreants to hack the administrative interface using specially crafted HTTP or HTTPS requests.

The issue affects FortiOS versions from 7.0.0 to 7.0.6 and from 7.2.0 to 7.2.1, FortiProxy versions from 7.0.0 to 7.0.6 and 7.2.0, and FortiSwitchManager versions 7.0.0 and 7.2.0.

Catch up on the latest network security news and analysis

Customers were notified via email and advised to update vulnerable devices to FortiOS 7.0.7 or 7.2.2 and above, FortiProxy 7.0.7 or 7.2.1 and above, and FortiSwitchManager 7.2.1 or above earlier this month. Those that can’t, said Fortinet, should immediately disable internet-facing HTTPS Administration interfaces.

After the patch was released, Horizon3.ai published proof-of-concept code for exploiting the vulnerability.

“An attacker can use this vulnerability to do just about anything they want to the vulnerable system. This includes changing network configurations, adding new users, and initiating packet captures,” it warned.

“Note that this is not the only way to exploit this vulnerability and there may be other sets of conditions that work. For instance, a modified version of this exploit uses the User-Agent ‘Node.js’.”

**Axis of exploit**

Meanwhile, cybersecurity firm Cyfirma warned that attackers are scanning for and attempting to exploit the vulnerability in the wild.

“Our intelligence research community observed Iranian and Chinese threat actors abusing the vulnerabilities of Fortinet products,” it said. “The suspected threat actors are US17IRGCorp aka APT34, HAFNIUM, and its affiliates in the ongoing campaign.”

Cyfirma warned that Iranian cybercriminals appear to be colluding with Chinese groups and Russian cybercriminals as part of the campaign, with the aim of supporting Russia’s offensive in Ukraine.

Dark web forum discussions, according to Cyfirms, have focused on exploiting weakness in enterprise networks that rely of Fortinet’s technologies, manipulator-in-the-middle (MITM) attacks, potential ransomware attacks, and lateral movement to hack deeper in the network of compromised organizations.

**Patching advice reiterated**

In response to the detection of attacks in the wild, Fortinet issued a further advisory, stressing the increased seriousness of the situation.

“Fortinet is aware of instances where this vulnerability was exploited to download the config file from the targeted devices, and to add a malicious super\_admin account called ‘fortigate-tech-support’,” it said, before reiterating its advice for customers to update.

However, four days later, it appeared that many affected organizations had still failed to patch their systems, leading to yet another warning from Fortinet.

“After multiple notifications from Fortinet over the past week, there are still a significant number of devices that require mitigation, and following the publication by an outside party of PoC code, there is active exploitation of this vulnerability,” it said.

In a statement for The Daily Swig, the company adds: “As part of our commitment to the security of our customers, we continue to proactively reach out to strongly urge them to immediately follow the guidance provided in our October 10 PSIRT Advisory (FG-IR-22-377), as we continue monitoring the situation.”

RELATED Failed Cobalt Strike fix with buried RCE exploit now patched

Critical authentication bug in Fortinet products actively exploited in the wild

Free service provides insights developers need to systematically identify and reduce container vulnerabilities.

DETROIT, Oct. 25, 2022 /PRNewswire-PRWeb/ — KUBECON + CLOUDNATIVECON NORTH AMERICA — In software supply chain security, knowing your software means knowing what's in it--for better or worse. Slim.AI, the Boston-based startup focused on optimizing and securing cloud-native applications, has today launched Container Intelligence, a free and open service that anyone can use to quickly gain  
valuable insights into what's in the most popular container images that they're baking into their software every day.

Despite the supercharged emphasis on security in the software industry, containers now have more vulnerabilities than ever before; moreover, a worrisome gap exists between developers and leadership on resources needed to address the problem. These findings are detailed in the second annual Slim.AI Public Container Report, published today and available for complimentary download.

Slim.AI aims to help close the gaps identified in the report by making Container Intelligence available to everyone, free. Container Intelligence scans more than 160 popular public container images making up 30% of total global pull volume using a combination of open-source and proprietary scanning tools. Slim.AI will quickly expand the dataset to cover the majority of public containers used by developers today across multiple registry providers. Developers can use Container Intelligence to make informed decisions when selecting containers or containerized applications for use in their tech stacks.

"Democratizing information about the security posture of public containers is critical if we want to meet the challenges of today's software supply chain," said John Amaral, co-founder and CEO at Slim.AI. "At Slim.AI, we believe in sharing information we have about the security and usability of public containers with developers so that they can make informed decisions about the containers they work with."

Key features of 'Container Intelligence' by Slim.AI:

*   Publicly available container profile pages on the Slim.AI website -- no login, no registration needed.
*   Profiles include vulnerability counts by severity, container construction details, and package information, along with comparisons to  
    similar public containers.
*   Containers are fully searchable and categorized according to use case (for example, base images, CMSs or DevOps tools).
*   The data is updated daily to ensure freshness.

Slim.AI will be adding more capabilities to Container Intelligence throughout the coming year. Future enhancements will include expanding the database to include more public registries, adding comparative analysis across images and providing container update notifications.

**Taking It to the Next Level with Slim.AI**

  
For those who want to know even more about their containers, developers can log in to the Slim.AI platform from the Container Intelligence page to analyze their own private containers, get vulnerability reports from multiple scanners, and automatically harden their container images for production.

Additionally, Slim.AI has been adding functionality for teams and is accepting a limited number of organizations into its design partner program. For more information, contact \[email protected\].

**Learn More About Container Security at KubeCon/CloudNativeCon**

  
For those interested in hearing more, Ayse Kaya, Slim.AI's senior director of strategy and insights, will present a keynote at KubeCon NA based on this dataset on Wednesday, October 26 at 10:05 a.m. EDT. Her presentation, "What We Learned Dissecting the World's Most Popular Containers," demonstrates the current paradox in software supply chain practices, especially the trade-offs teams make between "developer experience" and "production readiness."

Kaya's insights are based on a Dimensional Research survey of 300 software developers and DevOps engineers globally as well as an analysis of the most popular public container images used by developers today. This work forms the basis of the second annual Slim.AI Public Container Report.

"Perhaps the most stunning finding at a macro level is that after a year of intense focus on security, the cloud-native ecosystem is no safer today than it was this time last year," said Kaya. "The silver lining, however, is that awareness is increasing. The complexity of the problem is not our enemy; ignorance of the problem is. And our industry is taking strides to come together and make applications more secure."

Watch Kaya's keynote at KubeCon to learn more about her findings, which include:

1.  Of the top public containers Slim.AI observed over the past year, 60% actually contain more vulnerabilities today than they did one year ago. Most notably, high-severity vulnerabilities increased by 50%, followed by a 10% increase in critical vulnerabilities. The average public container has 287 vulnerabilities, 30% of which belong to a high/critical category (up from 20% last year).
2.  A discrepancy between executives and developers on both the capabilities required for supply chain security and the organization's preparedness. According to the survey, executives believe that more container security practices are happening in their organizations (49%) than frontline developers (34%).
3.  Developers are getting squeezed from both sides -- shifts to the left mean removing vulnerabilities from containers is a developer problem, with more and more customers demanding often unrealistic "zero vulnerabilities" in delivered software. Among developers, 88% said it is challenging to ensure containerized apps are free from vulnerabilities, complexity being the #1 contributing factor. Seventy percent stated their customers demand that their containers have zero vulnerabilities.

Visit Slim.AI at Booth SU64 to learn more from Slim.AI representatives.

**About Slim.AI**

  
Slim.AI helps developers create, build, deploy and run their cloud-native applications more efficiently and securely. The unique approach used by Slim.AI moves the focus on container optimization upstream in the DevOps lifecycle, giving developers the tools they need to author, manage and ship production-ready containers efficiently and effectively. More information at https://slim.ai and @SlimDevOps.

Tag

#intel