newnameplz
Member
- Apr 26, 2015
- 23
- 24
- 35
So you're pentesting a site and you come across a potentially exploitable vulnerability, but find out you're being blocked by a ClouudFlare WAF... or you're trying do some automated spidering but can't because of their CAPTCHAs... or, you know, you're trying to boot them offline.
Either way, you're probably interested in finding out the real IP of the server. Here I'll discuss the common mistakes admins make when trying to set up CF for their website and how you can use them to your advantage.
The first is leaving a direct-connect subdomain exposed. Sometimes when debugging it's nice to have convenient access to a direct connection to the server, which is why many default CloudFlare configurations leave a "direct-connect" subdomain whose A records point to the direct IP enabled. This will of course lead to disaster if anyone finds out that this subdomain exists. Most of the time it will be something like "direct.cfedwebsite.com" or "direct-connect.cfedwebsite.com", and you can use DNS recon tools like fierce.pl to find these subdomains.
A somewhat related problem is related to leaving direct-connect domains in MX records for your site. Take gamemerk.com for example. If we do a DNS lookup using DiG on the domain, we will get this:
If we try accessing the IPs in the A records directly, we will get errors from CloudFlare. But see that MX entry? It begins with "dc", and if we resolve that domain to an IP (162.222.212.104) and access it directly, we get the actual website! Thus, we have found the real IP of the server.
This happens because Cloudflare does not handle mail, so a direct connection has to be placed in the MX records. Some admins run mail servers and web servers on the same box, which leads to the MX record leaking the real IP.
A related issue is just running other services on the same box as your web server in general. For example, a domain can have no MX records at all, but it still sends mail to users from the same box as the webserver. If we can get an email to be sent to us somehow (eg new user registration, contact form), the SMTP headers on the email we recieve will leak the real IP. Similarly, if there is a TeamSpeak/Minecraft/whatever server running on the same box as the webserver, Cloudflare doesn't protect that, so just connecting and monitoring your network activity will net you the real IP of the server.
Finally, if all else fails, you can try to make the web application running on the server itself send you a HTTP request. For example, phpBB by default enables you to set your avatar by submitting a remote URL. It will fetch the content from the URL to set as your avatar, and in doing so it will leak the web server's real IP to the remote server it is fetching from. If you use a URL from an IP logging service or the server is one you control, you can easily find out the real IP of the webserver.
Either way, you're probably interested in finding out the real IP of the server. Here I'll discuss the common mistakes admins make when trying to set up CF for their website and how you can use them to your advantage.
The first is leaving a direct-connect subdomain exposed. Sometimes when debugging it's nice to have convenient access to a direct connection to the server, which is why many default CloudFlare configurations leave a "direct-connect" subdomain whose A records point to the direct IP enabled. This will of course lead to disaster if anyone finds out that this subdomain exists. Most of the time it will be something like "direct.cfedwebsite.com" or "direct-connect.cfedwebsite.com", and you can use DNS recon tools like fierce.pl to find these subdomains.
A somewhat related problem is related to leaving direct-connect domains in MX records for your site. Take gamemerk.com for example. If we do a DNS lookup using DiG on the domain, we will get this:
Code:
gamemerk.com. 299 IN MX 0 dc-b9dd4a95.gamemerk.com.
gamemerk.com. 21599 IN NS hank.ns.cloudflare.com.
gamemerk.com. 21599 IN NS lily.ns.cloudflare.com.
gamemerk.com. 21599 IN SOA hank.ns.cloudflare.com. dns.cloudflare.com. 2018460206 10000 2400 604800 3600
gamemerk.com. 299 IN A 198.41.249.162
gamemerk.com. 299 IN A 162.159.240.163If we try accessing the IPs in the A records directly, we will get errors from CloudFlare. But see that MX entry? It begins with "dc", and if we resolve that domain to an IP (162.222.212.104) and access it directly, we get the actual website! Thus, we have found the real IP of the server.
This happens because Cloudflare does not handle mail, so a direct connection has to be placed in the MX records. Some admins run mail servers and web servers on the same box, which leads to the MX record leaking the real IP.
A related issue is just running other services on the same box as your web server in general. For example, a domain can have no MX records at all, but it still sends mail to users from the same box as the webserver. If we can get an email to be sent to us somehow (eg new user registration, contact form), the SMTP headers on the email we recieve will leak the real IP. Similarly, if there is a TeamSpeak/Minecraft/whatever server running on the same box as the webserver, Cloudflare doesn't protect that, so just connecting and monitoring your network activity will net you the real IP of the server.
Finally, if all else fails, you can try to make the web application running on the server itself send you a HTTP request. For example, phpBB by default enables you to set your avatar by submitting a remote URL. It will fetch the content from the URL to set as your avatar, and in doing so it will leak the web server's real IP to the remote server it is fetching from. If you use a URL from an IP logging service or the server is one you control, you can easily find out the real IP of the webserver.
This is a common mistake.. people will point the domain directly to their server and switch cloudflare without actually rotating their old IP.
