Turning Camera Surveillance on its Axis

Turning Camera Surveillance on its Axis

Speakers: Noam Moshe, Team Lead and Lead Vulnerability Researcher, Clarity

Conference: DEF CON

YouTube: https://www.youtube.com/watch?v=wclvPznv5v4

Overview

In this compelling DEF CON presentation, Noam Moshe, a lead vulnerability researcher at Clarity, unveiled critical security flaws within Axis Communications' enterprise-grade IP camera management solutions. The talk, titled "Turning Camera Surveillance on its Axis," detailed a journey from initial discovery of an obscure internet-exposed service to achieving full, pre-authenticated remote code execution (RCE) on Axis management servers and, subsequently, on the connected IP cameras themselves. This research highlights the inherent risks in complex, proprietary protocols, even when seemingly secured with encryption and authentication.

Moshe's research focused on uncovering new attack surfaces within the internal networks of large organizations. By targeting Axis's widely deployed management infrastructure—found in major companies, educational institutions, medical facilities, and government agencies—the findings demonstrate how a single vulnerability can compromise extensive surveillance systems. The ability to execute arbitrary code on these central servers and cameras grants attackers not only full visibility into an organization's premises but also the capacity to manipulate or disable surveillance feeds, enabling "James Bond styled" interference with critical security operations.

The implications of these vulnerabilities are far-reaching. Axis is a dominant vendor in the enterprise IP camera market, and the exposed services identified globally underscore a significant attack surface. Moshe's work serves as a stark reminder that robust security requires continuous scrutiny of all components, including seemingly secure proprietary protocols. The responsible disclosure process with Axis Communications, leading to timely patches, demonstrates the positive impact of ethical hacking in strengthening global cybersecurity postures.

Background

▶ Watch: Research goal: Hacking into internal networks (1:20)

Axis Communications is a leading manufacturer of IP cameras, widely recognized for its enterprise-grade solutions. These cameras are ubiquitous in large-scale deployments, including corporate campuses, educational facilities, healthcare providers, and government agencies. A key characteristic of Axis cameras is their reliance on Axis OS, a custom, heavily modified Linux fork, which provides a robust but proprietary operating environment.

The challenge for organizations deploying dozens or even thousands of Axis cameras across multiple physical locations, offices, and floors lies in efficient management and monitoring. To address this, Axis developed centralized solutions:

• Axis Device Manager: A server-side application designed for comprehensive management, configuration, backup, and firmware upgrades of an entire fleet of Axis cameras from a single interface.
• Axis Camera Station: Another server-side application that provides a centralized platform for security personnel to view live camera feeds, often displayed in a matrix format in guard stations.

A critical requirement for many organizations is remote access to these management and viewing servers. Companies often have geographically dispersed sites, and administrators or security personnel need to monitor and manage cameras remotely. To facilitate this, Axis developed a proprietary communication protocol known as Axis Remoting. This protocol was designed to be "fully encrypted, fully authenticated, and fully secure," instructing users to simply open a specific port to enable remote connections. While Axis also offers a cloud-based solution, Axis Secure Access, its high cost (pay-per-traffic model) leads many organizations to opt for on-premise installations of Device Manager and Camera Station, exposing these services directly to the internet.

Moshe's initial research began by querying public internet scanning services like Shodan and Censys, searching for internet-exposed services associated with target companies. Among the usual suspects like VPNs and file-sharing services, he discovered "Axis Remoting," a service he was previously unaware of. This discovery prompted a deep dive into the protocol to uncover potential vulnerabilities and identify new attack surfaces on these devices, with the ultimate goal of achieving remote code execution on the management servers.

Key Findings

▶ Watch: Axis Device Manager for centralized camera control (3:00)

Noam Moshe's research uncovered a series of critical vulnerabilities in Axis Communications' enterprise camera management solutions, leading to two primary, high-impact findings:

1. Authenticated Remote Code Execution (RCE) via Deserialization Vulnerability: The core Axis Remoting protocol, used by both Axis Device Manager and Axis Camera Station, was found to be susceptible to a .NET deserialization vulnerability. This flaw allowed an attacker, after successfully authenticating (or bypassing authentication via a Man-in-the-Middle attack), to execute arbitrary code on the Axis management server. Crucially, once the server was compromised, the attacker could leverage legitimate Axis features, specifically the Axis AAP SDK for creating custom camera packages, to deploy malicious code onto the connected IP cameras, thus achieving RCE across the entire surveillance infrastructure. This initial finding required a man-in-the-middle (MITM) scenario to bypass authentication.

