A new skimmer uses WebSockets and a fake credit card form | Hacker News Reader

A new skimmer uses WebSockets and a fake credit card form

blogs.akamai.com

96 pointsgok39 comments

As a non-infosec person, I'm very curious why the term "skimmer" is used for this kind of exploit? Seems like a skimmer should be used for a physical device only. It seems odd to use it for exploits that take advantage of web-based vulnerabilities - they're entirely unrelated unless you make heavy use of analogies.

I was not familiar with this usage, and was initially confused.

For this kind of exploit, it seems like we already have the terms like formjacking and script injection.

Edit: I (half-jokingly) propose the term "skimware".

It's skimming credit card data at the point of use. Physical terminal or webpage doesn't seem a big distinction. The end result is the same, and it is a term that the general public is more likely to have heard. "Script injection" doesn't mean anything to to the average consumer.

Script injection is bad and all but doesn’t convey the fact that sensitive data is being sent to 3rd parties. Skimming, or card skimmer, immediately triggers thoughts of exfiltration.

I support the use of the term in this case.

Computers adopt terms for physical analogues all the time. They're not always 1:1. Like "Desktop" for your background/icons in an OS. Or "window" for a portion of your screen than an application uses. Or "mouse" because it looks like a mouse. These terms get rolled into use and kinda take on a meaning of their own in the context of computers. I'm sure there's better examples of words that you'd never relate to their original meaning, but skimmer seems fine to me for this application.

I would argue that "script injection" is the means by which the credit card is "skimmed"

Yes, agreed, it's "skimmed" in quotes, because it's an analogy. I'm still not sure if it's wise to use the same term for both a physical and virtual skimmer, from the point of view of a regular consumer.

Something like "skimware" seems better, if you must use a specific term related to "skimmer".

Maybe I'm wrong, though.

Yeah, well, if you look closely, I also put "script injection" in quotes. I only did that for emphasis.

A physical credit card skimmer is using the same "skimming" analogy.

Which analogy is that? I always assumed a physical card skimmer was based on the following definition of "to skim" (from Merriam- Webster):

2: to read, study, or examine superficially and rapidly

Edit: If you mean the original meaning (??) of skim (as in skim a liquid surface), then maybe???

Looking at the definitions from the free dictionary, they seem like different aspects of a common concept cluster. Light, superficial, quick motion, taking a small part away.

Skimming a card when it's swiped fits in perfectly with this.

When I think of a credit card skimmer, a pay at the pump card reader attack is what first comes to mind. Such as where the customer inserts their card, completes their purchase and the entire transaction goes through without any apparent issue.

This attack seems to be more like a spoofer, the comparison would be a phoney ATM machine that victims insert their cards, the card is cloned and the victim is then prompted to enter their PIN. After which, the phoney ATM professes a network error or the like and the card is returned. No legitimate transaction occurs.

I am a little concerned with the morality of publishing this attack in such detail without first notifying and giving a period of time for the susceptible vendors to patch this vulnerability. Doing so it is very reminiscent of how sensitive information was published years ago enabling drones of script kiddies to engage in Ddos attacks back a few years (decades) ago.

It was my understanding that there is a general code of conduct, regarding publishing these attacts that was created to prevent the proliferation of vulnerabilities before developers had an opportunity to address the issue.

Yeah like a pool skimmer or skimming fat from milk

I agree, it's not a skimmer.

> curious why the term "skimmer" is used

It has a history of this usage, eg https://blogs.akamai.com/2020/01/protecting-websites-from-ma...

It relates the attack to something a lay person can easily absorb. As their security blog is written for a lay person (ie, IT manager type person who has some understanding of infosec but probably not their day job), who will not care too much about the nuances of how the attack is perpetrated, the term serves them well.

> It has a history of this usage,

I'm not questioning the usage, just wondering why.

> lay person...who will not care too much about the nuances of how the attack is perpetrated

But the mechanism of the attack, and the way to protect against it is entirely different. That's my major issue, which I failed to fully explain above. These are completely different attacks, and completely different mitigations. And they only sometimes share the same target of the attack.

From my personal experience:

I had a customer once who wanted a security assessment of their payment terminal. Apparently one was stolen and they wanted to know how difficult it would be for an attacker to... well... "you know the name of the attack where they steal credit card info and such ?". So I replied "skimming". The attack actually did happen where they reversed the terminal to find vulnerabilities and used that to steal a database with payment information. No physical device was used for the attack, but the name "skimming" seemed relevant.

Bottom line is, you use the word you and involved people know to describe the threat we face.

> Bottom line is, you use the word you and involved people know to describe the threat we face.

Fair enough, that sounds practical. It just seemed like those two attacks were very different in mechanismn and mitigation. The term confused me here. But hard to argue with experience.

I would just call it another form of phishing.

IMO this is little help. The root of the attack, ie, how the attacker injected the code into user browser is not shown. Traditionally attackers can change domain names within hours after they realized that the destination was discovered.

IMG The correct approach when studying this type of attack is to understand the source of the attack, not the outcome

TBH, this whole blog post just seemed like a poor ad for Akamai's Page Integrity product, and deliberately overcomplicated 2 problems that should be very simple to deal with:

1. How did the malicious script get injected in the first place? CSP should eliminate if not greatly reduce this attack surface.

2. The blog post states "Also, a lot of CSP policies don't limit WebSockets usage." Umm, what? Why not, this seems incredibly stupid to me, that's the whole point of connect-src. What I did find was this issue report, https://github.com/w3c/webappsec-csp/issues/7 , stating that connect-src 'self' doesn't allow websockets in many browsers because it's technically not same-origin, so all I can imagine is that there is some (bad, lazy) practice where if you wanted connect-src 'self' to allow websockets back to the same host you just said "fuck it" and also put ws:* in your connect-src, which is just a bazooka aimed at your foot.

> CSP should eliminate if not greatly reduce this attack surface.

Sure. Or just don't load untrusted 3rd party javascript in your payment form. No banner ads. No dodgy trackers. The page where a user enters their card information is a high security context.

No, you're missing a very important vector described in the post. It's not just about making the payment page secure. Indeed, many (most?) e-commerce websites already link off to a secure 3rd party payments page. The problem is that if the originating page gets compromised, it can replace the link off to the secure payment page with a link to a malicious page.

This is not theoretical. Many websites include a primary "marketing" site built in something like WordPress that links off to a more hardened "app" site for authenticated users with stronger security policies. If your marketing site gets compromised, malicious scripts can usually pretty easily replace links to your app site to a spoofed page.

Oh; you're totally right. I missed that.

Before HSTS & key pinning was a thing, most people who visited gmail still browsed to gmail via http which redirected to https. Because the original query wasn't secure, someone at defcon did a silent MITM of gmail by catching the insecure http requests and not redirecting them to https. Then they caught people's credentials that way and proxied the real gmail, with all the images flipped all the images upside down so people knew something was up.

Its interesting to think about web redirects as a kind of chain of trust. The earlier insecure request destroyed the security of the secure context established later.

The correct approach is clearly not to ask how 3rd party scripts are being injected into your web page but instead to just purchase Akamai's Page Integrity Manager.

Injection and payload are orthogonal, somebody who can inject scripts just sells that to somebody who has a payload.

At least my Instagram story feed is full of ads where these people find each other. (I mark them all as "scam or illegal" but Instagram removes such ads with a few weeks of delay and never bans their accounts)

Completely agree, I was searching the comments to make sure someone pointed this out. The vector here is the how the injection occurred and not whatever the injected script is doing. Once code is injected its game over.

Gotta love the completely superfluous dig at Cloudflare. As if providing the client IP is what enabled the attack. That was probably the least interesting part of the attack. Cheap shot Akamai.

I feel like it isn't a dig at all:

> The skimmer uses a Cloudflare API in order to get the end-user IP address.

They described what the script does in detail, and that's part of what it does.

I agree. It would be weird to document the call to a 3rd party source without explaining it.

"Cheap shot". Yes.

Also no mitigation suggested other than CSP for which "A lot of CSP policies don't..." Which is a suggestion to use CSP correctly, in a backhanded way.

It is a sales pitch plus an info-sec report.

They do suggest a mitigation: Akamai Page Integrity Manager, which they say is proven effective against this attack. I wish they'd have stated if they had to make an update to PIM for it to recognize this attack, or if it worked as-is (as-was). The lack of such statement, given that this is a sales blog, strongly suggests they had to update PIM.

Indeed it's a bit of a cheap shot since they could have gotten the ip via whatismyip.com or any other innumerable ways. It just happened to use CF, which I'm sure they were jumping in joy about since they get to do a direct compare against CF: Akamai has PIM, CF does not.

Any idea how the attacker manages to inject their JavaScript code?

Sounds like it's likely coming from a browser extension because they called it "client side".

"The skimmer injects a loader into the page source as an inline script."

"Given the obfuscated nature and supply chain origination of in-browser attacks, traditional CSP-reliant approaches miss most of these types of attacks."

"Also, a lot of CSP policies don't limit WebSockets usage."

...But CSP is very aggressive with denying inline scripts.

Could be a browser plugin, or maybe an infected common JS package?

My reaction exactly. This whole post seemed like purely thrown shade against CSP, which should prevent both injection and data exfiltration as designed when used correctly, in order to sell Akamai's product.

There’s absolutely nothing of interest here besides the script using websockets instead of xhr to transmit the data?

It's also spoofing 3rd party forms thst it cannot inject itself into.

Interesting addition, the malicious domain is registered [1] to Ivan Popov, a Russian chess grandmaster. [2]

[1] https://domain.glass/tags-manager.com#whois

[2] https://en.wikipedia.org/wiki/Ivan_Popov_(chess_player)

Ivan and Popov are not exactly uncommon names, especially in Russia.

Reply on news.ycombinator.com