Tag Archives: security

Part 3: Safety nets vs. bad code

If you haven’t looked at part 1 and 2 here, I suggest you do before reading on. This is a direct continuation of part 1.

So the original $wpdb->prepare vulnerability, which, I remind you is based on a potential typo in third-party code, is followed up with a new potential vulnerability based on double preparing a query. So again, bad third-party code.

So here’s one for you. If a developer does $wpdb->prepare( "SELECT * FROM wp_users where ID = %d OR %d". $_GET['param1'], $_GET['param2'] ); (note the . instead of the ,) do I also get a $500 bounty? How far will this go? Will the method be removed completely because #security? To what extent should WordPress and PHP be blamed for potential developer mistakes?

Shouldn’t these be addressed in the actual third-party code and not in core? I’m at a complete and utter loss now. What’s next?

Shout outs to Slavco for bringing all these issues up both with the codebase and the community, and how things are or should be handled.



On WordPress Security and Contributing

…and how neither really worked today.

A sad story in two parts, where I’m rash, harsh and untactful. An explanation, a rant, a call for support, a call for action. You do not have to agree with me, I may be just an asshole and haven’t realized it yet 😉

Continue reading



12 WordPress Plugin Vulnerabilities in 12 Months

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.



Javo Themes Spot LFI Vulnerability

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…

Javo Theme Vulnerability

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).

Continue reading



WordPress Nonces Vulnerabilities

Quick Page/Post Redirect Plugin: A Case Study

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.

Quick Page/Post Redirect WordPress Plugin Vulnerability

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

Continue reading



The FancyBox for WordPress Vulnerability

…and how the exploit really worked

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.

Continue reading



Advertisement Proposal Scam

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?”…

Continue reading



Don’t Post Images of Your Credit Card Online

Yes, people actually do that and an account I’ve been following @NeedADebitCard aggregates credit card photos on Twitter. Not all images are relevant but many are. Credit card fraud is a serious issue as is, with all our connectivity to the World Wide Web and technology that allows us to be “social” that makes many people act irresponsibly, aggravates this.

Credit cardAnd some people actually think there’s nothing bad in posting parts of the card. Yet, the same people have no understanding of which parts are safe to display and which are not. General rule – don’t show your credit card at all, especially online for the general public to view. I have wiped out the critical information in my version of the image as to stop the propagation of this nonsense. The cardholder pasted the image in the clear. Size is taken from the original.

This was a recent image shared via Instagram and Twitter. The person’s peers left 20+ “aww”-type comments, and nobody pointed out that it might have been a bad idea. A sane person on Twitter did so, and the cardholder responded with confidence that it was not a problem since not all the information is available. Now, see, what you get when you don’t understand the technology you use every day?

The cardholder’s screenname contained her name, so the missing name on the left side is not missing any more. The first four digits are a BIN, a Bank Identification Number (or IIN, Issuer Identification Number). We know the issuer – Capital One, it’s a MasterCard Platinum. Quick search through the many BIN lists available online yielded the first 6 digits of the card – 517805, with the last two digits to confirm a match, plus upon closer inspection you can see digits two and three of the BIN in black under the silver numbers, a 7 and an 8 (look under the finger on the left).

After pointing out the bits of “concealed” information that I’ve managed to find out in under 5 minutes, the cardholder took down the image.

Quite excellent. Even if say the last 4 digits were somehow concealed, Luhn’s Algorithm would decrease the search space quite a bit, leaving a handful of valid numbers (probably, whoever does the math gets some kudos). We’re missing the CVV, but we have the rest – issue and expiry date, photo of the card, photo of the person, and a whole bunch of other photos of the person online (identity fraud anyone?). And the CVV part is not an issue in many CNP (card-not-present) points of sale.

Is posting images of your credit card online bad? Without doubt. And teach your children to be highly responsible when using modern technology, and think twice, no matter how confident they are.

Be safe.



WordPress 3.4

Codename “Green”, WordPress 3.4 was announced yesterday, boasting flashy features and upgraded functionality.

WordPress 3.4

Lots of hard work involved, lots of excitement and most can’t wait to upgrade, including me. However, as much as I want to update to WordPress 3.4 and enjoy the new stuff, I find it difficult to do so in production right now. I’m sure WordPress 3.4 is fantastic, but it’s too early, there’s bound to be a WordPress 3.4.1 with security fixes (or at least hot fixes) sometime this year.

My suggestion is that unless you have a huge need for one of the new features just wait a bit, see how it behaves out in the wild, how it is targeted. At a little over 200,000 downloads and less than 24 hours out in the wild it’s too early to tell. I’ll personally wait a couple of months before upgrading in production.

Other than that, hurray! Off to play with the new XML-RPC methods.



Timing Attacks in Web Applications

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.

Timing Attacks in Web Applications

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.

Continue reading