On Oct 17th 2015, we started receiving reports of Magento shops being infected by GuruIncSite malware. We found that attackers were somehow getting access to Magento admin panel, and were inserting malicious code into websites. Magento’s official site didn’t have any information on the attack, and all that anyone knew was that Magento software had a vulnerability that allowed admin access to attackers.

This is a fairly typical scenario in a zero-day attack. An attack is termed zero-day when the affected software vendor isn’t aware of the vulnerability being exploited, and virtually everyone that uses that software is vulnerable to an attack. Unlike other kinds of attacks, defense against a zero-day attack is harder because no official patch or notification would be available from the vendor. Business owners using the vulnerable software would be left to fend for themselves until a patch is available.

This is where a security specialist can help you. A zero-day attack is one of the security threats mitigated in Bobcares Proactive Server Management service. We are tuned into security channels 24/7 and are instantly notified when there’s a new attack outbreak. We then use unique characteristics of the attacks to block similar exploit attempts on servers under our care.

Today, I’ll go through the steps we took to protect one such Magento site from the GuruIncSite malware attack.

Start of a zero-day attack

On Oct 17th, messages started coming in on security channels about a new kind of malware affecting Magento websites. The affected domains were redirecting visitors to a site called guruincsite.com where viruses were downloaded into the visitor’s computer. The information was sketchy. All that anyone knew were:

• Only Magento sites were affected (till that point).
• Visitors were being redirected to guruincsite.com.
• Examples of Javascript codes that is inserted into the website.
• There’s no notification from Magento on what kind of vulnerability is being exploited.

No one knew what vulnerability was being exploited, how to patch the vulnerability, or if this was even related to Magento alone.

So, without an official patch there was no way for websites to be immune from the attack – Unless there was a way to block the attack before it reached the website. This is where a web application firewall (WAF) comes into play.

Protecting websites using a web application firewall

A web application firewall or WAF sits between the internet and a website. It analyzes each visit on the website to determine if it is an attack or not. A WAF is a critical part of website security, as attacks such as zero-day exploits seldom leave an opportunity for website owners to patch their websites.

Many website owners assume that a securely coded website is enough to block attacks, but a quick look at a vulnerability database will show you that even underlying frameworks such as Zend or Codeigniter has numerous vulnerabilities reported. Such vulnerabilities may not be easy to patch as it could affect web site functionalities. In such situations, a quick update to the site’s WAF can block attacks, giving developers enough time to upgrade the web site. So, we help website owners setup their own Web Application Firewall custom configured to meet their unique security challenges.

If there’s anything as risky as not using a WAF, it is to use one that is not updated. For example, some server management tools such as cPanel come pre-installed with WAFs. We’ve seen a lot of websites relying on such default WAF installations for their security. However, a WAF that is not updated with the latest rules cannot block a new kind of attack such as a zero-day attack.

A WAF detects an attack based on a set of attack signatures (aka rules) it stores in a database. Now, the important thing about an attack signature database is that, it is a list of KNOWN attacks. So, if there is a new kind of attack spreading in the internet, the signature database wouldn’t have a corresponding attack pattern, and will leave the WAF unable to detect an attack.

Firewall does not see a matching attack pattern in DB – Lets through an attack.

In such situations, our security engineers quickly identify a pattern in the new attack, create a signature for the attack pattern and update the WAF signature database. This enables the WAFs to keep these sites secured from the new wave of attacks.

Security engineer updates firewall database. Blocks attack.

Blocking GuruIncSite infection using WAF

Coming back to the GuruIncSite infection, on 17th Oct, all we knew initially was the pattern of attacks. We knew from the security reports that the attackers were injecting two different versions of malicious code into Magento websites.

{function LCWEHH(XHFER1){XHFER1=XHFER1

xhr.open('GET',​'http://guruincsite,com/1,php'

These attacks were launched on the administrator URL of the Magento sites, and were using the POST method to inject code into the database. This combination of factors were unique to this attack, and this formed the base for our WAF signature.

Blocking the attack using NAXSI

One of the Magento sites under the protection of our Proactive Server Management service was hosted on an Nginx server. We’d installed an open source firewall called NAXSI on that server, which has a signature database that can be extended with custom rules.

When we identified the attack pattern unique to the GuruIncSite malware, we created a NAXSI signature (aka blocking rule) that could block the infection. An example of such a blocking rule is:

MainRule "str:function LCWEHH(XHFER1){XHFER1=XHFER1" "msg:GuruIncSite obfuscated code injection attempt" "mz:$URL:/admin|BODY" "s:$ATTACK:8" id:55000031 ;

This rule told NAXSI to block all connections that had the string function LCWEHH(.. in the POST body that’s passed to /admin URL of the Magento site.

Similar rules were added for other variations of the attack to make sure all such injection attempts are blocked at the WAF level. A review of the NAXSI logs showed successful block of attempted attacks, which confirmed that our custom rules were indeed working.

NOTE : The NAXSI WAF code given above is for demonstration purposes only. It is not guaranteed to work in a live Nginx server as it has additional dependencies that need to be applied.

Closing notes

Once we had a confirmed attack signature identified, we created variations of the rules for another popular open source WAF called ModSecurity which is mostly used in Apache servers. Together, our custom NAXSI and ModSecurity rules blocked hundreds of attacks on Magento sites all through the next week, many of which would have been successful if the firewalls were not updated.

Zero-day attacks are a fact of life. There is no fire-and-forget solution to keep a website secure. To keep your customers safe, and to retain your ranking in search engines, it is important to keep your websites protected by a competent security service.