Tenable Research Advisory: AXIS Camera App Malicious Package Distribution Weakness

Tenable Research recently audited an AXIS M3044-V network camera and learned that AXIS has introduced an application platform to their cameras. The camera even came with an app pre-installed: AXIS Video Motion Detection. During the audit, we discovered that it’s possible for a malicious actor to tamper with the firmware and replace it with a malicious package.

Background

The AXIS M3044-V is a networked mini dome surveillance camera marketed to stores, hotels, schools, banks and offices for physical security and CCTV.

The AXIS Camera Application Platform (ACAP) is an open application platform that enables third-party developers to develop applications that can be installed on AXIS network cameras and video encoders.

From an attacker’s perspective, an application platform on an embedded device is interesting because it could make distributing and installing malware easy. Creating custom malicious firmware can be time-consuming and difficult. Furthermore, many embedded systems require digitally signed firmware which, to say the least, presents the attacker with a real challenge. You might be thinking that a well-written application platform would also require signed apps. Let’s see what AXIS did.

Analysis

The first thing we need to know is the format AXIS expects for an app. From the image below, you can see that the camera is expecting the application to have an eap extension.

Thankfully, since the camera comes with an application pre-installed, you can find an eap file in the firmware. An eap turns out to be just a gzip compressed tar.

When decompressed, the package reveals a fairly simple format: a binary, a couple of configuration files and some HTML.

The package.conf file appears to contain all the instructions for installing and executing the vmd binary.

The obvious approach to creating our custom application is to simply replace vmd with our own binary. Pursuant to that goal, I generated a little endian ARM reverse shell using msfvenom to replace vmd. I recompressed the package and tried to upload it. Unfortunately, I received an “It did not work!” error message. Could the application be signed in some way? Maybe there’s an API the binary needs to adhere to?

Before racing down those rabbit holes, let’s look at the POSTINSTALLSCRIPT field in package.conf. That sounds like it’ll execute a script of our choosing, right? To test this, I returned the vmd binary back to its original state, renamed my reverse shell to rev_shell.bin, created a bash script called rev_shell.sh to execute the reverse shell and changed the package.conf file to include POSTINSTALLSCRIPT=”rev_shell.sh.”

After repackaging the eap and uploading, I received this:

It appears we don’t have to worry about any type of package signing. Also, worth noting, we overwrote the original VMD install. Pretty neat! The problem now is that our reverse shell only starts after installation. That means any type of reboot will remove our connection to the camera. Also, since we overwrote VMD, a future update could remove our modifications. Let’s see if we can craft our own application to work around these things.

Since this isn’t an attempt to be stealthy, the first step to avoid being overwritten by future updates is to create our own application. This is easily done by changing a couple of items in the configuration file. Since our goal is to have our application installed by unwitting third parties (or not removed if we have some sort of supply-chain attack going on), we’ll name our application “AXIS IoT Security Module” and rename vmd appropriately:

Next, update the post install script to register the reverse shell with systemd:

And you’re good to go. Repackage all the files into an eap and, once again, you’ll get a reverse shell. And now the shell will come back up if the camera gets rebooted or there’s a firmware update. However, note that the reverse shell won’t survive a factory reset.

Vendor response

Following our Responsible Disclosure policy, we originally reported these, and other, findings to AXIS in late August 2017. After some discussion, their final statement was the following:

Business impact

A malicious package installed on the camera can be used to distribute malware to legitimate users or as a pivot point to execute lateral transfer. Physical security and CCTV operations can also be compromised.

Solution

While Tenable currently doesn’t offer a plugin that directly checks for tampered firmware, our AXIS web interface detection plugin will help customers to identify deployed AXIS cameras to determine their exposure to this kind of attack.

Tenable recommends that affected devices are deployed in segmented networks with access and authentication control to restrict usage to approved users.