Sesame Street among many Volusion customers are compromised; how the cookie monster is stealing credit card info.

Marcel Afrahim
10 min readOct 8, 2019

--

Data Breach of the day brought to you by Volusion!

What started as a simple toy shopping on sesame street store on a rainy afternoon turned out to be a much bigger deal than I thought.
Let me explain.

The Company

Volusion describes itself as a leading e-commerce solution for small businesses. With its powerful shopping cart software, Volusion has helped thousands of merchants and supposedly Shoppers have spent more than $28 billion in transactions and placed over 185 million orders on Volusion stores.

The Compromised

sesamestreetlivestore.com is the official sesamestreetlive.com online store to purchase sesame street merchandise and is build with Volusion’s All-in-One E-commerce Website Builder. Its Name servers are even maintained by the Volusion’s Name servers.

The checkout page is designed as a single page payment where all the info is entered on one page and validated on the submission before taking the user to the confirmation page.

While all the resources are loading from sesamestreetlivestore.com or volusion.com affiliated websites, there is an odd javascript file being loaded from storage.googleapis.com with interesting bucket name of volusionapi. if you are not aware of it, storage.googleapis.com is a Google Cloud Storage domain name which is a RESTful online file storage web service for storing and accessing data on Google Cloud Platform infrastructure. Anyone can signup and chose a unique bucket name and serve content with the performance and scalability of Google’s cloud.

Google Cloud Storage (and other Cloud storage providers) has been abused before where threat actors or malware authors distribute malicious code or actual malware through these legitimate services. Your’s truly actually wrote about this just last month.

So it seems to be a bit odd that of all the pages on the site, there is an external javascript being loaded from some randomly named storage on the checkout page of an e-commerce website.

The Cookie

resources.js is a minified Javascript code which on the surface looks like some code that some developer just grabbed from any open source libraries and used. As I will explain this script is posting credit card info entered on the page to another domain name and surprisingly its called “JavaScript Cookie”.

On the surface its pretending to be a simple, lightweight JavaScript API for handling cookies copied from the following GitHub repo with replica here.

But pretty-printing it using Chrome’s developer tools (thanks Google), it displays something very alarming and essentially what is at the core of the compromise.

At its core, the additional code consists of two sections. The first section is reading the values entered at the Credit Card information fields and after a series of checks, it's Base64 encoded along with serialization and simple shift operation, So that a simple Base64 deobfuscation would not reveal the data.

The data is then stored using the browser’s sessionStorage with the name “__utmz_opt_in_out”. sessionStorage is similar to localStorage; the difference is that while data in localStorage doesn’t expire, data in sessionStorage is cleared when the page session ends. This chart summarizes the difference between different storage types in the browser.

The second part of the script is responsible for reading that data stored and posting it to their primary server hxxps://volusion-cdn.com/analytics/beacon. The code itself does not need much explanation.

This is what will be shown as part of the network activity. The data itself can not be decoded by predefined functions. The URL looks like Analytics or Domain tracking URL and even an analyst might just ignore it as it is.

To an untrained eye, this does not look suspicious. Even most analysts would agree that this how legitimate Analytics and web tracking traffic look like these days.

Digging deeper, Volusion-Cdn[.]com is a fairly new domain name that was only registered last month. it shares nothing with Volusion infrastructure or nameservers and the biggest flag of all, it is being WhoisGuard Protected.

The associated IP address 66.42.76.145 is owned by United States Seattle Vultr Holdings Llc which is a New Jersey-based cloud hosting firm.

If you make a simple GET request to URL, it returns a pixel icon, similar to the ones used by many of the web trackers.

>>> https://volusion-cdn.com/analytics/beacon
> — — — — — — — — — — — — — — — — — — — — — —
> 200 OK
> — — — — — — — — — — — — — — — — — — — — — —
Status:200 OK
Code:200
Cache-Control:no-cache
Pragma:no-cache
Content-Length:98
Content-Type:image/png
Expires:-1
Server:Microsoft-IIS/8.5
X-Powered-By:ASP.NET

If you make a GET request to Volusion-Cdn[.]com, it redirects you to legitimate Volusion CDN cdn3.volusion.com.

>>> https://volusion-cdn.com/
> — — — — — — — — — — — — — — — — — — — — — —
> 302 Found
> — — — — — — — — — — — — — — — — — — — — — —
Status:302 Found
Code:302
Cache-Control:no-cache
Pragma:no-cache
Expires:-1
Location:https://cdn3.volusion.com/
Server:Microsoft-IIS/8.5
X-AspNet-Version:4.0.30319
X-Powered-By:ASP.NET

