When attacking a web application, I will frequently encounter a web application firewall (WAF) which greatly slows, or outright prevents classes of attacks. There are many guides available that discuss techniques for evading specific WAF protections. Following is a different take on this common challenge. In this post, I will discuss techniques for discovering the location of the protected web application origin server on the internet. If the origin is poorly configured, this can allow absolute bypass of the WAF. If anything, this exercise may expose revealing information about an application, and can expand the available attack surface.
The application origin should be isolated so that all public traffic must pass through the application firewall. In practice, this isn’t always the case. I would gamble to say that while WAFs are more common than ever, the percentage of those which are properly configured are lower than ever, for a couple of reasons:
- The WAF may be incidental. Developers may use Cloudflare specifically for site performance and uptime. The WAF is added value. Security was never the primary purpose, and so the origin configuration is neglected.
- The bar of entry has been lowered. Services such as CloudFlare, Sucuri, and the various WAF-as-a-service offerings by most cloud providers have a push-button deployment. Unsophisticated developers or sysadmins may deploy these services without properly configuring the origin. They probably get “good enough” results, anyway.
If the origin is on the internet, it’s worth spending the time to search for it. Even if you don’t get unbridled HTTP/HTTPS access, you may find other services there, or other interesting hosts nearby. If anything, it always helps to augment the OSINT database.
Here are some techniques I’ve successfully used to find origin servers.
This trojan was found on a compromised web server that was used to send mass emails with a malicious attachment. Upon execution, the malware searches all logical drives for common media and document files, appends .CRYPTOLOCKER to each file’s name and allegedly encrypts each file with 2048-bit RSA key. It places a text file in every subdirectory with ransom instructions. It persists on the system by copying itself to a TEMP folder, and adding that copy to the system autoruns. It also gives this copy a file-association to the “.CRYPTOLOCKER” file extension. When it finishes this dirty work, it displays a warning (seen above) with instructions for downloading the Tor Browser to (presumably) cough up some money for the private RSA key required to decrypt the files. This is a similar pattern that we have seen in recent ransomware variants.
I initially executed this sample in a sandbox that had no network connectivity. Though, the malicious process never attempts to make any network connections at any point. Regardless, it still modifies files and displays the CryptoLocker alert. I immediately found this to be unusual. My understanding is that CryptoLocker initially connects to a C&C server which in turn generates a unique RSA key pair of which one is sent to a client for file encryption. This clearly isn’t the case here. I supposed that it’s possible that a public key was hard-coded into this sample, but that seems unnecessarily complicated and fragile, since we know that this was intended to be sent to many inboxes. It’s time to take a closer look at this executable.
I responded to an incident that was initiated by an abuse complaint from a European ISP. Their mail server was receiving a large amount of backscatter due to emails that were initially sent from a server that I came to inspect. The sending server was a Postfix server, and there were many undelivered emails in the queue, coming from an unfamiliar domain. After closer inspection of the queue and the Postfix logs, it was clear that the emails were originating from a web server on the local network.
I received this malware sample from a system administrator of a small technology firm. He had discovered the sample as an email attachment on his mail server. He was concerned because his malware defenses had not protected his users. Furthermore, his endpoint anti-virus solution did not identify the malware, even after decompressing and executing it on an isolated system. I agreed to take a closer look at the executable and report my findings.