Blog

Third-party Risk: Magecart Creditcard Attacks

As Cloud Computing continues to grow, so do the breaches and disclosures of sensitive information. With the recent news surrounding credit card fraud, it may be worth investigating your third-party providers and your Amazon S3 buckets to ensure security controls are enabled to prevent a hefty fine in case of a breach.

Background on Magecart

Magecart is a group of hackers that are known for their digital credit card skimmers. These skimmers compromised many e-commerce sites last year (2018) and, they’ve yet again made headlines after infecting over 17,000 websites through misconfigured Amazon S3 buckets. The spray and pray approach would utilize automation to check for misconfigured S3 buckets and, once found, download the hosted JavaScript files, inject their malicious code, and overwrite the original files. Any website using the specific JavaScript files will have their users affected by the malicious code.

The diagram below depicts the attack scenario that was used against each of the 17,000 web sites. You’ll notice that the website utilizes an externally hosted JavaScript file that the attacker has replaced it with their own malicious version.

magecart-attack.png

Preventative controls can be enabled to ensure your organization doesn’t fall victim; however, it does require that any third-party hosting providers are also included in the scope of the controls. Magecart realized that the likelihood of the actual target sites being vulnerable to insecure file uploads is low and began looking into the third-party support sites that host supporting files (e.g., JavaScript on Amazon S3 buckets).

To protect your organization, consider the following:

  • Consider an AWS audit that checks for insecure permissions – there shouldn’t be any public write access available, especially if it’s a bucket that hosts your critical supporting web application files.

  • Conduct a penetration test against your AWS instances that also includes all third-party services currently being used on your web application. Any weakness within those third-parties could lead to your users being compromised.

  • Ensure logging is sufficient – if a breach was to occur, you need to have logs that will tell you what and how it occurred to assist in remediation time and future prevention.

Many of our clients used to ask that we exclude or remove third-party findings from their reports as it doesn’t affect them directly, but with recent uptick in Magecart attacks, their inclusion is a wise decision. Remember, web applications are only as strong as their weakest links, and weaknesses found in third-parties are being noticed by attackers. Thus, if a third-party is hosting your resource files, or web application server, they should also be included in the scope of any security testing to ensure your web application will not be affected by any malicious campaigns that will impact your company and its users.

Featured Posts

See All

December 10 - Blog

Hardware Token Protocols

Hardware token protocols: what are they, and what role do they play in your organization's cybersecurity? In today's article, our ethical hackers outline the most common hardware token protocols.

October 24 - Blog

Packetlabs at SecTor 2024

Packetlabs is thrilled to have been a part of SecTor 2024. Learn more about our top takeaway's from this year's Black Hat event.

September 27 - Blog

What is InfoStealer Malware and How Does It Work?

InfoStealer malware plays a key role in many cyber attacks, enabling extortion and lateral movement via stolen credentials. Learn the fundamentals about InfoStealers in this article.

Packetlabs Company Logo
    • Toronto | HQ
    • 401 Bay Street, Suite 1600
    • Toronto, Ontario, Canada
    • M5H 2Y4
    • San Francisco | HQ
    • 580 California Street, 12th floor
    • San Francisco, CA, USA
    • 94104