Untangle: Multi-Layer Web Server Fingerprinting

Untangle: Multi-Layer Web Server Fingerprinting

Speakers: Cem Topcuoglu

Conference: NDSS Symposium

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

Overview

In the modern web landscape, sophisticated web applications are rarely deployed as monolithic, single-server entities. Instead, they commonly reside behind complex, multi-layered architectures comprising Content Delivery Networks (CDNs), reverse proxies, and various cloud services. This architectural evolution, while enhancing performance and security, has rendered traditional web server fingerprinting tools largely ineffective. These legacy tools, designed to inspect HTTP responses for characteristic strings and server quirks, are fundamentally blind to the intricate processing and transformations occurring across multiple intermediaries. This talk, "Untangle: Multi-Layer Web Server Fingerprinting," presented by Cem Topcuoglu at the NDSS Symposium, addresses this critical gap by introducing a novel methodology and a prototype tool, Untangle, capable of accurately identifying both the server technologies involved in a layered chain and their correct ordering.

The inability of existing tools to discern these layered infrastructures poses a significant challenge for security professionals, particularly in the face of surging systems-centric web application attacks. Exploits like HTTP request smuggling, web cache poisoning, and HTTP/2 protocol downgrade exploits fundamentally leverage HTTP processing discrepancies between different servers in a layered chain. Without accurate visibility into these layers, defenders struggle to understand their attack surface, manage assets effectively, and implement targeted defenses. Untangle provides a groundbreaking solution by capitalizing on the very same discrepancies that enable these attacks, offering a generic and extendable approach to multi-layer fingerprinting.

The core contributions of this work are three-fold: the proposal of the first methodology in literature to fingerprint multi-layer web servers by exploiting HTTP processing discrepancies; the implementation of Untangle, a prototype that uses HTTP fuzzing to discover these discrepancies; and a comprehensive evaluation demonstrating its viability and effectiveness across 3-layer permutations of 13 popular proxy and server technologies. This research marks a pivotal step towards enhancing situational awareness and bolstering defenses against complex web application threats in the contemporary Internet.

Background

▶ Watch: Introduction to Untangle: multi-layer web server fingerprinting challenge (0:00)

The evolution of web architecture, driven by the demand for performance, scalability, and security, has led to the widespread adoption of reverse proxies, CDNs, and various middleboxes. A typical client request today traverses multiple HTTP processors—from a CDN, through cloud services, and potentially several internal proxies—before reaching the origin server. While this complexity is essential for delivering robust web services, it has simultaneously introduced a new class of security vulnerabilities known as discrepancy attacks. These attacks arise when two or more servers in the traffic path process the same HTTP message in different, often exploitable, ways.

Historical and contemporary examples of discrepancy attacks abound. Web Cache Deception exploits path confusion between caching servers and origins to leak confidential data. Cache poisoning attacks leverage processing discrepancies to inject malicious payloads into caches. HTTP Request Smuggling (HRS), first documented in 2005 and now experiencing a resurgence, abuses HTTP message boundary confusion to smuggle hidden requests, often leading to unauthorized access or command execution. More recently, HTTP/2-to-HTTP/1 protocol conversions performed by middle processors have been shown to create discrepancies that can be similarly exploited. These incidents underscore a crucial point: discrepancy attacks are not merely isolated bugs but rather systemic safety problems stemming from hazardous interactions between diverse technologies. Consequently, robust asset management that accurately tracks and tests all servers in a deployment is paramount for system owners.

In contrast to this modern challenge, traditional web server fingerprinting has been a routine security practice for over two decades. Tools like Nmap, Nessus, httprint, and httprecon have long provided capabilities for automated asset discovery, vulnerability tracking, and reconnaissance. These tools typically operate by sending a mix of valid and invalid requests to a target and then analyzing the responses for characteristic server traits, such as unique error messages, specific header ordering, or easily identifiable banner grabbing from the Server header. In fact, RFC 9110, the HTTP specification, even advises against overly detailed Server headers precisely to mitigate the risk of attackers exploiting known vulnerabilities. While simple obfuscation techniques can sometimes thwart these tools, their fundamental limitation in multi-layered environments is far more profound, as they are designed to detect a single server, not a chain of them.

