Breaking news: Bank-card-slurping malware sneaks into Forbes' mag subscription website The Magecart credit-card-skimming malware that is the bane of internet shoppers has been spotted again, this time on the Forbes magazine subscription website. The infection was clocked by net security watcher Troy Mursch at around 0400 UTC on Wednesday. It appears hackers unknown somehow installed malicious JavaScript on …
How do they know?
How can they verify this and prove it to an auditor?
My quick perusal of the JS code would mean that the websocket outbound traffic would need to be blocked (or at least audited.) This is not likely to have happened in a normal user's browser session.
So, if I have missed something obvious please be kind.
A few years ago, I lost one of my cards and someone had a party with it. So, I got a prepaid debit card,(99p per month).
When I see something online that I want to buy, I load the card with money via bank transfer (free), give it a couple of minutes to reach the card account and buy whatever it is I am wanting.
At least, by doing this, the amount a thief could get would be very limited and would only happen once as I would cancel the card and get a new one.
This seems to be so simple that I am wondering if I have missed something screamingly obvious. As I said, I am not techie so it would not suprise me if I have.
Cheers... Ishy
Or, rather than have to pay for a pre-paid debit card, you could open an account with one of the banks which lets you "freeze" and unfreeze your debit card (such as, in the UK, Starling Bank; a few other banks are also now starting to offer this service) and only unfreeze the debit card to allow payments when you actually want to use it.
I'm not aware of any banks offering this useful service for credit cards as yet, however?
Given ads on forbes have previously served malwware (ironic as Forbes try to prevent you viewing with ad blockers)
They should know how easy script based compromises are based on that prior experience.
Lack of reply to emails
All shows signs of them just not being bothered, and yet another company just making a pretence of being concerned about security
Maybe I'm missing something, but when you pay by credit card you don't pay directly the seller, you are redirected to the bank site which processes the payment. So why are they allowed to ask for the credit card numbers before forwarding the customers to the payment network? Why are they allowed to store in their DBs the credit card numbers? The big data craze has led to the creation of a countless amount of copies of sensible data without a practical purpose that increased dramatically the risks.
>> when you pay by credit card .... you are redirected to the bank site
> Err no.
Err yes. I never bought on Amazon and I don't know whether, given their size, they implemented their own payment system, but most of the time the payment is processed by payment providers in redirected pages.
Maybe I'm missing something,
Err yep...
but when you pay by credit card you don't pay directly the seller, you are redirected to the bank site which processes the payment.
That's not normally how it works. You enter your card details into the vendor site, which then passes those details to a payment verification gateway. The payment verification gateway either approves or declines the payment, based on cardholder details, card number and CVV.
If the payment verification is successful then at this point in the transaction, there optionally may also be a call to the bank's card verification process. Successful payments receive a token which is stored in the vendor database against the transaction ID to action refunds or repeat purchases.
Why are they allowed to store in their DBs the credit card numbers?
They aren't. Some cowboy outfits may do, but it's not common. If it's a vendor where you register an account, the vendor may store the last four digits of the card alongside the transaction token and user details, just so you can re-use the card for future transactions, but the four digits are simply there to display to the user so he/she can identify the saved card, not for use in transactions.
That's not normally how it works. You enter your card details into the vendor site, which then passes those details to a payment verification gateway. The payment verification gateway either approves or declines the payment, based on cardholder details, card number and CVV.
You are not correct, same reply I posted above is valid for you.
“The original Magecart skimmer was comprised of javascript embedded into e-commerce pages”
How does Magecart get onto the e-commerce sites in the first place?
“Analysis from Trend Micro in 2011 revealed that mass compromises of osCommerce implementations were used to inject iframes into legitimate vendor pages which then pushed users to downloads of data-stealing malware”.
Of course none of these attacks would be viable if the browser couldn't make connections outside of the main site:
‘NoScript detected a potential Cross-Site Scripting attack from https://www.theregister.co.uk to https://syndication.twitter.com.’
Oh no! Yet again - when will they learn?
NEVER carry out any sensitive transaction processing client side, as (obviously) it's open to tampering. Always do it server side.
The prevalence of mandatory scripting on sensitive transaction web pages is little short of criminal, but it seems web devs can't or won't take note of this. I have the horrid impression that it's down to lack of expertise - that they may not even understand that a problem exists, let alone how to avoid it. The penalty of course is not theirs - it's their clients' and ultimately ours.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
