The Chrome Web store went live in December 2010, and by November 2011, Google was reporting millions of downloads per day, over 200 million active users, and a total of 750 million extensions downloaded.
However, the stunning success opened a Pandora’s box of security threats. Most antivirus companies viewed CRX malware as a low severity threat because it was limited to the browser environment and could not affect local files, only steal passwords, clicks and browser-related data. They were also much less common than other file types. This article, the second in a four-part series, covers various CRX threats that arose in the past, and the significant steps Google has taken to address them.
One of the features malware developers initially took advantage of was “silent install” for Chrome extensions (CRXs). This feature originally allowed developers to deploy extensions as part of another installation in the Windows operating system without user consent, making it an easy target for malicious threat actors. For example, the “I want this” extension, which was spread in May 2012. It was installed silently as an attack vector and injected ads into what were supposed to be ad-free Wikipedia pages.
Following “I want this” and other malware attacks, in December 2012, Google disabled “silent install” for Chrome extensions using the Windows registry, as well as all extensions installed silently. This made the Command-line installation much harder and the silent attack vector obsolete.
In June 2013, Google added new security measures to the Chrome Web Store upload process, scanning each extension before making it publicly available. This was an important step in securing extensions hosted in the Chrome Web Store, however malicious extensions were still available in third-party platforms and could still be installed natively in browsers or bundled with file downloads. Therefore, in May 2014, Google took the most significant step it has taken to date in the threat landscape, announcing that it would prevent Windows users from natively installing extensions that were not stored in the Chrome Web Store. It also automatically disabled all extensions not installed from the Chrome Web Store, with no option to manually re-enable them until they were migrated to the Web Store. According to Google, this step alone caused a 75% decrease in customer support requests regarding unwanted Chrome extensions in the year following the implementation. In May 2015, Google implemented the same policy for other operating systems.
Throughout 2014, Chrome also discontinued its support of the Netscape Plug-in API (NPAPI), an architecture from the ’90s used for content plugins such as audio and video, that allowed unrestricted local access and called unprotected binary code from JavaScript. NPAPI had often been abused by malware developers. A well-known example was Theola, an NPAPI-based CRX malware, installed by the Mebroot rootkit. It had video recording functionality and its unrestricted permissions allowed it to access sensitive data and intercept all network activity. It was able to collect private information such as credit card information and passwords submitted by the victims in web forms. In 2015, the option to manually enable NPAPI was also discontinued.
Following Google’s efforts, the threat landscape was transformed from the wild west to an exclusive club. Attackers have had to adapt and change their strategy. Instead of trying to infect as many users as possible, following Google’s gatekeeping efforts, the real challenge became bypassing Google security measures and trying to get into the Chrome Web Store.
Read this whitepaper to learn more about Chrome Extension malware