The methodology behind Untangle draws inspiration from fuzzing, a well-established software testing technique for revealing defects by generating malformed or unexpected inputs. A particularly relevant variation is differential fuzzing, where identical inputs are sent to multiple systems to observe and compare their behavioral discrepancies. In the security domain, differential fuzzing has been instrumental in uncovering bugs in JavaScript engines, detecting DPI evasion techniques, and identifying semantic bugs in various software. More directly applicable to Untangle's work, recent research has leveraged differential fuzzing to pinpoint HTTP parsing discrepancies. Notable examples include T-Reqs, a grammar-based HTTP fuzzer used to find HTTP Request Smuggling vulnerabilities, and HDiff, which focuses on Host header confusion and cache poisoning. Untangle extends this concept, employing differential fuzzing to systematically build a comprehensive behavior repository that captures the distinct HTTP processing behaviors of various servers, forming the bedrock of its multi-layer fingerprinting capability.

Key Findings

▶ Watch: Understanding discrepancy attacks: web cache poisoning, request smuggling (2:00)

The core finding of the Untangle research is a definitive "Yes" to its overarching research question: it is possible to detect multi-layer web servers by utilizing HTTP parsing discrepancies. This addresses a critical limitation in current security tooling, which fails to provide visibility into the complex, layered architectures prevalent in the modern Internet.

Specifically, the key findings and contributions include:

• First Multi-Layer Fingerprinting Methodology: Untangle introduces the first methodology capable of fingerprinting multi-layer web servers by systematically leveraging HTTP processing discrepancies. This approach is generic, theoretically extendable to any number of layers and server technologies, and practical in real-world scenarios.
• High Accuracy for Layered Architectures: Through extensive evaluation on 756 unique 3-layer permutations of 13 popular server technologies, Untangle achieved remarkable accuracy. In its canonical configuration, it correctly identified all servers in the first layer (100%), 90.3% in the second layer, and 50.7% in the final, third layer, often providing partial but still valuable fingerprints for the remaining cases.
• Significant Outperformance of Traditional Tools: Untangle demonstrably outperforms traditional network scanners like Nmap. For single-server fingerprinting, Untangle identified all 13 tested servers without misclassification, whereas Nmap identified only 9 and misclassified one. More crucially, in multi-layer scenarios, Nmap struggled significantly, detecting Layer 1 in only 59.6% of cases, Layer 2 in 5.9%, and Layer 3 in a mere 4.5%, with a high rate of misclassifications and no detections. Untangle provides a viable solution where Nmap fails.
• Viable and Effective Discrepancy Discovery: The research showed that HTTP fuzzing is highly effective at discovering processing discrepancies. Across 13 server technologies, fuzzing triggered discrepancies in 142 out of 144 possible server pairings and revealed 37 unique behaviors. This demonstrates that a rich behavior repository can be built efficiently (in less than 6 days on a commodity machine), making the approach practical for ongoing maintenance.
• Real-World Applicability: Testing Untangle against 7528 real-world web deployments from the Tranco top 10K domains confirmed its practical efficacy. While ground truth was unavailable, comparisons with Nmap and manual analysis of disagreements indicated that Untangle was more often correct and significantly more efficient (median runtime of 3.79 seconds vs. Nmap's 19.74 seconds, with a median of 4 requests vs. Nmap's many more).
• Actionable Security Intelligence: Even partial fingerprints provided by Untangle offer valuable and actionable information, enabling security professionals to better understand their attack surface and defend against complex discrepancy attacks.

These findings collectively establish Untangle as a crucial advancement in web security, providing unparalleled visibility into the hidden layers of modern web infrastructures.

Technical Deep Dive

▶ Watch: Limitations of traditional web server fingerprinting tools (3:00)

