How a college student tricked 17k coders into running his sketchy script

Infecting military and government software engineers is easier than you may think.

Dan Goodin – Jun 14, 2016 10:10 am | 78

Attackers’ target of choice

Attackers who conduct espionage campaigns on government and corporate groups frequently regard developers as their target of choice. That’s because developers have high-level access to sensitive networks and also have the control over the code that other people inside a targeted organization execute on their computers. Case in point: a string of attacks in 2013 that targeted software engineers inside Facebook, Microsoft, and Apple by first infecting an iPhone developer website the employees were known to visit.

In the months following the attacks, Facebook and many other large organizations began restricting or outright blocking Java, Flash, and other browser plugins known to be vulnerable to drive-by download attacks. Tschacher’s research suggests that despite those measures, it may still be disturbingly easy for attackers to infect developers.

The 25-year-old student titled his thesis “Typosquatting in Programming Language Package Managers.” The technique has its roots in so-called typosquatting attacks, in which attackers and phishers registered domains such as gooogle.com, appple.com, or similarly mistyped names that closely resemble trusted and widely visited domains. When end-users accidentally entered the names into their address bars, the typos sent their browsers to malicious imposter sites that masqueraded as legitimate destinations while pushing malware or trying to collect user passwords. Then, in 2011, security researcher Artem Dinaburg introduced an attack he called Bitsquatting. It built off the spirit of typosquatting but instead of relying on end users entering the wrong domain, it capitalized on random single-bit errors made by computers.

Tschacher’s attack worked in a similar fashion. He first identified 214 of the most widely downloaded user-submitted packages on PyPI, RubyGems, and NPM, which are community websites for developers of the Python, Ruby, and JavaScript programming languages respectively. He then uploaded his untrusted code to the sites and gave them names that closely resembled the 214 packages. The student’s benign script provided a warning that informed developers that they may have inadvertently installed the wrong package. But before it did, the code sent a Web request to a university computer so he could keep track of how many times his untrusted code was executed and whether administrative rights were given.

It’s not clear if the experiment broke ethical or even legal boundaries, since it relied on confusion if not outright deceit to trick people into installing something other than what they intended to install. Still, the lesson the experiment imparts is worth heeding.

“I think we’re pretty well aware of the fact that if you install a random third-party module that no one has vetted and you don’t know, there is inherent risk because it could do anything,” Azimuth Security senior researcher Dan Rosenberg told Ars. “The novelty here is [that] even if you know and trust a module, if you make a typo you could still be running untrusted code.”