Hacking an Axis Network Camera

Based on three vulnerabilities discovered by VDOO, I demonstrate in this post how easily a network camera can be hacked

9 min readFeb 16, 2020

Motivation

This is the first article in a series that primarily deals with topics or problems in the field of cyber security and especially with the vulnerabilities of IoT devices. I got the idea after watching a video of a well-known white hacker recommending people in the field to share their own research and experiences with the community. So, here I am, writing my first article with the hope that the following articles will get better, thanks to your support, of course. So comments and feedback are very welcome.

Axis Q1635 Network Camera ©ipcam-shop.nl/de/

Background

A total of seven vulnerabilities were discovered by the Israeli start-up VDOO during a research [1] focusing on the IP cameras of the Axis manufacturer and published in June 2018. However, four of them are not considered critical although they can be used to crash various system processes and thus make the camera useless. The other three vulnerabilities can be combined to gain control of the camera without needing the login credentials. These three are listed in the Mitre database with the following ID’s CVE-2018–10660, CVE-2018–10661, and CVE-2018–10662 [2]. I will describe their functionality in detail in the following paragraph, as they are used in this experiment. Once the camera is controlled, it can be used for many purposes, such as fetching the video stream, adding it to a botnet, or using it as a network intrusion point to perform a lateral movement attack.

As VDOO explains in its article [1], the Axis cameras use the classic apache httpd web server for their web interfaces, which has been extended with some modules developed by Axis itself. For example, the module mod_authz_axisgroupfile.so controls access to files from the root folder, while the module mod_trax.so forwards specific requests to various processes for further handling. One such process is the /bin/ssid process, which runs with root privileges and processes files with extensions such as .shtm, .shtml, or .srv. Requests to a world-readable file, followed by a backslash and ending with .srv, are treated as standard requests to index.html and thus access is granted. At the same time, they are also treated as legitimate requests to a .srv path and therefore processed by a .srv handler. Such a request could look like this: http://IP_CAMERA/index.html/technikum.srv. After receiving the request, apache httpd parses it and fills the following elements in the request_rec structure with variables according to the following scheme:

• uri = “/index.html/a.srv”

• filename = “/usr/html/index.html”

• path_info = “/technikum.srv”

The vulnerability lies in the fact that the module mod_authz_axisgroupfile.so performs the authorization check based on the content of the variable request.filename and completely ignores the variable request.path_info. Thus, access is granted to the request /index.html/technikum.srv because the request is classified as one for the file /usr/html/index.html, which is world-readable and does not require authentication. This vulnerability, registered with ID CVE-2018–10661, can be used to bypass the authentication mechanism of the Axis camera.

Access gained in this way can now be used to exploit another vulnerability. This vulnerability is listed in the Mitre database under the number CVE-2018–10662 and allows any dbus message to be sent to the device’s bus, without restriction of destination or content. This is because the authorization mechanism designed to limit such requests, PolicyKit, is configured to automatically grant access to requests originating from the root user. Via the dbus interface, the values of all parameters can now be changed by parhand by calling policykit_parhand functions. The parhand parameter handler is responsible for retrieving, storing and changing many internal parameters of the device. If a user sets a parameter via the web interface, the corresponding CGI script (param.cgi) forwards the parameter request to the parhand binary, checks the access rights and stores the value of the parameter in the corresponding configuration file. Using two methods SetParameter and SyncParamter, new values can be set and stored in the configuration file.

The Shell Command Injection vulnerability, registered as CVE-2018–10660, exploits the ability of the previous vulnerability to change parhand parameters. Some of these parameters are used for passing shell scripts and are defined as shell mounted. The problem with this method is that the parhand shell parser, which interprets the parameter values, does not check for shell special characters and does not put the parameter values in quotation marks. In addition, some parameters are stored in configuration files in shell variable assignment format. The shell scripts then execute the configuration file directly, and by setting the parameter value with a semicolon (“;”) it is possible to inject any shell commands with root privileges. The following figure shows how such a http request is processed by the camera:

Flow diagram of a http request in an Axis camera ©[1]

Setting up the test environment

For testing the vulnerabilities, I have set up an experimental environment. I powered the target device, an Axis Q1635 camera, with a PoE injector and connected to the attacking computer via a USB network card. The selected camera runs under a vendor-specific Linux operating system and is equipped with an ARM processor ARTPEC-5, 516 MB RAM and 256 MB flash memory. According to [3], firmware version 6.30.1.3 of the camera has not yet been patched yet. The camera has been assigned by the manufacturer the following serial number ACCC8E74DA9D. I also use the default IP address 192.168.0.90 for this experiment.

