Axis Camera APP takeover

According to the initial publication, the EAP APP files which can be installed on a camera with administrative privileges consist of a tar compressed elf binary plus several config files and HTML code. This tar compressed file is gzip compressed and just named with the extension EAP. The APP being analysed in the initial blog was "AXIS Video Motion Detection". Replacing the elf binary named vmd in that application did not lead to the attacker code getting executed at all, but instead the POSTINSTALLSCRIPT="" parameter from the package.conf file was manipulated to execute an arbitrary /bin/sh script for code execution.

A look at the published exploit shows that most of the values in the config file are random values, except for the APPTYPE which has the value lua:

According to comments on the original exploit, this APPTYPE is used, because for other APPTYPES some required libraries are checked during the installation:

Trying to use this exploit in our project however failed, as no proper Session was created:

In the camera's APP menu, it's possible to check the logs for installed applications. Changing the appname GET parameter to the name of our failed malicious APP gives us an indication of why the exploit failed:

As the initial publication showed the config of one exemplary APP only, it was not the best to just 'guess' alternative APPTYPES for our EAP file. But where to get alternatives or more samples? Fortunately, the manufacturer itself provides a sort of APP-Store for applications that can be installed on the camera.

Going through some of those, the "AXIS Live Privacy Shield" APP looked like an promising candidate for our malicious APP. The package.conf file looked like this:

In this case, the APPTYPE used was aarch64 instead of armv7hf from the "Video Motion Detection" APP. First, we tried to embed our own shell script and execute it via the POSTINSTALLSCRIPT configuration parameter. But that unfortunately failed with different variations. After the project was already finished, we noticed another comment in the exploit, which states that sync and sleep commands are needed in between the malicious payload, so this might still work and is worth a try for anyone reading this blog. ;-)

But instead of just accepting what was written in the initial publication, we also tried to replace the liveprivacyshield elf binary with our own malicious one as a next step:

To get our final EAP application, we first need to compress our files into the tar format and then gzip compress them as mentioned before:

Be aware: If you don't rename the .gz file to .eap, the installation of the APP will fail.

The APP can then be uploaded and launched automatically or manually:

As you might see, it's possible to disallow unsigned APPs for installation. This might be configured on your target system as well and is therefore another source for a non working exploit. But in that case, it should be easily possible to just plug this option so that unsigned APPs are allowed again.

In our case, running the application leads to an incoming Meterpreter session:

For all the Red:

In general, if you're in a penetration test and you're struggling to get an exploit to work as it should in theory, don't give up and dig deeper. It's not about scanning and throwing PoCs at target systems, it's about showing the client the biggest impact and risks to your scope. The next time you see an Axis camera in your project and are faced with the same behaviour, you will know what to do.

For the Blue:

The ability to get RCE by uploading a malicious APP is unlikely to be fixed at any point in the feature, as it's "by design" and has been known to the vendor for over six years. However, there are several things you can do to prevent this scenario in your environment.

1. Ensure that the management interfaces for the camera are placed on a secure network, accessible only by jump hosts or the administrators themselves. This will prevent most potential attackers from accessing them in the first place - therefore no vulnerability can be exploited. **Don't put the web interface on the perimeter so that it is accessible from the Internet (yes, we've seen this before).
2. Use strong, complex passwords for administrative accounts to prevent attackers from guessing or brute forcing credentials. Doing these two things will reduce the risk of misuse a lot.