Introduction
I believe this name was chosen to be as ambiguous as possible for one of the Top 10 OWASP vulnerabilities. It can encompass anything and everything related to configurations but if we do some effort it is possible to define a general testing guide for security misconfigurations by looking at the common properties of all the issues we can find in write ups and activities.
The following properties of a system will usually point to a likely vulnerability though some of these properties are a bit more ambiguous and harder to test.
All of these best practices serve to cover a particular goal but we also need to know what these goals are so we can test with precision.
This can be anything from an exposed admin panel to damaging well-known exploits. Pretty much any attack that can be performed over the network and relies on configuration can be put into this category.
Companies often use services like S3 buckets from amazon without properly understanding them. This might lead to misconfigurations happening which could allow things like unauthenticated access.
Just like we already talked about in chapter 5 (Broken access control), we can use the OPTIONS http method to find out which http methods we are able to execute and sometimes this might concern http methods which are not fully implemented on the server.
This is not interesting at all for bug bounty hunters but pentesters should reports this as a best practice. A website should always force the user onto the https version of the website.
Hunting for security misconfigurations requires some special conditions because you need to either have a confirmable guess at a certain configuration or have access to how a system works by for example looking at it's source code on github. You will also need to confirm these findings though since an unconfirmed vulnerability isn't really one at all.
We can start by doing some google dorking and looking for conf files or yaml or xml or anything related to configurations.
Besides google dorking we can do the exact same thing for github where we might have some more luck as usually developers will mask things like passwords by putting them into environment variables but they leave all the other settings in plain sight.
Whenever you come across a configuration file it is up to you to find out exactly what every setting is for and if that setting can be unsafe by simply googling around and even just reading the manuals of the components for which those config files serve.
A good eye for detail netted this hacker 300$ by hunting down an API key while doing bug bounties.
https://hackerone.com/reports/1066410
During his attempts we can see he found a file containing a google API key. This API key was used for shortening URLs which would allow an attacker to mask their URLs as a URL of the company. This can lead to all kinds of phishing and scamming attacks. During the attack, it was also noticeable that an open redirect was possible where the url “https://lnk.clario.co/?link=[URLHERE]would accept any URL, as long as it had “clario.co” in it. These are some great examples of security misconfigurations where we have private tokens in a public script and where an open redirect was possible on a different endpoint.
Another great example was found by a user called “yourdarkshadow” who discovers that a header is not set properly leading to a security misconfiguration. https://hackerone.com/reports/12453 This was the Strict-Transport-Security header which protects websites from so called “downgrade” attacks.
Watch the video:
Subscribe for the latest news