CamDec: Advancing Axis P1435-LE video camera security using honeypot-based deception

Abstract

The explosion of online video streaming in recent years resulted in advanced services both in terms of efficiency and convenience. However, Internet-connected video cameras are prone to exploitation, leading to information security issues and data privacy concerns. The proliferation of video-capable Internet of Things devices and cloud-managed surveillance systems further extend these security issues and concerns. In this paper, a novel approach is proposed for video camera deception via honeypots, offering increased security measures compared to what is available on conventional Internet-enabled video cameras.

1 Introduction

Recent advancements in cloud-managed video cameras, video compression and streaming, and artificial intelligence applications in camera surveillance have enabled automated anomaly detection [23], pose estimation [18], real-time movement tracking [24], person (re)identification [31], and many more automated functions.

However, Internet-connected video surveillance systems have well-known security and privacy concerns, which are particularly important, given the large number of cloud-managed video surveillance systems [1]. The range of IP camera attacks includes software attacks (weak access control and authentication, insufficient transport layer protection, denial of service, cross-site scripting (XSS), cross-site request forgery (CSRF), path traversal, information leakage via file disclosure, command injection, buffer overflow, reverse engineering, unsigned/unverified upgrade); software/hardware attacks (data exfiltration); hardware attacks (debug protocol attacks, bootloader attacks, time-of-check to time-of-use (TOCTTOU) attacks, unsigned/unverified upgrade); optical attacks (command and control, data exfiltration), camera blinding (dazzling)); and—in case of wireless cameras—RF/wireless attacks (RF jamming, denial of service, eavesdropping) [9]. The login page of the web interface of IP surveillance and security cameras and other files, such as CGI scripts available through URLs for status requests, may leak camera model version, firmware, timestamps, serial number, P2P port number, Wi-Fi SSID, etc. even without authentication [19], while malware might exploit camera vulnerabilities to access sensitive information, such as passwords and PIN codes [15].

Given the array of potential cyberattacks against IP cameras (that are enabled by a variety of vulnerabilities and exploits, as seen, for example, in the Directory of Video Surveillance Cybersecurity Vulnerabilities and Exploits of IPVM),¹ an increasing number of camera vendors implement various security countermeasures—see the use of SSL certificates and the management data encryption on Cisco Meraki cameras,² for example.

Many commercial network cameras systems come with dedicated software applications for monitoring and control [12]. These are important from the security perspective because of the following reasons:

• They can have security vulnerabilities specific to the associated product or product line, which might rely on vendor-specific patches not released for years.

• The features of these software can potentially characterize a device, indicating a product line or even a particular camera model. This is important in determining how to emulate a camera with a honeypot to be deceptive, because leaving out any fundamental property and including features that are not supported by a camera would reveal to adversaries that the device is not what it looks like. Return values of executed commands and the faithful reproduction of actions such as camera zoom are actively used by attackers for fingerprinting IP cameras [27].

• The network traffic generated and utilized by these tools, along with the (often uncommon) TCP/UDP port number(s) used by them, are crucial when setting up security measures in the infrastructure.

2 Related works

Vulnerabilities of IP cameras include, but are not limited to, default credentials that can be used for brute force attacks, exposed TCP timestamps that allow attackers to compute uptime (leading to further attacks), and allowing OS fingerprinting [28]. A variety of freely available software tools can be used for the cyber-reconnaissance of IP cameras, potentially obtaining device data, such as IP address, hostname, MAC address, vendor, and server information, and target camera systems via the Virtual Switch System (VSS) port used for video streaming [10]. Sabotage intervention has to be timely, not only the logical tampering of recorded video footage, but also the physical tampering of camera devices, whether via occlusion, defocus, or displacement, should be automatically detected [25].

Baseline security countermeasures for IP cameras include, but are not limited to, changing default usernames and passwords, preventing information forwarding to third-parties, avoid port-forwarding to the camera, monitoring network traffic for spikes, and keeping camera firmware up to date. However, these do not protect from sophisticated cyberattacks, which require additional countermeasures. For example, Vempati et al. [30] proposed an approach that employs a micro-firewall rule to detect known traffic and allows video streaming even during cyberattacks, such as distributed denial-of-service (DDoS) attacks.

CameraObscura³ aims to mimic common features of IP cameras, such as camera stream, login, and firmware upload, thereby protocolizing botnet actions. It provides JSON-configurable routes to simulate logins and new firmware uploads according to vendor specifications, configurable headers to simulate a vulnerable web server, a web interface, and logging (text and JSON), as well as payload dumps (e. g., on fake firmware upload or POST with file).

