We do a lot of penetration tests for a wide range of clients; whether they be healthcare, retail, nonprofit, insurance, banks, industrial or anything in between. Even though this includes a diverse range of industries, they all seem to make the same mistakes that result in the same findings test after test, year after year.
Albeit most of these findings are not critical and don’t typically result in us compromising your systems, they do provide vulnerabilities that could leave an attacker with a foothold on your network. Also, from a compliance standpoint, many of these findings fail basic compliance requirements.
Luckily, most of these findings are easy to fix, and most of them involve web server misconfigurations. This article provide an overview of what those vulnerabilities are, and why they are vulnerabilities. In a follow up to this article, I will include technical “how tos” so that you can resolve these issues.
In no particular order:
Clickjacking
To quote Wikipedia, clickjacking is “a malicious technique of tricking a user into clicking on something different from what the user perceives, thus potentially revealing confidential information or allowing others to take control of their computer while clicking on seemingly innocuous objects, including web pages.”
Now really, Brandon, what does that mean? Here’s the scenario:
Your company has a website, acmecorp.com that includes a login screen, or some sort of form that collects information. Your website doesn’t protect against clickjacking
I’m looking to target your users. So I buy acmecor.com (one letter off…), I make a simple page that loads your website. The trick is that I “magically” have hidden fields on top of your username and password field that users can’t see.
Your users come to my website because I’ve lured them somehow
As they enter their username and password, I capture it. If I’m “nice” I throw them over to your website and let the user continue using your application. I now have their username and password.
Why is this a problem? Because I can “steal” your website without your users realizing it. About 99% of pen tests and Web Application Scans identify clickjacking as an issue! Best of all, it’s a 5 minute fix!
Server Information Disclosures
Like a lot of things you buy, they require a little customization. If you buy a new car, you adjust the radio, the seats, the mirrors, etc. Maybe you buy some new floor mats or those window deflector things. Either way, you don’t just jump in it and drive away. The same goes for your web servers.
Straight “out of the box” most web servers give away too much information and aren’t configured for the Internet. Most like to brag who they are by exclaiming to the world what product they are, and often time their exact version. They also give us lots of information about what their capabilities are, and sometimes allow us access to stuff we shouldn’t.
This is a vulnerability because as an attacker I can look up every vulnerable your server us vulnerable to. I might even be given the scripts or software I need to break in. It’s almost like telling me your security code on your home security system.
What can you do? Basically, it comes down to taking the time to “lock down” your servers. I explain how in the next couple of posts. This leads me to our next common vulnerability
Out of Date Systems
Now that your server told me EXACTLY what version it is running, I can quickly Google that the server was released in 2012, or whatever. I know there are 20 newer versions of the server, and that the server has 25 serious vulnerabilities. However, if you ran the latest and greatest, and hid a lot of the details, I’d have a much harder time getting in. First, because you locked it down as I suggested above I don’t know the exact version you’re running, but secondly, you’re running the latest version. With that, few if any vulnerabilities are known and finding a way in is much harder. Now I have to painstakingly search underground hacker forums, the “dark web”, and other nefarious locations that expose me to the threat of malware and all the other bad of the Internet.
Forgotten, Abandoned or Test Systems
This one is especially for those that develop their own systems or have a large number of systems. In this case, test sites get forgotten about. You upgrade your portal but leave the old one one. Whatever it may be. In either case, you’ve neglected it, didn’t configure it right, and left the front door wide open.
We have had complete compromises of our clients from systems in which the client responded “Oh crap, I forgot that even existed!” Guess what, as a hacker, we didn’t “forget” because we just found it!
In short, if you don’t need it, don’t put it on the Internet.
Web Application Firewalls
Many of the attacks that you’ll see are “well known” and have been around for, in many cases, decades. However, many sites are still vulnerable to them. Sometimes your password standards are weak or a user uses a weak password. In many of these cases, a Web Application Firewall could help protect against the known threats and block them altogether. It can also “lock out” an account if someone tries to brute force it.
Some options include appliances such as Netscaler, Barracuda, or F5; some as web services such as Cloudflare or AWS; some are features on your firewall like Sophos XG or Watchguard; and some are even modules to your webserver such as Apache’s modsecuriy.
In any case, you should have one, and fine tune it to block common threats like brute force attacks, SQL injections and Cross Site Scripting (XSS)
SSL Ciphers and Protocols
SSL ciphers and protocols are often overlooked because they’re misunderstood. First let’s get the 10,000 foot view of what we mean by protocols and ciphers.
When a web browser connects to a web server (or two email servers connect to each other, etc) they do so using a protocol. That protocol, or in its simplest term, the language the two computers use to talk to each other, is either SSL or TLS. Once they’ve established which protocol they’ll use, they agree on which ciphers will be used for the actual encryption of the communications. To use an analogy, the protocol is whether you’re going to ship a package via UPS or the Post Office, while the cipher suite is how well you secure the package itself during delivery. This is overly simplistic, but hopefully somewhat useful.
With that said, the web browser and web server need to agree on which protocol and ciphers they’ll use. You can’t control which browsers are used to connect to your website, but you can control the list of available protocols and ciphers. PCI requires you use “modern’ and “secure” protocols and ciphers. For protocols it’s simple; you must use TLS 1.1 or newer (TLS 1.2 is preferred). That leaves out TLS 1.0 and all of SSL.
For protocols, we don’t have to have any in depth knowledge of what to use. What we do need is knowledge on how to get them set correctly. Configuration all depends on your web server. For Apache or Nginix we use a web utility called the Mozilla SSL Configuration Generator. With the proper config in hand (select “modern”), we simply copy and paste into our virtual host. IIS is actually easier to configure because of a free utility called IIS Crypto. Download and install this utility on your webserver and then select the PCI template from the template screen. Apply and reboot and you’re done.
In addition to Nginiz, Apache, and IIS, ciphers and protocols can be configured on many type of servers and appliances such as Citrix Netscaler, Exchange, F5, etc.
To test that you’ve “got them right”, you can utilize Qualys’ free tool called SSL Labs. This handy website will give you a grade and lengthy details of where you’ve gone astray. Scoring an A+ is not hard to do and you should be doing it for all of your web servers.
Conclusion
Did you notice a pattern here? Three of the five common findings are directly related to your web server configurations. In fact, we could argue all five relate to web servers. The reason is pretty simple and straightforward: web servers are the most commonly deployed web technology, and they’re the most varied in their content and configurations. Further, they’re easy to “set and forget” which is the worst thing you can do.
While these are only five findings, they are on at least 80+% of all pen test reports we create; and most importantly they’re all easy to fix. Stick around and I’ll (hopefully) have up some tutorials on how to better configure your web servers. I’m working on articles for Apache and IIS, which accounts for about 95% of all web servers we encounter.