In this thread, I am going to showcase the machine that runs this forum, the EDIMAXIC-3115W. I will not only explain how you can mod one for your own hardware abuse but also why this is a terrible product for its intended use case due to its pallet of very unique and totally 100% professional security issues.
Chapter 1: The modding begins
Looking at it from the outside, one may think its just an average IP camera.
Once you open it up however, you will see that the manufacturer was nice enough to leave some handy little UART test pads available on the PCB.
Please note that to open it, you will have to lift up the large silver sticker on the left and right side facing the camera mount screw.
Now, what do you think this UART will give us? Debugging logs? Maybe a user-level CGI shell? Well, you guessed wrong because it by default gives you a full root shell with write access and everything!
Now, what do you do with a root shell? Simple. You dig around and see how the camera works!
"Thats cool and all but we wanna know some numbers!"
First of all, the camera uses a single-core RTL8196B MIPS central processor, clocking in at a whopping 390 MHz. It features 32 MB of RAM which is accessed over a parallel bus making the read times actually halfway decent. The network interfaces include a 2.4 GHz and a disabled 5 GHz WiFi modem and a 100 Mbps RJ45 Ethernet connection. The SoC also features an unpopulated single lane gen 2 PCIe interface as well as using a USB 2.0 interface to read the camera sensor using the v4l2 library. And yes, it does boot linux out of the box. The OS and kernel are stored on an 8 MB SPI ROM chip.
The SoC also features a few kB of internal flash storage which are used to store WiFi passwords, admin credentials and configuration data. A bash script reads this data on boot and copies it to the corresponding files in ramfs. Here comes our first weakness of the camera. The admin credentials are stored unencrypted in the /tmp folder. If you happened to not know the login data for your camera, the cat command is your friend here
"Now, how does the web interface even work?"
The included web server is the infamous lighttpd server commonly used in smart home appliances. Its main advantage is its low memory usage, but thats about all it does well. For web application scripting, it supports the CGI format. Unlike its nowadays still commonly used alternative PHP, CGI has very little memory safety and input sanitization features in place. This is an issue since unsanitized input can lead to unexpected behaviour. *foreshadowing*
"We know how it works, what can we make it do now?"
Actually, quite a lot. For starters, we can modify the save values in the internal flash to make the webroot point to a new directory like a mounted USB device. This allows us to host a primitive web server on the camera.
During my reverse engineering, I jokingly set this up to demonstrate that:
The possibilities dont just end there though. Knowing this camera boots Linux, we can quite easily extract the SPI ROM contents using DD over the cameras built-in telnet server which we can activate using the command telnetd on the UART. The ROM is located as three partitions in the /dev folder. With our partitions, we can now start hacking together our own kernel by extracting the built-in kernel configuration. For my example, I just copied the config onto a Linux 3.8 kernel as that was the latest one to work without major changes to the configuration. I then enabled all the modules I needed and compiled it. This process can take up to 20 minutes on a somewhat modern PC. If you use older hardware, expect a few hours of wait time.
With our new kernel that now points root to /dev/sda1 on default, we can finally connect a USB boot medium with a Debian rootfs to the port which once used to connect the actual camera to the logic board. Now we basically have a fully featured Linux server which will install and run any software (as long as it compiles for MIPS).
"Why should I avoid this as a camera again though?"
As we discussed earlier, the designers of this camera made multiple very bad decisions while developing the device. For once, the use of CGI without a properly secured web server is pretty much a death sentence. What doesnt help this is the fact, that the camera will on default forward its http server (not even https) to the world wide web using UPnP.
"Now hold up" you may say. "Isnt the http server kinda useless without UART?"
Well, the cameras has the typical feature of allowing requests to the webroot without logging in to provide a clean login page. The issue here lays in the fact that lighttpd does not sanitize URLs and the camera is actually misconfigured to have /www/. set as the webroot. Accessing http://hostname-of-camera.local/./tmp/ will therefore result in /tmp becoming part of the webroot.
Remember how the admin credentials are stored in plain text in the /tmp folder? You dont even need those!
The tmp folder also contains a snapshot_1.jpg and a snapshot_2.jpg which are updated every 5 minutes with the camera feed. By simply accessing these without ever having logged in, using your external IP shows why these cameras should NEVER be used by anyone for their intended purpose. So stay safe and do NOT use IP cameras without investigating them prior to use
___
I hope this entry has been interesting to you. Any feedback or personal experiences on this are happily welcome!
