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:
CSRF doesn’t necessarily need to happen over the Internet: due to the way the device is made our targeted user always has unauthenticated access to their web interface through their home/office LAN. So, we first identify a user connected either directly to their AirStream, or connected concurrently with their AirStream to the LAN. Then, since we don’t know the actual IP of the AirStream on the LAN, we send our target user a link to a webpage which holds CSRF-spraying JavaScript. Our proof of concept ( PoC ) page looks like this:
This JavaScript determines the IP range of the LAN using the browser and forces the browser to send HTTP GET requests all over the network, 192.168.0.0/24 (for example). It’s a spray approach, which guarantees to eventually hit the AirStream device.
Link to JavaScript – https://github.com/MrTurvey/NeetAirstream
To test this premise, we first exploited the combination of unauthenticated access to the web app alongside the POST/GET conversion. We crafted a GET request out of the POST request along with its parameters which asks the settings binary to change the AP name and password. The GET request was then put into our JavaScript. Once the target user clicks a link to a page containing our sprayer, the sprayer sends the GET request all over the network, eventually hitting the AirStream, and the AP SSID and password are changed.
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 GET Request can be found on line 41 of the JavaScript. If we inject the below into the vulnerable password parameter field, it is possible to make it execute and sends us a reverse shell.
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.
DigiFunk
SoundMate
AGPTek
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:
Disclosure
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:
August 12th
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.
August 24th
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.
September 1st
Neet say they have forwarded the findings onto the factory.
September 19th
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.
September 27th
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.
Conclusion
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.
