The Expert Guide to Defeating eSkimmers (ep. 8)

00:00:00:05 - 00:00:31:11 Chad Horton We had one merchant where they got so overwhelmed managing this list that they just stopped it and they're like, no, we're done. We're not going to do this. And it was no more than like 2 or 3 weeks after they stopped logging in and monitoring those and authorizing them that they got hit by a skimmer, and it took us three and a half weeks to get a hold of them to let them know, hey, there's a skimmer on your page, you really need to take action.

00:00:31:13 - 00:00:48:03 Jen Stone Hello, and welcome back to the Practical Cybersecurity Podcast. My name is Jen Stone. I'm your host today, but I have a huge team with me today to talk about a very important topic, and I would love it if you would each introduce yourselves, starting with Gary. 00:00:48:05 - 00:00:58:07 Gary Glover I'm Gary Glover, I'm the VP of our assessment team here at SecurityMetrics.

Been doing cybersecurity for about 21 years. 00:00:58:08 - 00:01:07:11 Chad Horton I'm Chad Horton, I'm the VP of technology here at SecurityMetrics. I'm the individual who coded the original design for the Shopping Cart Monitor product. 00:01:07:12 - 00:01:15:00 Aaron Willis I'm Aaron, good to be here with you again, Jen.

I'm the vice president of forensic investigation, and have been with SecurityMetrics about 16 years. 00:01:15:00 - 00:01:51:01 Jen Stone The last time we all got together, we talked about the new 6.4.3 and 11.

6.1 in the PCI standard. These are the ones that talk about protecting scripts on a payment page. And we want to talk a little bit about what the rule is and how far we've come since it becoming a new rule and how, what we're seeing in real life in terms of these issues.

So, Gary, would you please frame for us what 6.4.3 and 11.6.

1 are intended to do. 00:01:51:03 - 00:03:04:04 Gary Glover The original intent years ago, when we kind of started seeing the council think about this and asked for input from industry like us and other QSAs and other service providers, was what do we do about malicious scripts that are skimming credit card data off of payment pages? 6.4.

3 is kind of about, hey, if you have scripts on your payment page, you should know what they are or what they're doing, and you should keep a list of them. And I think part of the intent there was, boy, if you find out how much you've got on your payment page, maybe you'd like to reduce that number of scripts. We can talk about how that's worked over the years in a little while, but, and then 11.6.

1 was really kind of intended as a control to detect those kinds of changes, any kind of changes to the browser environment, the document object model, the DOM. That detects any malicious scripts or changes to important headers that are security headers, things like that. 00:03:04:05 - 00:03:18:21 Jen Stone What happens when we don't have the right kinds of protections in place for 6.4.

3 and 11.6.1? What is the actual result from a malicious actor standpoint?

00:03:19:01 - 00:05:48:11 Aaron Willis We first started seeing these iframe bypass attacks back in November of 2020. We started seeing merchants that had iframes installed and they were installed correctly. We saw the data leaking that grew in sophistication to where you didn't have to type in your credit card. Again, it would just grab it right from the initial get-go.

Everybody would get what they wanted, the merchant would get payment, the customer would get their goodies, and the attacker would get the credit card, and everybody was happy. A common analogy I like to make is if you put a safe in your house, you still have to lock the doors and windows. You can't just rely on the security of that safe for it. If a robber gets in your house and they're there with that safe long enough, they'll figure out how to get the goodies out, even if they have to replace that safe and put another one in place that they have the secret combination to.

So you have to lock the doors and windows on your website, because even a correctly configured iframe where everybody is doing everything correctly is still vulnerable. It's still just an HTML element on the page. And those elements have vulnerabilities if an attacker gets access to them. We have seen a number of our smaller clients moving to full payment redirects to get around 6.

4.3 and 11.6.1.

However, that's really kicking the can down the road. An iframe has inherent security features - same-origin policy that offers a whole lot more security than just a payment redirect. That's just a link. An attacker can change that very easily.

We've even seen ones now where a payment redirect is hijacked and payment still completes and nobody knows anything has happened. It's especially dangerous on mobile devices because oftentimes the screen is so small, you can't see that the URL is anything different than what it was. We encourage everybody to still use iframes. We don't want to deprecate iframes at all.

They're still the best way to protect that credit card data. 00:05:48:12 - 00:05:56:23 Jen Stone But there are things that you can do. And Chad, I want you to weigh in here because, yeah, you wrote that original Shopping Cart Monitor. 00:05:57:03 - 00:07:41:15 Chad Horton Yeah, our approach from the very get-go has been more in line with what you see in 11.

