Third-Party Code: Fertile Ground For Malware

Modern websites rely on many moving parts operating behind the scenes, which often include a mashup of Javascript, content, files, applications, and digital ads. Some of this code may be written by website owners, while the rest of the content can be any combination of resources called in from different locations on the Internet and under the control of third-party organizations.

The problem with remotely called third-party code is that it is only activated on a visitor's web browser and, as such, bypasses the site's web server where most security measures are implemented. If the remote host is compromised, the third-party code can be manipulated into serving up malware on any site accessing it -- totally unbeknownst to the website operator.

Depending on the goals of the attacker, the malware could be used to gain entry into a corporate network. Often, compromised websites are turned into a malware delivery agent infecting thousands if not millions of unsuspecting site visitors.

RiskIQ was recently involved in the discovery and disclosure of real-life example of this type of infection. Our researchers discovered RIG exploit kit embedded on an important and highly trafficked website. The culprit was a fake URL embedded on the website by a script tag call to a third-party resource. We suspect that RIG was designed to install data-stealing malware on jQuery users' computers, because these individuals -- typically web developers and systems administrators -- have high-level access credentials.

This made us curious as to how prevalent the usage of third-party code is on the public Internet. Adam Hunt, RiskIQ's resident data scientist, commissioned a study, and for this blog he's offered an excerpt of the data and some of his methods.

The purpose of this study was to quantify the number of libraries on a given domain, the number of third-party hosted resources (jQuery locally rather than hosted on a CDN), and the number of other hosts/domains/organizations that use that resource. Explains Hunt in the research:

In order to run this test we intentionally distributed the data collected from RiskIQ’s web crawling infrastructure across many computers due to the size of the dataset (3 to 5 TB per day). We used a custom built resilient distributed dataset (RDD) designed to read our RiskIQ custom data structures (data collected every day from all over the web). We used Apache Spark to query and pivot on a fraction of this data.

In a sample of over 2.5 million unique URLs collected over an 8-hour period, we aggregated the number of times javascript was retrieved from a third party. We discovered that roughly 70% of these URLs were running third party JavaScript via script tags being retrieved from one or more outside sources. Of the 295,000 unique hosts from that sample, we observed that 90% retrieved a remote resource. Examples of these resources would be: Google Analytics, Twitter, Pinterest, the Facebook like button, etc.

Ostensibly, there's nothing wrong with using third-party resources to operate a website. For instance, just because a resource is pulled in from a remote domain doesn't mean it’s malicious. In fact, the majority of domains belong to well known third-party hosting providers, cloud providers, CDNs, and third-party code libraries.

The real concern is the need to rely on and trust the efficacy of the security measures implemented by third parties. Since external resources have become essential for serving up most websites, this is a risk most organizations are willing to accept.

Traditionally, spam has been the preferred method of malware distribution. However, spam filtering and email security has been steadily improving over the years. Consequently, it appears big-brand corporate websites are becoming a more popular method for mass distribution of exploit kits capable of installing dangerous malware such as Trojan, Spyware, etc., on vulnerable computers.

RIG and Angler Exploit Kits have become more prevalent in recent years and are some of the most virulent on the black market. In a separate study using threat intelligence data from our global blacklist feed, since June 1, 2014, we've observed exploit kits RIG and Angler appearing on more than 30 unique domains within the Alexa Top 1000 most popular website list. These sites are controlled by some of the largest and most powerful brands in the world, almost all of them infected by an exploited third-party resource running on their sites.

The jQuery hack illustrates the massive reach of third-party resource infections. According to reports on its website, literally tens of millions of websites pull from jQuery’s library, either directly via their sites or via their CDNs. From our sample we observed more than 800,000 URLs pulling in jQuery directly, while roughly 375,000 retrieve jQuery from a different domain. All it would take is for the breach we discovered to make its way to the code library or the CDN, and any website pulling code from jQuery could be infected. This could result in massive malware distribution.

Clearly, third-party website resources and code play an integral role in the online economy. They enable interactive sites that allow people to transact with their banks; buy medical insurance; watch movies or television; share photos, videos, and documents; and so on.

Unfortunately, these resources also represent exploitable infrastructure that is outside the control of an organization's IT security team. Addressing this emerging challenge requires looking at security from a new perspective, since it is not under the purview of traditional information security practices. In the meantime, it remains fertile ground for launching attacks and distributing malware.