I further installed the metasploit-framework version 4.17.47-dev on the attacking computer running under Windows 10 Pro version 10.0.17134. Via Metasploit console I loaded the exploit module axis_srv_parhand_rce with the command “use exploit/linux/http/axis_srv_parhand_rce”. Then I set the IP address of the target device and the local host using the command “set RHOST 192.168.0.90” and “set LHOST 192.168.0.200” respectively. With “set target 0” I selected Unix in-memory as target system. Afterwards, I used “check” to verify once again whether the camera is vulnerable to attack. For the duration of the experiment, I also deactivated the antivirus program and the firewall. The environment was thus prepared to be able to start the attack on the camera. The next figure shows a screenshot of the console, where all the above commands are listed:

The three commands necessary to load and set up the exploit module

Proof of Concept

Once the test environment was setup up, I could simply launch the exploit [4] with the command “run”. The exploit does nothing other than execute the first two vulnerabilities described above to open a shell session. For the experiment I selected and executed a function from the VAPIX library of the Axis vendor and the Linux command “ls”. The first one fades in the text “FH-TECHNIKUM-WIEN” over the camera image. The figure below shows a screenshot of the camera image before the next command is executed:

Axis camera image before the text overlay is blended in

Next, I saved the IP address of the camera in the _SERVER variable and then executed the SetParameter command to set the desired text overlay. After that, also using the SetParameter command, I enabled the text overlay option. With a second command, I then saved the new settings in the camera configuration file. Another screenshot of the Metasploit console shows these three commands:

Commands used to fade in a text over the camera image using Axis vulnerabilities

The next screenshot illustrates the successful execution of the above commands:

Screenshot of the camera image with the overlayed text “FH-TECHNIKUM-WIEN” in the upper left corner

For the second scenario I exploit the CVE-2018–10660 vulnerability to inject and execute a shell command. The vulnerability is triggered via the param.cgi interface and I used it to list in the system log the contents of the root folder with the Linux command “ls”. A screenshot of the Metasploit console with the commands used is shown below:

The “injection” of the ls Linux command using an input sanitization vulnerability

Finally, I accessed the system log of the camera and checked if the command was executed successfully. You can see this in the screenshot of the camera log:

System log of the camera, showing the contents of the root folder

As mentioned before, access gained in this way can be used not only to execute demonstrative commands, but also to install malicious features that can be used for a lateral movement attack or make the camera part of a botnet.

Conclusion

The experiment proves once again that there is no such thing as 100% security and that software vulnerabilities are possible even with prestigious vendors like Axis. In particular, it should be noted that the tested vulnerabilities were possible because two simple principles of software development were not met. For example, violation of the principle of “privilege separation”, which states that a program should be split into parts and each part should be restricted to its own required privileges, facilitated the vulnerability CVE-2018–10662. Another principle affecting Web services is “input sanitization”, which means that user input should be checked before saving or executing to prevent the injection of malicious code. Proper application of this principle would have prevented the CVE-2018–10660 vulnerability. Despite these flawed implementations, managing IP whitelists could have protected against exploitation of reported vulnerabilities. However, this does not mean that the firmware does not need to be patched as soon as possible.

Mitigation

In order to increase the IT security of IoT devices accessible on the Internet, you should be actively involved, as most devices do not have the IT security features enabled by default. The following recommendations have been compiled from these sources [5] [6] and will help you to achieve a higher level of security:

Separate networks: If possible, physically separate the different networks of a building/object. If the existing cabling must be used, the Virtual Local Area Network technique (VLAN) should be deployed.
VPN for external access: Instead of forwarding ports and thus making the devices directly visible on the Internet, use virtual private network services (VPN). This provides anonymisation of devices and confidentiality of data on the Internet.
Strong, unique password: A password length of eight characters is recommended by all vendors, but a password of twelve characters of different types is currently considered very secure. Regular password changes are no longer state of the art and should therefore only be carried out if the password is compromised.
Use built-in IT security features: Data exchange should only take place via encrypted connections; access to the network or devices should also be restricted using the 802.1x protocol or IP filtering; central log monitoring can be handled using protocols such as SNMP.
Patch management: You should make sure that all devices and systems in the network always have the latest firmware versions.
Regular risk analysis and ongoing training: In most cases, the early detection of risks is much more cost-effective than the damage caused by a security incident. Getting to know your own systems better and raising awareness of IT security among your employees can significantly increase the protection of your IT infrastructures.

Today, many manufacturers offer their customers the so-called Network Hardening Guide, a guide that offers real help in securing devices and networks.

Last word

I hope you enjoyed the article and found it helpful. The next article will be published shortly and will analyse the IT security features of the top five leading camera vendors in Europe.

PS: My thanks go to my former employer who provided the hardware.

Best regards