Four OS command injection vulnerabilities exist in the XCMD testWifiAP functionality of Abode Systems, Inc. iota All-In-One Security Kit 6.9X and 6.9Z. A XCMD can lead to arbitrary command execution. An attacker can send a sequence of malicious commands to trigger these vulnerabilities.This vulnerability specifically focuses on the unsafe use of the `WL_WPAPSK` configuration value in the function located at offset `0x1c7d28` of firmware 6.9Z.

**SUMMARY**

Four OS command injection vulnerabilities exist in the XCMD testWifiAP functionality of Abode Systems, Inc. iota All-In-One Security Kit 6.9X and 6.9Z. A XCMD can lead to arbitrary command execution. An attacker can send a sequence of malicious commands 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.

The iota device receives command and control messages (referred to in the application as XCMDs) via an XMPP connection established during the initialization of the hpgw application. As of version 6.9Z there are 222 XCMDs registered within the application. Each XCMD is associated with a function intended to handle it. As discussed in TALOS-2022-1552 there is a service running on UDP/55050 that allows an unauthenticated attacker access to execute these XCMDs.

An XCMD, by virtue of being commonly transmitted over XMPP, is an XML payload structured in a specific format. Each XCMD must contain a root node , which must contain a child element, <mac> with an attribute v containing the target device MAC Address. There must also be a child element <cmd> which must contain an attribute a naming the XCMD to be executed. From there, various XCMDs require various child elements that contain information relevent only to that handler.

The testWifiAP XCMD is used to validate the existing wireless network configuration, and it does not expect any parameters. The XCMD appears as follows.

 <?xml version="1.0" encoding="UTF-8"?>
 
 <mac v="B0:C5:CA:00:00:00"/>
 <cmds>
 <cmd a="testWifiAP"/>
 </cmds>
 
 

The handler associated with testWifiAP is located at offset 0x104830 of the /root/hpgw binary included in version 6.9Z, and its decompilation is included here.

 int __fastcall testWifiAP(xml_node_t *xcmd, xstrbuf_t *response)
 {
 const char *err_str;
 wifi_config_t wifi_config;
 
 // [1] Copy the current wireless configuration into `wifi_config`
 fetch_wifi_config(&wifi_config);
 
 // [2] Pass the wireless configuration into the vulnerable function
 if ( do_test_wifiap(&wifi_config) )
 {
 err_str = strtable_get("XCMD_ERR_WIFI_AUTH", 18);
 xml_construct_error_response(response, 0, 82, err_str);
 }
 else
 {
 init_xml_response(response);
 }
 return 0;
 }
 

The handler itself is very straightforward. At [1] it collects the current wireless configuration and passes it to a delegate function we’ve named do_test_wifiap. It is the do_test_wifiap that contains the vulnerability, but this function is only executed when the testWifiAP XCMD is received.

The function we refer to as fetch_wifi_config is located at offset 0x1C722C. Its decompilation is included here.

 void __fastcall fetch_wifi_config(wifi_config_t *config)
 {
 fetch_config_value("WL_SSID", config->ssid, 191);
 fetch_config_value("WL_SSID_HEX", config->ssid_hex, 191);
 fetch_config_value("WL_AuthMode", config->auth_mode, 191);
 fetch_config_value("WL_WPAPSK", config->wpapsk, 191);
 fetch_config_value("WL_WPAPSK_HEX", config->wpapsk_hex, 191);
 fetch_config_value("WL_EncrypType", config->encryp_type, 191);
 fetch_config_value("WL_DefaultKeyID", config->default_key_id, 191);
 fetch_config_value("WL_Key", config->key, 191);
 }
 

These WiFi configuration values may be modified a few ways: by the user via mobile application or abode web application; through the setWifiAP XCMD; and via either the /action/wirelessPost or /action/configPost endpoints of the device’s local web interface. None of these mechanisms implement useful sanitization or sanity checking on the values. For the purposes of the following vulnerabilities, we assume that the remote attacker has manipulated these parameters prior to triggering the vulnerable testWifiAP XCMD.

