Page 160 - Hands-On Bug Hunting for Penetration Testers

Framework and Application-Specific Vulnerabilities Chapter 9

It's all about the attack scenario. This is the most essential point: most guidelines for KCVs
get thrown out the window in the face of a valid attack scenario. Companies aren't
interested in contributing a patch upstream just to improve the jQuery attack
surfacebthat's a lot of time spent validating, communicating about, and fixing a
vulnerability ultimately on behalf of another organization. But if you can convince them
that this affects their business, it can provoke a change (contributing a patch, updating the
component, switching to a different solution for that service) that will trigger your reward.
This chapter will explain how to:

Integrate known component vulnerability scanning into your Burp-based
workflow
Use tools to find application-specific problems in software like WordPress,
Django, and Ruby on Rails
Take a component-specific vulnerability from discovery, to validation, to
submission

Technical Requirements

In this section, we'll be working with Burp and some of its extensions to set up KCV
detection automatically. We'll also be relying on our usual browser setup to act as the Burp
proxy. We'll also be using WPScan as both a CLI and a Burp extension.

The WPScan CLI comes with a variety of install options. Once again, we'll be using the
container software Docker to download and run the XQTDBO CLI from within the context of
a custom execution context packaged with everything it needs. Docker allows us to port
this workflow anywhere we can install Docker, meaning that we don't need to worry about
OS-specific behavior. And because Docker caches the WPScan CLI image, we can use it
with only a marginal performance hit over a native installation.

Assuming that Docker is installed, to pull down the latest WPScan CLI image, simply run
this quick command:

docker pull wpscanteam/wpscan

[ 145 ]