4 - Detecting alterations at a patched TP-LINK router firmware to prevent a CSRF attack

IOT PT / 4 - DETECTING ALTERATIONS AT A  PATCHED TP-LINK ROUTER FIRMWARE TO PREVENT A CSRF ATTACK

- Layout for this exercise:




1 - Introduction

- This exercise is based on the CSRF (Cross Site Request Forgery) vulnerability described here:

http://www.jakoblell.com/blog/2013/10/30/




- According to the web author's comment,  "when a user visits a compromised website, the exploit tries to change the upstream DNS server of the router to an attacker-controlled IP address, which can then be used to carry out man-in-the-middle attacks."

- One of the affected devices is the firmware corresponding to the router TP-Link TL-MR3020:









 - Actually, the specific file affected by the vulnerability is the LanDhcpServerRp.htm, located into the folder /web/userRpm of the web root:




2 - Extracting the original and modified firmwares

- Now, what we are going to do in this exercise is compare two different firmwares. One corresponds to the original and vulnerable firwmare of the TP-LINK router, and the other corresponds to an modified or patched firmware.


- Both firmwares:




- Unzipping the original firmware:




- Unzipping the modified firmware:




- Two folders (in blue) are extracted:




- Going into the first folder:




- Applying binwalk to the original firmware:




- The root file system of the original firmware:




- Going into the second folder:




- Applying binwalk to the modified firmware:




- The root file system of the modified firmware:




3 - Locating the affected file LanDhcpServerRpm.htm

- Locating LanDhcpServerRpm.htm in the original firmware:




- Locating LanDhcpServerRpm.htm in the modified firmware:




- Let's put both files LanDhcpServerRpm.htm in the same folder, with the purpose of comparing them (the file corresponding to the modified firmware is renamed with a 1):






- Now, both files are in the same folder:




4 - Comparing fimwares with diff

- Let's use the diff command to compare both files:




















- The comparison yields a difference of a existing JavaScript script in the modified firmware:




5 - Comparing firwmares with kdiff3

- Also, a graphical tool can be used to compare files, like kdiff3:










- The user is prompted to choose even three files. In our case we are interested in just two files (A and B):





- Taking A as the root file system for the original firmware:




- Taking B as the root file system for the modified firmware:




- Both root file systems are choosen:




- 285 different files are found:

- Going to the file that causes the possible CSRF attack, following this path:

squashfs-root -> web -> userRpm -> LanDhcpServerRpm.htm

- The original firmware:




- However, the modified or patched firmware holds a JavaScript script that actually takes the session ID and prevents the CSRF vulnerability to be performed:

3 - Command Injection with Burp for NETGEAR router emulated firmware

COMMAND INJECTION WITH BURP FOR NETGAR ROUTER EMULATED FIRMWARE

- Layout for this exercise:



1 - Introduction

- This exercise is based on the Command Injection attack for NetGear devices registered here:

http://firmware.re/vulns/acsa-2015-001.php




- The vulnerability affects a great range of NetGear products, including the router WNAP320:





- One of the affected scripts is called boardDataWW.php, that will be analyzed for the purpose of attacking it through a Command Injection, sending a crafted input taking advantage of the lack of sanitization:




 - The vulnerable section of the script uses an insecure call to PHP function exec(), accepting any type of input for the parameter 'macAddress':




2 - Setting up the lab

- Unzipping and decompressing the firmware of the NetGear router:







- Extracting the .squashfs file:



- A new folder is extracted:




- Inside, we can find the whole root file system of the firmware, ready to be analyzed:







3 - Analyzing the vulnerable PHP script

- First, let's try to locate the vulnerable script boardDataWW.php, using the command locate:







- Opening boardDataWW.php we find the call to the PHP function exec():






- The parameter 'macAddress' is passed without further sanitization about the standard MAC address format:





- Let's see how exec() works:





4 - Intercepting with Burp

- Once the firmware emulated is available (as done in previous exercise):




- Going to the affected script:



- Enabling the proxy at the browser:




- Launching Burp:









- Enabling Burp to intercept Client requests and Server responses:




- Sending a fake MAC address:



- The message is intercepted:



5 - Launching the attack

- Sending the request to the Repeater:






- Now, let's try to craft the MAC address input so that the content of /etc/passwd is leaked to a file located into the root of the web page:

cp   /etc/passwd   /home/www/passwd # from here it is a comment




- Clicking Go and trying to access passwd from the browser:





- The file passwd is open and saved:




- The content of /etc/passwd has been leaked, so the attack is successful:




- Also, because Burp has been enabled to intercept the Server responses, the whole content is displayed:




- It is interesting to notice that this attack has been launched against an "emulated firmware", and not against an actual physical device.