The SIPHON architecture is an implementation of a distributed IP camera honeypot, featuring multiple IP cameras, a network video recorder (NVR), and an IP printer [14]. In SIPHON, camera locations are spoofed using wormholes based on instances in cloud services. These instances are deployed in different cities around the world, which can mislead adversaries using software tools such as Shodan⁴ or Fofa⁵ to identify IoT device locations, but the traffic is actually directed from the wormholes to a single location. This is particularly important from the deception point of view, because having any indication of a honeypot could discourage adversaries from performing—manual—attacks, considering all the factors that might impact the probability of an attacker giving up attacks, which can be estimated by a monotonic function of the form

$$\begin{aligned} p_{g}=\dfrac{h\left( c\left( 1+r_{h}p_{h}\right) \right) }{\left[ \left( c_{r}+c_{c}\right) \left( 1-p_{h}\left( 1-v_{h}\right) \right) \right] } [22] \end{aligned}$$

where h is a sigmoidal function (e.g., hyperbolic tangent), $c_{r}$ is the average (time) cost of reconnaissance, $c_{c}$ is the total cost of subsequent random system compromise, c is the perceived remaining cost to the attacker to achieve their goals, $p_{h}$ is the probability that the system is a honeypot as perceived by the attacker, $r_{h}$ is the rate of damage to the attacker (where damage is assumed to be proportional at this rate to the time the attacker spends in the honeypot), and $v_{h}$ is the ratio of the attacker’s perceived value of compromise (linear weighting if the attacker is unsure whether the system is a honeypot).

While SIPHON uses physical IoT hardware for the honeypots, along with the VPN connections and virtual machines to handle the networking, the developers also exposed a low-interaction honeypot running Trendnet camera emulator and observed the results compared to their high-interaction honeypots running physical IoT hardware. Note that on average, SSH sessions with the low-interaction honeypots lasted 30 seconds compared to one minute with the high-interaction honeypots.

As only one low-interaction honeypot is exposed with SIPHON, compared to the number of high-interaction physical IoT honeypots along with the different the geographical locations, this data is inconclusive. The authors found that the geographical location of the IP address of the exposed system did make a difference, therefore it’s possible that the low-interaction honeypot may have generated different data to the equivalent or similar high-interaction honeypots due to changes in the geographical location of the IP address they were exposed at.

Furthermore, as the devices were not modified, attackers could use the wireless capabilities of the devices to attack other nearby networks, or discover their real geographical location compared to the location shown by their IP address. Another approach, presented in [27], is to remove the Wi-Fi oscillators from their devices so that attackers cannot leverage the Wi-Fi capabilities of the honeypots.

While the authors in [14] discuss possible methods of device compromise detection and restoration for physical IoT devices, they do not discuss which methods they actually used in their research, and how regularly they restored and reset the firmware on their devices. This means that a previously infected device may still be in use when new attackers connect to it, meaning they are not connecting to a fresh honeypot each time and may not act in the same way upon knowing the device is already infected, or the device may not respond the same way.

Various parameters of cyberattacks can be utilized in machine learning to iteratively refine honeypot deception. For example, by using reinforcement learning, the interaction with an attack sequence can be prolonged via a transition reward function of the form

