I’m challenging myself to find 12 plugin vulnerabilities in the next 12 months, right in time for WordCamp Moscow 2018, where I’ll present peculiar vulnerable code and talk about practical security mistakes that don’t get caught by the official plugin repository review process.
Whew, it’s been a while…
I’ve had the misfortune to work with yet another theme from ThemeForest. A $60 premium theme and nothing less! Meet Javo Spot by Javo Themes…
Within half an hour of fiddling with it, trying to filter the output of their Listings Directory (which ended up being a 5-hour pain-in-the-butt task, which is a story for another day), I came across a glaring unauthenticated Local File Inclusion vulnerability (an LFI for short).
Quick Page/Post Redirect Plugin has 200,000+ active installs, with version 5.1.5 and older vulnerable to an attacker setting redirects to any URLs in bulk.
And why? All because the developer thinks a 5-byte WordPress Nonce will stop the bulk redirect import functionality from running. Newsflash: It won’t…
Last week a very popular plugin called FancyBox for WordPress was hit with a zero-day vulnerability which I happened to experience first-hand and dig into. If you’ve not heard about this here are a couple of links to get you up to speed:
The plugin was force-updated (where possible) on WordPress sites out there. This is the full disclosure of how the exploit worked.
So a couple of nights ago I got a weird e-mail from “Diana” at dianabem501@gmail.com. It said:
I have visit your blog https://codeseekah.com/
I can pay you $200 per month. Contact me for more info.
Intrigued, decided to respond and see where this scam went. I replied “What for?”…
When code is executed by a machine it takes some time to do so. Execution time ranges from nanoseconds to months and years and even more (think bruteforcing). Web applications construct output producing, in most cases, very short delays (think the time it takes to show Google search results after typing in the query). Depending on what output is request, how it is requested and what the input is web applications can vary their execution time.
In this article we’re going to exploit some of the open-source content management systems available using delays in its execution under differing conditions to evoke distinct differences in execution time, which allow us, as attackers, to make some useful conclusions.
Pingbacks have been part of the WordPress since the very beginning. One of my previous articles, titled WordPress Pingback Attacks explores two types of denial-of-service attacks that leverage Pingback request processing in WordPress. If you do not know how Pingbacks work, I suggest taking a quick crash-course here.
One of the attacks is a Layer 7, direct denial-of-service attack, performed by a handful of machines targeted at a single WordPress XML-RPC server with pingbacks enabled. Its purpose is to deplete the server of memory resources by forcing it to download and parse a target URL, which is specifically crafted to heighten resource usage while parsing. Up to 6:1 peak-memory-usage-to-download-size ratios have been reliably reproduced. There’s a bug that allows 5 times as much usage (i.e. 30:1 inflation ratios) when setup properly (WordPress 3.4 will suffer from it as well).
The second attack is a Layer 4 (typically bandwidth-exhaustion), reflected distributed denial-of-service attack which utilizes publicly available WordPress sites on servers of any size and is the subject of this article. Buckle up, off we go.
Yesterday I wrote a post titled On WordPress Pingbacks. While writing this I came to several conclusions that resulted in some interesting experiments and results.
I was going to publish my results along with that post, however, I wanted to make sure that the WordPress Security mailinglist had nothing against my publishing such information. With no word from them (I guess I expected too much to be contacted back within 24 hours), I’ve decided to dedicate a whole article to the Pingback attack, its potential, its limitations and further considerations and concerns.
I have read dozens of “How to secure your WordPress” articles, and one common “tip” among others is getting rid of the “generator” tag in the HTML head, for additional security through obscurity.
WordPress uses the meta “generator” tag to “disclose” its version. The paranoia surrounding this fact is unbelievable, and they think that by removing it they harden WordPress. And that is absolutely not true.
With so many reports of WordPress sites being hacked in one way or another, I decided to see how exactly WordPress sites are being invaded. The WordPress Codex has an excellent FAQ section titled “My site was hacked“, and it’s great. Hardening WordPress is another fantastic entry that deserves even more attention.
Not so long ago, I setup a honeypot on one of my private servers. I grabbed the latest stable version of WordPress and installed it. Waiting for any new WordPress vulnerability to be exploited would not be viable (although the TimThumb vulnerability is occasionally being attempted). I considered the latest stable version of WordPress secure, correctly setup, so I chose the single weakest link in the chain, located between the chair and the screen – the Admin.
