We are currently seeing a massive attack on Magento sites where hackers inject malicious scripts that create iframes from “guruincsite[.]com“. Google already blacklisted about seven thousand sites because of this malware.
There are two modifications of it. The first script is in not obfuscated:
Simple guruincsite script
… and the second one is obfuscated:
Obfuscated guruincsite script
The obfuscated scripts inject the “hxxp://guruincsite[.]com/2.php” iframe.
The Magento Guruincsite malware is usually injected in the design/footer/absolute_footer entry of the core_config_data table, but we suggest scanning the whole database for code like “function LCWEHH(XHFER1){XHFER1=XHFER1” or the “guruincsite” domain name.
We are currently investigating the infection vector and will update as we have more details. At this point, we can suspect that it was some vulnerability in Magento or one of the third-party extensions that allowed it to infect thousands of sites within a short time. Make sure to update everything: core files and extensions.
Since the vulnerability provides access to your database, hackers could use it to create malicious admin users; so it is a good idea to review your site users. You might also want to use a website firewall that protects your site against known and even not yet discovered vulnerabilities, and prevents access to site admin areas to unauthorized users.
Puja Srivastava
Krasimir Konov
Luke Leal
Juliana Lewis
Chase Watts
Daniel Cid
Ben Martin
Jon Watson
34 comments
Hi Denis, thanks for the update. How can we go about checking if an any of our magneto sites are affected?
Hi Raj, I’ve just encountered one of our customer shops with this code injected, the way I checked for it was to get a database dump and just do a text search for any keywords that are related to this ‘guru’ js. From there on you will be able to see whether there are any mentions of malicious code and if there are – where it is. In my case I found it in a home CMS page.
Beware, this will not ‘fix’ or detect the exploit, it is a temporary solution until the cause and a way to prevent this from happening again is found.
Hi Raj, the easiest way is to view the page source of your homepage in your browser. Look out for either of the obfuscated/non-obfuscated scripts from the post. If you find either of these at the bottom of the source file, you are infected.
Any word on if/when magento will address this?
Hi Denis,
Thank you very much for sharing this article. I can confirm the malicious code was in the design/footer/absolute_footer entry of the core_config_data table.
Just an important point to know though, you will need to ensure you clear your Magento cache to remove the code from your pages aswell as your Varnish cache, if you use it. Then you can request a security review from Google in Webmaster Tools. Hope this helps!
I also found that the malicious script created 20 admin accounts inside Magento disguised as @magentoecommerce.com and test accounts. Please make sure you remove these!
Would the Sucuri Sitecheck ( https://sitecheck.sucuri.net/ ) detect this?
Yes, it will.
On that note, it gives false positive on this page 😉
I got this on one of my sites – having investigated the source it turns out it wasn’t an exploit – a Russian IP address brute-forced the /downloader URL (I know) and then used the CMS to inject the code using a French IP. It appears to be automated based on the timings. It would have been prevented by blocking /downloader and changing the /admin URL. Brute force detection/IDS/IPS software would also have helped.
I doubt if they got access by brute-forcing given that thousands of sites got infected in a day.
True, in fact looking at the logs further shows the Russian brute-force continuing after the above attack, so probably unrelated.
This particular site was missing both SUPEE-6482 and SUPEE-6285, so one of these vectors may have been involved. Any word if any fully-patched sites were affected?
What was the exact URL that got hit?
The CMS page injection and footer HTML injection happened on separate days, taking around 5 seconds each. Here’s the log snippets for each:
GET /downloader/
POST /downloader/
GET /admin/?PageSpeed=noscript
POST /admin/?PageSpeed=noscript
GET /index.php/admin/index/index/key/xxxxxxxxxredactedxxxxxxxx/?PageSpeed=noscript
GET /index.php/admin/dashboard/index/key/xxxxxxxxxredactedxxxxxxxx/
GET /index.php/admin/cms_page/index/key/xxxxxxxxxredactedxxxxxxxx/?PageSpeed=noscript
GET /index.php/admin/cms_page/edit/page_id/3/key/xxxxxxxxxredactedxxxxxxxx/?PageSpeed=noscript
GET /index.php/admin/cms_page/edit/page_id/11/key/xxxxxxxxxredactedxxxxxxxx/?PageSpeed=noscript
GET /index.php/admin/cms_page/edit/page_id/4/key/xxxxxxxxxredactedxxxxxxxx/?PageSpeed=noscript
GET /index.php/admin/cms_page/edit/page_id/13/key/xxxxxxxxxredactedxxxxxxxx/?PageSpeed=noscript
GET /index.php/admin/cms_page/edit/page_id/6/key/xxxxxxxxxredactedxxxxxxxx/?PageSpeed=noscript
GET /index.php/admin/cms_page/edit/page_id/2/key/xxxxxxxxxredactedxxxxxxxx/?PageSpeed=noscript
POST /admin/cms_page/save/key/xxxxxxxxxredactedxxxxxxxx/
GET /downloader/
POST /downloader/
GET /admin/?PageSpeed=noscript
POST /admin/?PageSpeed=noscript
GET /index.php/admin/index/index/key/xxxxxxxxxredactedxxxxxxxx/?PageSpeed=noscript
GET /index.php/admin/dashboard/index/key/xxxxxxxxxredactedxxxxxxxx/
GET /index.php/admin/system_config/index/key/xxxxxxxxxredactedxxxxxxxx/?PageSpeed=noscript
GET /index.php/admin/system_config/edit/section/design/key/xxxxxxxxxredactedxxxxxxxx?PageSpeed=noscript
POST /index.php/admin/system_config/save/section/design/key/xxxxxxxxxredactedxxxxxxxx/
GET /index.php/admin/system_config/edit/section/design/key/xxxxxxxxxredactedxxxxxxxx/
Bots don’t need to follow the sequence: get login screen > post login > get dashboard > go to system config > go to design section > post the script into the section. This specific log looks more human to me.
The whole thing happened within 5 seconds with no js/css assets loaded so definitely automated. In fact it reminds me of the sort of logs I’d see when doing Jmeter testing of the front end e.g. you have to load the product page before adding a product to the basket so you can extract the form_key variable used for XSS protection.
So it looks like it tries to log into downloader, fails, then tries to log into admin, succeeds, reads a few links to get the key, then posts a cms page change and the system_config change for the footer.
I would suggest to whitelist admin IPs to allow access to admin pages. No unauthorized IP should be allowed to access /admin area at all. Also have a security extension to prevent such attacks.
That’s quite often simply not possible
One of our client’s sites apparently got hacked with this. Google is saying it’s because of the guruincsite domain, however I’m so far unable to find any of the referenced code anywhere on the site. What I DID find however was a bunch of javascript added to some cms blocks and the core_config_data table that was looking for the checkout pages and posting data to a third party. Make sure you check for stuff like that as well.
Did you look in the system config section design/footer/absolute_footer ? That’s where ours was.
Yep, depending on the exploitation method, it will be hidden on a different location.
what version of magento? 1.4?
hahaha
A client of ours recently got this as well. We found the injection in the design/footer/absolute_footer config option. The client was on v1.6 but with all security patches enabled.
We should group together or commonalities to see if we can figure out how this injection was made possible…
Hmm, I got the feeling this comes off the back of the shoplift attacks. Looks like the backdoor sellers finally got a bidder.
Can’t say for sure. On some cases we saw, it was related to the magmi vulnerability.
Wow, this is pretty serious stuff. No relation to the Magmi vulnerability?
Seems to be, at least partially. Looks like a type of Magento Exploitation kit trying multiple vulnerabilities, until they find one that works.
Hey guys, try check your FPC module…
Which vulnerabilities are used for the attacks?
Is this by the “Shoplift” security Issue (Patch SUPEE-5344)?
It looks like 6482.
i removed this from database and clear the cache also but still my site is give this “The site ahead contains malware” so please provide me a solution…
Did you patch your site with 6482 Patch? Make sure your site, all core and local modules are patched.
Comments are closed.