Welcome to HBH! If you had an account on hellboundhacker.org you will need to reset your password using the Lost Password system before you will be able to login.

hacking the DV-2020 router

  1. Home
  2. Forum
  3. Hacking in general
  4. hacking the DV-2020 router

Napoleon's Avatar

Napoleon

Member
0 0

Today I received my new router the DV-2020 MultiMedia Modem. After reading the article "Me and my router" I decided to test this one.

I could not find any way w/o using bruteforce to circumvent this login: http://imageshack.us/photo/my-images/807/loginp.png/

And all I could find in the source was:

<BODY BGCOLOR="#cc9999"><H4>401 Unauthorized</H4>
Authorization required.
<HR>
<ADDRESS><A HREF="http://www.acme.com/software/micro_httpd/">micro_httpd</A></ADDRESS>
</BODY></HTML>```




However, If I enter the correct password and login then I'm able to find the original password again. See below:
--------------------------------
I managed to retrieve the password **after login**:

DV-2020 MultiMedia Modem from Davolink inc.

1. Log in on 192.168.1.1
2. Click on "Management"
3. It's not possible (at least not w/o addons to view the source. It's protected. I noticed something like "<!-- hide" in the source). So save the entire page to disk to circumvent this minor protection.
4. Open menu.htm using a text editor. Then I made a search for "password". The first hit seemed to find it. It finds something like: href="http://192.168.1.1/password.html". Obviously that's the next file we will open in the browser.
5. Navigate to http://192.168.1.1/password.html  . when viewing the source code you will notice something like:

"
<!-- hide

pwdUser = 'thisUsedToBeMyVerySecurePassword1234!@#$';
"


Voila, there is our password in plain text. It's stored in a variable, unencrypted.

Misc info:
Default login for this router: user // user
It runs a micro_httpd server
If you use something like notepad++ instead of the regular notepad then the code formatting is kept.
I could not connect to it using Telnet.
I have wireless disabled.
It doesn't use cookies unless they are hidden or something. When I restart my browser I have to log in again but as long as I keep the browser open I don't have to log in again.
--------------------------------



Now my question of course is: What kind of pop-up is that and how do I get around it? It's not Java, I tested that. I think it's HTML but I'm not sure.

j4m32's Avatar

j4m32

Member
0 0

From what I can gather of what you've shown in the screen shot and your observations, you need to look ouside of the HTML souce for your answer in HTTP headers sent to the browser.

Packet sniffer or appropriate browser extension for viewing HTTP headers will help here as I believe this box is generated by the browser, not Java Script or anthing else as you've correctly identified, it certainly looks like a standard HTTP protocol username & password authenticated by the router webserver rather than necessarily anything else executing, like a perl, cgi or indeed any other server side scripting language.

Hopefully that answers the inital question of where does it 'come from'…

Circumvention, well I'd say it's less a case of circumventing and I'll tell you why.

The webserver has just recieved the request from the client. It is typically 'authoritative' (In that we have no physical access to the authentication hash in the HTTP request) needed to pass authentication. Since we have have not passed a HTTP header with an authentication hash it will respond with the HTTP code back to the browser and a short piece of HTML (That you've posted) to tell the browser to prompt for the username and password.

I don't know much about this but what I do know is that until you get it right you will not be returned the hash needed to pass the HTTP authentication check. So the only way to really "circumvent" the box is to essentially not use your browser at all, and write the bruteforce program to connect then hammer it with requests until it returns the hash which you then pass as a HTTP header. (Correct me if I am wrong since I have not sat down with the HTTP RFC in years).

Hope that puts you on track to where you wanted to go with it!

EDIT I've left out specifics of various webservers because I do not have a wide knowledge of how all webserver software to deal with HTTP layer password authentication, however you might be able to download a firmware image or root around the filesystem somehow if you find some way of getting to it, say via SSH - since most tend to be thin Linux kernels.

Jim,


Napoleon's Avatar

Napoleon

Member
0 0

Yes that did answer my initial question. Thanks.

And thus I started reading the headers:

Get:


GET / HTTP/1.1
Host: 192.168.1.1
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.9,nl-NL;q=0.9,nl;q=0.8,en-GB;q=0.7,de-DE;q=0.6,de;q=0.6,zh-cn;q=0.5,zh;q=0.4,en-AU;q=0.4,ru-RU;q=0.3,ru;q=0.2,en-us;q=0.1,en;q=0.1
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache

HTTP/1.1 401 Unauthorized
Server: micro_httpd
Cache-Control: no-cache
Date: Sat, 28 May 2011 10:39:24 GMT
WWW-Authenticate: Basic realm="DSL Router"
Content-Type: text/html
Connection: close```

