Not only the fronted we see or the backend we don’t, are responsible to make an application be vulnerable. A dynamic web-application carries a lot within itself, whether it’s about JavaScript libraries, third-party features, functional plugins and many more. But what, if the installed features or the plugins themselves are vulnerable?

So, today in this article we won’t be focusing on any specific vulnerability, rather we’ll follow up with some nice burp extensions that will help us to identify the vulnerable versions of the software or the libraries installed within an application.

Table of Content

• Exploring the Burp Plugins
  • Software Vulnerability Scanner
    • Configuring the Extension
    • Fingerprinting the installed software
    • The Vulners.com API
  • Retire.js
    • Setting up the plugin
    • Dumping the Outdated JavaScript Libraries

Exploring the Burp Plugins

Over in all of our previous articles whatever scanner or the plugin we’ve used, they all dump almost the same results i.e., they basically identify and guide us about the existing vulnerabilities majorly on the basis of the OWASP top 10.  But, what about the software or the add-ons library versions that were embedded within the application’s frameworks, how we could identify them that they are vulnerable or not.

Thereby in order to dig the web-application at its maximum depth, burp suite offers some amazing plugins that scans the embedded software and the add-on libraries and then further drop out the one that have the outdated version or their versions are vulnerable to some specific exploits.

So, let’s explore the two most popular extensions, one that checks the version from its exploits database and the other simply checks for the outdated JavaScript libraries.

Software Vulnerability Scanner

Have you ever surfed vulners.com to identify the vulnerabilities founded by the different security researchers?

Not yet, then over with this extension, you’ll get a better understanding of the vulners.com exploit’s database or its scanning API keys and the other features that the web-application carries within.

So, let’s initiate by exploring, what this burp extension is?

The Software Vulnerability Scanner is one of the most popular burp extensions that scans the application in order to determine vulnerabilities in the software versions using the vulners.com API.

But how this plugin detects the vulnerable software versions?

In order to do so, this plugin follows either of the two –

1. It identifies the vulnerable software with the fingerprints or the CPE (Common Platform Enumeration).
2. It checks the vulnerable paths with the database and identifies whether any exploit can be used against that path or not.

Pretty complex scenarios, right!! Follow up with the article and you’ll find them the simplest.

Configuring the Extension

Let’s install the plugin by navigating to the BApp Store at the Extender tab and there we’ll try to find Software Vulnerability Scanner.

As soon as we find that, we’ll tune over to the right section and will hit the Install button to make it a part of the Burp Scanner.

And within a few minutes, we’ll get its tab positioned into the top panel as “Software Vulnerability Scanner”, let’s explore if first.

Navigating to the plugin’s window, over at the Scan Rules tab, we’re having two segregated sections one for the API and other for the Scan Rules. However, the rule book for the scanning part had been loaded by default, thereby we just need to set the API key.

Although this plugin is good to go without the API key value, there it will simply try to match the vulnerable path with the database. But if you want to embed your own key, you can hit the get token.. section and register for an API key for free.

As soon as we hit the button, we got redirected to the vulners.com user info page. Login and fill the input fields to generate the API key.

However, for this section, we’ll be working without the API key. But we’ll enhance its scanning capabilities by customizing it over into the options tab.

Let’s unflag the checkbox of Scope Only and hit the Use scan by location paths option. Although flagging this feature might give us some false positives as it will take keywords from the vulnerable application and then match them with the keywords present at the vulners.com’s database.

Fingerprinting the installed software

Once done with the configuration, we’ll thus turn our browser’s proxy and will surf testphp.vulnweb.com. As soon as the web-page boots up, we’ll roam around in order to generate some traffic.

Enough roaming!! Let’s get back to our burp suite monitor and will switch to the dashboard tab there. From the below image, we can see that the burp scanner was on  Live Audit, i.e. whatever we did or surfed, it got captured and was shared with the burp scanner.

But what about the Issue Activities, let’s explore it and check what it is having for us.

As soon as the extend window opens, we’ll sort its contents with the Issue type. From the below image we can see that the scanner found something stating “[vulners] possible vulnerable path found”. Seems like our configuration is working perfectly.

Let’s explore this issue a bit deeper, carrying up from the Issue details, it dumps about a number of exploits that uses the same path and are into the vulners database.

Let’s check the PacketStrom by hitting the “Exploit” button aligned with that. And as soon as we do so, we got redirected to the vulners.com website with the exploit data over it.

As we tried to search artisits.php, we got the path value similar to the one we had over at testphp.vulnweb.com.

However, you can analyze the other listed exploits too much in order to have a better understanding of how vulnerable the software version could be.

Once done, we’ll further move back to the Software Vulnerability Scanner tab at our burpsuite and will switch to the Results section there, which contains the vulnerable software versions aligned with their names and hosts and the Possible vulnerable software uses specific paths.

Retire.js

Dynamic web-application carries a number of libraries within themselves whether it’s React, Angular or JQuery, but what about their analysis part like how we could identify that the application we’re testing is having the outdated version of the JavaScript packages or not.

Thereby for the analysis part, we’re having one more amazing burp plugin i.e. Retire.js, its name itself reveals its work as “Retire JavaScript” i.e. it identifies the retired or the outdated versions (vulnerable) of javascript libraries that application is using.

Before involving more into the theory section, let’s jump directly to its installation. However, you can learn more about it from here

Setting up the Plugin

Back into the bApp store and we’ll search for the keyword “R”, and there the one with the highest popularity bar is our plugin.

However, due to its popularity and its reviews Burp Suite had made it available only for the Professional Edition users. So let’s hit the Install button at the right-side and initiate the installation.

Once done with the installation part, let’s check it over in the top panel. But wait !! Where it is?

Similar to Active scan++,  as soon as the plugin got downloaded, it got embed up with the Burp Scanner, but we can check its existence by switching to the Extensions section at the Extender tab.

Dumping the Outdated JavaScript Libraries

Once the plugin got configured, we just need to initiate the scanner and within a few minutes, we’ll get the output. But in order to capture a clearer result, let’s disable the other scanner plugins and we’ll only flag Retire.js

Time to surf a vulnerable application. So, for time being, let’s make it the OWASP Juice Shop and we’ll bypass the application’s login with ‘ OR ‘1’=’1’ ;

As we did at the testphp.vulnweb.com, we’ll do the same here. Yes, surf the website with the browser proxy ON to generate traffic.

After a few page visits, let’s move back to the burp suite dashboard and will check the Tasks tab there.

From the below image, you can see that we got about 32 Requests in the Live Proxy Audit.

Let’s check them out in the Issue Activity tab. Sorting the contents as per the Issue Type we for the jquery vulnerabilities lined up there.

Turning to the Advisory section, we can see that Retire.js has dumped a vulnerable jquery library that was used over profile web-page of the application. However, we can search the exploitation of this jquery library on google and then we’re good to go.

At last, let’s check the Response tab to analyze how the plugin detected the vulnerable jquery version. So, from the below image, you can see that as soon as we hit the right-arrow button, we got the vulnerable version highlighted there, as the developer didn’t notice about that the jquery version is passing over with the HTML code.

Author: Geet Madan is a Certified Ethical Hacker, Researcher and Technical Writer at Hacking Articles on Information Security. Contact here