Untangle's methodology is rooted in the hypothesis that if web servers exhibit measurable HTTP request processing discrepancies, then carefully crafted requests can elicit distinct responses that leak information about the servers and their ordering in a layered chain. The system operates on the assumption of a pre-built behavior repository that provides two key functions: Behavior(request, server), which indicates whether a server responds with an Error, Pass (forwards unchanged), or Other (modifies/processes successfully), and Match(response), which maps an error response to a unique server technology or Unknown.

The fingerprinting process unfolds in three distinct phases:

Phase 1: Fingerprint In Order

This phase aims to iteratively identify each layer in sequence, starting from the client-facing server. An empty Ordered list is maintained. For each layer, Untangle searches for a specific probe request that satisfies two strict conditions:

1. For all servers not yet in Ordered, Behavior(request, s) must be Error.
2. For all servers already in Ordered, Behavior(request, s) must be Pass.

When such a request is found, it is sent to the target infrastructure. The expectation is an error response from the first undetected layer. The Match(response) function then identifies the server technology, which is appended to the Ordered list. This process repeats until all layers are detected or one of the termination conditions is met: either no suitable request can be found, Match identifies the next server as Unknown, or a success response is received, indicating no more error-generating layers. In an ideal scenario with a complete repository, Phase 1 yields a full, accurate sequence of servers.

Phase 2: Fingerprint Without Order

Recognizing that the behavior repository might be incomplete in practice, Phase 2 relaxes the probe selection requirements to identify server technologies present, even if their order cannot yet be determined. Building upon the Ordered list from Phase 1, an empty Unordered set is initialized. Probes are crafted such that:

1. For all servers not yet in Ordered, Behavior(request, s) is either Error or Pass.
2. For all servers already in Ordered, Behavior(request, s) is Pass.

These probes are designed to trigger error responses from any subsequent unidentified servers. The Match(response) function is used to identify these server technologies, which are then added to the Unordered set. If Match fails, Unknown is added. This phase concludes after all qualifying requests have been used.

Phase 3: Refining The Ordering

The final phase aims to establish the correct sequence of servers identified in the Unordered set, moving them to the Ordered list. This is achieved by sending probes where:

1. For all servers already in Ordered, Behavior(request, s) is Pass.
2. For all servers currently in Unordered, Behavior(request, s) is Error.

This ensures that an error response will be generated by the server closest to the client among those remaining in Unordered. The response is analyzed and matched, the identified server is moved to Ordered, and the process repeats. This phase terminates if the Unordered set contains Unknown (as its behavior cannot be predicted), no suitable probe request can be found, or only one server remains in Unordered (its order then being implicitly determined). Even if a full fingerprint isn't achieved, a partial fingerprint provides valuable insights that no prior technique could offer.

System Design and Implementation (Untangle)

The practical implementation of Untangle hinges on the automated construction of its behavior repository. This repository, capturing Error and Pass behaviors along with distinct error responses for each server, is built using differential fuzzing. Untangle's fuzzer extends T-Reqs, a grammar-based HTTP fuzzer, to generate requests specifically designed to reveal processing discrepancies.

The research focused on 13 popular technologies for experimentation, encompassing 4 CDNs (Akamai, Cloudflare, CloudFront, Fastly) and 9 standalone servers (NGINX, Varnish, HAProxy, Apache, Caddy, Envoy, ATS, Squid, Tomcat). The experimental setup involved deploying each server in proxy mode in front of an origin server that simply echoed proxied requests, providing essential feedback. Tomcat was the sole exception, lacking a proxy mode, and was thus always positioned as the origin.

Three main fuzzing experiments were conducted to generate a diverse set of discrepancy-triggering requests:

1. Request Line Mutations: This involved mutating method names (40 variations), URIs (8 variations), and protocol symbols, with up to two character mutations. The Content-Length header value and request body were also diversified.
2. Header Mutations: One to two standard (66-pool) or non-standard (1142-pool) headers were randomly inserted, with zero to two character mutations applied. Content-Length and body were again diversified.
3. Body Mutations: For POST requests, headers influencing body parsing, such as Content-Length and Transfer-Encoding, were fuzzed, along with the Trailer header. Both chunked and regular bodies were used.

