IoT Security: Backdooring a smart camera by creating a malicious firmware upgrade

hello I thought I would do a video on how to hack and backdoor an IOT camera using a compromised firm upgrade the goal of this video is to show why having a secure from upgrade process that checks the authenticity of the upgrade is so important as an example device I will use a wise conversion to you I've got quite a few of these as I'm using them in my IOT security training shameless plug if you're doing security professionally and want to get into your IT and embedded security I'm giving a hands-on training in February in Berlin that covers a wide range of attacks on real IOT devices if you use the code youtube' you get 10% off you can find the link to that in the description now what's nice about the white cam is that it's only $24 on Amazon and there's a large open source community developing open firmware for it so you can buy it hack it and then use it as a decent surveillance camera the camera is quite simple it has a USB a and a micro USB port on the back a rotating stand with a magnet in it and on the bottom an SD card slot and a button if you power it on you can access it using the Y scam app unfortunately you can't seem to use it without a wise account with the original firmware but we can just build our own anyway now let's get into the former on the Y scam site we can download the latest firmware version four point nine point five point 36 in my case let's download it and jump to the terminal turns a bit when I unzipped it the first time I had a bit of a chuckle as they seem to have packed it on Mac OS without removing all the metadata files that Mac creates now let's use our trusted tool bin walk to see what's in the image the first thing bin walk detects is au image header which is a common format used by the bootloader you boot this header already tells us quite a lot about the firmware it was created on the 15th of November the us type is Linux and the CPU type is MIPS this header also contains a couple of CSE checksums that we will have to update once we have modified the former next we see a kernel image was also detected a three-point 10.14 kernel which is from October 2013 the next entry seems to be invalid as can be seen by the minus 1 uncompressed size the next two and fries are interesting to squash affairs filesystems squash FS is a read-only file system that is commonly found on embedded devices it's mostly used for the root partition as having it read only ensures that the device can't easily brick itself as the last entry bin walk also found a jf FS to file system jf FS - or journaling flash file system - is a file system that is commonly used with flash memory devices now we could use Benoit to successfully extract a firmer but as we want to repack it later I want to write my own script that unpacks and later reap X the different firmware components so let's create a wise extractor Python script now first we will create a very simple class that simply keeps the name the offset and the size of each part of the firmware next we create an array of firmware parts with each part that been wok found we insert the offset and calculate the size of the part by checking where the next section starts for the last entry we just take the file size - the offset our script will take the first argument as a command in this case unpack and the second argument as the Verma file to read now we simply iterate over all former parts we defined and write them to separate files you can find the final version of this script and also some other resources in the description now if we go back to the terminal and run the script on our extracted firmware we get five files you image header image kernel squash FS 1 and squash FS 2 and J ffs - now let's create a folder to clean up a bit move in the firmware and our extractor and start unpacking the file systems for the squash of s file systems we can use n squash FS - D with the target directory and the image file and so let's extract both our squash F as file systems from the firmware for the J ffs to file system we can use Jefferson with the same syntax as you can see we now have three folders for all our file systems now let's take a look inside of those file systems the J ffs - file system contains a couple of folders with binaries libraries and configuration the first squash of s contains what looks like the root filesystem and the second squash of s contains a couple of kernel modules let's start by exploring the root file systems etc' directory so let's CD into a squash FS one out et Cie and run LS TC what's in there one very interesting file here is the shadow file it's the file that is used to solve passwords on Linux and UNIX machines so it might contain something interesting and if we cut it we indeed see that it contains a password hash for the user root let's try cracking it with John if it's a secure password this would not go anywhere but John already tells us that this is using quite a shoddy password hashing algorithm that is limited to 8 characters and after a couple of minutes we get the correct root password i smart twelve sweet now let's look at the startup of the system the scripts that run during boot can often be found in et Cie init dot t on this system there's just a single script here Arceus and if we open it we can see that during boot this machine does something quite interesting it seems like the camera is running telnet which could allow us to block into the camera remotely using the password we just cracked so let's see if it's actually running on the camera now I've set up the camera on my network and if I try to turn it into it I'm getting a connection refused and also if I port scan the camera using an map we can see that there are no common open ports on the camera let's grab the extracted firmware for a 1080 and see if maybe it gets disabled somewhere down the line and indeed we see I camera contains the string tality and if we run strings on it and grab for telnet we see that it might kill alternate deep processes luckily there are some workarounds if we check where eternity comes from we can see that it's just a link to busy box busy box is a tool collection for embedded systems we will see more of it later in this video now a trick with busy box is that you can not only use symbolic links you can also invoke busy box and then tell it which tool to run so if we change the contents of our CS to call busybox tennety instead of just an ID it should start as it won't get killed by the I camera binary now that we have changed something in the squash fs1 file system we need to generate a new firmware image with our modifications so far we have only modified squash FS 1 so we need to only repack in that single file system squash FS has a lot of options such as block size and compression to make sure we get these correct we can look at the output of unsupportive s - s on the original squash FS let's use the values and squash FS gave us and create a new file system from our directory using make squash FS once this is done we should have a squash FS 1 new file containing our new file system now we need to combine the kernel our new file system and the other file systems into an image so let's add a pack functionality to the script this script will open the supply destination file read in all the firmware parts from the file system 0 by Pat them to the right size so we don't change any offsets and write it all to a new file you might notice that we only start with the second entry in firmware parts that's because we will use a different tool to generate the image header back in the terminal let's move our squash FS 1 new file to use squash FS 1 and run our just updated script with the PAC command we will create a demo backdoor dot binary with this new file we are almost done all we have to do is generate the missing image header using a tool called make image for make image we need a lot of options but luckily running bin walk on your original image header gives us all of them so we can just fill them in and hit return to generate a new image if we run Ben walk on this newly created image we can see that the output of it looks almost identical to the first run of Ben walk and so we hopefully have succeeded in creating a valid firmware image for the device so all that is left now is to copy the image to a blank fat32 formatted micro SD card to upgrade the firmware I simply have to pluck the micro SD card into the bottom of the camera this is a bit fiddly but with a micro USB cable or some small plastic thing you can easily push it in then you have to press and hold down the button while connecting the USB cable as soon as the small LED next to the USB port turns blue / orange the firmware upgrade is running and you can let go of the button this will not delete the configuration and after a couple of minutes and a lot of blinking of the LED the camera should be back to normal so let's see if we can lock into it using talent and indeed using the previously correct ismart twelve part we can now use telnet to log in as root on the camera and if we check et Cie init the RCS we can see our talent modification so we have just successfully flashed a compromised firmware on this device now in most networks the camera will not be directly exposed to the internet and so we can only look into it while we are on the same network so let's put a small reverse shell on the device that makes the camera connect to a server of ours which will basically act as a small command and control server a common way to do this is to use netcat but as you can see we don't seem to have netcat and if we check the available busybox commands we can see that this system was indeed not built with netcat luckily busybox has pre-built binaries on their website including statically linked MIPS of binaries just what we need unfortunately is also relatively large with 1.5 megabytes and we don't have for that much space left on flash but luckily the device creates a temper vest a file system that is kept in RAM and gets deleted on every boot we can build a script that downloads busybox to ram on each boot and then uses to connect to us so let's create a bin back to our script in our root filesystem this script will first try to ping google.com once every second to determine whether the device already has internet and once an internet connection is established it changes the directory into slash temp and Donald's busy box if you are wondering about the strange IP it turns out that W get on this system does not support HTTPS so I had to upload busybox to a regular plaintext HTTP server once we have our busybox downloaded the script goes into an endless loop where it will try to connect to a small server i've rented on the Amazon Cloud and exposes bin as H to the destination server if the connection fails or is closed it will try to reconnect after 120 seconds we also need to add a call to our back door into the RCS startup file and so let's comment out our call to busybox tennety and instead add a call to our back door we also have to set the executable permission on our backdoor script now we can just again repack the image copy it to an SD card and flush it to repack the image I will just recall the earlier commands so I'll call make squash surface then move squash FS one new to squash FS one call our wise extractor script with the PAC command and finally call make image with the same arguments as before now I just copy the firmware to a micro SD and upgrade the firmware in the camera meanwhile connect to the Amazon instance which is our commanding control server and start netcat in listening mode on port 4 4 4 4 and hopefully our camera should connect after a couple of seconds and here we go we have a simple reverse gel onto the device as you can see we can access recorded video readout things like the Wi-Fi credentials and access the rest of the internal network now imagine if you sent this camera back to Amazon or sell it somewhere an on IT security savvy end-user will have almost no chance of noticing that his device was back toward I hope you enjoyed this video and - see you soon on this channel again thank you

Channel: stacksmashing

Views: 202,392

Rating: 4.9627748 out of 5

Keywords: Security, IoT security, IoT, Embedded, Embedded Security, Hacking, Reverse Engineering, Firmware, Firmware security, Ghidra, IDA Pro, binwalk, binary

Id: hV8W4o-Mu2o

Length: 13min 8sec (788 seconds)

Published: Mon Jan 13 2020

Reddit Comments

[u/interactionjackson]

this is great. always validate the origin of your firmware updates.

[u/chvishwakarma]

Interesting!

[u/nightauthor]

Is there another way to exploit the firmware simply by knowing the root password?

[u/minanageh]

Hi mate can you do it on routers ?

[u/AmateurFootjobs]

What if you don't have physical access to the device? Can you do this by spoofing an OTA firmware update to the device from the manufacturer?

[u/shaperaty]

Great

[u/[deleted]]

[removed]