1. Pre-Authentication RCE through Fallback Protocol and Anonymous Endpoint: A more severe discovery was a second, pre-authenticated RCE vector. Axis implemented a "fallback protocol" designed for scenarios where the primary TCP port was inaccessible. This fallback, described as "HTTP with AES encryption," contained the same underlying deserialization vulnerability. Critically, Moshe discovered a "super secret endpoint," /ore, within this fallback protocol that supported anonymous authentication. This meant an attacker could initiate a connection, establish an encrypted channel, and then exploit the deserialization vulnerability without any prior authentication or user interaction, achieving RCE on the server and subsequent lateral movement to cameras with full pre-authentication capabilities.

The widespread impact of these findings was significant. Moshe identified approximately 6,500 internet-exposed Axis servers globally, predominantly in the United States, using tools like Censys. Given that a single Axis server can manage up to 10,000 cameras, the potential scale of compromise was vast. The exposed servers were found in numerous educational institutions, government agencies, medical facilities, and large corporations. The research also revealed that the use of NTLM SSP in the primary protocol exposed server hostnames and domain names, providing valuable targeting information for attackers. The vulnerabilities were responsibly disclosed to Axis, who promptly developed and released patches to secure their customer base.

Technical Deep Dive

▶ Watch: Overview of the "secure" Axis Remoting protocol (4:15)

The technical investigation began with understanding the architecture of Axis Device Manager and Camera Station. Both are Windows native applications with distinct client and server components, all written in .NET. This detail was crucial as it hinted at common .NET security patterns and potential vulnerabilities.

The primary communication protocol, Axis Remoting, was wrapped with MTLS (Mutual TLS), meaning both the client and server needed valid TLS certificates, providing strong encryption and endpoint authentication. After the MTLS handshake, the protocol immediately required NTLM SSP authentication. A significant discovery here was that during the NLM SSP challenge-response, the server inadvertently exposed its hostname and domain name, providing valuable reconnaissance information to potential attackers.

Once authenticated, the core of Axis Remoting was revealed to be a JSON-based RPC (Remote Procedure Call) protocol. Clients would send JSON payloads to invoke specific methods on the server's backend. Moshe discovered that Axis utilized Service Contracts, a standard .NET mechanism for exposing server-side classes and methods for remote invocation. While simple primitive types (strings, integers) are straightforward, issues arise with more complex argument types, such as the ClientInformationDTO class observed in the LogOnAsync function.

The critical vulnerability stemmed from how these complex objects were handled. To instantiate ClientInformationDTO on the server, JSON deserialization had to occur. Axis was found to be using JSON.NET (a popular .NET JSON library) with the dangerous configuration TypeNameHandling.Auto. This setting instructs the deserializer to allow the client to specify the exact .NET type to be created on the server's backend by including a "$type" field in the JSON payload. This is a well-known anti-pattern in .NET security, as it enables an attacker to instantiate arbitrary classes on the server and trigger gadget chains—sequences of method calls within available libraries that ultimately lead to remote code execution. An example payload would include "$type": "Windows.ClientAPI.Class" to attempt to create a specific object.

While this established an RCE vulnerability, it was initially post-authentication. To achieve authenticated RCE, Moshe devised a Man-in-the-Middle (MITM) strategy. By positioning a malicious server between a legitimate Axis client and server, he could intercept the NLM SSP challenge-response. Leveraging the fact that Axis Remoting lacked message signing, the MITM server could perform a pass-the-hash (or more accurately, pass-the-challenge-response) attack to authenticate the legitimate client to the real Axis server. Once the authenticated session was established, the MITM server would then inject a malicious deserialization payload, crafted using tools like serial.net, into the client's communication stream, triggering RCE on the Axis server. The same technique could be applied in reverse to achieve RCE on the client application by having the compromised server send a malicious payload back.

After gaining RCE on the Axis server, the next step was lateral movement to the cameras. Axis cameras support packages, which are modular applications that can extend or modify camera behavior. Axis provides the Axis AAP SDK (a C++ SDK) for developers to create custom packages. By leveraging the RCE on the server, an attacker could compile a malicious backdoor package (e.g., using Docker for cross-compilation), sign it with their own key, and then use the compromised server's legitimate administrative functions to upload and execute this package on any connected cameras. This completed the chain, providing RCE on the client, the server, and the entire fleet of managed cameras.

