How Client-side Skimming (Magecart) Attacks Work?

  • Step 1 - Attackers add code with skimming functions to a script that is used by the target website.
  • Step 2 - The skimming function is executed by user browsers enabling it to steal sensitive information including account login credentials, payment card information by recording user keystrokes and input into form fields.
  • Step 3 – User information is sent to attackers.

Top Four Vectors Of Client-side Web Skimming Attacks

Javascript Libraries

Web applications that use third-party JavaScript code are vulnerable because of the lack of internal security management and oversight. As a result third party code can have an unrestricted level of access to sensitive data at the browser-level.

Sideloading And Chain-loading of Code

Sideloading and chain-loading techniques allow actors to load JavaScripts code with skimming capable malware on target web pages even while using legitimate scripts and tools. E-skimming breaches via sideloading can go undetected for a long time because infected code is loaded directly by web browsers well outside of the security perimeter.

Platform Or Cloud-Hosted Skimming

E-skimming code is found hosted by popular cloud platforms including Salesforce Heroku and Amazon CloudFront CDN, as well as on misconfigured Amazon S3 buckets. Such code can inject backdoors for inserting malicious code into JavaScript libraries used by thousands of organizations.

The Backdoors

Most organizations struggle with a single source of truth for their client-side code. Step one is actually knowing what exists. Let’s look into why most organizations struggle in discovering and classifying front-end assets. What more do we need to know?

Complexity in front end security leads to mistakes.

Mistakes, eventually, lead to breaches.

What does client-side chaos look like?

The front end complexity of web applications at an organization with ~1,000 employees

Assets:

60

password
pages

2

payment
pages

110

forms
ingesting PII

147

PII elements
ingested by forms

Risks:

50

vulnerabilities
detected

2

high
severity

38

medium
severity

10

low
severity

Surface:

2

domains
analyzed

703

web pages
total

3,318

scripts
detected

35

scripts per page
(average)

The Client-side (Front End) Problem Is Twofold:

1. Front end code, aka ‘the digital user experience’, can actively ingest customer/user information at the data input points including login and financial transaction forms, or any other web forms where organizations are processing sensitive user data.

Web development continues to move software logic to the client-side of web applications. Web applications increasingly execute both dynamically loaded and externally controlled JavaScript code into user web browsers. Dynamically loaded third-party scripts dramatically increase code variability while nearly eliminating event change controls. Increased variability and reduced controls mean a growing probability of compromise. Meaning, that every script, third-party and open source library can open a backdoor.

  • Are you aware of every backdoor?
  • Do you know what is flowing through these backdoors?
  • Can you lock and control backdoors?

About authors

Ivan Tsarynny is CEO and co-founder of Feroot Security, Member GDPR Advisory Committee at Standard Council of Canada, and is based in Toronto, Canada.
David Mundhenk, CISSP, CISA, PCI QSA, PCIP, is a Principal Security Consultant for the Herjavec Group, and a founding member of the PCI Dream Team.