They say that programming is the closest thing to magic that we have today. And you know what? They’re right. A few lines of code that look like nothing but gibberish to the uninitiated – and you can create entire worlds. How is it anything but magic?
On the opposite side, a few different lines of code can create the most intricate security systems. But the more intricate they are, the harder they fall. That’s where software security threats come in. Threats like security misconfiguration make systems, large and small, vulnerable to all kinds of cyberattacks.
Is security misconfiguration the most pressing threat though? And what entails this, truth be told, somewhat vague term anyway? Read more to find out.
Security Misconfiguration: Explanation, Examples, Prevention
A catch-all term (to an extent), security misconfiguration covers security controls that have been left insecure or misconfigured, putting the data and, at times, the entire system at risk. Plain and simple, any technical issue across any component that may arise from the app’s configuration settings and not bad code can be classified as a security misconfiguration vulnerability.
Botched default settings, shoddily documented config changes, incorrect permissions, you name it – all of them fall under this umbrella.
The most frequent ones usually come from the simplest mistakes (like the examples down below). But there’s nothing simple about the consequences that organizations often face due to these mistakes. From sensitive data exposure to complete server, web page, and application takeovers, security misconfiguration has caused serious damage to countless companies in the past. And, considering the #5 spot on OWASP’s top 10 web application security risks that this threat earned last year, it’s not going anywhere. So, you can pray it misses you, or you can learn more about security misconfiguration, including how to prevent and manage it.
Sounds good? Let’s go then.
How Security Misconfiguration Happens
As we’ve learned before, there are more complex and unusual security misconfiguration vulnerability reasons, but there are also some incredibly simple and common ones. The latter include:
Debugging Enabled
Most companies work with separate environments. Picture this: you enable debugging in a development environment to accelerate the debugging progress. Nothing unusual, right?
But there’s also nothing unusual about forgetting to disable this little feature before the production stage. So, all the attackers have to do is trigger the verbose errors that contain internal data, and, et voilà, they’re IN.
Default Credentials
A trivial concern more often than not, but default credentials can, at times, wreak serious havoc too. And, nine out of ten times, security misconfiguration is the culprit behind it.
You see, default credentials are usually shipped with a multitude of built-in solutions. These can be found in web apps, different network devices, just about anything that requires authentication. And, when you don’t change them once you’re done with the installation part, you’re opening the doors wide open. And, who could have guessed it, the first people to walk through these doors are usually hackers.
Misconfigured Permissions
Negligence. It’s always negligence. But, yeah, even the best devs will sometimes forget to set the right permissions on exposed (publicly too) directories, admin consoles, and dashboards. So, even the least skilled hackers can access these unauthorized files hassle-free.
Now, you might think the issue here is a broken access control exploit, but that’s not the case. No, BAC is the result, but the party to blame here is a security misconfiguration issue. It was present before the module reached any web app feature, it’s just that you usually find it out at that stage.
Cloud Misconfiguration
Cloud is a beautiful thing. Thanks to cloud storage and file-sharing solutions, small-time firms and powerhouse companies alike can spin up whole data centers in minutes, all without worrying that they might not have the required resources.
But with great freedom comes great… you know the spiel. More than that, the companies that use these solutions have to follow the shared responsibility model. That is, what happens in the cloud stays in the cloud is the customer’s responsibility, not the owners of the cloud service.
What that also means is that, like it or not, the breaches that happen due to security misconfig in the cloud will keep popping up. To give you a quick security misconfiguration vulnerability example, the Amazon S3 misconfigurations alone totaled above 400k Google results, which included security breaches from the biggest names in the game.
Hardware Misconfiguration
On the opposite side, network and different security devices can also be misconfigured, causing real problems both down the road and from the get-go.
What happens quite frequently is network engineers being a little lax with network device configurations. And, we get it, troubleshooting network problems can be a drag. But that’s no reason to forget the following security configuration.
Because when you don’t do that (or when you half-ass it), attackers might have a chance to access internal assets, pull off reverse shells without any restrictions, and more. Plus, misconfigured solutions like IPS, SIEM, and IDS can create further security vulnerabilities. To name one, when you forget to set up a bind shell during the intervention part, hackers will have no trouble defacing your web page.
And these are just scratching the surface. Security misconfiguration vulnerabilities also happen due to:
- Enabling unnecessary (usually default) features like useless services, accounts, privileges, ports, pages, you name it
- Working with insecure headers and directories or setting them to insecure values
- Overlooking the security settings (meaning also NOT setting them to secure values) in the app servers, app frameworks, libraries, databases, etc
- Using vulnerable and/or outdated components (which, btw, is just behind security misconfiguration on the above-mentioned top 10 web application security risks from OWASP)
- Not implementing appropriate security hardening measures across the app stack (just about any part of it)
- And, last but not least, not disabling default accounts with standard passwords (yeah, believe it or not, that happens A LOT).
Sounds a little vague anyway? Let’s look at a few examples of misconfiguration attack scenarios then.
Possible Attack Scenarios
The app server comes packaged with sample apps that haven’t been removed from the production server. Oftentimes, these sample apps include known security flaws, security flaws that attackers can exploit to compromise your new server. Say one of these apps is an admin console with enabled default accounts. In that case, all the hackers have to do is access that console with a default password and, that’s it, he’s the captain now.
The directory listing has not been disabled. Again, not an uncommon scenario, as unfortunate as it is. Hackers probe servers for this vulnerability first and foremost. So, say they discover that they can simply list directories. A little more complicated, but experienced attackers will then have no problem finding and downloading the compiled Java classes. From there, they can decompile and reverse engineer these classes to view the server code. At this point, locating a critical access control flaw in the app is a matter of when, not if.
The app server’s configured to return detailed error messages (like stack traces) to users. In this scenario, you can leave all kinds of underlying flaws exposed. Sensitive information, sure, but also the component versions that have well-known vulnerabilities. When they find those out, there’s no limit to what hackers might be able to do with your server. And, as you can guess, all they need to do (and, chances are, WILL do) is request these detailed error messages, which is child’s play.
The cloud has default sharing permissions open (and available to anyone who’s nice enough to ask) by other users of the service. Remember the shared responsibility model that we’ve mentioned before? Yeah, that’s the one. It means that, sometimes, it doesn’t even have to be you. It’s enough for one of your cloud neighbors to forget to disable default permissions and, using them, cybercriminals can access your sensitive data within this cloud storage service. Depending on these permissions, hackers might even be able to gain high-level access to the system.
Think that these are just hypotheticals that don’t happen in real life? Think again.
Security Misconfiguration Real-Life Examples
Security misconfiguration vulnerability issues are as old as any security measures themselves, so we’ve seen countless examples in the past. Here’s but a couple:
The NASA/Jira Incident
You’d think that one of the most technologically advanced and progress-driven companies in the world would know better. Alas, they didn’t.
All it took was one humble security enthusiast to identify a security misconfiguration in the biggest (and maybe the most disliked) collaboration tool out there – Jira. This one default authorization misconfiguration moment left multiple Fortune 500 companies, including NASA, vulnerable. Through this vulnerability, third parties were able to access internal user data, including names, email IDs, project details, and other sensitive information.
What happened? When Jira developed dashboards and filters for individual issues or entire projects, the visibility settings were set to All users and Everyone by default. Of course, ideally, things like roadmap tasks should have been shared within the organization, but the “beloved” Jira shared them with the public.
Key takeaway: Make sure you review the file-sharing configurations in each SaaS you use to avoid exposing confidential data.
Amazon S3 Mishaps
Amazon’s Simple Storage Service, also known as Amazon S3, has been abused by hackers more times than anyone can count. From the misconfigured S3 bucket that revealed 50,000 patient records in the U.S. to the ones that exposed over 80 US municipalities, the attackers spared no one.
Even the United States Army Intelligence and Security Command has leaked several sensitive files in the past due to Amazon S3, including OVA (Oracle Virtual Appliance) volumes with portions marked top secret.
Key takeaway: The fact that hundreds of corporations (including military and government agencies) rely on Amazon S3 doesn’t mean it is secure. In fact, looking at the dozens of security events in the past, you should carefully monitor the service’s authorization if you do decide to use it.
How to Prevent Security Misconfiguration
Remember how security misconfigurations happen? Yeah, that’s what you should avoid doing. In other words:
Disable Debugging. When you move the app from the development stage to the production stage, make sure to double-check all debugging features in the entire config. That’s right, they should ALL be disabled.
Change Default Credentials. The first thing you should do once you have installed any piece of software is change the default credentials. In fact, we would recommend making this a mandatory habit inside that company of yours.
Restrict Access to Administration Panels & Consoles. The second mandatory practice that you should implement company-wide is disabling access to administration tools before deployment. Needless to say, only those users that require them should have access to ‘em. Likewise, make sure to respect this practice with systematic audits.
Disable Directory Listing & Verify Directories’ Permissions. The deployed app should not allow directory listing, plain and simple. Apart from that, make sure that the permissions on separate folders and files are set properly.
Enforce Repeatable Security Hardening Measures. When it is configured correctly, a repeatable hardening process will make deploying other environments (that are also correctly locked down) fast and easy. So, make sure that the development, QA, and production environments are configured identically, using different credentials for each environment. Automate it and you’ll be able to set up new secure environments effort-free.
Use a Segmented App Architecture. A segmented app architecture ensures effective and, even more importantly, secure separation between its components and tenants. Besides segmentation, the architecture should incorporate containerization and/or cloud security groups (ACLs).
Keep the Platform Clean. Get rid of any unnecessary features, components, documentation, and samples. Besides being basically useless (hence the ‘unnecessary’ part), they’re also a security threat. Also, remove any frameworks that you don’t use. Ideally, you shouldn’t have installed them in the first place.
Let’s Recap
Security misconfiguration is an umbrella term for any insecure or improperly configured security control. When exploited, it lets hackers access confidential information or take control of the entire web page, server, or app. The impact of security misconfiguration has crippled countless giants in the past. So, make sure you educate yourself on the subject and follow the security misconfiguration prevention tips that we’ve covered above. Safe travels and may the odds be ever in your favor.
Configure it right: The ultimate security misconfiguration prevention cheat sheet