6.1, which is how do we detect changes that are occurring on the page? How do we detect variations that are commonly associated with skimmers and signatures in general? So all of our Shopping Cart Monitor versions from the ground up have been built for how do we achieve this 11.

6.1, where we can really pinpoint when behavior starts to step out of the norm and step into skimmer behavior so that we can notify the customer. Now, with the PCI DSS that came out, they introduced the 6.4.

3 inventory. And to be honest, it's both brilliant and painful at the same time. It's brilliant because they really have identified that supply chain attacks are a legitimate concern, that all merchants, all customers need to be aware of. That inventory side is also something that Shopping Cart Monitor does.

It's an agentless solution that allows us to shop your website. And it's gathering all the metadata, all the information about what is occurring on your checkout page. And then we do both an analysis against it, and then we also create a list of every JavaScript execution, piece of JavaScript code that executed on that page. That allows us to both do the analysis and also provide you a clean list that you can do your inventory against in order to achieve compliance.

But more importantly, be aware of what's occurring on your checkout page. And so ultimately, our tool has been designed to be a tool that allows merchants to identify when skimmers are there so that they can know when do they need to get eyes on the glass themselves, when do they need to step in and look for these types of attacks on their page? 00:07:41:17 - 00:08:10:00 Aaron Willis From a forensic investigator point of view, it really does grab everything that comes across and is assembled in the browser, or everything that gets called in from the third parties.

All that gets pulled in and we've got such an amazing data set to look at to find out what really is going on on that payment page. The moment the credit card is typed in by the customer. 00:08:10:02 - 00:08:56:21 Chad Horton The amount of data that we're gathering, we found skimmers that are hiding the actual JavaScript inside of images, inside of cache, inside of web storage, cookies, you sort of name it in different locations of the browser. They're trying to put that wherever they can, wherever they know people aren't looking.

And the beauty of Shopping Cart Monitor is it really does a fantastic job of gathering all that data, giving us full visibility that you can't get through, like dev tools or something like that, into everything that's occurring on that checkout page. And even when you get advanced attacks that are skimmers that are going on, where they're trying to delete records of themselves out of the DOM after they've injected or they've detected something on the page, we still gather all that data.

Deleting it doesn't make a difference. We still have all of that data to look at. 00:08:56:22 - 00:09:25:14 Jen Stone I want to revisit what you said earlier about the requirement. Part of the requirement is you have to know all of your scripts that are going to load on that payment page.

You have to have an inventory and they have to be justified. And I think, as you said, the initial thing was if we require merchants to record all of this information to keep it up to date, maybe they won't have so many scripts on their page. Is that what we're seeing in real life? 00:09:25:17 - 00:11:16:06 Chad Horton Unfortunately, I would strongly disagree.

We're not seeing customers reduce the number. I mean, there's just so many pressures from marketing, from PR, from everyone else who's trying to optimize the experience. The developers, all of them want to have all their scripts on the payment page. They want to know the moment that a customer drops out of that checkout process, including the credit card, because that could be an indication that there's something wrong that they need to improve.

There's some way that they can optimize it to increase the number of transactions that they're getting going through that page. There's so much valuable data to be gathered there. And because of that, people don't want to remove their JavaScripts. And most of these JavaScript libraries are upstream from a third party, so they just include them.

And we just see that list, I would say at least staying the same, but I would probably - I haven't looked at strong data, but I would guess that it actually is increasing. And to be fair, I want to just be super clear that we at SecurityMetrics see the challenge that the council has. They have foresight that we don't have. They know about supply chain attacks that are occurring years before we, as the general public, really see the size and the magnitude of them.

And so, like I said, 6.4.3 requiring merchants to know every JavaScript that is running on there, including third, fourth, and beyond-party JavaScripts that are loaded on that page, that is very tedious to accomplish, very tedious to try and go and authorize. How do you authorize a script that is a fifth party?

You don't even know how to track that down. And if you're a ma-and-pa shop, that is a very impossible task because you may not even understand what a JavaScript is. So I definitely see both sides of it - the pain on the merchant side, and I see the pain on the writers, the authors of these requirements and the challenges that they're trying to balance as well. It's an impossible task.

00:11:16:07 - 00:12:31:09 Aaron Willis I think when we first started on 6.4.3, I don't know that any of us really had an idea of how deep that rabbit hole went. Back in the early days, all that stuff happened back on the server side, and we invested so much time and energy securing the web server itself, because that was where the sausage was made.

