Close

January 18, 2021 • Carsten Eiram

D-Link DAP-2020 Multiple Vulnerabilities

Vendor / Product Information

“The DAP-2020 Wireless N Access Point allows your business to create a secure and manageable wireless network. Multiple operational modes, network management tools and security features gives network administrators more flexible deployment options.”

Source:
https://eu.dlink.com/uk/en/products/dap-2020-wireless-n-access-point

Vulnerable Program Details

Tested products and versions:

Vendor: D-Link
Product: DAP-2020 Wireless N Access Point
Version: 1.01

NOTE: Other versions than the one listed may also be affected.

Credits

Sven Krewitt, Risk Based Security
Twitter: @RiskBased

Vulnerability Details

D-Link DAP-2020 contains multiple pre-authentication vulnerabilities in the web-based management interface that may allow a remote attacker to hijack an active session or cause heap- and stack-based buffer overflows to execute arbitrary code.

webupg UPGCGI_CheckAuth() Function sessionid Cookie Integer Truncation Remote Heap Buffer Overflow
The ‘webupg’ binary is accessible as a cgi-bin program via the web interface. HTTP request processing is started in the UPGCGI_Main() function. After checking the request method and the content-type header, the function checks for a ‘sessionid’ HTTP cookie and passes its value to the UPGCGI_CheckAuth() function. This function causes the vulnerability, as it uses the string length of the ‘sessionid’ cookie to calculate a required buffer size but truncates it using a bitwise AND operation with 0xffff. The incorrect value is then used to allocate memory using the MSG_CreateMessage() function. Later in this function, sprintf() is used to write to the allocated structure without further boundary checks, causing a heap-based buffer overflow.

Exploitation of this issue causes webupg to crash and may allow arbitrary code execution. Authentication is not required to trigger this issue.

webproc WEB_CreateSSID() Function Insecure SessionID Generation Remote Session Hijacking
To log in, a user sends an HTTP request to /cgi-bin/webproc where the ‘obj-action’ parameter is set to ‘auth’ and the ‘:username’ and ‘:password’ parameters contain the user credentials. In the main() function of webproc, it was noticed that the time() function is invoked to pass a seed to srand(), which sets the seed for pseudo-random integer sequences that are retrieved when calling rand(). This pseudo-random number generator (PRNG) is considered insecure for cryptographic applications and only provides a limited amount of state. In particular, seeding the PRNG with a time-based value makes the generated numbers predictable.

This is of concern as rand() is also indirectly called in the WEB_GetCgiVars() function. This function parses cookies in HTTP requests and generates a new session ID in case one isn’t provided in the cookie or doesn’t exist. To generate the session ID, the function invokes WEB_CreateSSID(), which is a wrapping function for the above mentioned rand() function.

Presuming that a device has been properly set up and runs with a correct system time, an attacker can brute-force valid session IDs. This can be achieved by e.g. generating a list of valid session IDs for a reasonable time frame e.g. the last 5 minutes. If an admin has been successfully logged in within that time frame, a remote attacker can use the generated list to find the session ID and hijack the active admin session.

webproc WEB_GetCgiVars() Function Multiple Parameters Remote Stack Buffer Overflow
When handling HTTP requests, the /cgi-bin/webproc program parses the query string for parameters and their respective arguments. In the WEB_GetCgiVars() function, it searches for the ‘var:menu’ and ‘var:page’ parameters. In case either of these parameters are provided in the request, their values are copied into stack-based buffers using strcpy() without performing any boundary checks.

This may allow a remote attacker to cause a stack-based buffer overflow and execute arbitrary code. Authentication is not required to trigger this issue.

