The online payments ecosystem is plagued by formjacking attacks that siphon credit card data and other protected information from shopping cart pages.
The online payments ecosystem is plagued by formjacking attacks that siphon credit card data and other protected information from shopping cart pages.
This post is based on an episode of the SecurityMetrics Podcast with Host Jen Stone (MCIS, CISSP, CISA, QSA) and guest Aaron Willis (PFI, CISSP, QSA) which discusses the issue of formjacking, why current security methods don’t work, and how you can stop these attacks on e-commerce shopping cart pages.
Subscribe to SecurityMetrics Podcast here.
Jen Stone: E-commerce skimming is having an impact on the credit card industry, and therefore it affects the PCI compliance realm. This attack is known by other names as well: formjacking, redirects, keylogging, Magecart attacks.
Aaron Willis: In the forensics world, we especially want to prevent attackers from gaining access to payment card data. This type of digital skimming hack has its roots in the popular point-of-sale attacks where criminals would install physical devices next to a card reader in order to capture magnetic card data during a swipe, create a file, and send it off to a server somewhere. This was simply known as “card skimming.”
Jen: Card skimming still happens, but we no longer see the same impact at the physical point of sale that we see on online shopping cart pages. We call these online attacks “skimming” because they use the same concept–stealing your credit card information at the point of sale–only it’s happening online.
Aaron: The attackers took the idea of stealing data from a card swipe with a skimmer and put it online. When you’re at a card-not-present transaction, you’re not swiping your credit card. You’re typing a number into a field on a webpage. There are numerous ways that attackers can go about skimming this payment data. It can be similar to placing a card reader somewhere to catch data but instead of a physical device, they place a line of code somewhere–possibly on a server, or on a client that will harvest the card data, either as it’s typed in on the client’s computer, back on the server, or in any one of the third parties along the way.
Jen: We have a lot of listeners who don’t take credit card payments. Why does this apply to them?
Anytime you’re typing something into a field on a website, you could be entering critical sensitive information–like healthcare data, your name, phone number, or address.
Aaron: Who doesn’t do online banking these days? We see malware scripts being put anywhere they can grab credentials, whether that be online banking, digital medical records, even just a basic website compromise. If they can put a code snippet somewhere and grab data that they can profit from, they’ll do it.
Jen: E-commerce skimming sounds dire, but there are things we can do about it. Today, we’re going to talk about how to recognize it, what it is, and what you can do about it.
Aaron: We saw an initial increase in e-commerce skimming around the advent and implementation of EMV chips in the point-of-sale environment.
EMV has been effective in protecting point of sale, and we saw a decline in the cases of retail environment card skimming.
As a result, e-commerce environments became the new low-hanging fruit.
Jen: It’s hard to detect formjacking. As a security analyst, one of the things I’m supposed to do is look at the code on a webpage. It’s hard because of the sheer volume of code on every single page. I am supposed to look for malicious code, but it usually doesn’t look malicious, and it’s very difficult to find.
See also: SecurityMetrics PCI Guide
Aaron: In a point-of-sale environment, you’re locked down in a point-of-sale terminal. In the PCI world, there are regulations that protect point-of-sale terminals. Measures have to be in place, and there are layers of security wrapped around them. In the e-commerce world, the situation is more sophisticated and takes place on the backend. There numerous third-party scripts doing things like business analytics and advertising networks, where these 3rd party scripts are running.
Businesses use third-party services like webpage analytics–which are common and provide great ROI, but using them increases the available attack surface.
With shopping carts–especially open-source shopping carts–attackers have all the code available to them. So, if you shut down one attack there will be five more behind it. Attackers are constantly looking for exploits. They’re constantly running reconnaissance scripts. If you put a computer out on the Internet and watch it, you’ll see bot traffic that hits it over and over again. Hackers are looking for any opportunities they can take advantage of. If they find a way to exploit a shopping cart page, they get excited because there’s a good chance they’ll find credit card data. They can find and exploit vulnerabilities quickly. They may find an open port or a field that is not being sanitized properly, or perform a sophisticated type of cross-site scripting attack. Sometimes sites are exploited within minutes of a breach being announced.
Jen: We’ve seen in the news that some highly visible companies have had these types of attacks, and have really been impacted.
Aaron: We see them every day. Every day, thousands of websites are hit with malicious skimming code.
Jen: Thinking about some of the tools we have already in place that prevent a lot of malicious activity, wouldn’t you think that we already have the tools to combat this?
For example, FIM or file integrity monitoring. FIM tells you if a file has changed. And it will send you an alert when that happens. Why is that not telling us about javascript skimming?
Aaron: FIM is a vital tool. It’s not the only tool, it’s just another layer of security. If it’s properly installed and running correctly, FIM is good at telling you if a page in your shopping cart or in your card data environment has changed. But you also have to have people watching those alerts. Too many times with FIM, we see that it’s working and it’s alerting. But the alerts are going to an email address that’s not being checked and has 5,000 alerts that no one sees.
When you configure FIM, you have to tell FIM to look at certain pages and not look at other pages. FIM cannot protect what it can’t see. This can become problematic in a dynamic shopping cart environment. Think about this. The page that is rendered to the customer at time of checkout, with sometimes dozens of third-party scripts, data collectors, analytics and security scripts might be a very different page in the customer’s browser than it is on the server. FIM might see checkout.php as fairly static, but what does that page actually look like after all of the javascripts have been triggered, the “includes” are included, the plugins executed, and all the third-party cooks in the kitchen have added their seasoning to that final page? FIM sees none of that post-server frenzy and that is exactly when and where the bad actors are moving. It takes a different approach, and really, a different way of thinking about how we should be protecting that checkout page.
FIM can’t protect what it can’t see.
Jen: What about vulnerability scanning? Again, another essential security tool. Merchants need to be running vulnerability scans, but that’s just one aspect of security. One additional layer.
Aaron: A vulnerability scan has no ability to drill down into a shopping cart, click on a product, put that product in the cart, go to the checkout page, click into the CVV field, and enter data. (Which WIM products do.) Attackers are taking advantage of the moment when customers put in CVV numbers. They may have a little script running that completely hides the malware until the consumer finishes putting in the CVV number on the checkout process.
At that point, the attackers know they’ve got a full set of card data: a customer’s address, credit card number, and CVV. The malware is triggered. It launches, runs, grabs the data, and sends it out to another location. Then it goes dormant again waiting for the next customer to come along. An ASV scan has no ability to get down into the dynamic environment of a shopping cart. These are vital and necessary security tools, but they have blind spots when it comes to e-commerce or digital skimming attacks.
Jen: What about antivirus? Is it of any use in detecting e-commerce skimming?
Aaron: Antivirus is an effective tool for what it does. But, a lot of the affected websites are running on Linux systems. There aren’t many options out there for Linux antivirus. There are a few, but typically we see that merchants using Linux don’t use antivirus. If the malicious skimming code is running in a third party or in the database where the antivirus can’t see it, it has the same problem FIM has. If it can’t see it, it can’t detect it. Plus, a lot of times these malicious scripts are not operating on the server. They may exist on a content delivery network (CDN).
It is important to note that antivirus is still essential. We want everyone to use antivirus, but it is probably not going to see most e-commerce skimming attacks because they’re not running where it can see them.
Jen: What about client-side certificates?
Aaron: Client-side certificates are a useful tool for protecting the servers and the customers, and making sure that a transaction is operating in a secure tunnel. But if you’ve already got malicious code coming in on a third-party, it’s kind of like locking your doors after the attacker is already in the house.
Client-side certificates are great additional security to have, but they can’t directly combat digital skimming.
Jen: How does JavaScript skimming happen? When you investigate an attack, what evidence do you see?
Aaron: It depends on how the attackers are operating. If they have a connection to the merchant’s web server, or if credentials have been compromised, they can go in and insert programming code directly on the web page itself. They can capture data and nobody would know about it. The customer still gets their order and the merchant gets paid. Everybody’s happy. Especially the attacker.
With that level of access, attackers can go in and whitelist a checkout page so FIM is no longer monitoring it. We’ve seen that happen.
If attackers have access to the server, they can put code anywhere they want. If they’ve got access through a database server exploit, you can look at the shopping cart and see if it’s pulling code from the database. A lot of these shopping carts have code saved in the database.
We’ve seen JavaScript skimmers stuck in the dropdown lists that populate the state or country fields on a webpage. The attackers can see it’s included on the checkout page, so they decide that’s a good place to hide it. When that kind of attack renders on the browser, you don’t see the JavaScript. It’s hidden.
Jen: By the time a data breach gets to you and a company knows they’ve been losing credit card data, what is your process at that point? How long has it been in place by the time you are able to identify it so that they can correct it?
Aaron: I just got done with one case where malware had been operating since 2017. The company didn’t learn about it until the middle of 2019. The attackers had set up multiple backdoors, and it turned into a game of whack-a-mole. We would find one problem and fix it, then all of a sudden different types of malware would pop up in different locations.
In this case, the malware was on a server that we didn’t know about. It was a development server that everybody thought was offline. But it mistakenly was not. It was still communicating and connected to the Internet. It was behind on most of its patches and security updates. We were focused on the web servers and doing our best to figure out how they were getting in. We patched and updated everything, and made sure the exterior perimeter was as hardened as possible, but finally discovered it was coming from an internal source.
In these cases, it’s good to find out for sure what is in scope and what is connected to the Internet. Make sure that devices have been deprecated, make sure they’re unplugged and disconnected completely.
We started running into skimmers years ago. In our standard practice, we’d have a merchant come to us that had an issue. We would then create a forensic image of their web server, which creates an exact copy. We then bring it into the lab, tear it apart, and look under every rock in order to find the malware. We look through unallocated space checking for hidden backdoors.
A couple years ago, we got a case where a business was bleeding a lot of card data. We looked everywhere for months. We sifted through their code line by line, checked that every input field was sanitized, and verified that they were using multi-factor authentication and running antivirus.
They were doing it all right. They had everything in place. We could not find any problems in their code. We couldn’t find any malware.
That night, I decided to look at the HTML on the rendered code right at the moment of checkout.
I was acting just like a customer; I used a test cart, typed in a test order, put products in the shopping cart, and went right to the point of checkout and entering card data. Then I noticed that something in the JavaScripts on the pages I was watching. I went back and compared what was on the web server versus what was in the browser and realized I was looking at two different pieces of code.
We had been spinning our wheels looking at the web server, but there wasn’t any malicious code present. It was in their database server. It was getting included from a compromised third party.
It turns out they had some analytics scripts running on the back end that were providing great data about when customers would abandon their shopping carts.
The third party providing the analytics script had been compromised, so the code merchants received was compromised.
An attacker had been able to insert one tiny little line of code that would trigger when the customer would type in their credit card number and get to that CVV field. It wouldn’t even show up until they had clicked into the CVV field.
If that activity didn’t happen (entering the CVV), the JavaScript would never trigger and the malware code would never show up. We then realized that it was no longer sufficient just to check the web server for malicious code, because this was a pure JavasScript exploit. The JavaScript was coming from the third party, it was not on the merchant’s server. The merchant’s security was actually fine–as far as their environment–but the third party environment had a breach that allowed the attackers in.
Around this same time, more of these types of reports were being noticed. We realized that we couldn’t just look at the web server anymore. We had to look at the code as it’s rendered in the browser. We had to go through the checkout process and simulate the actions–just like a customer would go in and enter data.
Aaron: We have patented this formjacking detection process–during which we monitor for changes as we interact with the shopping cart. We have a huge success rate at finding malware as it’s operating in real time–right on the customer’s browser.
Jen: So WIM is the solution that SecurityMetrics offers, for people who are interested in early detection?
Aaron: Yes. WIM alerts the merchant that they have a problem and need to get eyes on the problem immediately.
Jen: So it reduces the damage instead of a business having to wonder where all their data went.
Aaron: Instead of losing 100,000 credit cards, you might lose one, be alerted to the situation, and quickly stamp it out.
Jen: It’s also important to realize that these attacks affect more than just credit card info.
Any information that you enter a website can be stolen through formjacking.
We use credit cards as an example because this is typically what our customers come to us for in forensic analysis. This model will help you protect any information being entered on webpages.
Anytime you have a login that protects a sensitive area of the website, you should consider running a WIM scan that will look for the changes that only happen when triggered by the user’s actions.
.svg)