These configuration values are passed to the function we’ve named do_test_wifiap which is located at offset 0x1c7d28. The function is reminiscent of the vulnerable web_wireless_connect function discussed in TALOS-2022-1556. The relevant portions of the decompilation are included below.

 int __fastcall do_test_wifiap(wifi_config_t *config)
 {
 int result;
 const char *static_command;
 int retry;
 int con_suc;
 const char *str_err;
 int wireless_enabled;
 char cmd_output[32];
 char command[256];
 
 wireless_enabled = 0;
 
 // [1] Ensure that wireless is enabled, otherwise exit early
 get_config_as_integer("WL_Enable", (int)&wireless_enabled);
 if ( !wireless_enabled )
 return -3;
 
 // [2] Ensure that one of `config->ssid` or `config->ssid_hex` is provided
 if ( !config->ssid[0] && !config->ssid_hex[0] )
 {
 log(7, 31, "No SSID!");
 return -2;
 }
 
 ...
 
 memset(command, 0, 0x80u);
 // [3] Identify whether the SSID is provided via the `config->ssid` or `config->ssid_hex` configuration value
 if ( config->ssid_hex[0] )
 {
 // [4] If via `config->ssid_hex`, inject directly into the OS command
 log(7, 31, "with hex string");
 vsnprintf_nullterm(command, 0x7Fu, "driver/wpa_cli -i %s set_network 0 ssid %s", "wlan0", config->ssid_hex);
 }
 else
 {
 // [5] If via `config->ssid`, inject directly into the OS command
 log(7, 31, "with acii string");
 vsnprintf_nullterm(command, 0x7Fu, "driver/wpa_cli -i %s set_network 0 ssid '\"%s\"'", "wlan0", config);
 }
 log(7, 1, command);
 
 // [6] Execute the command constructed at [4] or [5]
 popen_write(command);
 
 
 memset(command, 0, 0x80u);
 if ( strcmp(config->auth_mode, "WPA") && strcmp(config->auth_mode, "WPA2") )
 {
 
 // [7] If `config->auth_mode` is WPAPSK or WPA2PSK
 if ( !strcmp(config->auth_mode, "WPAPSK") || !strcmp(config->auth_mode, "WPA2PSK") )
 {
 // [8] then inject `config->wpapsk` directly into the OS command
 vsnprintf_nullterm(command, 0x7Fu, "driver/wpa_cli -i %s set_network 0 psk '\"%s\"'", "wlan0", config->wpapsk);
 log(7, 1, command);
 p_command = command
 }
 
 // [9] Otherwise, if `config->auth_mode` is SHARED or WEP
 else if ( !strcmp(config->auth_mode, "SHARED") || !strcmp(config->auth_mode, "WEP") )
 {
 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");
 
 // [10] Construct an OS command by injecting `config->default_key_id` and `config->key`
 vsnprintf_nullterm(
 command,
 0x7Fu,
 "driver/wpa_cli -i %s set_network 0 wep_key%s '\"%s\"'",
 "wlan0",
 config->default_key_id,
 config->key);
 log(7, 1, command);
 
 // [11] Execute the command constructed at [10]
 popen_write(command);
 memset(command, 0, 0x80u);
 
 // [12] Then construct a second OS command by injecting `config->default_key_id` directly
 vsnprintf_nullterm(
 command,
 0x7Fu,
 "driver/wpa_cli -i %s set_network 0 wep_tx_keyidx %s",
 "wlan0",
 config->default_key_id);
 log(7, 1, command);
 
 // [13] Execute the command constructed at [12]
 popen_write(command);
 
 if ( strcmp(config->auth_mode, "SHARED") )
 goto LABEL_19;
 log(7, 1, "driver/wpa_cli -i wlan0 set_network 0 auth_alg SHARED");
 p_command = "driver/wpa_cli -i wlan0 set_network 0 auth_alg SHARED";
 }
 else
 {
 log(7, 1, "driver/wpa_cli -i wlan0 set_network 0 key_mgmt NONE");
 p_command = "driver/wpa_cli -i wlan0 set_network 0 key_mgmt NONE";
 }
 
 // [14] Execute the command constructed at [8]
 popen_write(p_command);
 }
 ...
 }
 

**CVE-2022-33192 - OS Command Injection via WL_SSID and WL_SSID_HEX Configurations**

The conditional referenced at [3] is responsible for determining which of the two configuration values to inject into the OS command. Either value is equally exploitable, but WL_SSID_HEX will be prioritized if it has been set. At [4], the selected configuration value is injected, without neutralization or sanity checking, into an OS command which is executed via popen at [5].

If either of WL_SSID_HEX or WL_SSID have been maliciously formatted prior to the receipt of a testWifiAP XCMD, then receipt of the testWifiAP XCMD and subsequent execution of the vulnerable do_test_wifi function will result in arbitrary command execution with root privileges.

**CVE-2022-33193 - OS Command Injection via WL_WPAPSK Configuration**

The conditional referenced at [7] is responsible for determining whether the WL_AuthMode requires the use of the WL_WPAPSK configuration value. Note that the use of WL_WPAPSK_HEX is never used in this function. If the WL_AuthMode is either “WPAPSK” or “WPAP2PSK” then at [8] the configuration value is injected, without neutralization or sanity checking, into an OS Command which is executed via popen at [14].

If WL_WPAPSK has been maliciously formatted prior to the receipt of a testWifiAP XCMD, then receipt of the testWifiAP XCMD and subsequent execution of the vulnerable do_test_wifi function will result in arbitrary command execution with root privileges.

**CVE-2022-33194 - OS Command Injection via WL_Key and WL_DefaultKeyID Configurations**

