Password recovery D-Link DPH-400S or the story of a small hack

To me, through two acquaintances, the director of one taxi company asked me to reset the password from the D-Link DPH-400S IP phone. I don’t know the history of the phone and didn’t take an interest, but as I understood it, there is working and tuned equipment (including this multi-channel phone) that no one serves. Nobody knows the passwords either. And there is a desire to set up integration with a computer that certain people can do, but for this you need a password from the phone.

As the director told me, half a dozen people have already said that without resetting the settings this is impossible. It turned out all the same possible. And how it came to recover the password is a small story under the cut.

If someone got here in search of a password recovery method, and does not want to read my story, then you can immediately read from the bold header below .

When I heard about this task, two standard thoughts immediately came to mind - to look for a regular way to reset the password without completely resetting the config and, of course, the default passwords. For what the hell is not joking, and who knows what kind of "experts" have already come to watch the phone.

The first option quickly disappeared - the instruction did not offer such an option, and on the official D-Link forum, one question was offered to this question - a complete reset. And the director immediately rejected this option.
')
Therefore, it remained to hope for good luck - I googled up several variants of passwords from the phone itself via a button interface and 5 passwords from web access and, armed with Kali Linux (in case you still don’t want to surrender), went to the “customer”.

First of all I tried the prepared passwords on the phone itself - by. Well, maybe the web interface will please me? I asked the employees for the IP address of the phone - in response I received a surprised face and a phrase that they had no idea about it. And it inspired hope that it is still not changed. Having connected to the switch, which stood next to the phone, with the help of nmap, I quickly found the goal I needed, but even here I was disappointed - the passwords for the web interface did not fit either.

The following, and, at that time, the last thing that was planned was hope for a weak password.

Looking at the source of the login page to charge the brute force form through the hydra (THC-Hydra), I was a little horrified to find 10-15 screens of JavaScript code there. It turns out that in order not to send the password in clear text over HTTP, it, by the power of D-Link programmers, goes like this:

<username> + md5(<username> + ":" + <password> + ":" + <salt>) 

An implementation of md5 in javascript is also included. Apparently, a cheap replacement for HTTPS. I didn’t even check if a new salt is issued every time ( and this, I will say a little running ahead, in this case it is possible - the password is stored in clear form ) or replay attacks can become a serious threat to “HTTPS from D-Link”, because I decided not to torture the web service anymore, because there was no desire to prepare a special dictionary for brute force.

There was much more desire to join telnet, which also came as standard and was not disabled. However, the speed of a brute force of 20-30 passwords per second upset a little. I started the dictionary of the top 500 passwords and decided to wait, hoping for luck again.

Bored for 3 minutes after the start of the brutus, I decided to go on the phone with Nessus. However, the results of the scan were only open ports, which immediately seemed strange, since, at least, he had to swear at the use of telnet. It turns out that by default Nessus does not scan network printers, telephones and other dead devices so that they do not die under its pressure. Putting the necessary tick again, he launched the scan and immediately saw the expected yellow message that the insecure telnet protocol is being used. Then another, very predictable “IP Forwarding Enabled” is logical, because you can connect a computer through it if there are not enough ports in the switch. And after that I saw something interesting already:



The description of the vulnerability indicated that the VxWorks debugging service is hanging on port 17185 / udp, through which it is possible to read the device’s memory. Yes, it really can be useful. And the module for Metasploit, as it turned out, is available .

Who needs to reset the password, can start reading from here:

It remains the case for small, to merge the memory dump and hope that the password lies there in the clear.
Launch Metasploit:

 msfconsole 

Select the desired module:

 use auxiliary/admin/vxworks/wdbrpc_memory_dump 

The module has very few settings:



It is enough to specify only the IP address of the victim of the phone from which you need to pick out the password. Let it be 192.168.1.177:

set rhost 192.168.1.177

Next, run the module with the run command and see how the memory dump starts loading:


Finding a password in the dump decided to start with strings of course. Assuming that the former owners of this device did not change the login name “admin”, he immediately decided to click on the intended login, displaying 5 lines before and after the word “admin”. The result was a team

 strings vxworks_memory.dmp | grep -A 5 -B 5 admin 

Which, about a miracle, immediately gave the desired result:



At the same time, despite the fact that there was a lot of text output, the result I needed was almost at the bottom, I didn’t have to touch the scroll bar. And in open form ... Victory!

PS By the way, the password was not bad - 12 characters, large / small letters and numbers and seemingly absolutely random. It seems that the one who put it, knew about the importance of password protection. But, it seems, did not know that updating the firmware of devices is equally important ...