Blog: Vulnerability Advisory
A “Neet” CSRF to Reverse Shell in Wi-Fi music streamer
We recently decided to buy a music streamer; the Neet AirStream NAS1.1 – so we could more easily broadcast Kiss from a Rose around the PTP office. Cheap and on the first page of Amazon results, it looked ideal for our purposes. The AirStream runs on a local Wi-Fi network, supporting Airplay and DNLA.
You set up the server, and can send tunes from your phone to the server, whenever you’re connected to the Wi-Fi. And like a lot of similar products on the market, it’s also a little Linux box. So let’s see the ingredients here (and some of our immediate observations):
- Acts as an access point (which, at default configuration, is open).
- Connects to other Wi-Fi access points.
- Has a user-facing web application for changing config setting (but no login functionality or HTTPS)
- Can be accessed if connected to its own AP or through the Wi-Fi network it’s been connected to.
- Does system configuration settings (SSID, media server name, local Wi-Fi connection SSID & password) through a web API which sends XML-looking calls to a binary in the /cgi-bin folder.
- Allows POST to GET conversion
- Runs telnet…
Okay, so let’s imagine that this has been set up properly. The user has got it through the post, turned it on, actually set up authentication on the AirStream itself, so it’s not just left as an open AP (if it has been left as an open AP, hitting the telnet port with the undocumented default user/password of root/ifconfig (We know, sigh) will give us a shell). A normal user can’t change these default credentials on the web app configuration page so they’re likely to stay default making owning this device too easy and not fun. So let’s get a reverse shell instead.
Proof of Concept
STEP 1 – Identification for CSRF:
In principle, once doing this, we could physically drive to the location where the AirStream is, log into it with the password we set, and dump out the plaintext SSID & passwords that the AirStream stores for the local Wi-Fi. But, this didn’t feel like quite enough. We dug deeper into the box and found a few interesting things. The very lightweight version of linuxseems to use busybox for its system tools which, lucky for us, includes a basic implementation of netcat.
The web app runs from /www and /cgi-bin directories. Looking through the binaries in the cgi-bin folder (there’s a lot, many of which seem to be there for no reason), we hit upon an undocumented, and otherwise non-functional API call, which is meant to start a samba server, even though there’s no samba on the AirStream. Running the command clean did nothing. But code injected into the password parameter of the string runs nicely.
The line downloads a .sh file (which itself is written to get around the fact that the busybox implementation of nc lacks the “-e” flag functionality), makes it executable and then runs it. When our CSRF sprayer hits the page, we get sent a reverse shell from the target network.
The downloaded bash file contains the reverse shell as below:
STEP 2 – We’re in:
So we have managed to get the user to click the link and the reverse shell has connected back to us. We now have access to the device over the Internet rather than having to be physically present near the access point or on the adjacent Wi-Fi device it is connected to.
From here we can do a few things. As the Neet device is connected to another Wi-Fi network we can get up to some malicious activity, essentially making this a pivoting device. We could also sniff traffic waiting for any clear text passwords to come up or we could browse to the following directory and view the clear text Wi-Fi passwords for the devices it has connected to – /etc/config/wireless
So at this stage we just have total pwnage. Nice!
Further research showed that Amazon sells various other boxes nearly exactly the same as this one, just rebranded and in theory this attack could be used on any of the boxes as they all seem to run the same software.
Looking at Wigle.net, a known SSID searching platform we are able to see a list of AirStream devices:
From here it is possible to drill down to a precise location, and this can help us find a target user of an AirStream device:
After 60 days of trying to contact the manufacturer to no real avail, the time to publish has come. This is how the contact attempts went:
Looked on device for manufacture labels, nothing.
Tried to find Neet’s website, to see if they list a manufacturer, nothing.
Tried to Google for other rebranded ‘airstreams’ that linked to manufacturer, nothing.
Contact Neet to disclose vulnerability in the hopes that they could pass it on.
August 13th to 22nd
Neet say they have requested new firmware from the manufacturer.
Then no response for 10 days.
Neet say they are still waiting for an update, but also state they don’t really think this is a vulnerability.
I explain why this is a vulnerability, they say that they understand and that they will get back to me.
Neet say they have forwarded the findings onto the factory.
No contact for 18 days, but give me the managing director’s email after I tell them about the blog.
Email one of their Directors, no response.
Re-email the Director, talking about the blog going up soon and that I would like this fixed before hand.
Oh look, a very kind response, gives me a sales contact for a Chinese factory.
Also says they have stopped selling the AirStream.
September 28th till now
Sales contact forwards my email onto the IT team for the Chinese factory.
IT team, do not acknowledge my emails.
I think it is fair to say that this is not going anywhere and the factory probably do not even make the firmware for the device anyway.
I’ve published this post in a bid to try and make users aware of the issue.
Obviously there are a number of problems with this device, although firstly;
- Adding CSRF tokens to all functionality would be very helpful and render this whole attack useless.
- Secure coding practices should be followed as to stop this kind of command injection occurring in the first place.
- Adding the ability for normal users to change the password on telnet would be beneficial, as would getting rid of telnet altogether for more secure alternative such as SSH would also be of benefit.
- Adding a login page to the web application or even just requiring the current password for the Wi-Fi would also help as currently anyone on the network is able to change the password easily.
- Finally, HTTPS support would be worth thinking about as currently password changes are made in clear text.