Avatar

Jakub Brzozowski

Pentester, bug bounty hunter and security researcher. Also huge fan of Star Wars and coffee connaisseur :coffee:

Hacking into NAS

21 Jun 2021 » web-applications

nas_logo

Recently I decided to do a little cleanup in my computer stuff cabinet and found my old NAS (Network Attached Storage) that I’ve beed using some time ago. The device was a Thecus N299 - a basic model capable of running two 2,5” HDDs in a RAID matrix. As the support for this device ended in 2007 I was asking myself why I was keeping it around for so long.

nas1

I booted up the NAS and checked if there are any files I want to backup before throwing the NAS out. Unfortunatelly the credentials I had saved did not work and the NAS didn’t want to let me in.

nas2 nas3

I thought to myself that I can try to hack my way into the device and treat this as a challenge. Wasting no time I started Burp and proxied all the web application traffic through it. After fuzzing one of the CGI scripts, more precisely nas.cgi was returning some error messages upon fuzzing newFolder parameter.

nas4

This looked like a promising command injection, so I tried the following payload to confirm if the code gets executed.

$(ping 192.168.1.27 -c 10)

When I checked on the Wireshark running in the background, I could see that the device was indeed sending ICMP packets to my host!

nas5 nas6

As it was possible to achieve code execution I tried to establish a shell connection with the NAS to get access to my files. However every paylaod I tried ended up not connecting to my listener or the bind shell was not executing properly. I decided to change my approach and instead connecting to the device I tried to save the output of the commands in a text file on the server side and read the output manually after the execution. I sent a simple ls payload with ouput redirected to pwned.txt to the server and checked the result.

nas7 nas8

Fortunately the file listing was echoed to the file without any issues. Then I tried to check what user was the web application running on by sending the id command. When I checked the contents of the output file, I was pleased to see that the commands are executed with root privileges :sunglasses:.

nas9 nas10

From this point I could do everything I wanted on the system, including reseting password for the web gui, and accessing files I wanted to backup.

nas11

Apart from the command injection, the device has other vulnerabilities and werid quirks that have been used back in the 2007 such as session cookies in the HTTP parameters and storing session data in publicly accessible directory. With that in mind I will be even more happy to throw it into the trash.

References:

  1. http://www.thecus.com/product.php?PROD_ID=11