webproc WEB_DisplayPage() Function Multiple Parameters Remote Stack Buffer Overflow
When handling HTTP POST requests, the /cgi-bin/webproc program prepares the response by parsing POST request parameters in the main() function. If no valid session exists, it checks for the ‘getpage’, ‘errorpage’, and ‘nextpage’ POST parameters. If the ‘obj-action’ parameter is set to ‘auth’ it eventually calls WEB_DisplayPage() passing the values of ‘getpage’, ‘errorpage’, or ‘nextpage’. In this function the input is handled as a path to a local file. If the file does not exist, the data is copied into an error message string using sprintf() without performing any boundary checks.

This may allow a remote attacker to cause a stack-based buffer overflow and execute arbitrary code. Authentication is not required to trigger this issue.

webproc main() Function HTTP POST Parameter Remote Stack Buffer Overflow
The /cgi-bin/webproc program parses received POST parameters in a loop in the main() function to identify parameters starting with the string ‘var:’. The function checks whether a matching parameter exists and whether it matches one of the following parameter names:

var:CacheLastData
var:mod_
var:sys_
var:sessionid

If none of the conditions match, the main() function invokes sprintf() to write the parameter name and value into a stack-based buffer without performing any boundary checks.

This may allow a remote attacker to cause a stack-based buffer overflow and execute arbitrary code. Authentication is not required to trigger this issue.

webproc WEB_PostObjAuth() Function HTTP POST Parameter Handling Remote Heap Buffer Overflow
The WEB_PostObjAuth() function in the webproc binary can be reached by sending a POST request to /cgi-bin/webproc where the ‘obj-action’ parameter is set to ‘auth’. The main() function checks for this parameter and eventually calls the WEB_Post() function, which invokes WEB_PostObjAuth(). This function calls MSG_CreateMessage(), which allocates memory for a message struct with a fixed size of 0xf000. The function then loops over all provided POST parameters and checks if the parameter name starts with ‘:’ and has a length lesser than 15 characters. If the conditions are met, sprintf() is called to write the parameter name and value to the allocated heap buffer. By providing multiple overly large POST parameter values, it is possible to write past the end of the heap-based buffer.

This may allow a remote attacker to cause a heap-based buffer overflow and execute arbitrary code. Authentication is not required to trigger this issue.

libssap.so COMM_MakeCustomMsg() Function sessionid Cookie Remote Stack Buffer Overflow
This vulnerability exists in the COMM_MakeCustomMsg() function that can be reached via the CheckAuth() function in webproc. If a HTTP ‘Cookie’ header named ‘sessionid’ is set, it passes an array including the value of the ‘Cookie’ header to the COMM_MakeCustomMsg() function. It iterates over the array that is passed as argument and calculates the size of all strings in it. The size is used to allocate a message structure, and the function loops over the array again to write the strings formatted into the message struct. The function uses a temporary stack-based buffer that is filled using sprintf() without performing any boundary checks.

By passing an overly large ‘sessionid’ cookie in a POST request to /cgi-bin/webproc, where ‘obj-action’ is not set to ‘auth’, a remote attacker can cause a stack-based buffer overflow and execute arbitrary code. Authentication is not required to trigger this issue.

Solution

The vendor has currently not released a fixed version but one is under validation and scheduled for the end of January 2021.

References

VulnDB: 247192, 247193, 247194, 247195, 247196, 247197, 247198

D-Link: https://supportannouncement.us.dlink.com/announcement/publication.aspx?name=SAP10201

Timeline

2020-10-02: Reported sessionid heap buffer overflow to the vendor.
2020-10-02: Vendor response received.
2020-10-05: Reported insecure sessionid generation to the vendor.
2020-10-05: Vendor response received.
2020-10-07: Reported stack buffer overflow in WEB_GetCgiVars() to the vendor.
2020-10-13: Reported stack buffer overflow in WEB_DisplayPage() to the vendor.
2020-10-28: Reported final three vulnerabilities to the vendor.
2020-10-28: Vendor response received.
2021-01-15: Vendor releases security advisory but no fixed firmware release.
2021-01-18: Alert sent to RBS VulnDB clients and publication of this vulnerability report.