Linkedin Tag

Back to blog

Cisco client-side Magecart JavaScript attack

Friday, September 6th, 2024

Himanshu Anand's profile picture

Himanshu Anand

Another day, another high-profile client-side JavaScript attack. This morning, we read that Cisco is the next victim of malicious code being loaded through a third-party script.

The Cisco Merchant website operates on the Magento Enterprise framework, which is widely used by eCommerce websites. Magento offers a robust and scalable platform, but like any system, it’s vulnerable to exploitation if security patches and updates aren’t applied timely. The exact version of Magento in use at the time of the attack was Magento 2.4 (Enterprise).

undefined

Attacks targeting the Magento frameworks, have over time gotten their own nickname: Magecart attacks.

The attackers use a third-party script which inserts malicious code, often through a domain, to steal credit card and personal information. E-commerce sites are often a target in these attacks.

For more detailed information about vulnerabilities related to Magento, check these links:

The malicious script decoded

During our analysis, we discovered the following injected script on the website:

undefined

This script, hosted on the domain rextension[.]net/za/, which is associated with an IP address located in Russia (82.202.163.229), was found to be retrieving additional obfuscated code. The domain was recently registered on August 30th, 2024, making it just 7 days old at the time of our analysis on September 6th, 2024.

undefined

Why this matters

  • The domain's recent registration raises red flags as it could indicate a fly-by-night operation designed for quick exploitation before being abandoned.

  • Obfuscated scripts like these are difficult to detect without specialized monitoring, making them especially dangerous for both website owners and their customers.

How c/side would've stopped this attack

Had the Cisco merchant website have c/side in place, our detection engine would've caught this attack. One of our systems checks for newly registered domains, and in testing our engine caught this and alerted the user of this anomaly. The script itself was blocked from loading in browser of the test user, stopping this attack before it could take place. Here can be seen when this domain was registered (safe link).

Sign up for free and protect your site in seconds.

Deobfuscating the script step-by-step

The script retrieved was highly obfuscated, making it difficult to easily analyze. Below is just a portion of the obfuscated code:

undefined

The above script is multi-layer obfuscated JavaScript, which was loaded into a debugger.

Obfuscation is a method used to make code difficult to understand, typically as a means of hiding its functionality or protecting sensitive data. However, for analysts, developers, or security researchers, understanding the underlying functionality is essential and legal.

We put a breakpoint at:

undefined

And executed the script and, after couple of decodes, we got two interim decoded JavaScripts.

The first level of obfuscation is a function that takes an argument (Decoded right before the script) and transforms it using various JavaScript methods, such as string manipulation and character encoding.

undefined

A closer look will:

undefined

The final decoded version:

undefined

This snippet confirms that the script is focused on payment card fields, but it's still partially obfuscated, with functions like _0xDCAD and _0xDBA3. These functions further manipulate the content, and after more layers of decoding, the final script emerges.

undefined

Key aspects of the script

  1. Obfuscation: The script is heavily obfuscated, using functions like _0xDCAD, _0xDBB6, _0xDBC9 to create multiple levels of encoding and obfuscation. This is typical of malware or scripts trying to hide their actual functionality.

  2. Input Collection: The script collects information from HTML input elements identified by CSS selectors such as #authnetcim-cc-number, #authnetcim-cc-exp-month, #authnetcim-cc-exp-year, and #authnetcim-cc-cid. These are typically fields where users would input sensitive payment information.

  3. Data Handling:

    • The data collected (credit card number, expiry date, CVV, etc.) is gathered in the ffewq object.

    • The script then encrypts this information using AES encryption (via functions like encrypt, decrypt, round, etc.).

    • Once encrypted, the data is sent to a server using jQuery.ajax() calls (seen in the jQuery[_0xDB90[51]] section).

  4. Encryption: The script uses AES (Advanced Encryption Standard) for securing the data before sending it out. This includes several functions handling AES encryption logic (addRoundKey, mixColumns, encrypt, etc.), which are standard components in an AES encryption process.

  5. Periodic Execution: The script is designed to run at regular intervals (setInterval(_0xDBA3, 100);) to continuously check or send the collected data.

Please know that the c/side dashboard does this process for you, deobfuscating script to make them easier to read and analyze.

JSDeliverDeobfuscatedScript-cside.dev.webp

What happened in this attack

One of the possible vulnerabilities that may have been exploited in this attack is known as CosmicSting. This is a known exploit in the Magento platform that has been documented and researched. You can read more about it in detail at SanSec Research on CosmicSting.

Client-side attacks such as this one can be devastating to both businesses and customers, highlighting the importance of constant vigilance and the implementation of sophisticated security measures. Companies should ensure that they apply patches, monitor for suspicious activity, and utilize advanced tools like those offered by c/side to mitigate risks.

Himanshu Anand's profile picture

More About Himanshu

I'm a software engineer and security analyst at c/side.