This is a real example of how the filesystem can be used to take over a WordPress website.
It’s a really bad vulnerability. And it uses the filesystem! This is why I’ve been spending the last 16 episodes on this topic. If this doesn’t get you to sit up and take notice then I don’t know what will. Learning how to use the filesystem properly is absolutely critical for a programmer.
What happened? What was wrong with WordPress that enabled such a bad vulnerability? Listen to the full episode to learn more or read the full transcript below.
Transcript
There was a recently discovered security vulnerability in WordPress that I want to explain in this episode.
When you’re trying to figure out how severe a vulnerability is, there’s a few things to consider.
• #1 How likely is the vulnerability to appear? If it only happens in some rarely used extension, then it probably won’t affect very many people. This example comes straight from core. That means it exists in the main parts of WordPress itself and affects every single WordPress website in the world. That’s about as severe as you can get. The only way to get more severe would be for the vulnerability to exist in the core of the operating system itself. But then it wouldn’t be a WordPress vulnerability.
• #2 How difficult is it to exploit? If an attacker has to write code and even then there’s only a small chance to hit the vulnerability, then maybe it’s not so bad. In this case, it turns out to be very easy to exploit. Just a few clicks and uploading a simple video file is all it takes. Because it’s so simple, the severity of the vulnerability just went up again. And it was already high to begin with.
• #3 What benefit does an attacker gain by exploiting the vulnerability? Something as simple as a denial of service attack is not as severe. Don’t get me wrong. Even a denial of service attack is bad. But it’s not as bad as an elevation of privilege attack. That’s where an attacker can use the vulnerability to gain more permissions and do things not normally allowed. At a similar level is information tampering where an attacker can change data and cause false or misleading information to appear. And one of the worst is information disclosure. This is the type of vulnerability you hear about in the news whenever a big retailer says that their systems were hacked and customer information was stolen. That’s really, really bad. In this particular case, we’re talking about an elevation of privilege attack.
Okay, so this particular vulnerability exists in all WordPress sites, is easy to exploit, and results in an attacker being able to raise their privileges so high that they can just take over your site completely and leave the owner standing in the cold.
It’s a really bad vulnerability. And it uses the filesystem! This is why I’ve been spending the last 16 episodes on this topic. If this doesn’t get you to sit up and take notice then I don’t know what will. Learning how to use the filesystem properly is absolutely critical for a programmer.
What happened? What was wrong with WordPress that enabled such a bad vulnerability?
It starts out with a perfectly reasonable feature in WordPress. You see, WordPress allows multiple roles and one of those roles is an editor. The job of an editor is to create content on a website and change pages when needed. Some of these changes involve images and videos which are referred to in WordPress as media.
Now media files can have a thumbnail image. That’s an image that gets displayed, for example, in the spot where a video will be played. The thumbnail gets displayed before the video starts playing. This way, you can control what will appear on the page even before a visitor presses the play button.
WordPress also allows editors to delete media files. Again, this is a perfectly valid feature. You don’t want to leave unused media files laying around taking up space. And whenever an editor deletes a media file, then WordPress also deletes the thumbnail image.
And this is where the trouble begins. How does WordPress know which file is the thumbnail for a given media file? Well, it’s a property that was specified when the original media file was uploaded. The point is, the path to the thumbnail comes from the editor. WordPress just follows that path and deletes whatever file it finds.
Just think about that for a moment. Any editor on your site now has a simple means to delete any file on the computer that WordPress has access to. This already has the makings of a denial of service attack.
I mean, just delete some important file and make the website unable to run properly. Or worse yet, if the server computer is setup with the web hosting service having more privileges than it should, then maybe any file on the computer can be deleted. This could bring down the entire computer. For a web server hosting thousands of sites, they could all be brought down because of just one disgruntled editor on a single site.
But because we’re talking about WordPress, there’s one file in particular that’s very important. It’s the ultimate goal of many attackers. The file is called wp-config.php. It contains the password used to gain entry to your database holding all the information in your website. It’s the key to everything about a WordPress website. And it gets setup when a WordPress website is first being created.
You see, with this vulnerability to be able to delete any file that WordPress has access to, it’s possible to delete wp-config.php. This will trick WordPress into thinking that it needs to setup a brand new website. It will give an attacker the ability to create a new website where the old one used to exist and put whatever content the attacker wants in it’s place.
This goes far beyond a simple denial of service. It could even lead to information disclosure if an attacker was well prepared and able to put the website back to one that looks very similar to the old one.
All in all, this is a very serious vulnerability. But I can already hear you asking how it can be an elevation of privilege if an attacker had to already be an editor? Well, an elevation of privilege doesn’t mean that an attacker has to go from zero permissions to being able to do everything. All it really means is that somebody is able to gain more abilities than they would have access to. The fact that this vulnerability requires an attacker to start with editor privileges just makes it a little harder to pull off. But not by much.
Imagine a magazine website with hundreds or thousands of editors. You might trust each and every one of them. But do you trust that every one of them will have a strong password? All it takes is for one of them to have a weak password and an attacker can break in and use that editor’s privileges to take over the entire site.
How could this be prevented?
Well, the first thing is to fix the bug in WordPress. That code should not have blindly followed the path to the thumbnail and deleted whatever file it found. It should have made sure that the thumbnail also resided in the media folders. And probably made sure that the thumbnail wasn’t itself a media file used in another article. Otherwise, you could get one editor deleting images and videos from another editor.
But even beyond that, there are things you can do to protect yourself even with bugs like this one in place. In episode 236, I advised that you run your programs with the least permissions possible.
What that means in this case is to make sure that WordPress does not have the ability to delete wp-config.php. There’s no reason for WordPress to be able to delete this file. If you had setup your site so that WordPress could not delete the file, then no editor would be able to trick WordPress into doing something that was beyond its ability in the first place.
In the last episode, I advised against being predictable. This one is out of your direct control and more a problem for WordPress to deal with. You see, because every WordPress site uses wp-config.php and everybody know exactly where this file is located and because it’s such an important file, then it becomes the target of a lot of attacks. It’s only a matter of time before somebody figures out another creative way to get to this file.