In a new series of blogs, we will go over some recent data breaches and how metadata analysis could have helped with the detection and mitigation of certain events.
The Slickwraps breach has been outlined in detail in a (now archived) post done by a white hat hacker. I would recommend reading that for the very detailed specifics on how they found these exploits. The point of this blog is to show how you can monitor for these types of attack vectors using flow and metadata collection from various network sources.
Slickwraps breach analysis and timeline
A little backstory on the Slickwraps service: essentially what we have is a web server that allows customers to upload images to get printed onto wraps for cellphones and other accessories. In my lab example I have a web server that hosts a similar function.
The next section of this blog will be going over this attack step-by-step using metadata.
File traversal and illegal file uploads
The first step of the attack was to analyze the upload function of the website, which was a simple HTTP POST request to an upload.php script. We can easily inspect and manipulate our request by using some open-source tools to find out that the server is susceptible to path traversal using invalid filenames (i.e. ../../file.example). This allows us to upload files outside of the intended directory as well as access files not typically allowed (i.e. /etc/passwd)
Shell access and data exfiltration
In the Slickwraps breach, this allowed the attacker to upload a custom .htaccess fill, which allowed them to view different indexed directories like file uploads (the images that customers were uploading) and résumés and anything else stored in their media folder.
Now that we have access to indexed directories, we can try uploading a well-known PHP shell (p0wnyShell) to give us shell access to the server. Since the server does not validate what file types are being uploaded, our PHP script gets uploaded without any issue and we can execute.
Once shell access is given, the script allows the actor to upload and download files, as well as change directories. This was one of the ways the actor was able to download the SQL database.
Since this web server is primarily for uploading files, inspecting traffic for downloads from this machine proved to be simple and let us quickly see our attacker downloading ~4GB of data.
Before going too far ahead, I want to take a step back and talk a bit more about what the webserver would expect for legitimate traffic. This image above shows me uploading an image file (JPG) to the server, which we can see has a MIME type of “image/jpeg.”
The next image shows us uploading/accessing the PHP shell that we also uploaded. A couple of things stand out here.
First, that the URL being accessed shows “shell.php” with some different options appended to it. Even if we named our script something less sinister, these options still stand out.
Next, we see the MIME type as “application/json,” which is how the shell commands are passed to the PHP script. Using some metadata alarms, we could look for any suspicious MIME types or exclude the ones we expect (e.g. image/jpeg , image/png..etc)
Last but not least, the attacker set up a remote shell to keep persistent access to the system. They didn’t go into detail on what they used, but if I had to guess it was Netcat or a similar tool. We can execute Netcat from our infected host, which then gives us a persistent shell that we can use to access the web server whenever we want.
Metadata analysis and post-infection cleanup
Hopefully, you found this insightful and learned a couple things about the power of metadata for detecting malicious traffic. Another huge benefit of metadata is the ability to go back in time to see exactly what happened on the network. I am not saying metadata would have prevented this attack (since there were a lot of exploits used and bad practices), but it would have helped clean up the situation and confusion on what happened. If you have a breach that you would like covered in this series please reach out to our team to get it covered!
