Overview

In August 2012 WikiLeaks released information about a software that facilitates intelligence-gathering on U.S. and global citizens, using surveillance technology, called TrapWire.

The idea behind that software is, to use various models of surveillance cameras for intelligence reasons by by-passing their weak security setup. Using this software is possible for example having a payload running silently, doing face recognition and looking for a match in a list of faces fingerprints, pinging back only if there is a match.

We decided to evaluate how difficult it would be to build and deploy such a system.

We used AXIS as test case, which is a vendor that manufactures Video Surveillance Cameras that are deployed all over the world on public transportation, banks, train stations, airports, universities, and so on. As shown by this article, the build and deployment of such a system could be done without great effort in cost or manpower. In fact it could be done within days, because of the very low security level surveillance cameras offer. It would even be possible to attack the networks behind these cameras by gaining access through them or even use them as a botnet.

The Camera

The specific camera model we used in our case was the: AXIS 209FD Network Camera

These cameras use a PoE cable. This technology is widely used on VoIP phones, because it requires only one cable to handle data communication and power supply.

Having a PoE injector is the only requirement to have it setup and running.

From AXIS website about this camera

“Customer story using the AXIS 209FD Network camera:

Axis network cameras monitor flight safety Axis cameras ensure aviation safety at Sheremetyevo International Airport”

Technical details

The AXIS 209FD, runs Linux over ARM architecture and by default it runs services for HTTP and FTP.

In our setup the camera requests to set a root account password when configured for the first time.

It seems other models have a default user ‘root’ with the password ‘pass’, although this wasn’t our case.

Because of the fact that the cameras can be configured to VIEW only, it is a nice service for example for Hotels to show the local weather and their facilities to potential customers.

Interacting with the system

The system offers a Setup menu, which displays all the information about the camera and firmware version

under Advanced->Scripting it allows to modify the local files.

Basically under http://192.168.0.90/admin-bin/editcgi.cgi?file=YOUR_FILE_OR_DIRECTORY, the users can replace YOUR_FILE_OR_DIRECTORY by a value of their choice.

Enabling Telnet

By default Telnet is not enable, but it is as simple as to open http://192.168.0.90/admin-bin/editcgi.cgi?file=/etc/inittab , then uncomment the line that says “#tnet:35:once:/usr/sbin/telnetd” as shown in the following image, press “Save file”…

…and you are good to go.

As you can see, everything runs as root.

The BOA Webserver also runs as root, of course.

Vulnerability development

In order to do some vulnerability research you would need to do the usual stuff:

• Upload a statically compiled gdb, if you are looking for memory corruptions and the like.
• Download the contents of /usr/html, which is where the web contents are located, to look for vulnerabilities in their web interface.
• Download the binaries running by default and/or the ones which are called through the web interface, if you are willing to do some static analysis with IDA Pro.
• Audit their web interface with burp.
• Etc.

There is also available an SDK, if you like such an environment. This could become handy to an attacker who is willing to develop some malware for the platform. I talk a bit more about this at the end of this post.

Attacking the camera remotely

The two obvious ways would be to go after known vulnerabilities in the default HTTP and FTP services, Linux kernel, and the web interface.

The web interface is pretty interesting, since it calls binaries with arguments and such, it has binaries and scripts exposed as CGIs.

The ACLs to restrict the access to the different parts of the web interface depends on how sensitive the direct action is, at least that’s what I believe AXIS thought.

For example to change configurations you have to use an Administrator user, to access no-so-sensitive parts the Operator user, and to just view through the camera a Viewer user.

Some cgi are not properly protected, at least I think so.

For example the cgi command.cgi, is located in my setup under:

• http://HOST_OR_IP/axis-cgi/buffer/command.cgi

is in fact a shell script, which parses a bunch of arguments from the GET request.

The purpose of this cgi is to make camera captures, so that the user can afterwards retrieve them.

The user can configure the number of captures, how often to do them, give the task a name and launch it. Afterwards stop the task and retrieve the images. It is also possible to remove the files and directory created by the task.

Depending on the configuration given, the cgi will call a binary with the arguments provided. ;–)

This script is vulnerable to command injection, a bit tricky to exploit. The good thing is that it is accessible to every viewer. A lot of hotels, universities, and many others, have these cameras accessible to everybody to only view, which is enough to misuse this vulnerability.

The goal of this post in not about uncovering a bunch of 0days, neither about making a step by step exploitation tutorial, but to give the reader a taste of how much you should trust your Surveillance camera and give you some ideas about where to look to make them more secure. Given the fact these devices run Linux, hardening guidelines can help to secure them better. As the reader can imagine there are more vulnerabilities, which are much more interesting than this one, but they are beyond the scope of this post.

Since everything is running under the context of the user root, whatever vulnerability you find will give you root access to the camera.

Searching for targets

Searching for targets would differ on the attackers purpose, but let’s focus on someone who wants to get as many victims as possible without much effort.

SHODAN and Google would be two of the most straightforward tools to use.

SHODAN

Searching for “AXIS” would give a massive amount of potential targets.

On the other hand if the attacker is more focused on some specific camera model “AXIS 209FD”, would return a more specific list.

Google

By using the well-known ‘inurl’, we can do the following searches to get a list of cameras exposed to Internet:

• inurl:/view.shtml
• inurl:ViewerFrame?Mode=
• inurl:ViewerFrame?Mode=Refresh
• inurl:axis-
• inurl:view/index.shtml
• inurl:view/view.shtml
• liveapplet
• intitle:”live view” intitle:axis

being a little more specific, “inurl:/view/index.shtml site:.de”, to search for cameras in German domains.

Fingerprinting the camera

There are two very easy ways to identify the camera and firmware version.

Through FTP, the banner tells everything for you, in my case:

1
2
3

chidori:~ shadown$ ftp 192.168.0.90
Connected to 192.168.0.90.
220 AXIS 209FD Network Camera 4.43 (Jan 23 2007) ready.

Via the web interface you can get the release version, this is accessible even if the camera has been configured to always required to login.

It is under http://HOST_OR_IP/axis-release/releaseinfo

In my case:

1
2

part: 28507
version: 4.43

The Risk

Surveillance cameras are used for monitoring, and controlling, in order to keep places safe.

These cameras could be misused in a number of ways in the advantage of an attacker, for example:

• To watch activities and get behavior patterns.
• To replace the video stream of a pre-recorded one, so that the people monitoring would never get aware of what’s really going on.
• To deploy botnets.
• To attack the network behind the camera.
• To deploy a payload which does face recognition, which is pretty straight if cross compiling OpenCV
• at least, anything that a Linux box and a camera can do.

Conclusions

Surveillance Cameras seems not to have been developed with security in mind, at least it is the case of this particular camera. I’ve roughly looked at other AXIS cameras and they look pretty much like this one. All processes running as root, no proper ACLs and so on. Since the OS these cameras are running is a Linux, they are just like any other Linux box, which makes it pretty straight to develop some software and then deploy it to the camera.

As a matter of fact, a couple of weeks ago Konstantin gave me a malware he found on some router, a malware that targets home routers. I’ll do a dedicated post about this particular malware, since I found it pretty interesting because it targets a bunch of architectures, including ARM.

Although this malware is not targeting these cameras, it runs flawlessly in them.

Surveillance Cameras should be treated as any other Linux box, because that’s exactly what they are. And the security of these boxes should be taken a little more seriously.

Written by

Sergio Alvarez