18
Jun
16

iFrame Hack Reported

This week brought news of an inline frame (iFrame) payment solution that was hacked in the UK.  For all of you merchants that use an iFrame solution because you were told it reduced your PCI scope, you may want to rethink your security strategy.  For all of you hosting companies that offer these iFrame solutions because of the scope reduction value, you too may want to rethink your security strategy as well.

For those of us that are not Web developers, an iFrame is:

“An HTML document embedded inside another HTML document on a website. The iFrame HTML element is often used to insert content from another source, such as an payment page or advertisement, into a merchant’s Web page.”

For merchants using an iFrame for handling payments, the PCI DSS rules that the iFrame makes the merchant’s Web site out of scope because the iFrame is managed by the payment provider, not the merchant.  Thus merchants using an iFrame or a redirect are allowed to fill out an SAQ A.  However, because of increased risks to merchant Web sites using iFrames and redirects, the Council has updated SAQ A in response to those risks.

But there has always been a risk that iFrames and redirects could be manipulated.  The attack used in the article was fairly sophisticated in that it required a lot of knowledge about how that particular iFrame worked and then used a man in the middle (MITM) approach to intercept the invocation of the payment processor’s iFrame and insert their own iFrame.  Not a easy, but definitely effective.

The easier approach is an attacker changes the script/executable that invokes the iFrame/redirect to invoke a malicious iFrame/redirect.  A merchant would be alerted to such a change if critical file monitoring were required, but SAQ A does not require critical file monitoring.

This is why a lot of QSAs have told their clients that only fools believe that the requirements in SAQ A will keep their Web sites secure.  At a minimum, merchants using iFrame/redirect solutions should have critical file monitoring and logging implemented as well as conducting quarterly vulnerability scanning so that they can secure their Web sites as well as alert on any changes or any suspicious activity on their Web sites.

Advertisements

