Using components with known vulnerabilities – OWASP10
Hi all and thank you for tuning in once again!
This week we will be talking about another OWASP Top10 entry: the usage of components with known vulnerabilities.
Components with known vulnerabilities are often, but not always, the first vulnerabilities that are detected during a penetration testing assignment. This is due to the first inevitable step: mapping out your attack surface and gaining as much knowledge of the web application and supporting infrastructure as possible. By using simple port scans it is possible to gain knowledge of most services that are running on the web server. These services consist of applications that could be outdated or the libraries that are used by these applications could be outdated.
A problem with outdated applications and libraries is that there is a bigger chance of known vulnerabilities having been published, thus increasing your attack surface. The impact of the usage of outdated components depends on several factors such as the functionality and accessibility of the application that uses these components, but the impact is mostly related to the nature of the vulnerability that is present in the outdated component.
This can be exemplified by using a recent penetration testing engagement:
Company X is interested in performing a penetration test on a web application. This test has to be performed from a black box approach, meaning that we will not receive more information other than a URL.
After a TCP port scan on all 65535 ports, only port 443 seems accessible. So far, all seems fine and dandy but in order to gain more information about the web application, we can check the HTML source code. And after some digging we come across multiple references to a well-known Content Management System, Drupal.
Drupal has several characteristic folder and file names that are definitely worth probing and these default files are usually removed due to their informative nature. These files contain information about the environment and this is exactly the kind of information an attacker needs to set up an attack vector.
One of the files that we are looking for is CHANGELOG.txt. This file should normally not be accessible or be removed completely, but due to a security misconfiguration all users are able to view this file. After opening CHANGELOG.txt we are able to determine the used version of Drupal.
Searching for this version number using Google will give us a plethora of different vulnerabilities. One of these vulnerabilities stands out immediately due to the dangerous nature; it is possible for an unauthenticated user to add an administrator user by performing a SQL injection attack.
A great way to illustrate the ominous presence of the usage of vulnerable components is to use Google in combination with some good old Google dorks. A malicious user could easily exploit the situation described above by searching for CHANGELOG.txt files on Drupal installations:
Drupal installations vulnerable for SQL Injection
As seen in the screenshot above, we managed to find several vulnerable Drupal installations that are vulnerable for the SQL Injection described above.
Good news, when compared with other OWASP Top10 entries, is the fact that automated scanners easily detect outdated components. The Outpost24 OUTSCAN & HIAB modules are perfectly suitable for detecting the usage of outdated components that contains potential vulnerabilities.