The ultimate goal was pre-authentication RCE. Moshe discovered a fallback protocol mentioned in Axis documentation, designed for situations where the main TCP port was inaccessible. This protocol operated on a different port and was described vaguely as "HTTP with AES encryption." Initial attempts to access it with a browser resulted in a login prompt and a non-functional white screen, indicating it was not standard HTTP. Reverse engineering revealed a custom HTTP-like protocol:

1. The client sends an HTTP GET / request to the server, which responds with a channel ID.
2. The client then opens a new connection and sends HTTP GET /<channel_ID>. This establishes two distinct channels: a TX (transmit) channel and an RX (receive) channel, despite TCP sockets being inherently bidirectional.
3. A key exchange then occurs:

• Each side sends its public key.
• Each side generates a random AES key.
• Each side encrypts its AES key with the other side's public key and transmits it.
• Both endpoints now possess a shared AES key, establishing an encrypted channel.

1. Crucially, once this secure channel is established, the communication reverts to the same Axis Remoting JSON-based RPC protocol with the infamous deserialization vulnerability.

The final piece of the pre-authentication puzzle was bypassing the initial authentication. The main web server's fallback protocol used Negotiate authentication (Kerberos or NLM SSP). However, Moshe discovered a deeply hidden, "super secret endpoint" at /ore. For reasons unknown, this specific path supported anonymous authentication. By targeting /ore and then implementing the custom HTTP/AES channel communication, an attacker could establish an unauthenticated, encrypted channel and immediately exploit the deserialization vulnerability, achieving full pre-authentication RCE on the Axis server, and subsequently, on all managed cameras.

Demo / Proof of Concept

▶ Watch: Methodology for analyzing proprietary protocol (MITM) (6:40)

While the talk did not feature a live, real-time demonstration during the presentation, Noam Moshe meticulously detailed the complete exploitation chain, implying a robust proof-of-concept (PoC) was developed and tested as part of the research. The description of the attack vectors served as a conceptual walkthrough of the PoC, illustrating how an attacker could move from initial network discovery to full system compromise.

The PoC would involve:

1. Network Scanning: Identifying internet-exposed Axis Remoting services using tools like Censys.
2. NTLM SSP Hostname Extraction: Developing a basic client to connect to the primary Axis Remoting port, capture the NLM SSP challenge, and extract the hostname and domain name for targeting purposes.
3. Man-in-the-Middle Setup (for Authenticated RCE): A custom MITM proxy that intercepts Axis Remoting traffic, performs the NLM SSP pass-the-hash authentication, and injects a malicious deserialization payload. The payload would be generated using serial.net to craft a .NET object that triggers RCE upon deserialization.
4. Malicious Camera Package Creation: Using the Axis AAP SDK, compiling a C++-based backdoor package that would execute arbitrary commands or maintain persistence on the camera. This would likely involve using a Docker container for the specific cross-compilation environment.
5. Server-to-Camera Lateral Movement: Once RCE is achieved on the Axis server, the PoC would demonstrate using the server's legitimate APIs to upload and activate the malicious package on a target camera.
6. Pre-authentication Fallback Protocol Exploitation: Implementing a custom client for the fallback protocol, which would:

• Connect to the /ore endpoint to bypass authentication.
• Perform the custom HTTP/AES key exchange to establish an encrypted channel.
• Send the same malicious deserialization payload over this newly established channel, achieving RCE on the server without any prior authentication.

These steps, described in detail throughout the presentation, form a comprehensive blueprint for the exploitation, confirming the feasibility and impact of the discovered vulnerabilities.

Defensive Implications

▶ Watch: MTLS, User-Agent, and NTLM in protocol handshake (7:30)

The vulnerabilities uncovered in Axis Remoting and its fallback protocols highlight several critical areas for defenders to address to secure their IP camera infrastructure:

1. Immediate Patching: The most crucial action is to apply the patches released by Axis Communications as a result of Noam Moshe's responsible disclosure. These patches directly address the deserialization vulnerabilities and potentially other related issues. Organizations should ensure their Axis Device Manager and Axis Camera Station installations are fully up-to-date.