$$\begin{aligned} r_{t}(s_{i},a)={\left\{ \begin{array}{ll} 1 &{} \text {if }i \in Y\\ 0 &{} \text {otherwise} \end{array}\right. } [11] \end{aligned}$$

where $s_{i}$ is the state and a is the action, rewards the learning agent if a bot command is input string i, comprised of bash commands (L, known Linux commands, such as wget, cd, mount, and chmod), customized commands (C, commands executing downloaded files), or compound commands (CC, multiple commands with bash separators/operators), which form state set $Y = L \cup C \cup CC$.

3 Known P1345-LE vulnerabilities

Video camera vulnerability exploitation, similar to other hardware devices, strongly depends on the version of the firmware installed. A report released in 2018 by the security team at Vdoo has identified seven zero-day vulnerabilities that, at the time, affected 390 models of AXIS Communications’ IP cameras [21]. The P1435-LE on firmware older than v6.50.2.3 was noted as one of the models affected by the vulnerabilities identified [3]. This means that if an attacker manages to obtain a camera’s IP address on the Web and theoretically string multiple vulnerabilities together, a camera could be fully compromised. From our viewpoint, knowing the details of the vulnerabilities disclosed enables us in further accurately spoofing the IP camera within the honeypot environment. Since our honeypots do not necessarily have to be on the latest firmware version, they can represent IP cameras that are rarely maintained, often though a set-and-forget approach. These vulnerabilities would allow attackers to bypass the IP camera’s login page and take full control of the camera’s configuration and in theory the honeypots, including the following:

• Accessing the live view and freezing the video stream;

• Controlling the camera’s point of view;

• Disabling the motion detection capabilities;

• Disabling the camera entirely.

An attacker can also take more malicious actions through:

• Modifying the camera’s firmware;

• Adding the camera to a botnet;

• Using the camera as a network infiltration point;

• Using the camera to perform other malicious actions (DDoS attacks, crypto mining).

All Axis IP camera firmware are built on top of an underlying Linux operating system, each modified for its particular camera’s specifications. As Linux is utilized, the camera makes use of common services including Apache, GStreamer, and modified versions of FTP, SSH, and Telnet to provide core functionality. However, this poses a problem because new vulnerabilities can be present in the firmware core service dependencies. From Vdoo’s analysis of the firmware files and interaction with the camera’s front-facing interface, multiple issues where identified, ranging from authorization bypass and shell command injection to crashing the web server [21]. These vulnerabilities are identified through the CVE IDs:

• CVE-2018-10658:⁶ A memory corruption vulnerability discovered in multiple models of Axis IP cameras, which causes a denial of service (crash). The crash arises from code inside the libdbus-send.so shared object (or similar).

  This vulnerability allows an unauthenticated adversary to send a dbus-request (via the /bin/ssid .srv interface) with a specially crafted string to crash the SSID service. This crash arises from the code inside libdbus-send.so shared object (or similar).

  Because the crashes also occur by directly invoking "/usr/bin/dbus-send" with a similar string, this may affect other processes that include this code.

• CVE-2018-10659:⁷ A memory corruption vulnerability discovered in multiple models of Axis IP cameras, which allows remote attackers to cause a denial of service (crash) by sending a crafted command, which will result in a code path that calls the UND undefined ARM instruction.

  This vulnerability allows an unauthenticated adversary to send a specially crafted command (via the /bin/ssid .srv interface) that will result in a code path that calls the UND undefined ARM instruction (and possibly a similar scenario in MIPS or other architectures’ cameras) that causes the process to crash.

• CVE-2018-10660:⁸ A shell command injection vulnerability was discovered in multiple models of Axis IP cameras.

  To take advantage of this vulnerability, one must have permissions to change certain parhand parameters. This can be achieved by either 1) achieving/having administrator privileges (by using the CGI interface), 2) executing code inside the upnp daemon, or 3) finding other ways to control certain parhand parameters (see CVE-2018-10662).

  The parhand parameter handler is responsible for fetching, storing, and changing many of the device’s internal parameters. When a user sets a parameter through the web interface, the relevant CGI script (param.cgi) forwards the set-parameter request to the parhand binary, which checks access rights, and stores the parameter’s value in the relevant configuration file.

  Some of the parameters are used for feeding shell scripts, and are defined as shell-mounted ( in the parhand configuration file). The parameters’ values are parsed by the parhand ShellParser, which does not sanitize special shell characters, and also does not quote the parameters’ values.

  The shell scripts directly execute the configuration file (for the purpose of including the configuration parameters). By setting the parameter’s value with a semicolon (;), we were able to inject arbitrary shell commands with root privileges.

