Listen to this Post
Introduction:
Web Application Firewalls (WAFs) like Cloudflare are frontline defenses, shielding origin servers by proxying and filtering traffic. However, a critical misconfiguration occurs when the WAF’s security policies are not enforced on the origin server itself, allowing attackers to bypass all protections by connecting directly to the server’s IP address. This exposes the application to the very attacks the WAF was designed to prevent.
Learning Objectives:
- Understand the methodology for discovering a target’s true origin IP address.
- Learn to verify direct IP access and identify misconfigured WAF rules.
- Identify common server headers and configurations that leak origin information.
You Should Know:
1. Discovering Origin IPs with Shodan and Censys
Shodan and Censys are search engines for internet-connected devices. They are invaluable for finding origin servers by fingerprinting responses that match your target.
shodan search "CompanyName" "port:443" censys search "services.tls.certificates.leaf_data.subject.organization: CompanyName"
Step-by-step guide:
1. Identify your target’s domain (e.g., `target.com`).
- Use Shodan or Censys to search for the company name, often found in SSL certificates.
- Look for IP addresses that serve HTTPS/HTTP traffic but are not in the known Cloudflare IP range.
- Cross-reference these IPs with historical data using a tool like `host` to see if the domain ever pointed directly to them: `host target.com`
2. Leveraging Historical DNS Data
Services like SecurityTrails and DNSDumpster maintain historical DNS records, which often reveal the origin IP before the domain was moved behind Cloudflare.
Using the 'host' command to check for direct A records host target.com Using DNSDumpster via CLI with curl (note: use their web interface for best results)
Step-by-step guide:
1. Visit a service like SecurityTrails or DNSDumpster.
- Enter the target domain and review the historical A and AAAA records.
- Note any IP addresses that are not the current Cloudflare proxies.
- Attempt to connect to these IPs directly via your browser by modifying your `hosts` file or using curl: `curl -H “Host: target.com” http://
`
3. Identifying Subdomains Pointing to Origin
Often, less-critical subdomains like test.target.com, dev.target.com, or `api-old.target.com` are neglected and point directly to the origin IP.
Automated subdomain enumeration with sublist3r sublist3r -d target.com For each discovered subdomain, resolve its IP for sub in $(cat subdomains.txt); do host $sub; done
Step-by-step guide:
- Use a tool like
sublist3r,amass, or `subfinder` to enumerate subdomains. - Resolve the IP addresses of all discovered subdomains.
- Identify any subdomains that resolve to an IP not in Cloudflare’s range.
- This IP is a strong candidate for the origin server.
-
Verifying Direct IP Access and Bypassing the WAF
Once a candidate IP is found, you must verify that it is the origin server and that the WAF is absent.Using curl to check the response and server header curl -s -H "Host: target.com" http://<CANDIDATE_IP> -I Testing with a known malicious payload curl -s -H "Host: target.com" http://<CANDIDATE_IP>/api/v1/users?id=1+AND+1=1--
Step-by-step guide:
- Use `curl` to send a request to the candidate IP, setting the `Host` header to your target’s domain.
- Analyze the response headers. A server header like `nginx` or `apache` instead of `cloudflare` is a good indicator.
- Send a simple SQL injection or XSS payload. If the WAF is correctly configured on Cloudflare, this request would be blocked (403). If it returns a 200 OK or a database error, you have successfully bypassed the WAF.
5. Scanning for Vulnerabilities on the Origin
With direct access confirmed, you can now scan the origin server for vulnerabilities that would be hidden by the WAF.
Using nmap to scan the origin server nmap -sV -sC -p- <ORIGIN_IP> Using nikto to perform a web vulnerability scan nikto -h http://<ORIGIN_IP> -Host target.com
Step-by-step guide:
- Conduct a port scan against the origin IP to discover all running services.
- Perform a vulnerability scan with
nikto, ensuring to set the host header appropriately. - Manually test the application at the origin IP for common vulnerabilities like SQLi, SSRF, and broken access controls, which are no longer being filtered.
6. Cloud Misconfigurations: Public Buckets and Storage
Cloud infrastructure itself can leak origin IPs. Publicly accessible storage buckets or debug endpoints can reveal critical information.
Using awscli to check for S3 bucket misconfigurations aws s3 ls s3://target-dev/ --no-sign-request Scanning for common Azure or GCP storage URLs
Step-by-step guide:
- Check for misconfigured AWS S3 buckets, Azure Blobs, or Google Cloud Storage buckets using the respective CLIs or tools like
cloud_enum. - Look for backup files, source code, or configuration files (e.g.,
.env,wp-config.php) that may contain database hostnames or internal IP addresses. - These internal IPs can often be directly accessed from the public internet if the network is not properly segmented.
7. Mitigation: Hardening the Origin Server
This is not an attack against Cloudflare but a misconfiguration of the origin server. Mitigation requires proper network and server hardening.
Example iptables rule to drop all traffic not from Cloudflare's IP ranges iptables -I INPUT -p tcp --dport 443 -s 173.245.48.0/20 -j ACCEPT iptables -I INPUT -p tcp --dport 443 -s 103.21.244.0/22 -j ACCEPT iptables -A INPUT -p tcp --dport 443 -j DROP Using a webserver config (Nginx) to only allow Cloudflare IPs allow 173.245.48.0/20; allow 103.21.244.0/22; deny all;
Step-by-step guide:
- Obtain the current list of Cloudflare IP ranges from their website.
- Configure your server’s firewall (e.g.,
iptables,ufw) to only accept web traffic (ports 80/443) from these Cloudflare IP ranges. All other traffic should be dropped. - Alternatively, configure your web server (Nginx/Apache) to only allow requests from Cloudflare IPs, returning a 403 for all others.
- Validate the configuration by attempting a direct IP access; it should now be blocked.
What Undercode Say:
- The Human Element is the Weakest Link. This bypass highlights that the most sophisticated perimeter security is useless if the origin is not hardened. Security is a chain, and this is a critical broken link.
- Assumption of Protection is a Vulnerability. Relying solely on a WAF creates a false sense of security. Defense must be layered, encompassing network, host, and application levels.
This bypass technique is a stark reminder that security configurations are not “set and forget.” Continuous assessment and adherence to best practices, like restricting origin server access, are non-negotiable. The rise of easily deployed SaaS security solutions can lead to complacency, where organizations overlook the fundamental step of ensuring their actual infrastructure is not publicly exposed. This flaw is not in the WAF product but in its implementation, making it a pervasive and highly effective attack vector for persistent threat actors.
Prediction:
As organizations continue to rapidly adopt CDN and cloud-based security services, misconfigurations leading to origin exposure will become a primary initial access vector for mid-level threat actors and automated bots. We will see a rise in worms that automatically scan Shodan for exposed origin IPs behind popular WAFs, exploiting known vulnerabilities that are otherwise blocked at the proxy layer. This will force a paradigm shift in cloud security, moving from simple proxy-based protection to a zero-trust network architecture where every request, regardless of its source IP, must be authenticated and authorized.
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Abdulrhman Rabie – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
