Case Study: Credit Card Stealer Backdoor
REDSECLABS was contracted to perform a backdoor analysis for a customer operating a large e-commerce platform, following complaints from customers about patterns of credit card misuse linked to their purchases on the site. During an in-depth examination of the source code, REDSECLABS identified a backdoor within the "Authorize.net" plugin, which enables e-commerce websites to process debit and credit card payments. The malicious code was found to reroute successful credit card transactions to an external IP address under the control of an attacker.
The server was fortified with several security mechanisms, including ModSecurity and ImunifyAV. These tools are designed to identify malware by scanning for known signatures and relying on specific heuristics. Nevertheless, the sophistication of the backdoor allowed it to emulate legitimate functionality, thus evading the detection capabilities of these security solutions.
Root Cause Analysis
We started by reviewing "error logs" and "access logs". One interesting log entry revealed credit card customer details being sent to attacker controlled server.
Backtracking the error logs resulted in AuthorizeNetRequest.php. Close inspection revealed the presence of backdoor.
The above code snippet is part of a PHP class that interacts with the Authorize.Net payment gateway. It sends requests to Authorize.Net and processes the responses. Specifically, the highlighted code checks if a transaction has been approved by searching for the phrase "This transaction has been approved" in the response from Authorize.Net.
If the transaction is approved, it uses the file_get_contents function to make a request to attacker-controlled server. The URL of this server is obfuscated with Base64 encoding but is decoded at runtime to reveal the actual target URL.
Encoded Version aHR0cDovLzM4LjE4MC42LjE2Mi9hcGkucGhwP2ZvbGRlcj1hdGxhbnRpY2Z==
Decoded Version
http://38.180.6.162/api.php?folder=tmgm
This URL includes a parameter that seems to be dynamically filled with the IP address of the client connecting through Cloudflare ($_SERVER["HTTP_CF_CONNECTING_IP"]), as indicated using Cloudflare's server variable.
Searching for "This transaction" keyword reveals multiple files and original file which returns this error. The backdoor can be disabled simply by changing this status code to something else.
Command
[root@tmgm home]# grep -r "This transaction" *
Output
tmgm/vendor/authorizenet/authorizenet/lib/deprecated/shared/AuthorizeNetRequest.php: if (preg_match("/This transaction has been approved/", $response)) {
tmgm/vendor/authorizenet/authorizenet/tests/deprecated/AuthorizeNetAIM_Test.php: $this->assertEquals("This transaction has been approved.", $response->response_reason_text);
tmgm/vendor/authorizenet/authorizenet/tests/deprecated/AuthorizeNetCP_Test.php: $this->assertEquals('This transaction has been approved.',$response->response_reason_text);
tmgm/vendor/authorizenet/authorizenet/tests/deprecated/AuthorizeNetCP_Test.php: $this->assertEquals('This transaction has been approved.',$response->response_reason_text);
Malicious Code
The url http://38.180.6.162/api.php?folder=tmgm was encoded to base64 string. This URL includes a parameter that seems to be dynamically filled with the IP address of the client connecting through Cloudflare ($_SERVER["HTTP_CF_CONNECTING_IP"]), as indicated using Cloudflare's server variable.
Analysis of the IP Address
The server IP belongs to "3NT Solutions LLP", it hosts "api.php" script which is used to receive details regarding the credit card and store it on the server.
Entry point
Due to lack of logs, entry point was not identified. However, close inspection of the platform revealed vulnerable CKEditor plugin. Although this plugin was found to be dysfunctional, preventing the upload of arbitrary files, it did present a plausible vector for the initial breach. This vulnerability could have allowed attackers entry, after which they may have deleted or modified files to cover their tracks and prevent further exploitation by others.
Similarly, client had hired offshore developers and alternative explanation is that developers, may have deliberately installed backdoors. This theory is supported by our inability to identify any direct entry points during our penetration testing, suggesting that the attack vector might not have been a straightforward. Also, it is also likely that the vulnerability was patched by the website administrators, however, there was no evidence to support.
The grep command output reveals the existence of the specific string "This transaction has been approved" in multiple locations within the codebase, particularly within both the live code (AuthorizeNetRequest.php) and unit tests (AuthorizeNetAIM_Test.php, AuthorizeNetCP_Test.php). The presence of the suspicious code in AuthorizeNetRequest.php under a deprecated directory indicates that this file is part of the live codebase, despite being marked as deprecated. The specific action triggered by the string "This transaction has been approved" suggests that the backdoor is designed to activate only upon successful transaction confirmations, making it extremely difficult to signature based tools to find its presence.
Conclusion
Ecommerce platforms are regularly subject to Credit Card stealers. The stakes are substantial for both guests and the brand's image, with site owners facing significant consequences from these hazards. If you believe that you are subject to Credit Card stealing attack, we are here to help. Feel free and reach out to us via [email protected]