• CVE-2018-10661:⁹ A bypass of access control vulnerability discovered in multiple models of Axis IP cameras.

  This vulnerability allows an adversary to bypass the web server’s authorization mechanism by sending unauthenticated requests that reach the /bin/ssid’s .srv functionality. This vulnerability resides in modauthzaxisgroupfile.so, a custom authorization module for Apache httpd that was written by the vendor.

  Requests to a world-readable file that are followed by a backslash and end with the .srv extension (e.g., http://CAMERA_IP/index.html/a.srv) are treated by the authorization code as standard requests to the index.html and thus granted access, while the requests are also treated as legitimate requests to an .srv path, and are thus handled by the .srv handler simultaneously.

• CVE-2018-10662:¹⁰ An exposed insecure interface vulnerability discovered in multiple models of Axis IP cameras.

  Legitimate requests that reach the /bin/ssid’s .srv functionality can choose one of several actions by setting the action parameter in the request’s query string. dbus allows the user to invoke any dbus request as root (the uid and gid of the /bin/ssid process), without any restriction on the destination or content. Due to the dbus request originating from a root process, unrestricted access is granted to many dbus-services’ interfaces.

  While the dbus interface in /bin/ssid only serves the purpose of fetching specific values from some specific dbus-enabled services, it exposes a much broader functionality. Thus, this interface gives users the ability to control any of the device parhand parameters’ values. Control can be achieved by sending dbus-requests to invoke policykit_parhand process’ dbus-interface (PolicyKitParhand) functions.

• CVE-2018-10663:¹¹ An incorrect size calculation vulnerability discovered in multiple models of Axis IP cameras.

  The return_page and servermanagerreturnpage query string parameters in /bin/ssid’s .srv functionality are controlled by the user, and returned back to her in the response to the user’s request. When dealt with in the response-building code, these fields’ values are trimmed to a size of 0x200 bytes and copied to a malloced 0x200-bytes space by using the safe snprintf_chk function. Then the return value of the snprintf_chk function (supposedly their length) is saved in a struct member variable for later calculating the response’s content length.

  The vulnerability lies when the return value of the snprintf_chk function is the “the number of characters that would have been written if n had been sufficiently large.” This makes the calculated content-length larger than the actual data buffer, and as a result, extra bytes from memory are leaked in the response.

• CVE-2018-10664:¹² A memory corruption vulnerability discovered in the httpd process in multiple models of Axis IP cameras.

  This vulnerability allows an unauthenticated adversary to crash the httpd process, causing (at least) a black screen for viewers that were already logged to the camera using the web interface with default settings.

Upon disclosure from Vdoo, AXIS promptly published their own security advisory ACV-128401¹³ combining all seven vulnerabilities and released firmware updates for all effected models. From Vdoo’s research, they do not believe that any of the vulnerabilities have been exploited in the wild, leading to no known deliberate compromise, malware, security or data privacy threat. However, they do suggest the following recommendations to be implemented in newer firmware as a result of their findings:

• Improved privilege separation: It was identified that inadequate separation of code execution allowed functions to be executed with root privileges from an already running root process. Ensuring that an executed system processes is limited to only essential outside calls and variables is critical. This involves segmenting blocks of code execution and restricting necessary privileges (root) as required for that segment. Less reliance on root execution makes it difficult for an attacker to escalate their privilege and move laterally within the system.

• Adequate input sanitization: It was determined that no input validation was performed on all user input from the front-facing web interface when configuring the camera’s settings. This leaves potential invalid characters from not being removed prior to being saved to the camera’s configuration file. Invalid characters can cause problems during script execution and potentially lead to bugs and exploits. Input sanitization is critical to ensure that only valid characters are accepted as user input.

• Reduced reliance on shell scripts: The firmware makes use of multiple shell scripts that process user input from the front-facing web interface. These inputs are then saved to that camera’s particular configuration file. If improper input is saved and then executed by the shell script, arbitrary commands can be executed as root. By reducing or better eliminating the use of shell script executing as root, it becomes less likely that arbitrary malicious code can be executed.

• Encryption of firmware binary: As the camera firmware is unencrypted, anyone with technical know-how can view, extract, and analyze the firmware for anything of interest. This includes file structures, code/scripts and variable/function names to identify how the firmware works and weak areas that can be exploited. Encryption can be implemented in two method: 1) encrypting the firmware binary itself, or 2) security through obscurity.

To mitigate all known vulnerabilities and potential threats, all affected Axis cameras have to be maintained with the latest firmware released.

4 A novel approach for advanced video camera security via honeypots

The purpose of this research paper is to establish an approach, called Camera Security Using Deception (CamDec), whereby a Cowrie-based honeypot spoofs a hardware-based instance of a physical device. Such devices may include enterprise-grade network hardware (routers, switches, access points), IP cameras, IP phones, video and teleconferencing equipment, and Internet-of-Things (IoT) system-on-a-chip (SoC)/embedded devices, just to name a few. Traditionally, honeypots have been built to simulate unconfigured, poorly maintained devices to entice attackers in enterprise networks. However, this research aims to take this a step further by seeking to identify methods of spoofing IoT hardware, firmware, and software within a virtual Cowrie honeypot environment.

Specifically, this paper focuses on spoofing an Axis P1435-LE IP-based camera. Axis Communications is a leading global manufacturer and vendor of network video surveillance and analytics, access control, audio systems equipment, and communication platforms. The reason for selecting this specific IP camera brand is its global deployment in a wide variety of enterprises and commercial environments, including both the public and private sectors.

