The Equifax Hack: Web Shells in Action
DISCLAIMER: This post is for educational purposes only, we are not responsible for anything you do with this information.
I was reading the other day that the perpetrators (or maybe just their sales people?) were selling access to web shells after the Equifax hack and, after I got a few confused Twitter messages and other inquiries about web shells, I thought I would do a little tour of what a web shell is, how to detect them, and hopefully how to better prevent them.
WARNING: This post will contain some sarcasm because, well, I just can’t help myself.
A web shell is a piece of code (lots of times written in PHP since it’s popular and is what’s used to run WordPress – a favorite target of bad guys everywhere). This code will give the person connecting to it access to the underlying operating system of the target machine. It is literally a system shell running on a web server, it will allow you to do whatever the web server process is running as has permission to do and more importantly will allow you to access whatever the web server itself has access to.
If I were giving a test on web shells, this point would probably be on it and I might even make it worth a 100 points.
It’s important to realize that no one is going to breach your network with a web shell (well, if you get technical I suppose someone could use a web shell to run something to breach your network. But a web shell, by itself, isn’t a vulnerability). So, when your boss calls you into their office and screams, “What are we doing about this web shell vulnerability!?” they are sadly misinformed and ripe for parody. A web shell would be considered a payload if we’re using the Metasploit framework jargon and would be the thing an attacker would leave behind after exploiting a vulnerability. This would be the “maintaining access” part of the breach and in the Equifax case was apparently also a money making opportunity.
Alright, that all sounds good or really awful depending on your perspective, but how would you go about stopping someone from planting (yes, that’s the correct terminology) a web shell on your web server wreaking all sorts of havoc? I’m glad you asked.
Let’s make a list, shall we? These are really in no particular order:
- Run your web server as a lower privileged user. Most modern web server packages do this for you, but you should still have the “trust, but verify” mentality. This prevents the shell from being used as a higher privileged user (root or local admin). This is great for the local system, but as we will see there is more to do.
- Restrict your web server’s network. A perfect example is a public/internet-facing web server that has network access to an Oracle database it isn’t using. Why can it talk to it with unfettered access? Firewalls really do exist, they are not unicorns. Segment your network properly and restrict access to only that which is absolutely required…inbound and outbound.
- You’ve definitely heard this one before, but it bears repeating I suppose: Keep up to date with your vendor patches. I won’t repeat all the advice that goes with this one, but it’s definitely a good practice.
- Use a web application firewall or reverse proxy to further protect vulnerable web applications from naughty attackers.
- Pay attention to your penetration testing. Any penetration test worth anything will expose these types of flaws. If you don’t really read the reports then you’re just being negligent.
A word about detection. Prevention is fantastic, but information security is a multilayered discipline. So we need to monitor to make sure our protections are working and more likely knowing that something didn’t change.
I feel another list coming on:
- Log AND inspect all traffic to and from your web server. You’ll be amazed at the type of shenanigans you will see going on.
- Watch for “new” and unexpected files being put onto your web server. You are using some sort of file activity monitoring, aren’t you?
- While we’re on the above subject, why does your web server need to write to the directory it is served out of? (Hint: It most likely doesn’t and this one is probably more prevention but made more sense below the “watch for new” item)
- Are you monitoring SQL Queries? If you have a proper SQL logging infrastructure set up you can watch for weird queries to your database from your web server (or anywhere really). This can get intense depending on the application.
- Are you watching the outbound traffic from your web server? This is important because an adversary could be having the web shell “call home” to get instructions. This is pretty rare with web shells as they tend to be more interactive, but it can happen.
That’s about it for web shells. Next up is a video showing one in action.
About Hurricane Labs
Hurricane Labs is a dynamic Managed Services Provider that unlocks the potential of Splunk and security for diverse enterprises across the United States. With a dedicated, Splunk-focused team and an emphasis on humanity and collaboration, we provide the skills, resources, and results to help make our customers’ lives easier.
For more information, visit www.hurricanelabs.com and follow us on Twitter @hurricanelabs.