Now, so much of the sausage-making responsibility has moved into the browser, and that browser in many ways is now the web server. You know, it's going out and getting all of the sources. It's going back to the database and grabbing more stuff out of the database. It's going out to the CDNs and the third parties, and it all comes together in the browser.

And the attackers know this. And so they just hide in all that, you know, chaos that's going on in the browser. And they don't pop up until the exact moment when the customer is typing in their credit card data. And as soon as that data is there, the malware pops up, it grabs the credit card and goes back to ground.

And if you're not right there when it happens, you don't know anything. Anything out of the ordinary has happened. 00:12:31:10 - 00:13:13:01 Chad Horton The crazy thing is, even when you have a tool like Shopping Cart Monitor that is notifying you and saying, hey, you need eyes on the glass, there is a problem with your website. It's a crazy situation when you're talking about third, fourth, fifth, sixth parties because they're so far removed from the merchant.

The merchant sometimes struggles figuring out where do I go in order to resolve this. And even when they go to their third party, their third party is looking and saying, well, I don't know where to go to figure this out. Like we'll go to our third party and then it's sort of this process and it's a very challenging situation that we've got. It's not like the old days where it's like, hey, you've been compromised.

You need to go close this port and update it, and you need to treat that server as compromised. There's a long chain of individuals that sometimes have to get involved in these compromises in order to be able to bring it back and really fix this website. 00:13:26:22 - 00:13:31:14 Aaron Willis It really makes building a responsibility matrix very tricky. 00:13:31:15 - 00:14:18:22 Jen Stone And I think one of the real challenges when we're talking about merchants is our smaller merchants who fill out the SAQ.

We got a little more guidance from the council on it, saying it can't just be, hey, your iframe provider takes responsibility. They have to assure you that you are not susceptible to these attacks. So I initially saw several iframe providers that put publicly on their websites, "We are responsible for 6.4.

3 and 11.6.1." And then I think as I started seeing the depth of the problem, they went, oh, wait a minute, maybe this needs a little more conversation.

And so the merchants are in this awkward place of not being sure exactly what they're responsible for or how to address it. 00:14:18:22 - 00:14:58:05 Chad Horton I've had merchants come back to me and say, hey, last year they had on their website, like you described, that my service provider was publishing that they're taking ownership of it. They're doing that for me. And then they come back this year and that's no longer on their website when they go to confirm it.

Or they've talked to a technical support rep, like the first layer, technical support. And they say, oh yeah, of course it is. And yeah, I'll respond in the ticket. And they hurriedly type out and close the ticket.

But when you think about the ramifications of if there is a breach, is that going to actually legally protect them? And in many of these instances it may, but it's going to be costly. But I would guess that it's probably not going to protect them. And so like you described, getting it formally documented from the organization is always the best approach, but you still need to be checking in and making sure that they're not changing their business model, and you're left out in the cold and unprotected or uncovered.

00:15:17:08 - 00:15:56:21 Jen Stone And then I've even seen some language in responsibility matrices, you know, documented responsibility matrix that says “our iframe when properly implemented…” And then you're left with what does properly implemented mean? Like, does it also include these other protections for the iframe or are we just limiting it to the iframe itself? So although we hate to think about, you know, legal ramifications in the case of a breach, that really is something that people have to be aware of.

And what does this language actually mean in terms of that practical perspective of what do I, as a merchant, need to do? 00:15:56:23 - 00:16:10:12 Gary Glover Well, and if somebody uses the words, you know, "we're okay as long, you know, we've got your back, as long as you properly implement it in the iframe." To me, the next statement is “and here's how you do that.” 00:16:10:13 - 00:16:11:02 Jen Stone Yeah.

00:16:11:06 - 00:16:38:23 Gary Glover And it should be. Well, okay. You're telling me that this is one of the conditions for coverage? You better tell me then what you mean by properly.

So that's something that merchants can feel confident asking. If you see those kinds of statements, you can just go, well, okay, then give me the list of things that I should be doing. And if they can't provide that, then what? You have to make a business decision at that point.

00:16:39:00 - 00:17:29:14 Aaron Willis And a good point about the eligibility criteria. It says someone has to take responsibility and make the statement, "my website is no longer susceptible" or "their website is not susceptible." From a purely technical format, that's an impossibility because everybody's site is vulnerable. It's “how vulnerable is it”, right?