1. Network Segmentation and Isolation: Axis management servers (Device Manager, Camera Station) should never be directly exposed to the internet. They should be placed in a highly restricted network segment, ideally behind a firewall that only permits access from trusted administrative workstations via a secure VPN. Limiting network access to the absolute minimum necessary is paramount.

1. Review Remote Access Policies: If remote access to Axis management solutions is essential, organizations should re-evaluate their methods. Relying solely on a proprietary protocol, even if advertised as "secure," carries inherent risks. Secure VPN solutions with strong multi-factor authentication (MFA) should be the primary method for remote administrative access, rather than directly exposing the Axis Remoting or fallback protocol ports.

1. Strong Authentication Practices: While the pre-authentication RCE bypasses authentication entirely, for scenarios where authentication is still required (e.g., the primary Axis Remoting channel), organizations should enforce strong password policies and consider directory service integration (e.g., Active Directory) with robust security configurations. Avoid exposing NLM SSP directly to the internet if more secure authentication mechanisms like Kerberos or modern OAuth-based systems are available through a secure gateway.

1. Input Validation and Secure Deserialization: For developers and architects of .NET applications, this research serves as a critical warning: avoid TypeNameHandling.Auto in JSON.NET or similar configurations in other deserialization frameworks. Always implement strict input validation and use secure deserialization practices (e.g., whitelisting allowed types, using binary serialization only with trusted data, or avoiding deserialization of untrusted input entirely).

1. Monitoring and Alerting: Organizations should implement robust network monitoring to detect unusual traffic patterns on Axis Remoting ports (both primary and fallback). Look for suspicious JSON payloads, attempts to connect to the /ore endpoint, or any unexpected package deployments to cameras. Anomalous login attempts or administrative actions should trigger immediate alerts.

1. Supply Chain Security for Camera Packages: Given the ability to deploy malicious packages to cameras, organizations should strictly control what packages are installed. Only trusted, signed packages from official sources should be permitted. Any custom packages developed internally should undergo rigorous security review and testing.

1. Asset Inventory and Exposure Management: Regularly audit internet-facing assets using tools like Shodan or Censys to identify unintentionally exposed services, including Axis Remoting. Understanding an organization's external attack surface is the first step in defending it.

By implementing these defensive measures, organizations can significantly reduce their exposure to similar vulnerabilities and enhance the overall security posture of their critical surveillance infrastructure.

Key Takeaways

• Proprietary Protocols Are Not Inherently Secure: Axis Remoting, despite being proprietary and utilizing MTLS and custom AES encryption, contained critical vulnerabilities, demonstrating that obscurity or custom security layers do not equate to actual security.
• Deserialization Vulnerabilities Remain a Major Threat: The TypeNameHandling.Auto setting in .NET JSON deserialization (specifically JSON.NET) is a dangerous configuration that can easily lead to pre-authenticated Remote Code Execution when processing untrusted input.
• Fallback Mechanisms and Hidden Endpoints Can Undermine Core Security: The discovery of a fallback protocol with an anonymous authentication endpoint (/ore) bypassed the primary protocol's security requirements, showcasing how seemingly minor or obscure features can open critical attack paths.
• Centralized Management Systems are High-Value Targets: Compromising a central management server like Axis Device Manager provides a single point of failure that can lead to full control over an entire fleet of connected devices, including the ability to deploy malicious code to individual cameras.
• Information Leakage Aids Attackers: The exposure of server hostnames and domain names during the NLM SSP handshake provided valuable reconnaissance for attackers to identify and target specific organizations.
• Responsible Disclosure is Essential for Security Improvement: The successful collaboration between Noam Moshe and Axis Communications, leading to timely patches, underscores the importance of ethical hacking and responsible vulnerability disclosure in enhancing product security for all users.

About the Speaker(s)

Noam Moshe is a Team Lead and Lead Vulnerability Researcher at Clarity. His professional focus, which he describes as "one of the coolest" jobs, involves identifying vulnerabilities in a diverse range of devices. This includes operational technology (OT) such as PLCs and HMIs, medical devices like DNA sequencers and patient monitors, and, his personal favorite, IoT devices. Moshe's work involves setting up extensive labs, which he refers to as his "playground," to connect, analyze, and responsibly disclose security flaws to vendors. His expertise in reverse engineering proprietary protocols and uncovering deep-seated vulnerabilities was clearly demonstrated in his DEF CON talk on Axis camera surveillance.