The conditional referenced at [9] will be entered if the WL_AuthMode is set to “SHARED” or “WEP”. If that is the case, then the values from WL_Key and WL_DefaultKeyID will be injected at [10], without neutralization or sanity checking, into an OS Command which is executed via popen at [11].

If either of WL_Key or WL_DefaultKeyID have been maliciously formatted prior to the receipt of a testWifiAP XCMD, then receipt of the testWifiAP XCMD and subsequent execution of the vulnerable do_test_wifi function will result in arbitrary command execution with root privileges.

**CVE-2022-33195 - OS Command Injection via WL_DefaultKeyID Configuration**

The conditional referenced at [9] will be entered if the WL_AuthMode is set to “SHARED” or “WEP”. If that is the case, then the WL_DefaultKeyID value will be injected at [12], without neutralization or sanity checking, into an OS Command which is executed via popen at [13].

If WL_DefaultKeyID has been maliciously formatted prior to the receipt of a testWifiAP XCMD, then receipt of the testWifiAP XCMD and subsequent execution of the vulnerable do_test_wifi function will result in arbitrary command execution with root privileges.

**TIMELINE**

2022-07-13 - Initial Vendor Contact 
2022-07-14 - Vendor Disclosure 
2022-10-20 - Public Release

Discovered by Matt Wiseman of Cisco Talos.

CVE-2022-33193: TALOS-2022-1559 || Cisco Talos Intelligence Group

A hard-coded password vulnerability exists in the telnet functionality of Abode Systems, Inc. iota All-In-One Security Kit 6.9Z. Use of a hard-coded root password can lead to arbitrary command execution. An attacker can authenticate with hard-coded credentials to trigger this vulnerability.

**SUMMARY**

A hard-coded password vulnerability exists in the telnet functionality of Abode Systems, Inc. iota All-In-One Security Kit 6.9Z. Use of a hard-coded root password can lead to arbitrary command execution. An attacker can authenticate with hard-coded credentials 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.

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**

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

**CWE**

CWE-798 - Use of Hard-coded Credentials

**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.

Version 6.9Z of the iota firmware exposes a telnet service on TCP/55023. The password for the root user of each device is derived from the MAC address of the device. This derivation is easily repeatable and can be conducted off-device in order to recover the password of an arbitrary device.

The business-logic of password-derivation and updates to /etc/shadow occur within the /root/hpgw binary, in a function that we will refer to in this report as update_root_password. In version 6.9Z this is located at offset 0xA7BA0 and in 6.9X at offset 0xA7ADC. The actual calculation occurs within a function we will refer to in this report as keygen \[6.9Z: 0xA7A48, 6.9X: 0xA7984\].

    unsigned int __fastcall keygen(
        char *ciphertext,
        const char *mac_addr,
        int prefix,
        int postfix,
        int map_1,
        int map_2,
        int map_3,
        int map_4,
        int map_5,
        int map_6,
        int map_7,
        int map_8)
    {
        uint8_t sha256_result[32];
        char plaintext[64];
    
        vsnprintf_nullterm(plaintext, 0x3Fu, "%d%s%d", prefix, mac_addr, postfix);
        sha256(plaintext, 20, sha256_result, 0);
        ciphertext[0] = g_lookup_table[sha256_result[map_1] % 0x30u];
        ciphertext[1] = g_lookup_table[sha256_result[map_2] % 0x30u];
        ciphertext[2] = g_lookup_table[sha256_result[map_3] % 0x30u];
        ciphertext[3] = g_lookup_table[sha256_result[map_4] % 0x30u];
        ciphertext[4] = g_lookup_table[sha256_result[map_5] % 0x30u];
        ciphertext[5] = g_lookup_table[sha256_result[map_6] % 0x30u];
        ciphertext[6] = g_lookup_table[sha256_result[map_7] % 0x30u];
        ciphertext[7] = g_lookup_table[sha256_result[map_8] % 0x30u];
        ciphertext[8] = 0;
    }
    

The result of this calculation is stored in to the ciphertext variable, which the update_root_password function will use to calculate the md5crypt and update the /etc/shadow file contents with the modified password. This appears to occur once on every execution of the hpgw binary.

While this password generation functionality existed within version 6.9X, the telnet server had been disabled and the root password was not used anywhere else. With the release of 6.9Z, the telnet server has been re-enabled and this vulnerability became exploitable again.

Knowledge of the hard-coded prefix, postfix, map_#, and g_lookup_table values and the MAC address of the device is all it takes to calculate the root password for the device and successfully authenticate via telnet.

**TIMELINE**

2022-07-13 - Initial Vendor Contact  
2022-07-14 - Vendor Disclosure  
2022-10-20 - Public Release

Discovered by Matt Wiseman of Cisco Talos.

CVE-2022-29889: TALOS-2022-1569 || Cisco Talos Intelligence Group

