This OWASP Top 10 item is one of the most common vulnerabilities, but it’s also one of the easiest to fix
When the average person thinks of a hacker, a certain image usually comes to mind. A shadowy figure in a dark room, surrounded by monitors, with pages and pages of code flowing by. Hoodies, sunglasses, and bottles of Mountain Dew may also be present. They’re working a sort of dark magic on super-complex systems, using their expertise to penetrate even the strongest of security measures.
Now sure, there may be some hackers that operate like this (especially the Mountain Dew part, need to get that caffeine somehow), using high-level skills and the most advanced methods to achieve their goals. Quite frankly though, it’s often much easier for them. As we saw when we examined the OWASP Top 10 List of the most common vulnerabilities, there is a wide range of exploits available to attackers, some easier to take advantage of than others.
Today we’re going to look at a type of vulnerability that is one of the easiest to exploit, requiring only a relatively basic knowledge of computer systems. It’s one that relies more on the lack of training and mistakes of end users, rather than the sheer skill of the attacker. But at the same time, it’s a vulnerability that could lead to the theft or destruction of your data, resulting in costly recovery efforts. We’re talking about security misconfiguration.
So, what is security misconfiguration? How does this vulnerability end up impacting businesses like yours? And what can you do to prevent security misconfiguration attacks?
Let’s hash it out.
What Is Security Misconfiguration?
Security misconfiguration is a broad term that can cover a lot of ground and be applied in many different areas. What’s common though, is that security misconfiguration occurs when best practices aren’t followed during the setup of security measures for an asset. The reason that security misconfiguration is viewed as a vulnerability is because attackers will try and exploit these mistakes to gain unauthorized access to the user’s system.
Security misconfiguration can apply to either devices or software. Operating systems, servers, and applications can all be affected. So can network devices, email servers, and end-user devices like laptops or cell phones. Basically, anything that has configurable security features can fall prey to this vulnerability.
When talking specifically about software, security misconfiguration can occur anywhere in the application stack. We’re talking databases, frameworks, servers, network services, virtual machines, containers, etc. And all it takes is one bad configuration in a single area. If an attacker finds something to exploit, then not only can it lead to them gaining access to a portion of the system data or functionality, but it can also snowball into a complete system compromise that brings with it devastating business impacts for your company.
Security Misconfiguration: An Easy Mistake to Make (and Even Easier to Exploit)
It’s now harder than ever to stay ahead of the curve thanks to the increased complexity of applications, OSes, and frameworks that are used by both data centers and cloud systems. All these various components are rapidly evolving independently of one another, which creates a challenge when deploying the appropriate processes and actions for effective protection. More and more enterprises are moving towards cloud services, and COVID-19 has accelerated this process even more as remote work has seen a full-speed ramp up. It’s easy to neglect security basics when plunged into such a dynamic, high-stress environment.
As we touched on, security misconfiguration vulnerabilities are viewed as “low hanging fruit” since they’re relatively easy to detect and exploit. It’s often the path of least resistance for an attacker that is targeting servers, applications, and cloud configurations for the purpose of causing catastrophic harm and creating costly data breaches. It’s a huge problem that is repeatedly being taken advantage of by hackers at an alarming rate, with a recent Output24 study finding that misconfiguration is responsible for a grand total of 82% of security vulnerabilities.
Security professionals now have less time than ever to understand systems that are only increasing in complexity. Areas will be missed, and human errors will happen. By being aware of the most common mistakes however, you can shut the door on a large percentage of security misconfiguration attack vectors in a fairly easy and straightforward way.
The Most Common Mistakes That Lead to Security Misconfiguration
Unnecessary features are not removed or disabled. This can be things like:
- Unnecessary ports being left open,
- Unneeded services permitted to run,
- Leftover pages still available to access, and
- Unused accounts with certain privileges not being deleted.
By not removing superfluous components, features, and code samples, you’re leaving the application open to attacks. Say, for example, the application server includes demo programs that don’t get deleted from the production server. If these demo programs have security vulnerabilities, then it’s possible for hackers to use them to compromise the entire server.
Default accounts and passwords are still being used. This is one of the simplest, yet most common items on the list of security configuration mistakes. All sorts of devices and programs come with a set of default credentials that allow the owner to initially access them out of the box. They’re present in network devices, web applications, and pretty much anything that requires authentication.
This isn’t inherently a problem, except for the fact that they often don’t get changed after the initial installation. By not having a policy requiring the changing of default credentials, you’re leaving yourself exposed to an attack. It’s easy for hackers to use lists of common default usernames and passwords to brute-force your system and gain unauthorized access.
Error messages reveal too much information. Default server configurations can lead to overly informative error messages, containing information like detailed stack traces, being returned to users. This can result in sensitive information being disclosed and can give attackers helpful information like which component versions are being used so they can search for corresponding flaws to exploit.
Old software versions or missed updates. Out-of-date software leaves your system exposed to known vulnerabilities that may already have patches (but of course, you can’t stay fully protected unless you regularly perform updates).
Upgraded systems aren’t properly configured. Upgraded software can bring with it new security features, but said features aren’t going to be terribly useful if they aren’t enabled or configured correctly. You’ll want to review every update to see what exactly is being changed/introduced/removed and adjust your configuration accordingly.
Cloud systems aren’t configured correctly. Cloud solution providers take a huge chunk of responsibility and workload off the laps of their clients. You can have your own cloud-based data center up and running in minutes, something that would’ve taken orders of magnitude longer previously. However, you’re still responsible for the configuration of your cloud resources.
AWS uses a “shared responsibility model,” for example. AWS takes responsibility for protecting all the infrastructure that actually runs the AWS cloud services. The customer, on the other hand, must properly mange their cloud OS, associated software, and the AWS firewall.
Debugging is left enabled. Most companies are setup in a way where they have two distinct environments, one for development and one for production. Debugging is enabled in the development environment because the greater amount of information that’s returned is helpful in refining the software and cleaning up errors. It shouldn’t be left on in the production environment though because hackers can theoretically trigger lengthy error messages that expose sensitive code-related information that can ultimately be used against you.
Unprotected files & directories are out in the open. Attackers can gain unauthorized access to sensitive files if developers neglect setting permissions on certain directories, dashboards, or admin consoles. Forced browsing attacks can be used to try and locate susceptible locations that can be accessed in the hope of finding restricted files.
It’s even easier for attackers if directory listing is enabled on the server. Then they can simply ask for a list of all the files and directories that are present. For example, a hacker could search for complied Java classes and grab them off the server. Then they can decompile the code in the hopes of finding an exploitable flaw in the application.
Real-World Consequences of Security Misconfiguration
Now that we know some of the specific ways in which security misconfiguration attacks can occur, let’s take a quick look at some recent real-life examples and ramifications:
MongoDB Databases
Earlier this year, a hacker targeted nearly 47% of all MongoDB databases on the internet. The common theme across them all? None were protected with a password. As a result, the attacker used an automated script to locate the vulnerable ones, delete their content, and leave a ransom note demanding payment to a Bitcoin address within 48 hours.
What’s even more disheartening is that similar attacks have been happening since 2017, but users haven’t been learning their lessons in significant numbers. The number of exposed MongoDB servers in 2017 was 60,000, and the number has only slightly decreased to 48,000 over the last three years.
Travel Firm’s Customer Data
In September of 2019, UK travel firm Teletext Holidays fell victim to a data breach that lead to the personal information of thousands of customers being exposed. Roughly 500,000 files that contained details like email addresses, home addresses, phone numbers, and birthdays were sitting out in the open on an unprotected AWS server, freely available for anyone that thought to take a look.
A Cache of Biometric Data
Similarly, a massive database of biometric data on over a million people was left unprotected and unencrypted by the company Biostar 2. It was found in August of 2019 by a pair of Israeli security researchers that were scanning corporate systems to find flaws that could lead to data breaches. The Biostar 2 database contained 27.8 million records, plus other data such as admin panels, dashboards, fingerprint and facial recognition data, access logs, and staff details. The database wasn’t read-only, either. If you had access, you could literally change a person’s fingerprint.
AWS Misconfiguration
One of the biggest causes of identify theft in the United States has become the exposure of AWS buckets. A major incident of this type occurred in late 2019, when pen tests found the personal data of 750,000 citizens sitting in an unsecured AWS bucket. It was a stash of birth certificate applications, protected without even a password, that exposed “the applicant’s name, date-of-birth, current home address, email address, phone number and historical personal information, including past addresses, names of family members and the reason for the application — such as applying for a passport or researching family history.”
The Cost of Human Error
As we’ve seen, human error is a primary cause of security misconfiguration, such as in the case of a Spring contractor misconfiguring a cloud storage bucket and exposing hundreds of thousands of mobile phone bills. Mistakes happen, and oftentimes its merely a case of people forgetting or simply not knowing that certain defaults need…