In total, these experiments generated an impressive 4,280,839 unique requests. After collecting responses and proxied requests from the 13 servers, their behaviors were categorized:

• Error: Server returned an error response, indicating a processing issue.
• Pass: Request was successfully processed and proxied without modification to mutated sections.
• Other: All other behaviors, including modified proxied requests, timeouts, HTTP 0.9 responses, and zero-byte responses, were grouped here as irrelevant for fingerprinting.

The fuzzing efforts proved highly successful, triggering discrepancies in 142 out of 144 possible server pairings (e.g., only Envoy-Fastly and Apache-Caddy showed no discrepancies) and identifying 37 unique behaviors across all server combinations. This rich repository was built in less than 6 days on a single commodity machine, validating the feasibility of periodic updates.

Error-to-Server Matching

A critical aspect of Untangle's implementation is its robust strategy for matching observed error responses to known server technologies. To ensure resilience against common server cloaking practices, the system deliberately avoids relying solely on rigid signatures like the Server header. Instead, it employs a flexible response similarity metric.

Untangle transforms response messages into a set of tokens and computes a Jaccard similarity score, quantifying the overlap between tokens in a probe response and those in known repository responses. The probed layer is then labeled with the server technology corresponding to the highest similarity score in the repository. The researchers experimented with two ways to compute similarity: over the entire response, and separately over the full response, error code, and body data. Exploratory work revealed that higher weighting of error codes and response bodies yielded more accurate matches, as these components are most indicative of processing discrepancies.

To further enhance detection, this similarity score is supplemented with checks for a small number of fixed strings, particularly CDN-specific response headers such as CF-Cache-Status for Cloudflare, X-Amz-Cf-Pop for CloudFront, and X-Served-By for Fastly. Critically, the commonly removed Server header is explicitly avoided.

Finally, two matching strategies were considered:

1. Best match: Always selects the highest similarity score, meaning an Unknown classification is not possible. This simplifies the methodology but risks mislabeling truly unknown servers.
2. Similarity threshold: Classifies a server as Unknown if its similarity score falls below a predefined threshold. This is crucial for real-world scenarios where Untangle might encounter technologies not in its repository. This threshold (empirically determined to be 1.82) is a key parameter for the system's robust operation.

Demo / Proof of Concept

▶ Watch: Untangle's methodology: behavior repository and three phases (4:20)

While the talk did not feature a live, interactive demo in the traditional sense, the extensive "Evaluation and Results" section serves as a comprehensive proof of concept, demonstrating Untangle's capabilities in both controlled test environments and real-world deployments.

The evaluation was conducted in a meticulously controlled test setup designed to replicate realistic multi-layer topologies. The conditions for these experiments were:

• Three layers were always used.
• CDNs were invariably placed before standalone servers.
• The last layer was never a CDN.
• No multiple instances of the same server were used.
• Tomcat, due to its lack of proxy mode, was always used as the last layer.

Under these conditions, 756 unique fingerprinting experiments were executed, covering all practicable 3-layer permutations of the 13 server technologies. Untangle operated with no prior knowledge of the target infrastructure beyond a domain name. Results were categorized into Full fingerprint (all 3 layers correctly identified and ordered), Partial fingerprint (first n layers identified and ordered, with remaining layers identified but unordered or Unknown), and Misclassification (at least one layer incorrectly identified).

Experiment A: Phase 1 Only (Basic Similarity)

This initial experiment used only Phase 1 of the methodology with a basic similarity metric (over the entire response, no static header checks, no threshold). It yielded a Full fingerprint in 38 cases (5.0%), Partial fingerprint in 680 cases (90.0%), and Misclassification in 38 cases (5.0%). Layer 1 detection was 100%, Layer 2 was 50.5%, and Layer 3 was 5.0%. Manual analysis attributed misclassifications to the basic similarity metric missing subtle response differences.