The aim of our research is to develop, design, and build an implementation of a Cowrie-based honeypot that efficiently spoofs an Axis IP camera instance. This research focuses specifically on the Axis P1435-LE IP camera, and hardware, firmware, and software analyses, enumeration, and fingerprinting conducted on it. Based on these findings, the reverse engineering of the camera’s default front-facing public interface is attempted to identify the device’s unique traits for accurately mimicking them.

At the time of writing, the latest firmware release for P1435-LE is version 9.80.2.2 LTS (long-term support).¹⁴ The P1435-LE is described by the manufacturer as a compact bullet camera suitable for any light condition, with built-in infrared LEDs, 1080p recording at 50/60 fps, and support for two lenses (wide and telephoto) [4].

4.1 Camera configuration

As an initial step, a factory reset was performed on the P1435-LE, and the default configuration was left unchanged. Once connected to the Local Area Network (LAN), the camera was accessed via the device’s web interface using its default credentials. This access also enabled the configuration of the device, with access to functions such as IP addressing, DNS, date/time, recording settings, and port enabling/disabling.

4.2 Automated Cowrie installation

In the proposed solution, a combination of tools is used to automatically create and deploy Ubuntu virtual machines that host Cowrie honeypots. Packer¹⁵ is used to download and install Ubuntu 18.04 LTS, together with Ansible¹⁶ to automatically update and install dependencies for virtual machines, before using a shell script to configure the Cowrie honeypot instances.

Building on related works of other researchers, Packer, Ansible, and associated shell scripts have been selected to be used for this project. The reasoning behind this design is supported by efficient building and rapid deployment of an unmanaged image across multiple VM hosts.

In addition, this solution ensures the virtual honeypot instances’ integrity, and that they meet the specific operational requirements of the project build and application. The use of pre-built Vagrant machines¹⁷ or Docker containers¹⁸ was discarded due to project scope and because of their vulnerability to malicious creation and modification.

The security concerns inherent in Docker provide an edge to attackers [29] through denial-of-service (DoS) and distributed denial-of-service (DDoS) attacks. Furthermore, the possibility of privilege escalation is heightened when employing Docker containers, as they require operational access to the Linux kernel [16].

Our project approach supports custom configurations, such as specific camera model templates, so that honeypots can run bespoke virtual environments rather than using default configurations that might otherwise be more readily detected [6, 7]. This approach reduces reliance upon third-party image updates, such that the desired version of software can be installed to meet specific application requirements, together with that of the operating system.

Furthermore, by leveraging the technology of virtualisation, in the event of a honeypot compromise, or each time the honeypot is accessed, the administrator can quickly implement a “destroy and re-deploy” action. In contrast, physical devices would need to be manually re-flashed with the correct firmware, assuming that the compromise did not damage the underlying physical hardware.

4.3 Ensuring plausibility

Plausibility is a critical aspect of any honeypot configuration, where the fundamental goal of the honeypot is to mimic a vulnerable camera, and to attract and extend attacker interaction for as long as possible. This mimicry ensures that sufficient evidence can be collected about attackers and their malicious actions. The ability of the honeypot to mimic a hardware-based instance of any physical device is of paramount importance.

There remains the potential for further research in this field with a particular focus on improving honeypot believability throughout the attacker honeypot interaction.

The P1435-LE supports advanced features, including 1080p video recording, Lightfinder,¹⁹ Wide Dynamic Range (WDR), OptimizedIR (Axis proprietary technologies) [2], and includes support for SSH and Telnet out of the box. To define a clear scope for our research, the constraints under which the P1435-LE camera operates had to be outlined. For this reason, the default configuration and the most common services of the camera have been analyzed.

In order to determine the most common ports open on the Axis P1435, the project team turned to IoT search engines Censys and Shodan. Used by attackers and penetration testers alike [8], Shodan has become a favorite cyber-toolkit, because it can identify and index public-facing IP devices. Access to the IoT search engines is through a web browser, permitting the search engines to discover device types and models of interest that have a public-facing presence online. The search engines work by scanning the Internet using a custom scan algorithm, leveraging user-entered search criteria, and parsing the banners returned by the device as a result of the search engine scan. Search terms can be concatenated and filtered, thereby permitting a customizable search functionality.

For the purposes of this project, the search was defined using the make and model of the camera of interest. The results are then displayed through the web browser interface delivering information such as the following:

• (a) IP address

• (b) Hostname

• (c) ISP

• (d) Open ports

• (e) Protocols

• (f) Device host country

• (g) Device host city

• (h) Detected banner(s)

• (i) Date of last update

