CleanSlate Blog

Just How Easy is it to be Hacked?

Earlier this year, David Gilbertson published an excellent article on Hacker Noon with the eye-catching title “I’m harvesting credit card numbers and passwords from your site. Here’s how.” While the article is noted as a fictional endeavor, the approach that is detailed is certainly something that could have a negative impact on corporations around the world.

A Relatively Simple Approach

In the author’s pseudo-confession, he states “I’ve been stealing usernames, passwords and credit card numbers from your sites for the past few years.”

Gilbertson went on to detail how his code looked at form fields with standardized names (password, card number, CVC, etc.) and relied upon built-in events to execute the following tasks:

  • Digest data from all form fields (document.forms.forEach(…)) on the page.
  • Grabs document.cookie from the session.
  • Transforms the information into a random-looking string const payload = btoa(JSON.stringify(sensitiveUserData)).
  • Sends the data to a domain he manages, between the hours of 7 pm and 7 am (local browser time).

How Does His code Work?

At the heart of the attack, is the uber-popular implementation of npm. For those who are not aware, npm is a JavaScript package manager and at the core of products like grunt, bower, gulp, browserify, and cordova (just to name a few).

“Lucky for me, we live in an age where people install npm packages like they’re popping pain killers.” – David Gilbertson

In David’s (fictional) approach, he decided to leverage npm as his distribution method. Creating a library that allows console log messages to be displayed in color, he figured other libraries would welcome his functionality. After all, seeing colors on the console is pretty cool, right?

Next, he used several accounts to submit pull requests (PRs) to various front-end packages and dependencies. The PRs focused on making a much-needed fix, then added his logging functionality as well. Developers going the extra mile is always a welcome thing, especially in open-source projects.

The PRs would be approved and the fix would be deployed, as well as his way-cool colorized logging package. The only issue is that his way cool package also included the functionality to perform the tasks noted above.

Once his PRs were approved, he started to see ~120,000 downloads a month – with none of the customers expecting any issues. As a result, he began receiving torrents of usernames, passwords, and credit-card information. Some of those arrived from Amazon Alexa-top-1000 sites as well.

Are We Doomed?

While Gilbertson states his endeavor was purely fictional, the simple nature and potential for wide-spread deployment is very concerning. The biggest challenge is getting development teams away from simply accepting packages that are available via services like npm.

In a perfect world, every package (and all associated dependencies) would be analyzed, reviewed, and scanned at the version level, prior to being implemented. In the real world, this feat is daunting at best and unlikely to be utilized. As a second layer, the QA effort (in a perfect world) would be mindful of monitoring network activity when updates are being validated. However, the real world typically yields a laser-focused eye on the item being addressed with the fixes/enhancements, often leaving broader topics (like network activity) unaddressed.

Agile teams utilizing Scrum typically allocate 20% of a given Sprint cycle for technical debt. Perhaps, some of this time can be spent gaining an understanding of the packages and dependencies that are being introduced from the prior Sprint – if not the current Sprint.