… we want them all. Vulnerabilities submitted to us from our Detectify Crowdsource community of 150+ ethical hackers makes Detectify what it is, and it is because of this collaboration we can make the internet more secure. Our community provides us with research, which we automate into our scanner and we reward the ethical hacker responsible for submitting the vulnerability every time it is found by our scanner. There are four main types of vulnerabilities we prioritize:
CMS core vulnerabilities:
We’re starting out with the backbone of a system – the core. Now, as with some of the other vulnerability types on this list, CMS core vulnerabilities includes many different technologies. Simply put, CMS core vulnerabilities means vulnerabilities affecting the core of Content Management Systems (CMS), systems such as EpiServer, Drupal, Magento, WordPress core and many more (Crowdsource members can log in to see our list of prioritized technologies here).
An example of a CMS core vulnerability could be a remote code execution on Drupal. But remember, it can also be a vulnerability opening up for a XSS attack (cross-site scripting attack) or a CSRF attack (cross-site request forgery attack) targeting any other CMS too- At the end of the day, CMS core vulnerabilities are defined by the fact that they affect core systems themselves.
Third party misconfigurations:
Sometimes, vulnerabilities show their ugly face in (what seems to be) perfectly safe places. Only through certain combination of, what should be perfectly viable settings, do these vulnerabilities appear. What this means is that some combinations of optional settings, that a user can choose from, can open up for vulnerabilities. And while these mishaps are not necessarily bound to a specific type of technology per se, they are not any less important, as the results can be devastating. An example of this is the Amazon Web Service (AWS) S3 buckets misconfiguration. While AWS are aware of the security issue following the misconfigurations, they are not likely to mitigate it since it is caused by the user.
Coding mistakes:
Let’s be blunt. Sometimes you simply forget things, no matter how important they are. We are all human, and that’s the problem. In other words, these are vulnerabilities that are not caused by any plugin or CMS, but rather occur due to common mistakes in programming. An example of this could be to not protect against adding a forward slash to an URL. If you make a request to https://example.com/test, the server will respond with a location-header with /test/ as value. In other words, it will send you to a specific location on the example.com webpage under /test/. However, if you added an additional slash to your request, https://example.com//test.se, the location-header will now point to //test.se/ which is an external domain. This might seem harmless, but this error could lead to some nasty re-directions.
While these mistakes are often taken care of through reminders and proper coding procedures, these vulnerabilities (i.e. mistakes in general) are technology agnostic, which means they can appear everywhere.
Extension vulnerabilities:
Unsurprisingly, extension vulnerabilities made the list and this refers to extensions or a plugins directly, not the technology the plugin is built upon (eg. WordPress plugin Jetpack). Due to this, these vulnerabilities can affect many types of extensions and are certainly not limited to WordPress.
In conclusion:
What should be noted is that when we are looking for vulnerabilities, we are not in any way excluding unoriginal research. What we mean by this is that Crowdsource ethical hackers submitting vulnerabilities to us do not have to be the underlying researcher themselves. If a vulnerability is stumbled upon online, and we have yet to implement it, we will gladly accept it. Our Detectify Crowdsource community is at the forefront of security research, which helps us continue to provide a cutting-edge automated web application scanner.
Are you a part of the Crowdsource community? Submit a module here!