Experiment B: Phase 1 Only (Refined Similarity)

By enabling the refined similarity approach (separate scores for response components, static CDN header checks), but still only using Phase 1, misclassifications were entirely eliminated. This experiment achieved Full fingerprints in 43 cases (5.7%) and Partial fingerprints in 713 cases (94.3%), with 0.0% misclassification. Layer 1 detection remained 100%, Layer 2 improved to 55.5%, and Layer 3 to 5.7%. This demonstrated the effectiveness of the refined similarity metric.

Experiment C: All Phases (Refined Similarity)

The full methodology (Phases 1, 2, and 3) with refined similarity dramatically improved results. Full fingerprints jumped to 390 cases (51.6%), with 363 cases (48.0%) as Partial fingerprints and only 3 cases (0.4%) of Misclassification. Layer 1 detection remained 100%, Layer 2 significantly improved to 90.3%, and Layer 3 reached 51.6%. This clearly showed the power of Phases 2 and 3 in boosting detection for deeper layers.

Experiment D: All Phases (Refined Similarity, with Threshold)

This experiment, representing Untangle's canonical configuration, introduced a similarity score threshold (empirically determined as 1.82) to enable Unknown classifications. It resulted in 383 Full fingerprints (50.7%), 370 Partial fingerprints (48.9%), and 3 Misclassifications (0.4%). Layer 1 detection was 100%, Layer 2 was 90.3%, and Layer 3 was 50.7%. The slight decrease in Layer 3 accuracy compared to Experiment C was deemed an acceptable trade-off for the crucial ability to classify unknown servers.

Untangle Versus Nmap

A direct comparison with Nmap, a widely used network scanner, highlighted Untangle's superior capabilities.

• Single Server Fingerprinting: Against the 13 servers in isolation, Untangle detected all 13 without misclassification. Nmap identified 9, failed to identify Envoy, HAProxy, or Varnish, and misclassified Fastly as Varnish. This demonstrated Untangle outperforms Nmap for single server fingerprinting.
• Multi-Layer Fingerprinting: In the 3-layer setup (756 permutations), Nmap's performance was severely limited. It detected Layer 1 in only 450 cases (59.6%), Layer 2 in 45 cases (5.9%), and Layer 3 in 34 cases (4.5%). It also had 73 misclassifications (9.6%) and 154 cases (20.4%) with no detection. Manual analysis confirmed Nmap's confusion by layering, often failing to detect servers it could identify in isolation. This conclusively showed that traditional tools like Nmap do not function correctly against multi-layer infrastructures, while Untangle provides a viable solution.

Testing In The Wild

Finally, Untangle was tested against 7528 real-world web deployments from the Tranco top 10K domains (October 2023), after filtering for functional targets. While ground truth was unavailable, the goal was to assess practical implications.

• Untangle fingerprinted 6360 targets to one of its 13 known servers.
• Nmap fingerprinted 5877 targets.
• The tools agreed on 4984 cases (66.2%), mapping to the same server.
• In cases of disagreement, manual analysis of samples revealed that Untangle was more often correct (57.4%) than Nmap (19.5%) when Untangle identified a known server and Nmap identified something different or unknown. Conversely, when Nmap identified one of the 13 servers and Untangle detected Unknown, Nmap was correct in 44.2% of cases, while Untangle was correct in 48.5%. Untangle's errors were primarily due to heavily customized error responses or unknown servers returning highly similar errors. Nmap's errors were often due to server cloaking.
• Performance: Untangle demonstrated significantly higher efficiency with a median runtime of 3.79 seconds and a median of 4 requests issued, compared to Nmap's median runtime of 19.74 seconds.

These results unequivocally prove that Untangle is effective in practice, capable of handling server version and configuration diversity, and offers a more efficient and accurate solution than traditional tools for multi-layer web server fingerprinting in real-world scenarios.

Defensive Implications

