How iFrame Payments Were Compromised in MITM Attack

The Foregenix Digital Forensics and Incident Response Team recently reported a man-in-the-middle attack that we had seen executed against an iFrame redirected payment method.  The attack specifically targeted the iFrame of a popular UK Payment Service Provider (PSP). We have received numerous requests for more detailed information around how the attack was orchestrated – principally as outsourced payment models were considered largely secure – and in that light we present the details of how the attack was accomplished.

Understanding Man-in-the-Middle Attacks on iFrame Payments

ECommerce businesses have been advised to implement hosted payment pages from their payment service provider, or utilise a redirect payment via iFrame.  In so doing they are considered significantly more secure than alternatives, warranting a reduced PCI DSS validation questionnaire.  The message reaching much of the market is that if you use one of these proposed payment options on your website, you don't need to worry about security.  This is NOT correct.

An insecure website can have payment data compromised, regardless of whether they use a hosted payment page or an iFrame redirected payment page.  Here's Visa's alert from 2010 on this issue.

Here's how a well-known eCommerce business in the UK utilising a well known and respected UK Payment Service Provider for payments was compromised and lost a significant volume of payment card data:

The Payment Service Provider iFrame Man-In-The-Middle Breach

The “introduced” code behind the attack was very specific to the targeted website and required a degree of previous research and reconnaissance in order to establish database credentials, which were hard coded into the malware. All that said, with only a few minor modifications to the website, this malware could be used against any website where the Payment Service Provider iFrame is in use.

At the point that a consumer elects to proceed to the checkout pages details of their order, including total price and the website's ID are submitted to the Payment Service Provider in order that a transaction identifier can be generated and the Payment Service Provider can anticipate a request from the website's customer for an iFrame.

The transaction ID is an alphanumeric thirty eight (38) character value that uniquely identifies the transaction to the Payment Service Provider backend system and must been submitted in full as a parameter within the URL when requesting and submitting the iFrame, essentially to reference the transaction. Failure to provide the transaction ID value correctly and in full would generate an error message and the transaction would fail. In this breach the attacker's were able to extract the transaction ID from the website's database.

The code then generates a spoof request to the Payment Service Provider, requesting the iFrame content for the transaction ID that was taken from the database.  The code then establishes a connection from the website's web server to the Payment Service Provider, presenting the valid transaction ID, spoofing the HTTP user-agent and presenting a referrer field to make it look to the Payment Service Provider that the request is genuine.

The iFrame page returned by the Payment Service Provider was captured into a variable which the code page then manipulates using a number of string replacement calls, appending a client side JavaScript to end of the HTML body before serving the iFrame on to the customer from the website's web server.  Being unaware of the manipulation to the payment process, the customer enters their payment card details to the iFrame and the malicious JavaScript uses the HTTP POST method to transfer the input back to the website's web server. 

A function in the code captured all data to the server using the POST method and sent it to an external server located in Iran.

Once the manipulated iFrame had been used the malicious code presents the genuine iFrame inserting the correct transaction ID so that the customer can continue with their transaction and the Payment Service Provider are not alerted to the suspicious activity by receiving a second request for the transaction ID.

From the consumer's point of view the data entered into the iFrame vanishes and the customer is left with an empty iFrame to complete again. It is expected the customer would assume something went wrong with the web page and re-enter and submit their payment details which, on the second attempt, are submitted direct to the Payment Service Provider. Because a valid transaction ID is supplied, the Payment Service Provider authorise and process the transaction normally.

There are a number of security controls that could be implemented by the payment processor, which would have negated this and future attacks of this nature.

1. The Payment Service Provider accepted an iFrame request from the same IP address that submitted the initial request to generate the transaction ID. If at this stage the Payment Service Provider recorded the IP address of the web server requesting the transaction ID they would have been alerted to the spoofed request for the iFrame created by the malicious code.
2. The final submission of the genuine iFrame is sent to the Payment Service Provider from a different IP address to the one that made the original request. The (legitimate) iFrame was requested by the merchant's web server, but returned by the customer. This again should have alerted the Payment Service Provider to the man-in-the-middle attack.

With the increase of iFrames being used by website we expect to see attacks of this nature increase, especially if payment processors provide minimal validation of the requests to their servers.

The targeted website could have detected/prevented this attack quite easily by:

1. Monitoring for File Changes - changes made by their own developers = GOOD. Unrecognised changes = POTENTIALLY BAD.
2. Maintain Updated Software - Magento release patches regularly, as do most platforms. Websites are advised to keep up to date to ensure that they do not expose their businesses to vulnerabilities in the software. 
3. Install a Web Application Firewall - if your developer team are unable to manage patching quickly, a Web Application Firewall can help to detect and prevent the vast majority of attacks attempting to compromise a website.
4. Cardholder data scanning - If malicious code is harvesting card data to the website's webserver then card data scanning will identify the harvest file and alert the website developers.
5. Malware scanning - If an attacker gains access to a webserver, they usually leave a webshell/backdoor to enable them to access the website easily.  File Change Monitoring will identify the new files being added to the website, but if the website's team misses this, a good malware scanner will identify the webshell and alert them.
6. Change Passwords and review Administrator User Accounts in order to ensure that there are no unknown users that have been placed into the database.

Securing your website is not a dark art - install FGX-Web and discover how easy it is to gain control of your website security.