20 Responses to “iFrame Hack Reported”


  1. 1 Kyle
    June 20, 2016 at 3:23 PM

    Forgenix didn’t do a good job obfuscating the code. Those URLs are clearly for SagePay.

    Is this really considered a sophisticated attack? I could implement a similar attack that wouldn’t even require the customer to enter their details twice.

    • June 21, 2016 at 10:42 AM

      Sophisticated in that it required research on the part of the attacker.

      • 3 Kyle
        June 21, 2016 at 5:57 PM

        Did it though? Forgenix says that prior research must have been needed to get the database credentials but I don’t see why. The way most web apps work is you establish a pool of database connections and then each request uses a connection out of that pool. If the attacker can execute their own code on the server then they have access to the db pool by default (and probably every credential the web app uses).

        The only possibly sophisticated part is how they managed to modify files on the server but since Forgenix’s article is tagged with Magento it was probably due to the publicly known exploit mentioned in CVE-2016-4010.

        All in all I imagine it’s your average drive by Arabic kids that normally stick to defacing sites.

      • June 21, 2016 at 6:01 PM

        As an article a few days ago pointed out, “sophisticated” is all in the eyes of the writer of the article.

  2. June 20, 2016 at 8:29 AM

    So merchants shouldn’t let their web servers get hacked. Even if all cardholder data is supposedly being posted on another web site, they still have a duty to protect their own web servers.

    • June 20, 2016 at 12:24 PM

      Exactly. Out of scope is only for PCI compliance purposes, not security purposes.

  3. 7 Louis
    June 20, 2016 at 7:11 AM

    Wait, where does the SAQ A-EP come in ? I thought web merchant were now being directed to do at least an A-EP… Even with redirect.

    • June 20, 2016 at 12:26 PM

      If the sensitive authentication/cardholder data (SAD/CHD) does not flow through their Web site as with a redirect or iFrame, they can comply only with the requirements in SAQ A. SAQ A-EP is for all other methods used for payment processing.

  4. June 19, 2016 at 2:07 PM

    and one more comment – I also advice to do not add automatically web servers to PCI scope. there are known solutions on market which allow to descope web servers from PCI DSS scope even for eCommerce solutions …

    • June 20, 2016 at 12:30 PM

      Be careful with scope for eCommerce. The only true out of scope solution for eCommerce is the solution that is totally outsourced with no merchant operated Web site.

      • June 20, 2016 at 4:56 PM

        I do not agree with you . There are known solutions where merchant operate web servers but they are not (1) processing cardholder data and (2) cannot impact cardholder data security. As such they are considered as not in scope. In other words – even if you hack web servers you cannot steal cardholder data as other controls are in place which will prevent from that

      • June 21, 2016 at 10:41 AM

        But if they are the start of the payment process, i.e., their Web site directs you to the payment processor, then who do you blame when the merchant’s Web site directs you to a malicious payment page? They don’t process the data, but they sure caused the problem.

      • June 27, 2016 at 3:58 PM

        Merchant obviously is part of the process however it’s different discussion. I claimed below that in eCommerce world there are known solutions that web servers can be out of scope even when they generate payment or link to iframe page.

        In “standard” approach web servers obviously are in scope however in some “non standard ” they can be easily excluded.

      • June 28, 2016 at 5:43 AM

        First, let us be absolutely clear. There is no solution that will ever totally put the merchant out of scope for PCI compliance. If a merchant accepts payment cards for payment, they are in scope for PCI compliance. Period. Given that fact, the absolute minimum of PCI requirements that any merchant can comply with are the requirements documented in SAQ A. In order to use SAQ A, the merchant must have totally outsourced their eCommerce and cannot have any other payment channels. If the merchant does not have their own Web site, then I would agree with your comment.

        Where the discussion/argument comes from is over merchant Web sites that the merchant maintains that do a redirect or use an iFrame to process payments. A lot of us in the security profession argue that if that redirect or iFrame invocation method is tampered with, it is not the service provider that will be at fault. It is the merchant that will be at fault. However, under the PCI SSC’s current rules, that merchant Web site is viewed as out of scope and does not require the requisite security protections that other eCommerce Web sites require. Not that the merchant’s Web site necessarily needs all of the controls specified in SAQ A-EP, but definitely more than what is specified in SAQ A.

  5. June 19, 2016 at 2:03 PM

    To be honest I’m not suprised to read that. SAQ A approach is bad by design. There is a multiple known methods to capture cardholder data by malicious individual (internal and external) . So my personal opinion is that for eCommerce market PCI SSC should review SAQ A approach and extend it – current approach is simply no longer valid.

    Based on my experience I would add at least
    -> req 2 – change of defaults
    -> req 6 – patching (especially software components not systems), change control and SDLC
    -> req 8 – password policy for system components and application components
    -> req 10 – Logging especially admin activity (10.2.2)
    -> req 11 – Vulnerability Scans, Pen Tests (esp external ones), FIM

    Only my personal opinion, but as a QSA I have a problem to sign SAQ A for my clients. This is excellent examle when compliance is not equal security ..

    • June 27, 2016 at 11:16 AM

      REALLY… an iframe? They deserved to be fined

      • June 27, 2016 at 1:33 PM

        Sorry but should be fined for what ? And who ?

      • June 27, 2016 at 1:44 PM

        Alex is referring to the merchant.

        If a Web server managed, maintained and controlled by a merchant initiates the payment processing by using a redirect or an iFrame and that invocation method is changed by an attacker to now invoke a malicious redirect/iFrame, that breach is the merchant’s fault, not the service provider’s fault. Therefore the merchant should be fined for their lack of security, not the service provider.

    • June 27, 2016 at 1:48 PM

      Exactly. This is why I tell my clients to do more than SAQ A if they really want to be secure. But I add monitoring of changes to the redirect/iFrame as well as admin access in requirement 10.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Announcements

If you are posting a comment, be patient, as the comments will not be published until they are approved.

If your organization has a PCI opportunity, is in need of assistance with a PCI issue or if you would like the PCI Guru to speak at your meeting, you can contact the PCI Guru at pciguru AT gmail DOT com.

I do allow vendors to post potential solutions in response to issues that I bring up in posts. However, the PCI Guru does not endorse any specific products, so "Caveat Emptor" - let the buyer beware. Also, if I feel that the response is too "sales-ee", I reserve the right to edit or not even authorize the response.

Calendar

June 2016
M T W T F S S
« May   Jul »
 12345
6789101112
13141516171819
20212223242526
27282930  

Enter your email address to subscribe to the PCI Guru blog and receive notifications of new posts by email.

Join 1,814 other followers


%d bloggers like this: