Hacking Holberton School’s Security Cameras

Rick Harris
Sep 14, 2016 · 6 min read

It is a busy season at Holberton School as students, including myself, are looking for opportunities to step outside the classroom and into the industry. So what would make me want to break away from interview preparation and start up a new project? Julien Barbier, co-founder of Holberton School, was chatting with several students and daringly said he was surprised that no student has tried to hack the school’s security cameras. Challenge accepted.

Finding the Cameras on the Network

The first step to hacking the cameras is to be on the same network. Holberton School has a separate wireless network for infrastructure devices including the IP cameras. Volunteerism paid dividends because the student DevOps team that I was a part of was given access to that network. Once connected, I need to locate the devices on the network. In the past I have used network monitoring tools to see devices on a network. Instead of using one of those I investigated command line tools available to learn something new.

Address Resolution Protocol

ARP, or address resolution protocol, is the translation of the network IP address to the device address (MAC or physical address). A command line tool called “arp” is described as an “address resolution display and control”. I entered “arp -a” in Terminal and hit return, it displayed the IP and MAC address of devices on the network. The physical address may be used to identify the manufacturer of a device. The response showed several devices with similar physical addresses. However, I needed further confirmation. Often IP cameras have a web interface to manage the device. Entering the IP address in a web browser confirmed that they were the cameras.

Default Passwords are a Hacker’s Friend

Now that the cameras were located on the network. The next problem was access. A default user and password come already configured on the device . The new owner is expected to change the password, but often they don’t. The first thing I did was check the default user and password that I obtained via Google. The default logins were not changed. Once logged in to each camera, I had access to all streams. As a note, I hacked the cameras while the school was relatively empty since I usually am the first to arrive. Accessing the streams is a hack in itself. However, I wanted to affect the image streaming from a camera. To do this I needed to get inside the camera, so I turned to the “nmap” tool to identify others services running on the camera.

Mapping the Ports on a Network Device

According to the tool’s description, “Nmap (‘Network Mapper’) is an open source tool for network exploration and security auditing.” This made it perfect for what I was trying to do. I entered “nmap -p<port range> <ip address>”. The results revealed that port 22, the default port for SSH, was listening. I tried using the default username and password to SSH into the camera. To my surprise it worked! In fact, when I reviewed the /etc/passwd file the only user account was the default user which meant that I would have access to manage the files as well. However, not all would be as simple as it seemed. The camera uses a Linux environment modified specifically for the device, Dropbear for SSH, Lighttpd for the web server, Busybox for the bulk of normal Linux shell commands, and, as I discovered later, Evostream for the media server.

Subverting the Web View

The majority of configuration files were on a read-only mount of the file space which prevented modification. A mount is a connection to a physical disk space such as a hard drive or some other type of storage. In a recent, Commando Project at Holberton School we were given a broken server that we had to repair and bring the services back online. One piece of the problem was that the SQL database was on a read-only mount preventing the service from starting. Through this I learned about using “mount” to remount the file space with read/write capabilities. However, mount would not work to change the permissions on the camera. As a result, I was blocked from altering many of the main services of the camera.

The camera constantly changed jpeg images in the tmp folder. The web page accessed the images to provide the “live stream” on the web interface. The web interface files in the “www” folder were located on the read-only mount so I could not modify it there. However, I did have write access in the “tmp”, meaning temporary, folder. I copied the web folder into temporary folder. There I modified the symbolic link to point to my hacked image. A symbolic link is basically a file pointer that tells the system to respond with a different file when asked for that file. The next step was to get lighttpd to point to the modified files.

Redirecting and Restarting lighttpd

The primary lighttpd configuration file was in the /var/etc folder which was in a read/write mount. To redirect the web server, I used the vi text editor to change host file path from “/usr/www” to “/tmp/www”. With all of my hacked configurations in place. I restarted the service using the command “pkill lighttpd”. To confirm it worked, I logged back into the web interface of the camera. It displayed my hacked image with a pokeball in place of a hanging plant and a black hole in the floor.

Hitting a Roadblock with the Server-Managed Configuration

While I knew the camera’s web interface was down, I could tell that the cameras were managed by a central server used to access the streams. The active connections showed one from the server. I did not believe the hack altered the stream on the server. Through a source with access to the server I confirmed that the hack was not effective.

Taking the Camera Offline

With the amount of time to devote to this project dwindling, I tried to understand how the image was going from the the camera to server to determine what I could do to disrupt the process. The most interesting part of the output from “netstat -pal” was the manufacturer’s streamer service. It connected to a service called “evostreamms”. A quick Google search revealed that this is a media server. To confirm the media server hosted the stream to the security camera server, I created a looping shell script to kill the media server service, and created a listener on the same port with “nc -lp <port>”. The streamer service sent a Flash video stream to that part. The security camera server connected to the media server to get the stream. When I stopped the media service I took the camera offline.

Although the camera was offline, still images were still updated in the tmp folder and could be retrieved. The manufacturer’s streamer service produced the updated images. To prevent those images from being created I took that service offline as well. The issue persisted until the camera was manually rebooted which initialized the camera configuration process.

All Good Things Must Come to an End

While I wanted to take the next step of streaming a looped video through the media server, I could not devote more time as I needed to prepare for interviews. In terms of the camera, I was impressed by some of the protections in place. The fact that I could kill a core service without something noticing seems flawed. However, much of the hack would have been inhibited by changing the default password. The security camera server managed the configuration of the cameras, so when implementing the system the camera logins may be overlooked. I met with Julien to reveal the hack and point out vulnerabilities in the system. It was a great learning experience with even more still there to be learned.

This article was first published on LinkedIn

Rick Harris

Written by

Full-stack Software Engineer | @holbertonschool Student | Fan of the @FightingIrish | Opinions represented are my own.