238: Filesystem: Recent WordPress Attack Lets Editors Take Over.

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 unuse