3

I've been doing research on the OWASP top 10 web application vulnerabilties, one of them is using components with know vulnerabilities. I'm a little confused here, as I don't understand how you could possibly check a web application for this.

My understanding is that you would have already had to find a vulnerability within the site and successfully exploited it to figure out if there are any other known vulnerabilities in the site.

So my question is, how can you check if a web application (as the attacker) has known vulnerabilities in it without already having exploited the application successfully? Is this even possible?

Gyzo
  • 43
  • 6

3 Answers3

2

how can you check if a web application (as the attacker) has known vulnerabilities in it without already having exploited the application successfully?

There are various ways of fingerprinting a web application without having privileged access.

A common way to start is by identifying the versions of used libraries, frameworks and their respective plugins. This can be done by inspecting the source code, headers, guessing paths of readme files, etc. You'd then check if these versions are up-to-date or if there are any published vulnerabilities for them on the web.

As an example, take Facebook's blog https://newsroom.fb.com/. By looking through the source code, you'll quickly find strings indicating that they're using Wordpress, e.g.:

<meta name="generator" content="WordPress.com" />

Knowing that they employ Wordpress you may want to look for popular plugins that are known to be vulnerable. E.g., they seem to be using the AMP plugin, because there is a readme.txt at:

https://newsroom.fb.com/wp-content/plugins/amp/readme.txt

This readme reveals that they use the latest version 0.5.1, so the plugin seems up-to-date.

Another example would be https://stackoverflow.com where you can discover which version of jQuery they use:

<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.12.4/jquery.min.js"></script>

Although 1.12.4 isn't the latest version, there don't seem to be any immediately exploitable flaws.

As you can see, checking an application for known vulnerable components doesn't necessarily require privileged access since versions and configurations are often leaked.

Arminius
  • 43,922
  • 13
  • 140
  • 136
  • This makes a lot of sense. So basically everything I'd need to know (besides the plugin names and such) I can find in the HTML of the web application itself, correct? – Gyzo Nov 23 '17 at 00:23
  • 1
    @Gyzo You don't find *everything* in the source code but often you find enough to draw conclusion about the components a web app is using. Nonetheless, an audit by an external attacker can never replace a proper white-box test. – Arminius Nov 23 '17 at 00:34
  • It seems like creating a testing tool for this, would be a very large project – Gyzo Nov 26 '17 at 22:47
  • @Gyzo Actually, there are testing tools for different frameworks. E.g., there is [WPScan](https://wpscan.org/) for Wordpress. – Arminius Nov 26 '17 at 22:56
  • Yes I'm aware of those, but I mean, an all in one that is capable of testing any website, would be extremely difficult – Gyzo Nov 26 '17 at 23:19
1

Why do you have to be the attacker? The OWASP Top 10 is meant for application developers and their QA teams.

If you're looking for something meant for black-box pen-testers, there's the OWASP Testing Guide

The easiest way to detect A9 using components with know vulnerabilities is tool like OWASP Dependency Check that integrate into the product's build environment.

Mike Ounsworth
  • 57,707
  • 21
  • 150
  • 207
0

In addition to Arminius' excellent answer there are a couple of other ways to look at this.

First, if you're using a component with known vulnerabilities and it is exposed in some way, then that is all you need, because you can test for and exploit it directly. Some prominent recent examples have been the numerous parsing vulnerabilities in ImageMagick that were directly exploitable on sites that allowed arbitrary file upload, and then attempted to parse those files with vulnerable versions of ImageMagick. Or the "none" algorithm vulnerabilities that were present in a number of popular JWT libraries.

Perhaps most importantly though, remember that the primary focus for the OWASP Top 10 is not penetration testers in any case. There's an OWASP testing guide for them. The Top 10 is for developers, to help them think proactively about issues their applications may have. It's a far more straight-forward piece of guidance when viewed from that perspective, which is to know what dependencies and components your application is using, do the leg work to ensure that they don't have known vulnerabilities, and replace any that do, and in maintenance mode, don't forget about what your application is using so that when new vulnerabilities are discovered, you can react to them before they bite you like one of the Apache Struts vulnerabilities bit Equifax.

Xander
  • 35,525
  • 27
  • 113
  • 141