▶ Watch: Phase 1: Iteratively identifying each server layer in sequence (4:50)

Untangle provides critical capabilities for security professionals defending against modern web application attacks, particularly those exploiting HTTP processing discrepancies in multi-layered architectures.

1. Enhanced Asset Management: For organizations leveraging complex infrastructures involving CDNs, reverse proxies, and cloud services, Untangle offers an unprecedented level of visibility. It enables security teams to accurately identify all server technologies in their deployment chain and their precise ordering. This is fundamental for robust asset management, moving beyond simply knowing the client-facing server to understanding the entire processing pipeline.
2. Targeted Vulnerability Management: By identifying specific server technologies and their interactions, Untangle empowers defenders to conduct more targeted vulnerability assessments. Knowing the exact sequence of, for example, a Cloudflare CDN, an NGINX reverse proxy, and an Apache origin server allows security teams to prioritize testing for known vulnerabilities or misconfigurations specific to that combination, rather than generic scans. This is particularly crucial for identifying potential weak points susceptible to discrepancy attacks.
3. Defense Against Discrepancy Attacks: The research highlights that attacks like HTTP Request Smuggling (HRS), web cache poisoning, and HTTP/2 downgrade exploits thrive on processing discrepancies between layered servers. Untangle directly counters this by revealing the very information attackers seek to exploit. Defenders can use Untangle to map their attack surface and proactively test for these discrepancies within their own infrastructure, ensuring consistent HTTP message processing across all layers.
4. Configuration Verification and Anomaly Detection: Untangle can be used to verify that web server configurations align with intended architectural designs. Deviations, such as the presence of an unexpected proxy layer or an incorrect ordering, could indicate misconfigurations, unauthorized deployments, or even active compromise. This enables security teams to detect anomalies and maintain architectural integrity.
5. Improved Incident Response: In the event of an attack, accurately knowing the server technologies and their order can significantly expedite incident response. It helps pinpoint which specific layer might be vulnerable or compromised, guiding forensic analysis and remediation efforts more efficiently.
6. Informed Security Tooling: The detailed fingerprints provided by Untangle can inform and improve other security tools. For instance, Web Application Firewalls (WAFs) or intrusion detection systems (IDS) could leverage this precise architectural knowledge to apply more context-aware rules and better detect sophisticated attacks.

In essence, Untangle transforms a blind spot into a source of actionable intelligence, enabling defenders to move from reactive mitigation to proactive defense against the complex threats posed by multi-layered web infrastructures.

Key Takeaways

• Traditional web server fingerprinting tools are fundamentally ineffective in modern multi-layered architectures, leaving security professionals with significant blind spots.
• HTTP processing discrepancies between layered servers are a prevalent phenomenon and the root cause of critical web application attacks like HTTP Request Smuggling and web cache poisoning.
• Untangle introduces the first methodology capable of accurately identifying both the server technologies and their precise ordering within a multi-layer web infrastructure by leveraging these very HTTP processing discrepancies.
• The methodology employs differential fuzzing to build a comprehensive behavior repository of server responses, which is then used in a three-phase iterative process to fingerprint layers in order, without order, and finally refine the ordering.
• Untangle significantly outperforms traditional tools like Nmap in both single-server and, crucially, multi-layer fingerprinting scenarios, demonstrating high accuracy (50.7% full fingerprint for 3-layer systems) and efficiency in real-world deployments.
• This novel approach provides critical situational awareness, enabling defenders to enhance asset management, conduct targeted vulnerability assessments, and proactively defend against complex, systems-centric web application attacks.

About the Speaker(s)

Cem Topcuoglu is the presenter of the "Untangle: Multi-Layer Web Server Fingerprinting" talk at the NDSS Symposium. Based on the content of the presentation, he is a researcher deeply involved in the development and evaluation of the Untangle methodology and its prototype tool. His work focuses on addressing the challenges of identifying and securing complex, multi-layered web server infrastructures, particularly in the context of HTTP processing discrepancies and modern web application attacks.