In addition, Shodan can provide an assessment on the likelihood that the device is a honeypot. By comparing previously defined characteristics of known honeypots, Shodan can estimate the probability that a scanned IP address is a honeypot and describe that probability as a so-called “honeyscore.” A honeyscore assigns a numeric value between 0.0 and 1.0 to the IP address.

While the P1435-LE does have added support for SSH (port 22) and Telnet (port 23), these services are not enabled by default. Only FTP (port 21) is enabled. While these additional services can be opened by the administrator of the camera, in a commercial setting this is unlikely to be the case, due to the security risk associated with leaving ports such as SSH and Telnet open. Performing a Nmap scan on the P1435-LE also confirms the default camera configuration (see Listing 1).

As determined by the Nmap scan, in conjunction with the results from Censys and Shodan, the scope for masquerading the Cowrie honeypot configuration will be limited to the following open ports of the P1435-LE camera:

• Port 21 (FTP): Axis P1435-LE Network Camera ftpd 9.80.22 (2020)

• Port 80 (HTTP): Apache httpd 2.4.41 ((Unix) OpenSSL/1.1.1d)

• Port 554 (RTSP): GStreamer rtspd

4.3.1 Mimicking the camera’s file system

The camera’s OS architecture is built upon the Yocto project’s Poky OpenEmbedded framework, which was described by [5] as a collaboration project to develop templates for various hardware platforms. Its functionality enables developers to efficiently prototype software projects.

The Axis P1435 camera file system is based on a customized version of BusyBox v1.31.0, modified to perform camera-specific functions from an embedded Linux environment. BusyBox is described as a multi-call binary that combines minimalist versions of common Unix utilities in a small executable. Licensed under GPLv2, BusyBox is open source, has an active community participation, and provides access to the latest versions available through the Busybox website.²⁰ In the case of P1435, BusyBox is shipped with over 100 functions, including dd, echo, find, fdisk, grep, head, tail, uname, inetutils, modutils, net-tools, sysvinit, and tar, among others.

Mimicking of the camera file system was achieved using the built-in Cowrie createfs utility. The source files used were derived from either a Busybox binary or alternatively from the camera firmware binary file, where the use of one or the other was dictated by the specific honeypot deployment deliverable. For example, by downloading an earlier firmware version for a camera from the OEM website, it is possible by extracting the squashfs from the firmware .bin file, to use this to create a “vulnerable-looking” file system within the honeypot. Known Axis camera CVE vulnerability lists are available on the company website, however, most firmware updates cannot be automated, and therefore the responsibility for updating the firmware remains with the end user, which may result in overlooked security updates. This can be witnessed by IoT search engines, which often reveal outdated firmware.

4.3.2 Utilizing the user accounts

The Axis P1435-LE camera is delivered with three disabled factory default accounts, those being:

• Administrator: can change settings, access recordings, and live view.

• Operator: can access recordings and live view.

• Viewer: can access live view.

These accounts can then be enabled as part of the camera configuration process and assigned appropriate passwords at the discretion of the camera deployment engineer. Once configured and enabled, the camera   /etc/passwd and  /etc/shadow file contents will need to be copied and imported in their respective locations within the honeypot, thereby accurately mimicking the user account structure of the donor camera.

Since September 2018, the credentials attackers can use to connect to Cowrie are stored in /etc/userdb.txt. Previously, this file was located in /data/userdb.txt and came as a part of the default Cowrie build. However, since September 2018, the userdb.txt must be created and configured from /etc/userdb.example as provided in the Cowrie build.

The credentials for the previously created camera accounts (Administrator, Operator, and Viewer) can be copied and added to the honeypot’s userdb.txt file. In addition, by editing the userdb.txt, it is possible to specify user account/password combinations that can be used by attackers to gain access to Cowrie, and exclude all others. For this purpose, we used the top 20 Sucuri Wordpress honeypot user account/password combination captures, and applied them to each of the Administrator, Operator, and Viewer user accounts. This can extend an attacker’s login interaction attempts with the honeypot, thereby providing the opportunity for generating a more extensive login record.

4.3.3 Replicating camera functions

Some of the ports used by P1435-LE can be reproduced on Cowrie, as shown in Table 1.

Table 1 P1435-LE and Cowrie reproducibility

The possibility to replicate the P1435-LE functions from the honeypot is determined by the feasibility of spoofing the live feed from the camera in this environment. According to the Nmap scan performed, the RTSP stream service was identified as GStreamer.²¹ However, for our purposes, VLC,²² a free and open source multimedia player, was utilized as the RTSP server on the honeypot for two reasons.

