Dlink router boleh di hack?
Setakat ni hanya affect model-model ni je :DIR-100
DI-524
DI-524UP
DI-604S
DI-604UP
DI-604+
TM-G5240
BRL-04UR
BRL-04CW
Reverse Engineering a D-Link Backdoor
All right. It’s Saturday night, I have no date, a two-liter bottle of Shasta and my all-Rush mix-tape…let’s hack.On a whim I downloaded firmware v1.13 for the DIR-100 revA. Binwalk quickly found and extracted a SquashFS file system, and soon I had the firmware’s web server (/bin/webs) loaded into IDA:
http://www.devttys0.com/wp-content/uploads/2013/10/dir-100_loaded_in_ida.png
Based on the above strings listing, the /bin/webs binary is a modified version of thttpd which provides the administrative interface for the router. It appears to have been modified by Alphanetworks (a spin-off of D-Link). They were even thoughtful enough to prepend many of their custom function names with the string “alpha”:
http://www.devttys0.com/wp-content/uploads/2013/10/alpha_functions.png
The alpha_auth_check function sounds interesting!This function is called from a couple different locations, most notably from alpha_httpd_parse_request:
http://www.devttys0.com/wp-content/uploads/2013/10/alpha_auth_check_call.png
We can see that alpha_auth_check is passed one argument (whatever is stored in register $s2); if alpha_auth_check returns -1 (0xFFFFFFFF), the code jumps to the end of alpha_httpd_parse_request, otherwise it continues processing the request.Some further examination of the use of register $s2 prior to the alpha_auth_check call indicates that it is a pointer to a data structure which contains char* pointers to various pieces of the received HTTP request, such as HTTP headers and the requested URL:http://www.devttys0.com/wp-content/uploads/2013/10/s2_data_structure.png$s2 is a pointer to a data structure
We can now define a function prototype for alpha_auth_check and begin to enumerate elements of the data structure:struct http_request_t{ char unknown; char *url; // At offset 0xB8 into the data structure};int alpha_auth_check(struct http_request_t *request);alpha_auth_check itself is a fairly simple function. It does a few strstr’s and strcmp’s against some pointers in the http_request_t structure, then callscheck_login, which actually does the authentication check. If the calls to any of the strstr’s / strcmp’s or check_login succeed, it returns 1; else, it redirects the browser to the login page and returns -1:http://www.devttys0.com/wp-content/uploads/2013/10/auth_check_code.pngalpha_auth_check code snippet
Those strstr’s look interesting. They take the requested URL (at offset 0xB8 into the http_request_t data structure, as previously noted) and check to see if it contains the strings “graphic/” or “public/”. These are sub-directories under the device’s web directory, and if the requested URL contains one of those strings, then the request is allowed without authentication.It is the final strcmp however, which proves a bit more compelling:http://www.devttys0.com/wp-content/uploads/2013/10/user_agent_strcmp.pngAn interesting string comparison in alpha_auth_check
This is performing a strcmp between the string pointer at offset 0xD0 inside the http_request_t structure and the string “xmlset_roodkcableoj28840ybtide”; if the strings match, the check_login function call is skipped and alpha_auth_check returns 1 (authentication OK).A quick Google for the “xmlset_roodkcableoj28840ybtide” string turns up only a single Russian forum post from a few years ago, which notes that this is an “interesting line” inside the /bin/webs binary. I’d have to agree.So what is this mystery string getting compared against? If we look back in the call tree, we see that the http_request_t structure pointer is passed around by a few functions:http://www.devttys0.com/wp-content/uploads/2013/10/call_graph.pngIt turns out that the pointer at offset 0xD0 in the http_request_t structure is populated by the httpd_parse_request function:http://www.devttys0.com/wp-content/uploads/2013/10/user_agent_struct_1.pngChecks for the User-Agent HTTP header
http://www.devttys0.com/wp-content/uploads/2013/10/user_agent_struct_2.pngPopulates http_request_t + 0xD0 with a pointer to the User-Agent header string
This code is effectively:if(strstr(header, "User-Agent:") != NULL){ http_request_t->0xD0 = header + strlen("User-Agent:") + strspn(header, " \t");}Knowing that offset 0xD0 in http_request_t contains a pointer to the User-Agent header, we can now re-construct the alpha_auth_check function:#define AUTH_OK 1#define AUTH_FAIL -1int alpha_auth_check(struct http_request_t *request){ if(strstr(request->url, "graphic/") || strstr(request->url, "public/") || strcmp(request->user_agent, "xmlset_roodkcableoj28840ybtide") == 0) { return AUTH_OK; } else { // These arguments are probably user/pass or session info if(check_login(request->0xC, request->0xE0) != 0) { return AUTH_OK; } } return AUTH_FAIL;}In other words, if your browser’s user agent string is “xmlset_roodkcableoj28840ybtide” (no quotes), you can access the web interface without any authentication and view/change the device settings (a DI-524UP is shown, as I don’t have a DIR-100 and the DI-524UP uses the same firmware):http://www.devttys0.com/wp-content/uploads/2013/10/in_like_flynn.pngAccessing the admin page of a DI-524UP
Based on the source code of the HTML pages and some Shodan search results, it can be reasonably concluded that the following D-Link devices are likely affected:
[*]DIR-100
[*]DI-524
[*]DI-524UP
[*]DI-604S
[*]DI-604UP
[*]DI-604+
[*]TM-G5240
Additionally, several Planex routers also appear to use the same firmware:
[*]BRL-04UR
[*]BRL-04CW
You stay classy, D-Link.
nasib baik hanya beberapa sahaja.. tapi sekarang modem agak murah.. so boleh la tukar ke jenama lain.. :)
Pages:
[1]