Buck Rogers in the 25th Century

We're finally on the list to get fiber Internet at our house in the sticks. Thus, I'm in the process of converting my completely off the grid household into a relatively modern setup. I'm talking Cat6 cable runs, punch downs, a managed POE switch, and a few wireless access points. Might even get a weather station and a few cameras. Crazy, I know.

And to top it all off, I purchased an HP Z440 server workstation off of NewEgg¹. With a Xeon processor, 32GB of RAM, an NVIDIA Quadro video card, and a 1 TB SSD Drive, it's an adequate setup for XCP-ng and virtualizing all the things.

As I wax nostalgic, I'm reminded me of that time I wrote an academic paper about how NewEgg totally got compromised by a little outfit collectively known as Magecart.

Magecart?!?!

I grew up with Dungeons and Dragons, HeroQuest, Dragon Strike, Battle Masters, Final Fantasy, and Dragon Warrior. So when I think of the word Magecart I envision a Final Fantasy black mage careening down a mine shaft.

Maybe a little like Grandia? (Courtesy Let's Play Archive)

Or the old Final Fantasy 3/6² mine cart ride? In fairness, this was pushing the limits even back in the SNES days. (Courtesy Let's Play Final Fantasy)

Spoiler Alert! Magecart has nothing to do with the 16-bit era. It's a blanket term assigned to a group of threat actors. The catchy name originates from the Magento e-commerce platform (hence the Mage) and for the generic Shopping Cart of most checkout platforms.

Pixelated graphics aside, the Magecart threat groups specialize in the theft of credit card numbers from online e-commerce websites. So how do they employ their thievery? Let's take a closer look.

In The Beginning

In the beginning, there was HTML. HTML provided a way for web browsers to display content to the masses. It could format paragraphs, italicize and bold text, even gasp display images. This would be perfect, if all anyone wanted out of the Internet was to read Tolstoy all day.

But we demanded more. And thus, the concept of forms was born, where the masses could interact with their websites. And provide the answer to life, the universe, and everything. But mainly, they were a way to take input from the user. Which is somewhat handy when the website in question would like to acquire their major credit card number to purchase goods and/or services.

But HTML forms have several limitations³, one of which is the requirement to submit the entire form to the web server before getting any sort of feedback.

Consider a credit card transaction: You need to enter a card number, your name, your billing address (including the zip code), the expiration date of the card, and the CCV for fraud prevention purposes. With a standard HTML form, none of the fields can be validated prior to sending them to the web server. The card number should have only numbers, for example⁴. The expiration date should include a month and a valid year, and probably a little "/" in the middle that you may or may not have to enter.

And with a basic HTML form, all of that data has to be submitted to the server before any of the input can be validated.

Enter JavaScript!

JavaScript is a computer code language that is executed within the web browser. Among its many capabilities is HTML form validation.

JavaScript can check:

• If you entered a valid American Express, VISA, or MasterCard credit number
• If your expiration date is a valid month and year
• If your zip code is a five digit number.

It greatly enhances the user experience and reduces the burden on the web server. As InfoWorld puts it:

JavaScript lets us create a smoother alternative to this clunky flow of events. We can take the information from the form and submit it quietly in different ways; for example, we might update the data incrementally as the user updates the form.

But what if I'm an attacker? What if I can insert some JavaScript in your checkout page and submit it quietly in different ways? What if, when you enter your credit card number I submit it quietly to a little website that I have setup to steal your juicy, very valuable credit card information?

That's exactly what Magecart does. It inserts and/or modifies the JavaScript in a checkout form to quietly submit credit card information to the attacker's environment.

On the (in)Security of the Modern web

Surely, we would never allow an attacker to put their grubby little hands on our sacred web browsers. Right? Right?!?!?

As it turns out, web security is complicated. It's a spiraling web (pun intended) of Cross Site Scripting, Cross Site Request Forgeries, SQL Injection, Clickjacking, and dozens of other attacks.

As the inimitable James Mickens⁵ puts it in his lecture on Web Security⁶

"Suffice it to say the browser is now incredibly complicated. And so what does this mean from the perspective of security? Well, basically it means that we're screwed."

The specific attack we're interested in is known as form action hijacking, sometimes called formjacking or web skimming.

"Form action hijacking allows an attacker to specify the action URL of a form via a parameter. An attacker can construct a URL that will modify the action URL of a form to point to the attacker’s server."

Form action hijacking is what allows an attacker to silently send credit card details to a server they control. This was how NewEgg was compromised, and forms the basis of this little paper.

So tell me about this academic paper...

The paper was a final project for the Public Policy course in my Masters program. The assignment was to write about a security incident, analyze via the Diamond Model⁷, and determine what regulations or standards could be applied that may have prevented the incident.

In the case of NewEgg Magecart incident, I'll summarize a few key points:

• NewEgg was compromised by Magecart Group 6, the same adversary responsible for a previous incident with British Airways.
• The attackers registered a domain, neweggstats.com and requested a valid TLS certificate with Comodo. These lookalike domains are very common and are difficult to discern from the legitimate web sites.
• The attackers managed to insert their JavaScript web skimmer directly into the payment processing page, and at only 8 lines of code it would be difficult to detect by even the savviest of users.

• The skimmer hijacked the web form, sending the credit card number and other sensitive info to the neweggstats.com domain which was hosted on a bulletproof provider.
• A dark web posting claimed to have exfiltrated 500,000 credit card numbers over about a month.
• As a merchant, NewEgg must comply with the PCI-DSS. However, while they must notify their service provider in the event of a breach, there are no requirements to notify the general public. Thus, the exact extent and scope of the hack is not known.

If you're interested in reading the paper, you may find it here.

How could this be prevented?

As far as tangible recommendations for battling Magecart?

• Be very careful with any 3rd-party Javascript on payment processing forms. As the PCI Security Council puts it - "any third-party content included on a payment form is an opportunityfor an attacker to silently steal cardholder data"
• If you must include 3rd-party Javascript, use Subresource Integrity to validate that the script hasn't been modified by an adversary.
• As a consumer, be conscious of the web sites you share your credit card numbers with. If possible, use virtual credit card numbers that are only valid for a single use, especially with untrusted sites.
• Hosted checkout pages, like PayPal, redirect to the service provider for entering payment information, bypassing the merchant entirely. These providers are (usually) more prepared to handle the security required for payment processing.

When in doubt, don't enter your payment information. And if you suspect you have been compromised, contact your payment provider and ask for assistance.

Footnotes