Firstly, it had to be determined if service spoofing is indeed possible and the mechanisms of how Nmap detects services in order to accurately match it to the service aiming to be spoofed. Secondly, to aid with easier mass-scale honeypot deployment using VMs with sets of standardized software preloaded that can be modified by the user to appear as something else to Nmap.

As part of this research, we attempted to spoof a live video feed through VLC. Feeding VLC a video file of earlier recorded footage has the following benefits:

• 1. it looks believable;

• 2. the first and last frames loop together at a clean cut; and

• 3. the file used has the same video properties of which the P1435-LE would record at.

For our purposes, we used a ten-minute recording from the P1435-LE with the timestamp removed (which would compromise the authenticity of the stream when the video stream is played in a loop). This was done in an Ubuntu 18.04 testing environment as follows:

• 1. Install VLC on Ubuntu:

  

• 2. Set VLC to use root (geteuid to getppid):

  

• 3. Create spoofstream bash script:

  

• 4. Copy the command into the spoof stream bash script:

  

• 5. Change permissions of the spoofstream bash script:

  

• 6. Create a service file:

  

• 7. Copy the configuration into the service file:

  

• 8. Enable the new service on system reboot:

  

• 9. Check the status of the new service upon reboot:

  

During the process of getting the live stream to work, we faced some technical issues. First, installing VLC using Snap (as suggested on the VLC website) installs VLC in another directory rather than the default program directory, which should be avoided. By default, VLC does not have root permissions, and therefore it will refuse to output the video stream on port 554; instead, it outputs it on port 8544. To overcome this, VLC requires root permission for all the ports lower than 1024 [17].

With the live stream successfully working, upon system boot and remote users being able to connect on port 554, another issue occurred. Upon performing a Nmap scan of the Ubuntu 18.04 testing environment, it was evident that Nmap was identifying “VLC rtsp 3.0.8” as the service version running on port 554 (see Listing 2).

To have VLC report to Nmap something else other than VLC when using the -sV or -A flags for port scanning, we developed a script that launches VLC as root, points to a video file, and opens an RTSP stream on the host. To do this, the VLC source code was downloaded and modified by finding all references to the VLC version string, i.e., 3.0.12 in the latest release source code at the time of writing,²³ which appears in six files (see Figure 1).

Fig. 1

Files containing the VLC version string

However, only three of these files need to have 3.0.12 replaced. These are configure (lines 592, 593, and 5227), configure.ac (line 5), and vlc.pot (line 9).

To compile, we followed the steps from https://wiki.videolan.org/UnixCompile/. However, before compiling, source code dependencies are needed within Ubuntu [13]. Additionally, because the files have been modified, before executing ./configure, we executed autoreconf -f -i, which resolves any potential errors [20].

With VLC now complied and installed, VLC was set to host an RTSP stream, and accessed it via the host. While the stream was playing on the host, an Nmap scan was performed with flags -sV and -A, respectively. Note that the actual version string was replaced. However, the service was still detected correctly as VLC rtspd (see Listing 3).

This is a major problem for the believability aspect, because it would give away the appearance of the P1435-LE camera, and an attacker may raise questions as to why an IP camera would have VLC running on it.

To determine from where the string VLC rtspd was pulled from, the contents of the VLC source code was searched, but no reference was found to such a string. Further research lead to Nmap’s nmap-service-probes file, which contains a list of regex-based search patterns formatted similarly to the Perl syntax to identify the service running on the identified ports.

While this file could not be located on the local host, reviewing the Nmap source code online led to the nmap-service-probes file.²⁴ Doing a search for the string VLC rtspd within this file revealed the regular expression string used to identify the service (see Listing 4).

The caveat is that the string Nmap outputs describing the identify of the service is hard-coded within Nmap, rather than the VLC source code, as identified from the above Perl search pattern p/VLC rtspd/, is essentially p/service/.

Next, it was attempted to find within the VLC source code what the match command is looking for so that it can be modified appropriately. We searched the VLC source code contents for the specific string DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, as it matches specifically what Nmap intends to find, which only appears in two files, as shown in Figure 2.

Fig. 2

Files containing the string Nmap is searching for

However, only the httpd.c requires modification. We were able to locate with probable cause that the VLC rtspd strings Nmap is detecting for are located between lines 1738–1821 of this file, as shown in Figure 3. It is highly likely that this is the only source which outputs the required parameters needed by the match command within the VLC source code.

Fig. 3

Location of the VLC rtspd match Perl search pattern within VLC’s source code