At this point, it is pretty obvious volusion-cdn[.]com has nothing to do with the Volusion and it is made only to look like Volusion owned domain name essentially to steal credit card information.

The Count

Why is Count von Count saying 6593?

While it is not overly sophisticated, the actors behind this operation went through some lengthy steps to make the traffic look normal. What was not mentioned was how did the script get into the page in the first place. Using Chrome’s source tab, you can search the entire source of the website currently loaded on the session. Just searching for initial script file URL

<hxxps://storage.googleapis.com/volusionapi/resources.js>

I found out that the script is dynamically injected to the page and it’s initially stored at

<https://www.sesamestreetlivestore.com/a/j/vnav.js>

The code itself is claiming to be jQuery UI — v1.10.3, used for navigation UI menu, but there is the addition of the script to load the secondary malicious script to post data via a third script. Are you following?

https://www.sesamestreetlivestore.com/a/j/vnav.js

The directory path to the vnav.js looks to be an integral part of the E-commerce store and something that is not used for one particular customer if you are running a platform to host an e-commerce website.

As advertised!

Given the number of customers advertised by Volusion itself, I checked out some other website showcased by Volusion that might have the same path.

Are you thinking what I’m thinking?

The compromise is not only unique to Sesame-Street Store and most likely any e-commerce website hosted on Volusion is probably running malicious code and posting the credit card info of the consumers to the outsider domain.

Searching “a/j/vnav.js” on publicwww.com brings up 6593 web pages that are probably hosted by Volusion and are probably compromised, if not higher.

Now you know why Count von Count is saying 6593.

While I can’t confirm it unless I go through the entire list of websites, it's safe to assume to all the vnav.js files are pointing to singular location and once that is compromised, the entire customer base of Volusion is compromised. It is hard to determine when exactly did the information leakage started, but one of the response headers for resources.js JavaScript file uploaded to Google Cloud Storage is pointing to the the timestamp “Thu, 12 Sep 2019 15:18:59 GMT”.

We will have to wait for confirmation from Volusion or Google Cloud but it is possible the car skimming attack started even earlier since this is modification time stamp and not creation.

The most famous credit card skimming attack responsible for compromising over 2 M e-commerce websites is Magecart which has the history of using Vultr Holdings data centers ( just live Volusion-Cdn[.]com) and using public cloud storage to host their malicious scripts. It was just two days ago the RiskIQ published a new report about its operations.

While the investigation is still ongoing, the Google Cloud Abuse team and Volusion have not been responsive to take down the malicious code. I will update as I hear back and find more info.

IOCs and Samples:

hxxps://storage.googleapis.com/volusionapi/resources.js

hxxps://volusion-cdn.com/analytics/beacon

Updates:

According to zdnet, the number of compromised sites could be as high as 20,000.

A Volusion spokesperson confirmed to CyberScoop after this article’s publication that customer credit card information was included in this incident.

Volusion confirmed a fix has been issued, but it did not release any statement on number of customers affected.

https://twitter.com/Volusion/status/1181661671674335232

Trendmicro has confirmed this card skimming attack is associated with FIN6 Cyber crime group and has published a detailed analysis report on the attack.

https://blog.trendmicro.com/trendlabs-security-intelligence/fin6-compromised-e-commerce-platform-via-magecart-to-inject-credit-card-skimmers-into-thousands-of-online-shops/

“Group 6 is known to only target top-tier victims, investing in scams where they can receive a big payoff from one attack. This single hack of Volusion allows them to receive credit card data from 3,126 online shops.”

The analysis goes through the entire code injection and code analysis and the evidence of FIN6 being behind the attack. They also have a very good tip:

To defend against this type of threat, website owners should regularly check and strengthen their security with patches and server segregation. Site owners should also employ robust authentication mechanisms, especially for those that store and manage sensitive data. IT and security teams should restrict or disable outdated components and habitually monitor websites and applications for any indicators of suspicious activity that could lead to data exfiltration, execution of unknown scripts, or unauthorized access and modification.

Other Comments:

I’m still investigating why Chrome’s XSS Protection is not preventing the POST here. If you try to make a manual request from Chrome’s console, CORS policy does prevent the post. Could it be that the sessionStorage is treated differently?

📝 Read this story later in Journal.

👩‍💻 Wake up every Sunday morning to the week’s most noteworthy stories in Tech waiting in your inbox. Read the Noteworthy in Tech newsletter.

--

--

Marcel Afrahim

Publishing Independent Cyber Security & Malware Analysis research on Medium.