Vulnerabilities are always there. So if a third-party service provider comes in and says, "we have validated that this site is not susceptible to any scripting attacks," how did you do that? That's an impossible statement to make because every site is vulnerable. 00:17:29:16 - 00:18:04:17 Chad Horton Secure is also susceptible to timeframe.

Right? I can have my web server 100% secured and locked down. I've done everything within my ability today, but if tomorrow there's a zero-day that undoes all the preparation that I've done today. And so if you look at these requirements, part of that cadence and PCI in general, whether we're talking about ASV or reviewing your policies, social engineering training, whatever it is, they all have a cadence to them so that we can be refreshing what we've been doing, reevaluating and seeing.

Are we doing everything we can to lock this down or to secure it? 00:18:04:18 - 00:18:39:04 Jen Stone So let's say just from an operational point of view. So we've got a business leader or IT director who's listening to this podcast and saying, you know what, I have an iframe doing our e-commerce. We've got third parties involved.

I know we have a lot of scripts because of marketing, that type of thing. I don't know that I want to jump and put Shopping Cart Monitor on and have that go yet. I kind of want maybe more of a point-in-time deep-dive inspection. What option do you have for that?

00:18:39:06 - 00:19:12:20 Aaron Willis Our forensics team has a service called Shopping Cart Inspect, and this is a one-time or once-a-year look under the hood at your website in all of its various states of the transaction process. We have an actual person, a forensic technician, look at the JavaScripts that are affecting the checkout process, and let you know if any of those JavaScripts are a concern, or presenting a security threat. 00:19:12:21 - 00:19:44:04 Chad Horton And that is a forensically trained human looking at this; as someone with a set of skills, a certain set of skills, that your teams internally probably don't have.

So including them and having them look at it is such a high value to have. Similarly, having a forensically trained expert looking at your website, looking at that, it's another layer of protection that you get and assurance that you get over the security or the state of the application. 00:19:44:06 - 00:20:02:16 Aaron Willis So many times in that shopping cart, we even find malware that's present that nobody knew about and can really provide a baseline going into Shopping Cart Monitor so that you don't accidentally whitelist malware that could potentially already be present.

00:20:02:18 - 00:20:21:16 Gary Glover I mean, it's not a PCI requirement to do that, but it's sort of analogous to saying I run an ASV scan, but once a year I do a pen test with a real person. And, you know, again, it's not something that could be required of, but it's the difference between an X-ray and an MRI. 00:20:22:04 - 00:21:31:22 Aaron Willis We had one of our forensic team members found what we call a zero-malware attack. There literally was no malware running on the checkout page, but the credit card data was still leaking.

And, you know, common sense, "Wait, how is that even possible?" What the attackers had done was go through. They'd gone in and found an analytic script, a legitimate analytic script that had the capability of capturing everything on the page. But if properly configured, it would exclude credit card data.

The attackers had gone in and just added a little flag to the credit card fields that the legitimate script would then include credit card related data in what it was grabbing. And then, you know, the customer would type in the credit card. The legitimate business analytics script would then grab all of that data, and the attacker would then exfiltrate it on a page long after the transaction had completed. 00:21:32:00 - 00:22:02:02 Jen Stone So I would be interested to know, Aaron, you are doing these kinds of inspections, forensic activity against e-commerce pages all day, every day.

You know, you have a huge breadth of experience in this. How often really are you getting malware issues on pages where maybe the merchant thought they were just fine? 00:22:02:05 - 00:24:05:20 Aaron Willis And it happens more often than not. When we get a case where a merchant is suspected of leaking credit card data, quite often we go in and find the merchant has attempted to set up everything correctly.

You know, they cut and pasted the code from the legitimate service provider. And, you know, they believe everything is running smoothly. But the problem is, the attackers are still getting in on the merchant side. As Gary mentioned earlier, we're not seeing service providers being compromised.

It's not something happening inside of that iframe that's the problem. More often than not, that iframe is perfectly intact. The attackers have just found a clever way of circumventing the same-origin policy, the protection that that iframe provides, and it's usually something happening on the merchant side of things; A plugin that was out of date, a SQL injection vulnerability, maybe not even in the payment application, but something somewhere else on the site that allowed the attacker to get in and move into a position where they can then inject some JavaScript in that's going to allow them to circumvent the security of that iframe.

