Software Dependency Failures: jQuery, a Canary in the Coal Mine
Keeping dependencies up-to-date is challenging for any software development project and even more so from a systems administration point of view. Too often you see packaged web projects, which have been put together and then forgotten. They contain dependencies to third party libraries, which never get updated even if the application itself is maintained – at least to some extent.
In my daily work I research the impact of vulnerabilities on the scale of the Internet. Most of the time, vulnerabilities in protocols, services and platforms keep me and other security professionals busy, whereas the upper layers and especially the web layer is often something of an afterthought. To find out whether there is a pink elephant in the room, I wanted to analyze a web application library which is ubiquitous and has had issues with vulnerabilities which are more or less persistent – which lead me to jQuery.
My hypothesis was that software dependencies cause hidden vulnerabilities in applications considered secure, even if they are otherwise developed or maintained as they should.
Dependabot to the Rescue
In a perfect world, I really wouldn’t have to do this kind of research, since developers and sysadmins had this in hand before the software gets deployed and whenever it is updated. To that end, a great way to keep the dependencies of your software project up-to-date is Dependabot, which you can find on Github. You can use it with GitHub (including GitHub Enterprise), GitLab, and Azure DevOps. We use it extensively in our own development work as well.
A Case Study on jQuery Vulnerabilities
Since we’re not living in a perfect world, I decided to study the state of jQuery, a popular Javasript library used in most web front-ends. More specifically, I wanted to look at a vulnerability with the largest impact in terms of version coverage. To that end, I discovered CVE-2020-11022, which affects most of the releases out there, apart from the three latest, namely 3.5.0, 3.5.1 and 3.6.0.
For the study to be representative, I defined cpe:/a:jquery/jquery_ui as my base group, which in total yields a population of roughly 1.9 million IPs over a 60 day observation period through Shodan.
Why 60 days? With our automated collection method through the Shodan search API, the number you see for a given Shodan dork equates roughly to 60 days worth of data represented as unique IPs. Using unique IPs is important as any given host or service may be scanned multiple times during that time.
The reason why I decided to use jQuery UI as the base group for my study is that these are web applications which:
- utilize more interactive javascript elements in their code
- are likely to represent a larger number of interactive web applications
- are more likely to be exploited in case they are affected by a software vulnerability such as an XSS.
jQuery UI is a curated set of user interface interactions, effects, widgets, and themes built on top of the jQuery JavaScript Library. Whether you’re building highly interactive web applications or you just need to add a date picker to a form control, jQuery UI is the perfect choice. – jqueryui.com
Since jQuery UI depends on jQuery, focusing on a vulnerability of a software dependency highlights the nature of these vulnerabilities in general. My hypothesis was that they are latent and persistent unless the developer is actively maintaining the dependencies of their software project in the first place – with a tool such as Dependabot referenced above.
Obsolete Dependencies - a Side Product
At present, the latest non-vulnerable versions of jQuery are 3.5.1 and 3.6.0. For my study, in addition to looking at the total population of vulnerable jQuery instances, I wanted to map out End-of-Life subjects as well. In the context of jQuery, versions 1.x and 2.x are EOL in addition to being vulnerable to at least CVE-2020-11022. In other words, these guys can be likened to Zombies hanging around the edges of long forgotten deployments and/or software development projects.
The State of jQuery Vulnerabilities Exemplified
Q: What did you find in practice?
A: Based on a sample of 100k hosts, my preliminary results are as follows:
- Approximately 26% of all the publicly reachable jQuery UI web applications contain a version of jQuery which is vulnerable to CVE-2020-11022.
- Approximately 21% of jQuery UI instances are EOL which raises my eyebrows even further.
Once I’ve done my 60 days of collection I will update these figures accordingly. Let’s see about lies, damn lies and statistics then.
What types of hosts are we talking about?
Looking at the HTML titles, I could get a sense of the types of vulnerable applications out there.
A cursory examination revealed a number of:
- online banking sites (also big brand names)
- cloud infrastructure management interfaces
- SSL VPN servers
- firewall management interfaces
- authentication pages with login in their title.
The list goes on and on, but I think I’ve made my point that these are not just static web pages out there.
jQuery, a Canary in the Coal Mine
Looking at the hosts with vulnerable jQuery components on them in further detail, painted a picture of a broader set of problems. In that sense jQuery turned out to be a great “canary in the coal mine”. What I mean by this is that discovering a machine or service with vulnerable and especially obsolete jQuery instances seems to be a good marker for discovering a plethora of other issues on those hosts, which are mainly due to lack of maintenance.
In practice, this means poor configuration management in terms of publicly exposed services which should not be exposed to the Internet in the first place. It can also mean that the services have other unpatched known vulnerabilities in them. In some cases the subjects looked like totally abandoned machines, which for some reason are still kept on the ventilator by someone paying the hosting bills.
jQuery as a Canary Example
I picked a random host from the EOL group and it turned out to be a pretty good canary indeed. It was running jQuery version 1.8.3 and what appeared to be some kind of an online marketplace and a CRM in the same package.
Based on the version number detection, Shodan claims that these vulnerabilities beyond the obsolete jQuery are present on the host:
$ jq '."vulns" | sort | .[]' example.json
"CVE-2015-9253"
"CVE-2016-5385"
"CVE-2017-7272"
"CVE-2017-7963"
"CVE-2018-19395"
"CVE-2018-19396"
"CVE-2019-9637"
"CVE-2019-9638"
"CVE-2019-9639"
"CVE-2019-9641"
You will notice that CVE-2020-11022 is not on the list, since that is based on my own heuristic markers in the data. I’m not going to dig into the vulnerabilities above in detail, but they mostly relate to vulnerable PHP versions.
My point here after all was to exemplify the canary in the coal mine aspect of vulnerable jQuery versions in the data set.
Handling Software Dependency is Difficult
In this post, I’ve only scratched the surface of some of the issues that stem from not handling a software project’s dependencies properly. As we saw above, these can relate to either software development or the maintenance of already deployed instances. I of course have been looking at the latter, which should be a non-issue – but is not.
The right place to keep the dependencies up-to-date is in your source code repositories and to make sure that you ship out applications which are maintained also from the dependency perspective. This methodology, however, only applies to you if you are the developer. As an end user, you should ask the vendor to provide you a software bill of materials, SBOM. In addition, you can turn to services which perform a software component analysis for you, such as Black Duck.
If, however, you are in a situation where you can do neither, a good starting point is to use service such as ours to validate that you have all of your ducks in a row (pun intended). From the software component analysis point of view, using Shodan for this is not the most optimal of approaches, but we wouldn’t be here if we lived in a perfect world either. I, for one, would rather be in Central France enjoying sumptuous wine and doing landscape photography (and not necessarily in that order). 😉
Since a lot of the above is related to IT asset management, you might want to read Tuomas Haarala’s thoughts on the subject as well.
Give Us Feedback or Subscribe to Our Newsletter
If this post pushed your buttons one way or another, then please give us some feedback below. The easiest way to make sure that you will not miss a post is to subscribe to our monthly newsletter. We will not spam you with frivolous marketing messages either, nor share your contact details with nefarious marketing people. 😉