I’ve been increasingly interested interested in firmware and have also stated in my previous articles that I would write an article on unpacking and hacking firmware. I thought this would be a good start. This isn’t some old firmware, the build date is February 2015 and has some interesting features. I see a lot of people writing articles on routers and thought I’d change things up a little and look at CCTV.
First of all the firmware on this brand is publicly available, which is obviously great for me and it includes some release notes and a image file. The first thing I notice when looking through the hex is this:
Having a little search through the internet I find it’s a particular processor which is optomised for such things as CCTV monitoring. Nothing else grabs my attention after this, I can’t find any magic numbers manually. So I move on to what most people do and look to binwalk to identify for me, what I have in this .img file.
Seems like we don’t have a whole lot of work on our hands in extracting this, looks like just some simple compression. I had a hunch but wanted to be fully sure of the entry points (manually checking entry points are annoying). Potentially you can view the .img to see that gzip is used, there are many strings to give it away.
Edit: Someone has pointed out that gzip strings doesn’t neccessarily mean gzip. You must still search for a magic number.
After using binwalks extract functionality I was presented with 2 files. The first file I checked seemed to be a simple tar archive and was easy enough to just use tar to extract the contents of it. So far, so good.
The other file returned just data when trying to identify it. I decided to delve back into a hex editor and found a magic string that looked like a squash file system. I also found some paths that would relate to a file system.
I extracted it with binwalk and was full of crt files and a config file. Edit: This is the kernel config file.
A little nosey around the file system and I find something interesting. To run a web interface for the user, the firmware runs Lighttpd, this will allow it to use a lightweight application to run a web server. In the web directory, the first thing that strikes me is the lack of robots.txt, I’ve just checked and I have found multiple sites running this particular software. I could share dorks, but some of these sites are charities, and so I’ve decided not to. I’ll have a show of what it looks like though; it runs on Java, which isn’t.. amazing. Most have not implemented it with authentication (atleast the ones spidered).
I decided I didn’t want to destroy the system (I’m only looking), and decide to just view “Live View”. Nothing spectacular about it, but still, it’s a CCTV with no authentication. Which is due to the CCTV administrators not the manufacturer. Although robots.txt wouldn’t go a miss here.Depending on what device you are using and where you are located will depend on what java applet you get. It goes through some trivial checks on what device you use (although obviously the check doesn’t have to be extensive) before giving you a version that suits you. Mobile’s are not served with an applet by viewing it on a browser. Instead it gives you simply a “setup” option.
The applet itself drops a .dll onto your home folder in Java. In the folder “CWS”, nothing too major about the applet, nothing was obfuscated or anything just a simple read through JD-GUI will do for me.
On further inspection of the .dll file it seems its packed with a common packer that a lot of people use, UPX. This could be a potential problem because dropping a .dll from Java which is packed by UPX could start off a few AV’s. UPX is widely triggered as either malicious or PUP by AV’s due to the sheer amount of malware that uses the packer. Customers may be turned away if the Java applet keeps getting detected as malicious. UPX is really easy to unpack so I won’t show anything here, what I do see is that it seems an outsourced job for the software there are many comments in the PHP code which seem to be Korean and although it’s nothing much the language on the bins are Korean.
I haven’t had much time to look at reversing the files yet, but it was very easy for me to just view the camera, although, I am unable to control it, privacy issues exist with people not correctly authenticating the machine. The code seems very rushed or unorganised. There is a page that shows you all the information about the device, this can be used by an attacker to find specific flaws. I’m also given a list of all buyers of this software, so I can exploit there systems too!
I left this if you could call it vulnerability for a couple of months, I haven’t gone through every single piece of code in the new version, but I think Spotify have patched this in their latest versions. When I was studying in my local college, I didn’t have mounds of money and tasked myself with finding ways to defeat the Spotify limitations on my phone. A little overview on Spotify free on a phone, you basically can’t choose a specific track, can only skip a few times and playing tracks is done with shuffle.
If any of you have reversed apk’s before, you’ll know there’s one tool up for the task, apktool, a lot has changed since I last used it and that was only a few months ago. One interesting thing to note is that I didn’t decode the resources, this will break the decompilation process that apktool is running, you will be unable to correctly re-compile the apk if this done. The argument -r is therefore needed to ensure we don’t decode to resources. Like most things I tried looking into the ins and outs of the code from Spotify, but what it boils down to usually is finding a simple vulnerability.
Spotify released a web application around the same time I was looking into the apk and gave it a little look. I found Spotify’s URI format and thought this could be useful when trying to change values in the mobile app. It indeed was, as we’ll found out in a moment.
I’m using version 0.7.9.1170, there have been a vast amount of different versions since and haven’t checked where it had been patched. I’ve only tested 0.7 and the latest from 10/04/2015. In this vulnerability, we’re interested in the folder /assets after we have decompiled it successfully from apktool. You’re folders may look different, I have built from this folder before so there are many folders that may not be there in the screenshot.
I then compiled and signed my app and put it on dropbox to be downloaded to my phone. It’s self signed and so you will have to enable “Unknown Sources” and can just enable “just once”. Once installed I logged in to my free spotify account and it worked, I could play the tracks I wanted, when I wanted. Another glitch in system is that once you’ve played a track through this, you can’t select it again. What do we do to resolve this? We delete the cache, login again and we can replay the track again. Not the most efficient way of bypassing something. But, as a student, I thought it was good enough for my needs. I uploaded a demo, and the reason I uploaded to dailymotion is because I know YouTube would probably take it down.
So I first came interested into “router hacking” in the past few weeks, I’m going to have future posts on my findings because it’s such an interesting area that I don’t think enough people look at. I first started getting interested in analysing routers and dissecting the inner workings of them when I was watching a DEFCON 22 talk on the TR-069 protocol. If anyone hasn’t seen it, I have it below. The TR-069 protocol allows your ISP to interact with your CPE (Customer Premises Equipment), essentially your router. One of the big things it’s used for is upgrading your firmware on your router, can we see something wrong with that?