Fake jQuery injections have been popular among hackers since jQuery itself went mainstream and became one of the most widely adopted JavaScript libraries.
Every now and then we write about such attacks. Almost every week we see new fake jQuery domains and scripts that mimic jQuery. For example, one of the most prevalent malware infections of the last couple of weeks is the attack that injects fake jQuery script into the head section of WordPress and Jooma sites.
The script is injected right before the closing </head> tag and looks like this:
There are a few interesting things about this malware that I want to talk about here.
Not Obfuscated
Although it infects PHP files, the injected code is in JavaScript. Hackers decided not to obfuscate it. Probably to make it less prominent during manual code reviews. This also helps keep thing simple, and as I’ll show later, the attackers need to change the injected code often and their coding skills are not that great.
Hosting Script on Multiple Compromised Sites
After a 10 second timeout, the JS code dynamically injects another script that looks like this:
https://infected-site.com/js/jquery.min.php
Where infected-site.com is some compromised third-party site where hackers placed their malicious scripts. The domain changes from site to site, and on the same site after reinfections. Literally every site with the injected JS malware can also be reused to host the /js/jquery.min.php script.
Bugs in the Malware Injector
As you might have noticed, there are two identical scripts injected scripts on the screenshot. This happens quite often because of a bug in the malware injector. It simply looks for the </head> tad and injects malware right before it. It doesn’t check whether that file already contains the malicious code.
Since hackers try to regularly update the code in order to use new domains or just reinfect sites that have removed the removed malware, many infected web pages can contain more than one malicious script – sometimes more than 10 of them. The same flawed logic makes them inject the script in other inappropriate places (e.g. inside comments that contain the word </head>).
Infected Themes and Templates
The main targets of this attack are WordPress and Joomla sites. When hackers break into such a site, they run a script that looks for all WordPress and Joomla installations on the compromised server account and then injects that malicious JavaScript code into theheader.php file in every WordPress theme and into the index.php file in every Joomla template (or whatever file that has the </head> tag). This makes the cleanup relatively easy. You just need to remove the malicious code from header.php (WP) orindex.php (Joomla) or just restore them from a clean backup, plus check for thejquery.min.php in the /js directory.
To check if you’re infected, you can leverage our free malware scanner – SiteCheck. Here is what the output may look like:
Prevent Reinfections
Removing the malware is not enough. As I already mentioned, hackers regularly try to update the malicious code so the problem will inevitably return unless you delete all the backdoors and close the security holes. The hackers uploaded the initial backdoor after logging into WordPress and then either uploading some plugin or editing some theme file (usually 404.php). After that they used the initial backdoor to create multiple robust backdoors in different directories of compromised sites.
Given that most WordPress sites are under constant brute force attacks, trying to guess admin passwords, we can assume that the WordPress passwords could have been guessed this way. We also noticed that some of the compromised sites had malicious WordPress admin users with names like “backup“, “dpr19“, “loginfelix“. Some of them had been created during past attacks though.
In other words, after removing the visible parts of infection, you should harden you site to prevent reinfections:
- Change passwords for all WordPress and Joomla sites
- Review them for malicious admin users. Remember there’s rarely a need in more that one admin user. There are more appropriate user roles in WordPress for most tasks.
- Make sure your CMS and all its third-party components are up-to-date. All unused stuff should be ruthlessly deleted from server.
- Add some protection against brute force attacks.
It would also really help if you protect your site with a web application firewall (WAF) such as our CloudProxy that helps block all malicious requests that try to exploit known and yet unknown security holes, stop brute-force attacks and prevent hackers from accessing your SMS admin areas.
Source:https://blog.sucuri.net
Working as a cyber security solutions architect, Alisa focuses on application and network security. Before joining us she held a cyber security researcher positions within a variety of cyber security start-ups. She also experience in different industry domains like finance, healthcare and consumer products.
