Breaking F5 BIG-IP Next: From OData Injection to Full Administrative Control

TLDR: Modern network appliances like F5 BIG-IP Next are moving toward containerized, microservice-based architectures, but they remain vulnerable to classic web application flaws. This research demonstrates how OData and SQL injection vulnerabilities can be chained to bypass authentication and gain full administrative control over the appliance. Pentesters should prioritize auditing these management interfaces for injection points, as they often lack the robust security controls found in standard enterprise web applications.

Network appliances are the black boxes of the enterprise. We treat them as trusted infrastructure, often assuming that because they sit at the edge, they are hardened against the common web vulnerabilities we see in standard applications. This assumption is dangerous. Recent research into F5 BIG-IP Next appliances proves that even when vendors shift to modern, containerized, microservice-based architectures, they often carry over the same fundamental flaws that have plagued web applications for decades.

The Architecture of a Modern Appliance

F5 BIG-IP Next represents a significant shift in how these devices are built. Instead of a monolithic binary, the platform now relies on Kubernetes and Go to orchestrate over 30 microservices. Each service runs in its own container, and the system uses a PostgreSQL database for configuration management, with granular access controls implemented per service.

On the surface, this looks like a massive security win. Container isolation and microservices should, in theory, limit the blast radius of any single vulnerability. However, the management interface—the central point of control—is still a web application. If that application has an injection vulnerability, the underlying architecture matters less than the trust the application places in user input.

Exploiting the Management Interface

The research identified two primary injection vectors in the BIG-IP Next Central Manager API: OData injection and SQL injection. These are not obscure, zero-day-only techniques. They are classic Injection flaws that exist because the application fails to properly sanitize input before passing it to the backend database or API layer.

The OData injection, tracked as CVE-2024-21793, allows an attacker to manipulate queries sent to the Central Manager API. By crafting specific OData filters, a researcher can leak sensitive information, such as administrative password hashes. The SQL injection, CVE-2024-26928, provides a more direct path to bypassing authentication entirely.

During the demonstration, the researcher showed how these vulnerabilities could be chained. By injecting into the login form, they were able to extract the admin password hash one byte at a time. The speed of this exfiltration is limited only by the network latency and the efficiency of the brute-force script. Once the hash is recovered, it can be cracked offline, or the injection can be used to manipulate the database state to create a new, unauthorized administrative user.

The Reality of Post-Auth SSRF

Beyond injection, the research highlighted a critical Server-Side Request Forgery (SSRF) vulnerability. While SSRF is often dismissed as a low-impact finding, in the context of a containerized appliance, it is a gateway to the internal network. Because the appliance acts as a central management hub, an attacker who gains access to the management console can use the SSRF to pivot into the internal management network, bypassing firewall rules that would otherwise block direct access to those internal services.

The impact here is clear: an attacker who compromises the management interface doesn't just own the appliance; they own the bridge into the rest of the infrastructure.

Why This Matters for Pentesters

When you are on an engagement, do not skip the management interfaces of network appliances. Many of these devices are now essentially Linux servers running a web stack that hasn't been audited with the same rigor as a customer-facing web application.

If you find a login page, treat it like any other web target. Look for injection points in the parameters, test for SSRF, and check for Broken Access Control. The fact that these devices use HashiCorp Vault for credential storage or run on Kubernetes does not mean they are immune to these flaws. It just means the exploitation path might involve a few more steps, like identifying which microservice is handling the request.

Defensive Considerations

For the blue team, the takeaway is that patching is only half the battle. While F5 has released updates to address these specific vulnerabilities, the underlying issue is a lack of standardized security practices across the entire development lifecycle of these appliances.

Defenders should focus on:

1. Network Segmentation: Never expose management interfaces to the public internet. If they must be accessible, put them behind a VPN or a jump host with strict multi-factor authentication.
2. Egress Filtering: Limit the ability of the appliance to make outbound requests. This is the most effective way to neutralize the impact of an SSRF vulnerability.
3. Monitoring: Log all API calls to the management interface. An unusual volume of requests to the login endpoint, especially those containing OData or SQL syntax, should trigger an immediate alert.

We are seeing a trend where network vendors are rushing to modernize their platforms, often prioritizing feature parity over security. As researchers, our job is to keep pushing on these interfaces. The shift to microservices and containers is a step forward, but it is not a substitute for secure coding. If you are testing these devices, keep digging. The complexity of these new architectures is exactly where the next generation of bugs is hiding.