Send (using a false password: theusername // thepassword):
```markuphttp://192.168.1.1/

GET / HTTP/1.1
Host: 192.168.1.1
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.9,nl-NL;q=0.9,nl;q=0.8,en-GB;q=0.7,de-DE;q=0.6,de;q=0.6,zh-cn;q=0.5,zh;q=0.4,en-AU;q=0.4,ru-RU;q=0.3,ru;q=0.2,en-us;q=0.1,en;q=0.1
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Pragma: no-cache, no-cache
Cache-Control: no-cache, no-cache
Authorization: Basic dGhldXNlcm5hbWU6dGhlcGFzc3dvcmQ=

HTTP/1.1 401 Unauthorized
Server: micro_httpd
Cache-Control: no-cache
Date: Sat, 28 May 2011 10:40:56 GMT
WWW-Authenticate: Basic realm="DSL Router"
Content-Type: text/html
Connection: close```

I thought it used SHA-256 as micro_httpd uses. But it's not SHA256 (not 64 in length) and it's not SHA1 either because "dXNlcjpwYWFyZGVuMSE=" doesn't look like: 0024321b5cf7cd9e6d0d67226dcca25f19701e52. I also tried NTLM w/o any results.
But who cares anyway, that hash most likely contains my faulty username and password. The headers look like a dead-end to me and doesn't look like the "low quality Made in China" that I expected from it.


It looks like the only way to get in is by knowing how to hack ACME's micro_httpd server.  But according to Google is only has known DoS vulnerabilities...
Browsing the directories like: http://192.168.1.1/httpd.conf gives the 401 error too. However, it gives a 404 error when the file is not found so it's possible to figure out the directory structure somewhat.
Also the login p // p (the default for that micro http server didn't work).


After some Googling on port sniffing I found NMap (Yes I can program it too but why program it when there like hundreds around. Call me a skiddie T.T)


NMap results:
```markup
PORT   STATE SERVICE    VERSION

21/tcp open  ftp        D-Link or USRobotics ADSL router firmware update ftpd

23/tcp open  tcpwrapped

80/tcp open  http       micro_httpd


Running: Linux 2.6.X

OS details: Linux 2.6.13 - 2.6.31

Uptime guess: 0.838 days (since Fri May 27 15:34:31 2011)

Network Distance: 1 hop

TCP Sequence Prediction: Difficulty=199 (Good luck!)

IP ID Sequence Generation: All zeros

Service Info: Device: broadband router

Wait a minute… port 23? Isn't that telnet? According to my dusty memory and google it is. So it's open but I can't telnet to is… Did the manufacturer forget to close it or can I still telnet to it somehow..

Okay. My conclusion: It is hackable but not for me yet. I'd probably have to lookup the unix 2.6.x vulnerabilities but the problem is: my UNIX knowledge is near zero. I know how to install one and how to perform some basic operations but that's it. Damn :(


j4m32's Avatar

j4m32

Member
0 0

Nah NMap is fine. Look at this string you've written here:

"dXNlcjpwYWFyZGVuMSE=" Just look at the mixture of upper and lower case, that's base 64 encoded. Decode it and you get: "user:paarden1!"

Notice in the headers it's using "basic" authentication - doesn't get much more basic than this. Though the only way to really "attack" this would be to be between the adminstrator and the router (Man in the middle) on the local side unless it had fascility for WAN remote management. Even then, looking at what NMap tells you about the SYN/ACK sequence (TCP Sequence Prediction), the chances of guessing the SYN/ACK sequence is pretty slim.

The FTP server may be equally vulnerable to bruteforce, it may even have a default username and password or even a dormant username and password. You're better off loging in with your administrator username and password and haveing a root around its filesystem to find any vulnerabilities that would open it up remotely.

Most domestic routers go to some length to make sure it is really only accessible to the administrator of the hardware and typically only from a local interface - doesn't mean it's impossible - but they tend to have thought about the pitfalls and limited you to a web interface.

Port numbers can be deciving, the most useful tool is anything that can connect to a remote address almost 'raw', so to speak, when you have no idea what protocol it may be. For example, I could quite easily say: set up SSH on port 80 (if I like). Nothing is set in stone, but most people tend to leave things standard though. This router isn't like to have any other remote management stuff (I think).

Jim,


Napoleon's Avatar

Napoleon

Member
0 0

First of all: Thanks for the responses.

Brute force: Because we now now it uses the header information to proces the login and what encryption it uses and its format markup<username>:<password> it can easily be brute forced. However, brute forcing a hard password like the sample I provided earlier takes forever to crack. There doesn't seem to be a maximum number of login attempts so it's possible but not doable.

There seem to be more default accounts: support // support (I guess this one is used by the Internet Provider for remote maintenance on the router?) lama // lama (for FTP, not confirmed)

I tried using Telnet but the connection is immediately closed.

I tried using both Putty and FireFTP (ports 21 and 23) but the DV2020 immediately closes the connection. The FTP port is only used for firmware updates. I did notice that the users can't change the FTP login credentials without hacking around in that thing so if it would be somehow possible to gain remote access by FTP that that would be a serious security problem. Therefor I take that as another reason to believe that the FTP is very well secured against remote attacks.

The links provided had some useful information but… Once again it seems that this thing is well protected and that it requires a decent amount of UNIX knowledge and it's known vulnerabilities and such. I currently lack the hardware and time to set up a UNIX system. Well I could use VMWare perhaps but learning UNIX and it's security is something that takes a lot of time.

However, hacking it locally from within the administrator's area is indeed very easy as from there on it's all Javascript and such. So if somebody wants to enable some settings that the Internet Provider disabled then that would be easy.