Four format string injection vulnerabilities exist in the XCMD testWifiAP functionality of Abode Systems, Inc. iota All-In-One Security Kit 6.9X and 6.9Z. Specially-crafted configuration values can lead to memory corruption, information disclosure and denial of service. An attacker can modify a configuration value and then execute an XCMD to trigger these vulnerabilities.This vulnerability arises from format string injection via the `ssid` and `ssid_hex` configuration parameters, as used within the `testWifiAP` XCMD handler

**SUMMARY**

Four format string injection vulnerabilities exist in the XCMD testWifiAP functionality of Abode Systems, Inc. iota All-In-One Security Kit 6.9X and 6.9Z. Specially-crafted configuration values can lead to memory corruption, information disclosure and denial of service. An attacker can modify a configuration value and then execute an XCMD 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, 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.

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 it 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.

The iota device receives command and control messages (referred to in the application as XCMDs) via an XMPP connection established during the initialization of the hpgw application. As of version 6.9Z there are 222 XCMDs registered within the application. Each XCMD is associated with a function intended to handle it. As discussed in TALOS-2022-1552 there is a service running on UDP/55050 that allows an unauthenticated attacker access to execute these XCMDs.

An XCMD, by virtue of being commonly transmitted over XMPP, is an XML payload structured in a specific format. Each XCMD must contain a root node , which must contain a child element, <mac> with an attribute v containing the target device MAC Address. There must also be a child element <cmd> which must contain an attribute a naming the XCMD to be executed. From there, various XCMDs require various child elements that contain information relevent only to that handler.

The testWifiAP XCMD is used to validate the existing wireless network configuration, and it does not expect any parameters. The XCMD appears as follows.

 <?xml version="1.0" encoding="UTF-8"?>
 
 <mac v="B0:C5:CA:00:00:00"/>
 <cmds>
 <cmd a="testWifiAP"/>
 </cmds>
 
 

The handler associated with testWifiAP is located at offset 0x104830 of the /root/hpgw binary included in version 6.9Z, and its decompilation is included here.

 int __fastcall testWifiAP(xml_node_t *xcmd, xstrbuf_t *response)
 {
 const char *err_str;
 wifi_config_t wifi_config;
 
 // [1] Copy the current wireless configuration into `wifi_config`
 fetch_wifi_config(&wifi_config);
 
 // [2] Pass the wireless configuration into the vulnerable function
 if ( do_test_wifiap(&wifi_config) )
 {
 err_str = strtable_get("XCMD_ERR_WIFI_AUTH", 18);
 xml_construct_error_response(response, 0, 82, err_str);
 }
 else
 {
 init_xml_response(response);
 }
 return 0;
 }
 

The handler itself is very straightforward. At [1] it collects the current wireless configuration and passes it to a delegate function we’ve named do_test_wifiap. It is the do_test_wifiap that contains the vulnerability, but this function is only executed when the testWifiAP XCMD is received.

The function we refer to as fetch_wifi_config is located at offset 0x1C722C of the hpgw binary included in firmware 6.9Z. Its very straightforward decompilation is included here.

 void __fastcall fetch_wifi_config(wifi_config_t *config)
 {
 fetch_config_value("WL_SSID", config->ssid, 191);
 fetch_config_value("WL_SSID_HEX", config->ssid_hex, 191);
 fetch_config_value("WL_AuthMode", config->auth_mode, 191);
 fetch_config_value("WL_WPAPSK", config->wpapsk, 191);
 fetch_config_value("WL_WPAPSK_HEX", config->wpapsk_hex, 191);
 fetch_config_value("WL_EncrypType", config->encryp_type, 191);
 fetch_config_value("WL_DefaultKeyID", config->default_key_id, 191);
 fetch_config_value("WL_Key", config->key, 191);
 }
 

These Wi-Fi configuration values may be modified a few ways: by the user via mobile application or Abode web application; through the setWifiAP XCMD; and via either the /action/wirelessPost or /action/configPost endpoints of the device’s local web interface. None of these mechanisms implement useful sanitization or sanity checking on the values. For the purposes of the following vulnerabilities, we assume that the remote attacker has manipulated these parameters prior to triggering the vulnerable testWifiAP XCMD.

