Security Advisory: Remote Code Execution in Delta Electronics DVW Devices

Summary

The Delta Electronics DVW devices expose a web administration interface to users. This interface implements multiple features that are affected by command injection and stack overflow vulnerabilities.

Impact

Successful exploitation of these flaws would allow remote unauthenticated attackers to gain remote code execution with elevated privileges on the affected devices.

Description

Stack Buffer Overflow through Login

The net-cgi binary defines an array containing structures for each request handler. A request handler defines a path, content-type, cache-control, and up to three different functions that I defined as preprocessor, processor, and postprocessor. Pre-processor and post-processor are optional.

In the authentication handler (checkauth.cgi) preprocessor, request parameters login and password are read and saved as temporary configuration data tmp_http_username and tmp_http_passwd:

These values are then used in the authentication handler processor, where they are copied without bound checking using strcpy into arrays stored on the stack. This is what the platform picked up:

Of course, this is not the only example as different binaries are riddled with config_get -> strcpy operations. In net-cgi alone, more than 170 valid buffer overflows were identified.

Remote Code Execution through TFTP Settings Management

The tftp_server and tftp_dfirm_name parameters can be used to inject arbitrary commands in the TFTP command constructed by the web management interface:

Remote Code Execution through Admin Password Setting

When the administrator chooses a new password, this password is used unsanitized in a system call, leading to a command injection.

Remote Code Execution through Network Scan Feature

The remote_ip request parameter is used unsanitized in a system call, allowing authenticated users to inject commands at will:

Remote Code Execution through ACLs Management

The /usr/sbin/net-cgi file is responsible for handling all web requests. Authenticated users can provide a MAC address to filter or authorize through ACLs:

void FUN_1002e600(undefined4 param_1,undefined4 param_2)
{
char *acl_idx;
long acl_idx_long;
char* select_del;
int acl_id;
FILE *__stream;
char acStack_178 [32];
char wlacl_id [64];
char wlacl_id_value [268];
acl_idx = get_request_parameter("select_del",param_1,param_2);
acl_idx_long = strtol(acl_idx, 0, 10);
if (0 < acl_idx_long) {
sprintf(wlacl_id,"wlacl%d", acl_idx_long);
acl_idx = config_get(wlacl_id);
// NOTE: copy user controlled 'select_del' parameter to wlacl_id_value
strcpy(wlacl_id_value, acl_idx);
select_del = get_request_parameter("select_del",param_1,param_2);
acl_id = config_update("wlacl", select_del);
if (acl_id != -1) {
sprintf(acStack_178,"%d", acl_id);
config_set("wl_acl_num",acStack_178);
}
endis_wps_stuff();
__stream = fopen("/tmp/Aclmacaddr", "w");
if (__stream != (FILE *)0x0) {
// NOTE: write user controlled 'select_del' to /tmp/Aclmacaddr
fputs(wlacl_id_value, __stream);
fclose(__stream);
}
}
return;
}

The content of this file is then used to kick the MAC address from the wireless network, and this is the command injection that was identified by our platform:

Remote Code Execution through WPS PIN Management

Another but similar injection flow exists. If the user sets WPS authentication they can provide a hidden_PIN value through the web interface. This will be saved in /tmp/wps_client_pin :

void FUN_1002e1bc(undefined4 param_1,undefined4 param_2)
{
char* hidden_pin;
config_set("WPS_type","PIN Number");
write_val_to_file("start","/tmp/wps_process_state");
hidden_pin = get_request_parameter("hidden_PIN", param_1, param_2);
if (hidden_pin != 0) {
write_val_to_file(hidden_pin,"/tmp/wps_client_pin");
}
return;
}

Then, this value is used unsanitized in a system call, as reported by the platform:

Some checks are performed on the client side, but this is not sufficient since an attacker can simply submit the request directly to the server.

Recommendation

This product being EOL, Delta Electronics will not patch the vulnerability. If replacement of the EOL device is not possible, ensure access to the administration interface is restricted to administration network zones only, to reduce likelihood of exploitation.

Key Takeaways

A year ago, CISA released an ICS advisory about this exact device due to the publication of CVE-2022-42139, an authenticated command injection identified by Cyber Danube. Since then, it’s quite clear that the device did not receive any attention in the form of extended security testing or source code review. They simply patched that specific vulnerability and released an update.

ICS devices such as industrial ethernet routers are usually installed for long term deployments that, sadly, usually exceed the manufacturer device support lifespan (an issue that will be addressed by the upcoming EU Cyber Resilience Act). With our recently introduced binary static analysis feature, we not only demonstrate how manufacturers can maximize return of PSIRT efforts and run effective vulnerability discovery and management programs, but it also provides ICS device operators the tools required to perform meaningful supply-chain risk assessment.

Timeline

• 2024-01-24 –Report submitted to Delta Electronics PSIRT through email and webform.
• 2024-04-03 –Reminder email sent to Delta Electronics.
• 2024-04-11 –Delta Electronics indicates they did not receive our previous emails for unknown reasons. Ask for the report.
• 2024-04-11 –Report submitted to Delta Electronics.
• 2024-04-15 –Delta Electronics indicates that “since DVW-W02W2 is no longer in production and maintenance, Delta decided not to patch these vulnerabilities.”
• 2024-04-24 –Release ONEKEY advisory in coordination with Delta Electronics.