[BreachExchange] Just How Easy Is it to Be Hacked?

[Audrey McNeil]

https://dzone.com/articles/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).

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.

Have a really great day!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riskbasedsecurity.com/pipermail/breachexchange/attachments/20180502/93e0e4d3/attachment.html>