These configuration values are passed to the function we’ve named do_test_wifiap, which is located at offset 0x1c7d28. The relevant portions of the decompilation are included below.

 int __fastcall do_test_wifiap(wifi_config_t *config)
 {
 int result;
 const char *static_command;
 int retry;
 int con_suc;
 const char *str_err;
 int wireless_enabled;
 char cmd_output[32];
 char command[256];
 
 wireless_enabled = 0;
 
 // [1] Ensure that wireless is enabled, otherwise exit early
 get_config_as_integer("WL_Enable", (int)&wireless_enabled);
 if ( !wireless_enabled )
 return -3;
 
 // [2] Ensure that one of `config->ssid` or `config->ssid_hex` is provided
 if ( !config->ssid[0] && !config->ssid_hex[0] )
 {
 log(7, 31, "No SSID!");
 return -2;
 }
 
 ...
 
 memset(command, 0, 0x80u);
 // [3] Identify whether the SSID is provided via the `config->ssid` or `config->ssid_hex` configuration value
 if ( config->ssid_hex[0] )
 {
 // [4] If via `config->ssid_hex`, inject directly into the command buffer
 log(7, 31, "with hex string");
 vsnprintf_nullterm(command, 0x7Fu, "driver/wpa_cli -i %s set_network 0 ssid %s", "wlan0", config->ssid_hex);
 }
 else
 {
 // [5] If via `config->ssid`, inject directly into the command buffer
 log(7, 31, "with acii string");
 vsnprintf_nullterm(command, 0x7Fu, "driver/wpa_cli -i %s set_network 0 ssid '\"%s\"'", "wlan0", config->ssid);
 }
 // [6] Call the log function with the format string injected with attacker-controlled configuration values at [4] or [5]
 log(7, 1, command);
 
 popen_write(command);
 memset(command, 0, 0x80u);
 if ( strcmp(config->auth_mode, "WPA") && strcmp(config->auth_mode, "WPA2") )
 {
 
 // [7] If `config->auth_mode` is WPAPSK or WPA2PSK
 if ( !strcmp(config->auth_mode, "WPAPSK") || !strcmp(config->auth_mode, "WPA2PSK") )
 {
 // [8] then inject `config->wpapsk` directly into the command buffer
 vsnprintf_nullterm(command, 0x7Fu, "driver/wpa_cli -i %s set_network 0 psk '\"%s\"'", "wlan0", config->wpapsk);
 // [9] Call the log function with the format string injected with attacker-controlled configuration values at [8]
 log(7, 1, command);
 p_command = command
 }
 
 // [10] Otherwise, if `config->auth_mode` is SHARED or WEP
 else if ( !strcmp(config->auth_mode, "SHARED") || !strcmp(config->auth_mode, "WEP") )
 {
 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");
 
 // [11] Construct a command buffer by injecting `config->default_key_id` and `config->key`
 vsnprintf_nullterm(
 command,
 0x7Fu,
 "driver/wpa_cli -i %s set_network 0 wep_key%s '\"%s\"'",
 "wlan0",
 config->default_key_id,
 config->key);
 
 // [12] Call the log function with the format string injected with attacker-controlled configuration values at [10]
 log(7, 1, command);
 
 popen_write(command);
 memset(command, 0, 0x80u);
 
 // [13] Then construct a second command buffer by injecting `config->default_key_id`
 vsnprintf_nullterm(
 command,
 0x7Fu,
 "driver/wpa_cli -i %s set_network 0 wep_tx_keyidx %s",
 "wlan0",
 config->default_key_id);
 
 // [14] Call the log function with the format string injected with attacker-controlled configuration values at [12]
 log(7, 1, command);
 popen_write(command);
 
 if ( strcmp(config->auth_mode, "SHARED") )
 goto LABEL_19;
 log(7, 1, "driver/wpa_cli -i wlan0 set_network 0 auth_alg SHARED");
 p_command = "driver/wpa_cli -i wlan0 set_network 0 auth_alg SHARED";
 }
 else
 {
 log(7, 1, "driver/wpa_cli -i wlan0 set_network 0 key_mgmt NONE");
 p_command = "driver/wpa_cli -i wlan0 set_network 0 key_mgmt NONE";
 }
 popen_write(p_command);
 }
 ...
 }
 

**CVE-2022-35874 - config->ssid/config->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 config->ssid or config->ssid_hex configuration values, with ssid_hex taking priority if both are provided. Below is a partial decompilation of the do_test_wifiap function, with annotations.

 ...
 memset(command, 0, 0x80u);
 // [3] Identify whether the SSID is provided via the `config->ssid` or `config->ssid_hex` configuration value
 if ( config->ssid_hex[0] )
 {
 // [4] If via `config->ssid_hex`, inject directly into the command buffer
 log(7, 31, "with hex string");
 vsnprintf_nullterm(command, 0x7Fu, "driver/wpa_cli -i %s set_network 0 ssid %s", "wlan0", config->ssid_hex);
 }
 else
 {
 // [5] If via `config->ssid`, inject directly into the command buffer
 log(7, 31, "with acii string");
 vsnprintf_nullterm(command, 0x7Fu, "driver/wpa_cli -i %s set_network 0 ssid '\"%s\"'", "wlan0", config);
 }
 // [6] Call the log function with the format string injected with attacker-controlled configuration values at [4] or [5]
 log(7, 1, command);
 ...
 

First, at [3], it is determined whether to use the ssid_hex or ssid configuration value. In either case, the selected value will be used at [4], or [5] to construct the command buffer. Finally, at [6] the injected command buffer is passed as the format parameter to the log function, resulting in attacker control of the format string.

