Our last article explored trends we were seeing against WordPress and something became very evident – Arbitrary File Vulnerabilities ranked #1 for vulnerabilities being scanned for.
Although the scope of our tests were limited, it does a lot to help better defenders better understand the tactics, techniques and procedures (TTP) being employed by bad actors.
Why Arbitrary File Vulnerabilities Matter
Of all the vulnerabilities, why are Arbitrary File vulnerabilities becoming so prominent? To better understand, we have to gain a better appreciation for this class of vulnerability.
While we often attribute this class to Download and Upload, there are others as follows:
| Class Type | Basic Description | Severity |
|---|---|---|
| Arbitrary File Read | The ability to see – think of a Directory Traversal, the ability to see the content in a directory when you allow indexing. | Moderate |
| Arbitrary File Execute | This is typically a serious vulnerability, and is often used interchangeably with Remote Code Execution (RCE). | Critical |
| Arbitrary File Download | This is the ability to download a file from the server. In the logs we shared in the last article what we saw were mostly download vulnerabilities (i.e., bad actor trying to download wp-config). | Moderate |
| Arbitrary File Upload | This is the ability to upload something to the server. Allowing someone to upload what they want to your server gives them the ability to push a malicious payload for more nefarious actions. If your server allows them to execute those files, you have a real problem. | High |
Things get especially tricky when vulnerabilities can be daisy-chained together. An Arbitrary File Download by itself is annoying, but manageable. If the same vulnerability allows the bad actor to upload something, that vulnerability becomes exponentially more dangerous. Introduce the ability to execute that file remotely and now you have yourself a world of problems.
Exploiting GET Requests
Arbitrary file vulnerabilities present bad actors with a unique opportunity to take control of your websites and perform nefarious actions. It’s why vulnerabilities like the zero-day released yesterday on the Fancy Product Designer plugin are so important.
It’s also why bad actors are so quick to added to the automated scans we were previously discussing. What’s especially important to make note of are the type of scans bad actors are making.
For instance, what you’ll often find is the use of GET requests when testing for the availability a vulnerability. Something like this:
[02/Jun/2021:07:26:33 +0000] "GET /wp-content/plugins/fancy-product-designer/assets/jssocials/jssocials.css HTTP/1.1" 404 20943 "" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.75 Safari/537.36"This is an example of the type of scans we’re seeing across our network as bad actors ramp up their scan operations. Time is of the essence in these type of situations, especially when it’s a zero-day and currently unpatched.
GET requests are a fan favorite because the risk of detection is low. By design most administrators allow GET requests, without it their website visitors would not be able to see the website. It, by design, allows a remote user to view something, which is how browsers work by default. It’s what makes it such a great tool to leverage to test for the availability of something without setting off alarms.
In this example, the scanners are likely looking to confirm the file exists before initiating the next phase of the attack which is likely attempting to verify the vulnerability itself exists. This makes sense considering it’s an Upload vulnerability, which does not mean it also includes a Download vulnerability. In this situation, the best way to verify is to find a file that is known to exist (CSS files are great files for this type of validation).
The type of vulnerability you’re dealing with will absolutely dictate the tactics employed. When it’s a download vulnerability it already uses a GET request, and it’s why in our previous post you saw so many targeting the wp-config.php file by default in WordPress. No need to check if something exists.
Again, another file that must exist and is super critical to the applications function. Downloads however are wide ranging in what they target, and it’s not uncommon to see requests to things like .env variables, git hub configuration files, Docker file and a variety of files that are often forgotten by website owners.
Using a WAF to Virtually Patch at the Edge
There is no more perfect example of the benefit of a Web Application Firewall (WAF) than when researchers release a zero-day disclosure. Here is a situation where the website owner literally has no option but to stress because there is no patch, but now they, along with the rest of the world, knows a vulnerability exists.
With the NOC WAF this type of exploit attempt is already blocked at the edge for our customers, even if the website has the vulnerability active on the site.
2021-06-02 15:17:14 88.198.91.76 403 199 HIT waf:exploit_blocked3 GET /blog/wp-content/plugins/fancy-product-designer/inc/custom-image-handler.php HTTP/1.1 88.198.91.76 Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.75 Safari/537.36and
2021-06-02 13:58:03 88.198.91.76 301 166 HIT waf:exploit_blocked3 GET /wp-content/plugins/fancy-product-designer/inc/custom-image-handler.php HTTP/1.1 88.198.91.76 Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.75 Safari/537.36This gives the website owner peace of mind of knowing they are protected, and gives the plugin developers the time to update their software. A win win for everyone.