A Quick Change Of Format
We’ve been watching the statistics on these security blog posts, and they are among our least read content, so we’re going to mess with the content a little. Instead of taking more of a marketing/newsletter angle with it, let’s get nitty gritty with some things we at Armor have actually encountered in the wild.
Today’s topic is:
How Did They Get Into My Website,
And What Did They Do?
Did you know that you can put a PHP shell inside a JPEG file? In fact, this is one of the more common exploits we encounter, as most websites that accept uploads, accept JPEG images.
As a general rule, everything on Linux is a file somewhere, and everything can be read as if it is a text file. That second part is true of Windows and Macs as well, but they can make you jump through some hoops. This is important because to a web server, a PHP file is nothing but a text file it needs to do something with after reading.
JPEGs, like most documents, have a place for metadata in their specifications, and in fact, for JPEGs, this Exif metadata is written in plaintext inside the JPEG file, along with the binary data that makes up the visual data of the image. PHP code is noted with a <? or a <?php before and a ?> to close it. If we find a JPEG where the binary data and the other Exif data does not include those symbols, and then we can use a dedicated Exif editor to drop our shellcode into the comment section of the image.
Now, we have a valid JPEG image with a shell in it, but that isn’t enough. Our payload is inoperable in its current state. First, we need to get the file on the server, and then we either need to convince the server that it should look at the JPEG as a PHP file, or rename the JPEG to a PHP file. For the first, we just need to find an upload form or a document that is looking for an upload from a form. When we are penitration testing systems, we have a benefit that hackers don’t in that we can read the code in our documents and analyze them for vulnerabilities. Putting our pen-testing hats on then, we have identified a document in our hypothetical framework that is not verifying that the upload is coming from the right form, is doing image validation on the upload, but allows the user to set the filename the image is saved to on the server with no validation of the filename.
This makes our job easy. The HTML form hooked to this processor is built to only accept JPEGs and doesn’t actually post the value to set the filename, even though it is one of the things the processor looks for, so we open up our Dev Tools and add that input to the form, set it to shell.php and upload our image. Now, if we know exactly where that image is uploaded to, we can navigate to that location and access our newly uploaded shell. If you were doing this yourself, you’d probably notice that the binary data of the image is still output, but because this is considered a text document with PHP code inside it, the binary data does not display like a picture, but as a string of characters, much like it looked in the text editor.
So our shell is functional, and it will do things if we give it commands, but if we’re looking to smuggle out data through it, we either need to filter the data or use our initial shell to upload a larger, more flexible shell. Since we are pretending to be hackers, we have to assume we don’t have much time, so uploading a new shell is our best option.
Okay, But What Did They Do?
In our experience, hackers come in two varieties: those who are there for the thrill of it and to get security experts to step up their game, and those who are there to make money. These two varieties have very different goals. The first, and arguably, the kind that you want in your system, if anyone is to get in, are going to deface your website and let you know that they were there. When viewed objectively, some of these defacements have a level of humor to them, and many of them are clever just for the sake of being clever. These hackers almost never try to compromise your data, and while they are the most visible, they are also the most harmless. If you ever find that your homepage has been replaced with a large garish image and some music, you can be fairly certain that the damage is relatively minimal, and is mostly due to neglecting to update the framework, a bad configuration on your hosting, or poorly written custom code. Typically, these sites only take a few minutes to an hour to recover, but closing the holes they used to get in can take much longer.
The more terrifying hacker, though, is the one who is in it to make money. These are the ones who usually cover their tracks very well. They are after any way they can to make money off of their intrusion. That can be data harvested from your database or email, or it can be turning your website traffic into unsuspecting carriers for Cryptomining or the spread of a Bot-Net. In either case, it is in their best interest that you do not notice for as long as possible, so these are the ones that will delete their shells after the fact, do things like utilize special network communications that aren’t logged as fully to send commands to their shells, who will replace your copy of JQuery with the cryptominer library that still has all of JQuery’s functionality built in, who will place all of your email into an archive, download and remove the archive and sell the data inside it to whoever is buying. These people will usually not deface the website, as much as they will quietly modify it to fit their needs. Maybe they’re part of an SEO scam where they simply need to link to one of their websites from your higher traffic website, but do it in such a way that you would never notice (this one is pretty common, they use CSS to place the link outside of the normal viewable space of the website. Google and Bing Bots still see it and index it, but normal users won’t know the difference. Because these intrusions are so stealthy, they are much harder to recover from and can take several hours to several days to fix, especially if we track them back to their intrusion point and close it up.
So What Should We Do?
In either case, there’s a lot of work that goes into protecting your website, but no one is perfect, which is why we came up with a solution to help protect those more vulnerable situations. We call it Drawbridge, and I won’t go into too much detail about how it works, but think of it as a last line of defense. If it is installed and running, it injects itself into ANY PHP files the server is asked to execute, and it does a quick check to see if it knows this file, and if it doesn’t, it stops the execution before any foreign code is parsed. No exceptions. We have seen it work against a number of intrusion attempts already. It isn’t magical, and it doesn’t mean that your framework is PCI compliant, or that you will be protected if an intruder manages to find another way to compromise your site. But it’s a lot like putting a big security door on your website. Yeah, you can get through it with the right tools, but if your goal is to make as much money as possible, you might think twice about trying to break into something that is going to take a little more effort than the WordPress site next door. And ultimately, that’s the only reasonable goal for security. Nothing is ever hacker proof, but if you can make it hard enough to not be worth it, you can minimize yourself as a target.
And that’s really the goal of this newsletter. The internet can be an easy place to get taken advantage of, but with a few relatively simple steps, you can make it much harder. Let us help you take them.