In order to attempt to mimic GStreamer’s Nmap output, it’s match command was also identified within the nmap-service-probes file by doing a search for the string GStreamer rtsp (see Listing 5).

The httpd.c file was then modified as follows:

• Lines 1783–1821 were replaced to contain only the required parameters and values of GStreamers Nmap detection, these being i_status, Server, Connection, Cache-control, Pragma, and Date as shown in Figure 4.

• Lines 263–287 where deleted entirely, and

• Line 234 was modified from { 503, "Service unavailable" }, to { 503, "Service Unavailable" } — note the capital U.

Fig. 4

Modified httpd.c file with GStreamer rtspd match Perl search pattern

After running make uninstall and make clean, and recompiling the new changes along with the replaced 3.0.12 strings as mentioned earlier, Nmap cannot detect what the service is running on the open port. Instead, it tries its best to guess what the unrecognized service is, as none of the Perl search patterns got a result. Nmap will instead create a unique fingerprint ID listing the details of its attempted detection so that the unidentified service can be officially added within the nmap-service-probes file and distributed in the next update. Of particular interest, when performing a scan with the -A flag, Nmap detects and outputs the modified changes to the source code (see Listing 6).

Given that the service is hard-coded into Nmap rather than pulling the service name from the detected open port, such is the case with the version number, this approach has challenges in terms of ease of implementation and version-dependence, given the required amount of tinkering required just to get this far. The authors believe that this should be possible to achieve with additional work.

Future work on this area includes:

• Performing a Wireshark packet capture of Nmap’s service detection probing on the modified VLC implementation,

• Further reverse engineering and modification of VLC’s source code,

• Reverse engineering of GStreamer’s source code, and

• Better understanding of the specifics of Nmap’s fingerprint ID syntax.

5 Evaluation

Malware Information Sharing Platform (MISP)²⁵ is an open source utility that provides a central indicators of compromise (IoC) database that is easily accessible for both technical and non-technical users, providing information about malware and attacks, which are stored in a semistructured format [26]. The correlation features of MISP allow valuable data to be automatically provided, thereby showing the relationship between each event in the database. This data can then be exported in many different formats, including OpenIOC, plain text, and XML outputs, along with intrusion detection system (IDS) rules [26].

By using MISP with Cowrie, honeypots can automatically report findings to MISP, which can be exported in many different formats based on potential requirements. This also allows the reports of multiple honeypot instances to be collated into one centralized reporting system, where the number of sightings of a particular sample or file can be accurately measured from multiple systems or sessions, and the data can be correlated to provide forensically valuable statistics.

Cowrie includes a MISP module in its code that can automatically upload information about any files that are uploaded to the honeypot during an SSH session, allowing MISP to store and correlate reports about these samples instead of having to inspect the honeypot logs manually. This allows for significantly faster and easier incident reporting and data collation than attempting to parse plain-text logs manually.

By using this approach, we monitored the incidents on our proposed honeypot approach, while also providing statistics and forensically valuable information with regards to the number of sightings on a particular file or sample across numerous honeypots.

Fig. 5

Attributes stored by Cowrie in MISP for the Adobe Reader DC installer file

Figure 5 shows the attributes that are added into MISP by Cowrie’s default MISP module when a connecting user uses the wget command in their SSH session to download the Adobe Reader DC installer.²⁶ The information includes file size, entropy, multiple hashes, and the sample itself. Note that although the sample is stored as “malware-sample”, it may not always be malicious, because non-malicious data can also be uploaded to Cowrie.

By default, the hashes and the sample files are correlated, allowing MISP to link similar events that involve files with the same hashes together. However, if the exact same file is uploaded to Cowrie, it will just increment the number of sightings in MISP rather than creating a new event, which reduces duplicate reports but results in correlation charts not displaying every instance of the event.

6 Conclusions

This paper presented a novel approach for honeypot-based hardening of video camera security, and presented an implementation for an Axis camera model. In particular, this approach provides mechanisms to mimic the Axis P1435-LE camera, spoof videostreams through VLC, while keeping believability, frame boundaries, and video file properties in mind. This requires taking the characteristics of the chosen device model to mimic into account to an extent that adversaries—at least initially—will not realize that they are interacting with a honeypot and not a video camera. The proprietary solutions, varying device characteristics, and software implementations all pose challenges in terms of practicality and scalability, and in particular, prevent device-specific components and streamlined development practices for future software versions and device models. This approach has been evaluated using MISP, which allows for generating reports, identifying threats and camera hacking attempts, and linking similar events.