Advanced Caching Attack Targeting WordPress Owners

Doxxing yourself out of the Anonymous Hacker Collective by starting a public security company does come with certain risks, such as the increased likelihood that the number of cyber attacks you are about to absorb is going to skyrocket. To that effect, over the course of the last week I have begun picking up on a new probe/hacking technique I’ve never come across before.

Auditing my firewall logs, it appears as though hackers are attempting to probe the back end of my website by searching for archived blog posts within the contents of my trash can. This is done by attempting to manually search for a hyperlink with “_trashed” added to the end it, indicating that the attacker is not actually looking for the published version of the article itself, but instead for the specific URL assigned to an article once it has been unpublished and transferred into your trash bin.

For example, these people automatically know that every WordPress blog comes pre-installed with at least one published blog post; The Journey Begins. Therefore, becomes Or becomes So on and so forth.

What are They Searching for?

Researching the mechanics of how the trash bin works and how WordPress remembers data, even when a blog post has been unpublished and trashed, your LiteSpeed and Varnish Cache still treat/remember it as though it is a published post, because once upon a time that article actually was published. That is what cache is all about, after-all. But more on that briefly.

Earlier this year I was forced to mitigate a string of attacks originating out of Ukraine, where hackers had begun attempting to launch Cross-Site Scripting (XSS) attacks against cached versions of old blog posts I had once published under a different, but still connected, domain name. What I had uncovered was that the attackers were attempting to use my Varnish Cache in an attempt to enable Server-Side Includes (SSI) Injection of malicious scripts in outdated versions/URL’s of articles they hoped would be less secure than their current versions. While my firewall sealed them off gaining access to wp-Admin dashboard, I was only truly saved by the NoScript browser add on through Mozilla Firefox, which first alerted me to the XSS attack allowing me to block it.

Similarly, as was reported about 1 month after I first mitigated the attack, GoSecure came out with a new threat analysis explaining how “While conducting a security assessment, we noticed an unexpected behavior in the markup language Edge Side Includes (ESI), a language used in many popular HTTP surrogates (reverse proxies, load balancers, caching servers, proxy servers). We identified that successful ESI attacks can lead to Server Side Request Forgery (SSRF), various Cross-Site Scripting (XSS) vectors that bypass the HTTPOnly cookie mitigation flag, and server-side denial of service. We call this technique ESI Injection.” Adding that “through our testing, we’ve discovered a little under a dozen popular products that can process ESI: Varnish, Squid Proxy, IBM WebSphere, Oracle Fusion/WebLogic, Akamai, Fastly, F5, Node.js ESI, LiteSpeed and some language-specific plugins.

View GoSecure‘s Full Report:

Combing my experience earlier this year, along with the new knowledge that trashed articles/URL’s on WordPress are still automatically cached as though they still exist published by default, it appears as though hackers are attempting to probe for cached versions of old articles in order to launch Edge Side Include (ESI) attacks against them.

How To Mitigate The Attack

Step 1: Purge or Remove All Cache. Thankfully, because of my experience earlier this year, I already knew better than to leave all my cache just “innocently” hanging around, and have security measures in place to purge all Varnish cache on a weekly basis. Similarly, you should make it a habit to purge/clear your Varnish cache on a regular basis, or disable the LiteSpeed cache plugin altogether – if you have already installed it. Granted I am a bit of a security freak, but I just don’t want the added security liability of leaving my cache out in the open simply to make my site milliseconds faster for my visitors, the risk/reward just isn’t there for me.

Step 2: Force all traffic through HTTPS. As GoSecure‘s report even elludes to, these sorts of attacks are only successful through bypassing holes in http protocols. Something which can easily be resolved by simply forcing all of your website traffic through the encryption of your SSL.

Step 3: Empty your trash bin. Quite simply, hackers can’t exploit a trashed article or URL if there is nothing inside your trash bin intself. Not only will clearing out your trash bin help free up some of your data and make your site more organized, but it will also prevent this latest hack from finding you.

Published by

Brian Dunn

Writer, Researcher Owner: Rogue Media Labs | Rogue Security Labs (929)-319-2570 BrianDunn@RogueSecurityLabs.Ltd

Leave a Reply

Your email address will not be published.