Want to know the easiest way to hack most of the WordPress installs on a host? It’s as easy as attacking the host’s internal DNS server, then just sitting back and waiting on users to install your backdoor. If you can manage to change the IP address that “api.wordpress.org” resolves to, you’ve won the battle.
I can’t take credit for finding this, it was pointed out on Twitter:
tweet deleted
So this is nothing new – though I don’t think most users realize that this hole exists, or how hard it would be to find out that they’ve been attacked.
Internal networks rarely receive the same degree of scrutiny as public facing systems when it comes to updates and hardening, making an attack against an internal DNS server not just possible – but quite likely. Since HTTPS isn’t used to protect against MITM attacks, and the packages aren’t signed, so there’s no verification that what you downloaded matches what was released. So going after the DNS server is just one attack option.
Here’s a quick overview of just how it could happen:
- Hacker signs up for an account with a large host
- The attacker targets the internal DNS server and manages to redirect the API domain
- The API domain now points to an altered update check that serves an infected update package
- Users install updates with no idea that they aren’t original
It would be trivial to modify the WordPress update package to add a backdoor and modify the update check (wp-includes/update.php) to point to the attacker’s site – that way if the attack against the DNS server is fixed, compromised sites will remain compromised. This does assume that the host’s internal DNS server has some vulnerability – but in my experience that wouldn’t be surprising.
If the WordPress team started signing their updates, these issues would be gone; though it doesn’t look like that will happen:
tweet deleted
What makes this worse? Both the API and download domains already support HTTPS, but this doesn’t do any good if the application is hardcoded to use HTTP.
Wow! It’s been over a year since this blog o’ mine has seen any activity, though I’ve certainly not forgot about it. A lot has happened in the last year, so I’ll use this post as a bit of an update (and a warm-up for my return to blogging).
I’m not going to promise you’ll see a new post daily as was once the case, though I’ll try to ensure something new is up at least once a week.
As Shapchat has increased in popularity, I’ve been asked several times to revisit my Snapchat API & Security post, to address the changes that they made in response to my complaints. So, here is it – sorta.
I started making detailed notes and looking at the changes they made – but yesterday @tlack made that mostly irrelevant with his release of Snaphax, a PHP library to interact with the undocumented Shapchat API.
Update 3: In 2014 the FTC filed a complaint against Snapchat for their failure to provide the level of security they promised. The findings listed below were sent to the founders of Snapchat, that email was quoted in the FTC compliant as proof that Snapchat was aware of these issues.
Update 2: The Snapchat API has changed to address the issues I pointed out to them – and the new API has issues as well.
An Issuer Identification Number (IIN, more commonly called a BIN) is the first 6 digits of a credit or debit card, and it identifies the bank that issued it – and if you want to know if a number is a real credit card or just a bunch or random digits, it’s a huge help. While credit card numbers do use the Luhn algorithm (mod 10 check) to see if the number is valid, it still produces a huge false-positive rate.
During my Christmas vacation last year, I converted this site from WordPress to Hugo; while I’ve been happy with the change, a couple of features are missing. One of these is that there was a section with related content at the bottom of each post. I wanted to get it back.
Thankfully Hugo has native support for Related Content, so while I was hoping this would be a simple task, there’s a note that made things substantially more complicated:
