DEF CON 33 Recon Village - A Playbook for Integration Servers - Ryan Bonner, Guðmundur Karlsson

Title: Plumbing the Plumber: Attacking and Securing Enterprise Integration Servers

Introduction

In the world of cybersecurity, we often focus on the shiny new layers of the technology stack—the React frontends, the serverless functions, and the Kubernetes clusters. However, beneath these modern abstractions lies the 'plumbing' of the corporate world: Integration Servers. These middleware giants, like WebMethods, have been quietly connecting mainframes to Salesforce instances for nearly 30 years. Because this infrastructure is often viewed as legacy or 'boring,' it has escaped the rigorous scrutiny applied to other web technologies. In this post, we’ll explore the research presented at DEF CON 33 by Ryan Bonner and Guðmundur Karlsson, who demonstrated how these hidden hubs represent one of the most significant unmapped attack surfaces in enterprise security.

Background & Context

Integration servers act as a central hub for business-to-business (B2B) transactions, data transformation, and legacy system bridging. Originally developed in 1996 and later acquired by Software AG (and recently IBM), WebMethods is a staple in the infrastructure of global banks, healthcare providers, and insurance companies. Despite its criticality, the platform is notoriously difficult for independent researchers to study. Training is prohibitively expensive, and documentation was historically locked behind paywalls. This 'security through obscurity' has backfired, leaving thousands of misconfigured servers exposed on the public internet, often with administrative services accessible to anyone with a web browser.

Technical Deep Dive

Understanding the Root Cause: The ACL Trap The primary vulnerability in WebMethods deployments isn't a complex memory corruption bug; it's a fundamental misunderstanding of the Access Control List (ACL) model. When developers build services in WebMethods, they often encounter 401 Unauthorized errors during testing. To 'fix' the issue quickly, the common practice is to change the service's permission to the Default ACL.

What many developers fail to realize is that the Default group inherently includes the Anonymous user. By assigning a service to Default, you are inadvertently publishing it to the open internet. When this is done to internal packages or administrative utilities (like those in the wm.public namespace), the results are catastrophic.

Step-by-Step Reconnaissance and Discovery

1. Querying OSINT Engines: The first step is identifying the servers. Using Shodan, a researcher can search for the specific authentication header associated with these servers. A query like www.authenticate: "integration server" is a highly effective starting point.
2. CT Log Scanning: For companies that don't expose their integration servers on standard ports, Certificate Transparency log scanning can reveal subdomains (e.g., int-server.company.com) that point toward the middleware.
3. Endpoint Fuzzing: Once a target is identified, the next step is to probe the /invoke/ endpoint. This is the gateway to executing services. A request to /invoke/wm.server/ping might return a 200 OK, confirming the server is alive and responding.

Exploitation via Service Invocation WebMethods services can be invoked via simple GET or POST requests. If a service is assigned to the Default ACL, an attacker can trigger it by simply navigating to a URL.

For example, if the wm.public:os_command service is exposed, an attacker might attempt to execute system commands by passing variables through the URL parameters. While some services require complex data structures (making them harder to exploit), many 'public' services are designed for simplicity. The researchers noted finding endpoints that returned plaintext B2B passwords, sensitive healthcare records, and even services that allowed for direct command injection.

Mitigation & Defense

Defending these systems requires moving away from the 'make it work first' development mentality.

1. Audit ACLs: Administrators must regularly audit all services, particularly those in the wm.public and custom packages, to ensure they are not assigned to the Default or Anonymous ACLs unless absolutely necessary.
2. Network Isolation: Integration servers should never be directly exposed to the internet. They should reside within a protected network segment, accessible only via VPN or a managed API gateway with robust authentication (MFA).
3. Disable Unused Packages: If a built-in package is not required for business operations, it should be disabled to reduce the attack surface.
4. Monitor Logs: Monitor the /invoke/ logs for unusual spikes in 404 or 500 errors, which may indicate an attacker is fuzzing for unauthenticated services.

Conclusion & Key Takeaways

The 'Plumbing the Plumber' playbook serves as a stark reminder that legacy infrastructure is not synonymous with secure infrastructure. As the researchers demonstrated, by applying modern reconnaissance techniques to 30-year-old middleware, it's possible to find critical vulnerabilities in the world's largest organizations. For security professionals, the lesson is clear: don't ignore the plumbing. Whether you are a bug bounty hunter or an internal blue teamer, auditing your integration servers and middleware hubs should be a top priority. As we look toward the future, these 'invisible' layers of the stack will continue to be a primary target for those who know where to look.