OnePlus minus 40,000 credit cards: Smartmobe store hacked to siphon payment info to crooks OnePlus today confirmed thieves siphoned tens of thousands of people's credit card numbers from its online store. The Chinese phone company admitted after a week of probing that about 40,000 of its customers had their payment card details nicked while buying stuff from its web shop. Crooks were quick to start plundering …
"Critics may note that OnePlus has previously given indications of playing fast and loose with computer security. The mobe maker was found last year to have shipped handsets with factory diagnostic backdoors left active and, just days before this investigation was kicked off, OnePlus admitted it had accidentally gave some international customers a China-exclusive app that relayed clipboard-related data back to Alibaba servers."
Whenever I pay with my Belgian prepaid mastercard, the payment processor refers me to my bank's verification page, where I need to perform a challenge-response routine with my TAN generator, card, and PIN. I've only ever encountered exceptions with Amazon, but I don't remember if they asked a verification for the first payment (and are only exempt for follow-up purchases), or if they never asked at all.
So I would assume that crooks, when trying to pay with my card details, would encounter the same verification wall. Thus making my bank details safe. Is that right?
It depends, can you process transactions without verification? Some schemes I'm familiar with like Secured by Visa/Mastercard Securecode only work if supported by the vendor, so they'd just use your card at an unsupported vendor. If it doesn't require vendor support (unsupported vendors would have to be deined), and you can't use the card to make point of sale transactions on a magnetic (not chip) card, then you're probably safe. But it would be my guess, that is probably not the case.
I'd call your credit card provider and ask them to cancel and replace that card.
Short answer? No.
That security relies on opt-in, which in EU companies usually do (Amazon is an outlier - they are too big to be coaxed probably), but outside it's more of a mixed bag, because credit card companies don't have the power there to tell the merchant to upgrade security or else.
IDK if it's possible for yourself to block any transactions without 3DSecure process on your bank side (that would prevent you from purchasing anything from Amazon, mind), but otherwise credit card processors tend to pass through any payment that meets the criteria, as they are set for that particular merchant. Many banks also apply some behavioral risk models, which actually stop some frauds. However, primarily they don't want to block legitimate payment (which is far more likely event, event in crime-ridden areas).
Still, if it's a fraud and you are not part of it and you didn't do anything really, really stupid, banks usually foot the bill (I know for a fact that my bank does at least).
And 3DSecure (in its VBV incarnation) is a bad thing (IMHO) as it encourages users to accept javascript / content from sa different site thsn the one they started their purchase on.
And if someone has "forgotten" their password, then all you need is card details (that you could have acquired illegitimately) to assign a new VBV password.
It g9ives the illusion of security but encourages bad security practice by users.
I avoid VBV sites whenever possible
"We are eternally grateful to have such a vigilant and informed community, ..."
Can we at least mix into the shower of "hell!"s a few 'hail's that (for whatever reason) they recognize that the relationship with customers can be of benefit to them, however much it might look antagonistic? Every company ought to have a "Tips and Corrections"-like response mechanism.
When the clock is running out on your reputation, you want to know bad stuff soonest!
"Here's how it went down: one of the store's servers was hacked, and its code modified....."
Would almost be an acceptable explanation if it was an inside job, by the persons responsible for said server. Even in that scenario, they should have had procedures in place to prevent the possibility. Otherwise, the train of events began much earlier with clueless managers, architects, sysadmins and developers ending up putting a vulnerable server online for processing consumer purchases. This sounds very much like they allowed direct remote logins to the server from the internet - a basic error that should never happen for systems like this,
Agreed, I don't play in serious (sensitive) web stuff - silly personal projects mostly. But if I was putting something online for my company, that dealt with sensitive customer information, you see enough of these articles that I would spend 30 minutes writing a Nagios script to verify the web content on the remote server periodically (every 24-hours).
It won't prevent a breach, hopefully the other layers of security would, but if they fail, at least this would highlight there's been a breach within 24 hours (rather than 2 months). it'd highlight what files have been altered and could, if you spent the time, shut down the site automatically while administrators investigate. It'll also mean you're responding to the attack a lot sooner - while logs are fresh, the attackers are still eagerly awaiting their stolen data etc.
> I would spend 30 minutes writing a Nagios script to verify the web content on the remote server periodically (every 24-hours)
(Static) web content isn't the issue.
There was almost certainly something generating dynamic pages on the backend (PHP, JBoss/Struts, maybe some web framework), and it wasn't being patched regularly. Or else the application code itself was written insecurely. Either way, the attacker exploited some vulnerability to add additional code that did the dirty. It could, for example, have installed a cron job which sent out the credit card details periodically.
Protecting the *whole* system with something like tripwire might have alerted them sooner though.
They are also not PCI compliant, I bought a phone from their online store last year and it looked suspect (not in terms of coding but because their website would be a expensive nightmare to push through the PCI compliance process) I mentioned this in a support call and got an nonsense answer that suggested that they had never heard of PCI. If this is the case they will be liable for all the fraudulent payments. They have stopped taking payments on their website now and I bet that's down to the fact that their accounts just been suspended due to non compliance by the payment processor / Merchant Bank rather than making sure their code is clean...
.....my card got hit on 1/12. It was Malaysia. Fortunately my credit card company denied the charges since I'm nowhere near Malaysia and don't have a history of such purchases. Regardless, the pain of getting a new card/account has commenced and a year of credit monitoring isn't going to make me feel better.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