Supplying a config->ssid_hex or config->ssid value of %x.%x.%x.%x.%x.%x... results in the following log message being generated:

 [DBG ][WEB ]driver/wpa_cli -i wlan0 set_network 0 ssid '"7148d871.7148d950.333a4143.252e51.0.33.76c46000.3a224e50.252e78"'
 

**CVE-2022-35875 - config->wpapsk**

This misuse of the log function occurs when logging the construction of an OS command meant to configure the WPAPSK of the wireless network. While the configuration values support the creation and fetching of a config->ssid_hex value, it is not used in this function. This vulnerability may only be triggered via the use of config->ssid. Below is the relevant portion of a decompilation of the do_test_wifiap function, with annotations.

 ...
 if ( strcmp(config->auth_mode, "WPA") && strcmp(config->auth_mode, "WPA2") )
 {
 // [7] If `config->auth_mode` is WPAPSK or WPA2PSK
 if ( !strcmp(config->auth_mode, "WPAPSK") || !strcmp(config->auth_mode, "WPA2PSK") )
 {
 // [8] then inject `config->wpapsk` directly into the command buffer
 vsnprintf_nullterm(command, 0x7Fu, "driver/wpa_cli -i %s set_network 0 psk '\"%s\"'", "wlan0", config->wpapsk);
 // [9] Call the log function with the format string injected with attacker-controlled configuration values at [8]
 log(7, 1, command);
 p_command = command
 }
 ...
 

At [7], it is first confirmed that the type of authentication required for the Wi-Fi AP is either WPA or WPA2. If so, then at [8] the config->wpapsk configuration value is used to construct the command buffer. Finally, at [9] the injected command buffer is passed as the format parameter to the log function, resulting in attacker control of the format string.

Supplying a config->wpapsk of %x.%x.%x.%x.%x.%x... results in the following log message being generated:

 [DBG ][WEB ]driver/wpa_cli -i wlan0 set_network 0 psk '"7148d870.7148db90.333a4143.252e51.0.33.76c46000.3a224e50.252e78"'
 

**CVE-2022-35876 - config->default_key_id / config->key**

This misuse of the log function occurs when logging the construction of an OS command meant to configure the WEP key management for the wireless network.The WEP key is provided via the config->key configuration value, and the key identifier is provided via the config->default_key_id. Below is the relevant portion of a decompilation of the do_test_wifiap function, with annotations.

 ...
 // [10] Otherwise, if `config->auth_mode` is SHARED or WEP
 else if ( !strcmp(config->auth_mode, "SHARED") || !strcmp(config->auth_mode, "WEP") )
 {
 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");
 
 // [11] Construct a command buffer by injecting `config->default_key_id` and `config->key`
 vsnprintf_nullterm(
 command,
 0x7Fu,
 "driver/wpa_cli -i %s set_network 0 wep_key%s '\"%s\"'",
 "wlan0",
 config->default_key_id,
 config->key);
 
 // [12] Call the log function with the format string injected with attacker-controlled configuration values at [10]
 log(7, 1, command);
 ...
 

At [10], it is first confirmed that the type of authentication required for the Wi-Fi AP is either WEP or SHARED. If so, then at [11] the config->default_key_id and config->key configuration values are used to construct the command buffer. Finally, at [12] the injected command buffer is passed as the format parameter to the log function, resulting in attacker control of the format string.

Supplying %x.%x.%x.%x.%x.%x... for both the config->default_key_id and config->key configuration values results in the following log message being generated:

 [DBG ][WEB ]driver/wpa_cli -i wlan0 set_network 0 wep_key7148d88c.7148ddd0.7148de90.252e51.0.33.76c46000.3a224e50 '"252e78.7148df54.1.223a2243.220a2c22.5f534d4d.73736150.3a226477.a2c2222"'
 

**CVE-2022-35877 - config->default_key_id**

The final misuse of the log function within testWifiAP occurs almost immediately after the previous vulnerability, when logging the construction of an OS command meant to configure the WEP key management for the wireless network.The WEP key index is provided via the config->default_key_id configuration value. Below is the relevant portion of a decompilation of the do_test_wifiap function, with annotations.

 // [13] Then construct a second command buffer by injecting `config->default_key_id`
 vsnprintf_nullterm(
 command,
 0x7Fu,
 "driver/wpa_cli -i %s set_network 0 wep_tx_keyidx %s",
 "wlan0",
 config->default_key_id);
 
 // [14] Call the log function with the format string injected with attacker-controlled configuration values at [12]
 log(7, 1, command);
 popen_write(command);
 

At [13] the config->default_key_id is used to construct another OS command. At [14] the injected command buffer is passed as the format parameter to the log function, resulting in attacker control of the format string.

Supplying a config->default_key_id of %x.%x.%x.%x.%x.%x... results in the following log message being generated:

 [DBG ][WEB ]driver/wpa_cli -i wlan0 set_network 0 wep_tx_keyidx 714ad874.714addd0.714ade90.252e51.0.33.76c66000.3a224e50
 

**TIMELINE**

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

Discovered by Matt Wiseman of Cisco Talos.

CVE-2022-35874: TALOS-2022-1581 || Cisco Talos Intelligence Group

Adobe Illustrator versions 26.4 (and earlier) and 25.4.7 (and earlier) are affected by an Improper Input Validation vulnerability that could result in arbitrary code execution in the context of the current user. Exploitation of this issue requires user interaction in that a victim must open a malicious file.

Security Updates Available for Adobe Illustrator | APSB22-56

Bulletin ID

Date Published

Priority

ASPB22-56

October 18,  2022     

3

**Summary**

Occurs prior to authentication:  The vulnerability is (or is not) exploitable without credentials.

Requires admin privileges:  The vulnerability is (or is not) only exploitable by an attacker with administrative privileges.  

Adobe has released an update for Adobe Illustrator. This update resolves critical vulnerabilities that could lead to arbitrary code execution. Note: this bulletin was published in alignment with the regularly scheduled Adobe Illustrator update released at Adobe MAX 2022**.** We recommend users update their installations to the newest version based on the priority rating above.  

**Affected Versions**

**Product**

**Version**

**Platform**

Illustrator 2022  

26.4 and earlier versions   

Windows and macOS

Illustrator 2021  

25.4.7 and earlier versions   

Windows and macOS

**Solution**

Adobe categorizes these updates with the following  priority ratings  and recommends users update their installation to the newest version via the Creative Cloud desktop app's update mechanism.  For more information, please reference this help page.

Product

Version

Platform

Priority

Availability

Illustrator 2022    

27.0

Windows and macOS

3

Download Page

Illustrator 2021    

26.5.1

Windows and macOS

3

Download Page

**Vulnerability details**

Vulnerability Category

Vulnerability Impact

Severity

**CVSS base score**   

**CVSS vector**  

CVE Numbers

Improper Input Validation (CWE-20)  

Arbitrary code execution  

Critical

7.8

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

CVE-2022-38435  

Out-of-bounds Read (CWE-125)  

Arbitrary code execution  

Critical

7.8

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

CVE-2022-38436  

**Acknowledgments**

Adobe would like to thank the following researcher sfor reporting these issues and for working with Adobe to help protect our customers:   

*   Tran Van Khang - khangkito (VinCSS) working with Trend Micro Zero Day Initiative - CVE-2022-38435, CVE-2022-38436

**Revisions**

March 16, 2022: Added affected & fix versions for Illustrator v25.x

For more information, visit https://helpx.adobe.com/security.html, or email PSIRT@adobe.com

CVE-2022-38435: Adobe Security Bulletin

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

HEIDENHAIN Controller TNC on HARTFORD Machine

A high-severity vulnerability has been disclosed in the SQLite database library, which was introduced as part of a code change dating all the way back to October 2000 and could enable attackers to crash or control programs.
Tracked as CVE-2022-35737 (CVSS score: 7.5), the 22-year-old issue affects SQLite versions 1.0.12 through 3.39.1, and has been addressed in version 3.39.2 released on July 21

A high-severity vulnerability has been disclosed in the SQLite database library, which was introduced as part of a code change dating all the way back to October 2000 and could enable attackers to crash or control programs.

Tracked as CVE-2022-35737 (CVSS score: 7.5), the 22-year-old issue affects SQLite versions 1.0.12 through 3.39.1, and has been addressed in version 3.39.2 released on July 21, 2022.

"CVE-2022-35737 is exploitable on 64-bit systems, and exploitability depends on how the program is compiled," Trail of Bits researcher Andreas Kellas said in a technical write-up published today.

"Arbitrary code execution is confirmed when the library is compiled without stack canaries, but unconfirmed when stack canaries are present, and denial-of-service is confirmed in all cases."

Programmed in C, SQLite is the most widely used database engine, included by default in Android, iOS, Windows, and macOS, as well as popular web browsers such as Google Chrome, Mozilla Firefox, and Apple Safari.

The vulnerability discovered by Trail of Bits concerns an integer overflow bug that occurs when extremely large string inputs are passed as parameters to the SQLite implementations of the printf functions, which, in turn, make use of another function to handle the string formatting ("sqlite3\_str\_vappendf").

However, a successful weaponization of the flaw banks on the prerequisite that the string contains the %Q, %q, or %w format substitution types, potentially leading to a program crash when user-controlled data is written beyond the bounds of a stack-allocated buffer.

"If the format string contains the '!' special character to enable unicode character scanning, then it is possible to achieve arbitrary code execution in the worst case, or to cause the program to hang and loop (nearly) indefinitely," Kellas explained.

The vulnerability is also an example of a scenario that was once deemed impractical decades ago -- allocating 1GB strings as input -- rendered feasible with the advent of 64-bit computing systems.

"It's a bug that may not have seemed like an error at the time that it was written (dating back to 2000 in the SQLite source code) when systems were primarily 32-bit architectures," Kellas said.

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

22-Year-Old Vulnerability Reported in Widely Used SQLite Database Library

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

Identity fraud has increased at 84% of dealerships, with 60% losing three or more vehicles in the last year.

FOOTHILL RANCH, Calif., Oct. 25, 2022 /PRNewswire-PRWeb/ — Identity fraud has increased dramatically in auto dealerships since the pandemic, with 60% of auto dealerships reporting the loss of three or more vehicles to it in the past year, according to the new report, "Is Identity Fraud Jeopardizing Digital Retailing Profitability," from automotive fintech innovator eLEND Solutions. The report, based on a survey of over 700 auto dealerships across the U.S., reveals that while dealerships cite identity fraud as their top fraud challenge/concern, and almost unanimously agree that its increase is because of the increased digitization of the deal, 66% lack adequate identity fraud protections.

"The pandemic changed a lot of things in the auto industry - and that is particularly true when it comes to fraud which, as this report underscores, is causing more and more losses for dealers - an estimated $619 million\[1\] for franchise dealers alone," said Pete MacInnis, CEO, and Founder of eLEND Solutions. "Economic conditions and, especially, increasing digitization of the car buying process are driving more fraud but, unfortunately, this report reveals that most dealerships have not implemented ID verification technologies that can prevent it."

According to the report, 84% of dealerships have directly experienced identity fraud at their dealership since the pandemic, with a third seeing an over 20% increase in identity fraud-related activities since the pandemic started. And, in just the past year, 79% directly experienced an identity fraud-related vehicle loss at their dealership.

When asked to explain the increase in identity fraud, 95% relate it directly to the increase in the digitization of the deal and remote buying experiences, with 86% predicting that as more of the transaction moves online, identity fraud will increase and become harder to prevent. The report also reveals that losses are not limited to identity fraud, with the vast majority of dealerships reporting an increase in loan application fraud in the past year. Seventy-seven percent saw a 10- 20% increase or more, with over one-third reporting that one in every 100 applications at their dealership was fraudulent.

The report also investigates what dealerships have been doing to prevent fraud: "photocopying the driver's license / ID" (64%) is number one, with the "Red Flags Rule" (56%) at number two. Only 33% reported using critical document authentication as part of their process, a significant disconnect.

"Without actually validating/authenticating ID documents and buyer identities, dealerships remain particularly vulnerable," said MacInnis. "As more of the transaction becomes digital, embracing ID verification technologies that include forensic authentication of the driver's license document, in conjunction with matching data extracted from the document against hundreds of databases, can easily help dealers minimize fraud risks before it becomes an expensive problem."

Dealers were also asked about the timing of their credit pulls, a practice that rapidly evolved once the pandemic prompted more of the process to move online. As compared to 2018, when only 8% of dealers said they pulled credit before the test drive, today 40% report doing so, with only 20% today waiting until right before the F&I handoff, versus 39% in 2018.

"This shift in credit pull timing is a dramatic and positive change in the way auto dealerships do business and, with the right technology in place, has positive implications for preventing fraud if dealerships take the opportunity to validate customer identity upfront with the simple swipe of a driver's license - but only if document authentication is part of that process," concluded MacInnis.

**Key Data Takeaways**

*   84%, say there has been a noticeable increase in identity fraud since the pandemic.
*   79% of dealers experienced an identity fraud-related vehicle loss at their dealership in the past year.
*   Seventy-nine percent say that identity fraud has increased in their dealerships by over 10%, and nearly one-third say it has increased  
    between 21% and 30%, or more. 
*   60% reported a loss of three to five vehicles, or more, in the last twelve months.
*   89% of dealerships report an increase in loan application fraud in the past year.
*   34% report that one in every 100 applications at their dealership was fraudulent.
*   95% track identity fraud to the expansion of remote buying experiences and the digitization of the deal.
*   86% agree that as more of the transaction moves online, identity fraud will continue to grow and become even more challenging to prevent.
*   67% do not include driver's license document authentication to protect themselves from identity fraud.
*   40% report pulling credit before the test drive, vs 8% in 2018.
*   93% say that if a driver's license scan could be converted into a consumer consented pre-qualification it would be a meaningful benefit.

About eLEND Solutions: eLEND Solutions(TM) (DealerCentric rebranded) is an automotive FinTech company focused on deal generation solutions - that power transactional digital buying experiences for the retail automotive industry. The platform specializes in digital credit, identity, and finance solutions for remote and in-store shoppers, designed to accelerate conversions of digital end-to-end purchase experiences concluding with fundable, transactable deal structures.

For more information, please visit http://www.elendsolutions.com.

Tag

#mac