Misconfigured WAFs Heighten DoS, Breach Risks

Many organizations using Web application firewall (WAF) services from content delivery network (CDN) providers may be inadvertently leaving their back-end servers open to direct attacks over the Internet because of a common configuration error.

The problem is so pervasive that it affects nearly 40% of Fortune 100 companies leveraging their CDN providers for WAF services, according to researchers at Zafran who studied the cause and scope of the problem recently. Among the organizations that the researchers found susceptible to attacks included recognizable brands, including Chase, Visa, Intel, Berkshire Hathaway, and UnitedHealth.

Pervasive Issue

WAFs act as intermediaries between users and Web applications. They inspect traffic for a range of threats and block or filter anything deemed suspicious or matching known patterns of malicious activity. Many organizations have deployed WAFs in recent years to protect Web applications against vulnerabilities they haven’t had time to patch.

Organizations have multiple options for deploying WAFs, including on-premises in the form of physical or virtual appliances. There are also cloud- and host-based WAFs.

In total, Zafran found some 2,028 domains belonging to 135 companies among the Fortune 1000 that contain at least one supposedly WAF-protected server that an attacker could directly access over the Internet to launch denial-of-service (DoS) attacks, distribute ransomware, and execute other malicious activities.

“The responsibility [for] the misconfiguration lies primarily [with] the customers of CDN/WAF providers,” says Ben Seri, chief technology officer of Zafran. But CDN providers who offer WAF services share some responsibility as well for failing to offer customers proper risk avoidance measures and for not building their networks and services to circumvent misconfigurations in the first place, he says. 

The problem, as Seri explains it, has to do with organizations not adequately validating Web requests to back-end origin servers that host the actual content, applications, or data that users are trying to access.

A Failure to Follow Best Practices

With a CDN-integrated WAF service, the CDN provider — like a Cloudflare or an Akamai — provides the WAF as part of its edge infrastructure. All incoming traffic to an organization’s Web applications is routed through the CDN’s WAF — a reverse proxy server within the vendor’s edge network. The reverse proxy identifies which back-end server or resource a particular Web request is intended for and then routes it there in an encrypted fashion. “This means that when a CDN service is used as a WAF, the web application it protects is open to Internet traffic and is expected to validate that it responds only to web traffic that originates from and by the CDN service,” according to the Zafran blog post.

If the customer is using best practices, the IP address of the back-end server is something that only the customer and CDN provider would know. CDN providers also recommend that organizations add IP filtering mechanisms to ensure that only requests from the CDN provider’s IP address range are permitted access to back-end servers. Other recommendations include using pre-shared digital secrets known only to the CDN provider and the back-end server as a validation mechanism, and using what is known as mutual TLS authentication to validate both the origin server and the CDN provider’s proxy server.

These measures are effective in protecting back-end servers when implemented correctly. But what Zafran discovered was that many organizations have not adopted any of these recommended validation precautions, thereby leaving back-end servers directly accessible over the Internet. “It is a lack of validation in Web applications that are designed to be protected by a CDN/WAF that leaves them open to all Internet traffic,” Seri says. “It is like having a private S3 bucket left open to the Internet as a public bucket. Only in this case, it is protected Web applications that are left open to the Internet, instead of allowing only inbound traffic from the CDN provider.”

Easy to Find

Exacerbating the situation is the fact that the IP addresses of enterprise origin services are not as private as many assume, Zafran’s researchers found. The security vendor pointed to certificate transparency (CT) logs as one example of a relatively easy place for attackers and researchers to discover all domains belonging to a specific organization. CT logs provide a publicly accessible record of all SSL/TLS certificates that certificate authorities issue to website operators and are meant to improve trust and accountability around certificate issuance. Unfortunately, they also provide a starting point for attackers to gather detailed information on all the domains and subdomains belonging to an organization, including those associated with critical back-end servers and services.

“The issue was discovered to be extremely widespread,” Seri says. “From a random sample of Internet servers that were designed to be protected by Cloudflare, 13% were found to suffer from this misconfiguration. This means that, potentially, 13% of all domains protected by Cloudflare can be directly attacked.” Unfortunately, CDN/WAF providers require the cooperation of their customers, who control their own load balancers and Web applications, to mitigate this threat, he adds. Zafran is contacting affected companies as well as impacted CDN/WAF providers to help them quickly identify the full extent of this misconfiguration and address it, Seri says.