And so it happens quite often where the merchant has no idea that they even have a vulnerability that could allow the credit card data to leak from their side. But the attackers have found the loophole around those things, and that's in the customer's browser at the moment they're putting that credit card data in. That's where these new attacks are happening. And that's why 6.

4.3 and 11.6.1 monitoring is essential, because that's where these new attacks are happening.

00:24:05:22 - 00:24:25:01 Jen Stone Maybe let's think about what we're going to see over this next year, either from an industry or compliance standpoint or from what the threats themselves are going to do or how we address them, maybe how Shopping Cart Monitor itself will evolve. What do you see when we come back a year from now? 00:24:25:03 - 00:25:26:23 Chad Horton I think the number one thing that we're seeing is that we've put a lot of weight, especially on smaller merchants, like I mentioned or alluded to earlier.

Now they have to justify and authorize all these scripts. They have to maintain that list, and then they also get alerts of any time things are changing on their website that could be indicative of a problem. And so I think in general what we're going to see is merchants, if providers like SecurityMetrics that are providing solutions are going to have to lean on AI heavier, provide more tools for merchants to be able to say, hey, this is the level of technical experience my organization has.

This is the amount of time that we have that we can invest to this, and they're going to have to start leaning on AI or other such wizards. Or maybe it's just even outsourcing to other organizations to take some of this heavy load from them so that they can offload it and only get escalated when those critical issues occur or the issues that they want to be involved with, that they have the ability to be involved with, that they can. 00:25:27:00 - 00:25:36:03 Gary Glover And it becomes this: "Now I have all these scripts and do I really know what they are?

I'm just going to go ahead and authorize them all." 00:25:36:04 - 00:27:02:20 Chad Horton I had shared with Aaron the other day that we had one HR lady who worked at a law firm who, she was doing her inventory, called in on the very last one to our technical support, and she asked for help. She's like, I really have no clue what I'm doing. And the agent's like, hey, yeah, let me get on board.

Let me hurry and look at your results. Let me see what you've done so far. And she had gone through every JavaScript and written N/A for every single one of her authorization rules, because she just had no clue what she was doing. She didn't know what a JavaScript was, she was just trying to get through.

But she's the individual at that organization, a non-technical organization, that's being put in the situation to make those decisions. And so I think that's where we're really going to see a suite of tools or services around how do we provide additional support to these smaller and midsize merchants to help them find success with these requirements and gain the benefits that really can come from them at the same time? And so I think the number one thing I see changing in the next year is going to be that.

And then the number two, I'm going to say it because I know Aaron is going to say it, but I want to steal it. I want the credit, okay, we can share or we can share the credit, Aaron. But I think the number two is we're going to see an increase in supply chain attacks. If you look at the last six months, it's just been steadily rising.

I mentioned Bitwarden CLI got compromised last week from when we're recording this. I think we're going to see an increase of those on the websites. 00:27:02:22 - 00:28:19:16 Aaron Willis Node package manager also got hit. That was a huge one that is a fundamental library for so many things that we're doing in e-commerce.

Alert fatigue is a very real issue. You know, we can alert on everything. You know, it's slightly suspicious or medium-level suspicious. But the other real issue is checking a box saying you did something, but no real security is behind it.

And so the industry is going to have to wrestle between those two things - alert fatigue or check the box on a not-real solution that's not providing anything that offers a real solution. And so in the next year, that's going to have to be wrestled with. And solutions that aren't doing anything have to be filtered out. Solutions that are causing alert fatigue, especially for smaller merchants that simply don't have the ability to deal with that much information.

Those have to be refined with either AI tools like Chad was mentioning, or you know, better ways to handle it. For smaller merchants, those things still have to be wrestled with. 00:28:19:18 - 00:29:15:14 Jen Stone I think from a QSA standpoint, we are getting better at understanding these requirements and learning better how to evaluate them and offer recommendations for small and, well, for merchants of all sizes to be able to meet them. This was a challenge for a lot of QSAs to understand the technology behind it.

And I'm grateful that from 2020 and even before we launched it, that you brought me into this conversation and shared that knowledge. And for any QSAs that are listening, if you're still struggling with it, there are FAQs out there. SecurityMetrics - Gary wrote a great white paper on some of these skimmer attacks and how to deal with them. And so there's great information out there on how to understand and deal with it and be able to offer good advice.

Any final words before we close? 00:29:15:16 - 00:29:17:08 Gary Glover See you next year. 00:29:17:10 - 00:29:21:15 Jen Stone Absolutely. It's a date.

All right. Thanks, everyone.