Known Flaws in Mobile Data Backbone Allow Hackers To Trick 2FA (vice.com) 50
A known security hole in the networking protocol used by cellphone providers around the world played a key role in a recent string of attacks that drained bank customer accounts, according to a report published Wednesday. From the article: For years, researchers, hackers, and even some politicians have warned about stark vulnerabilities in a mobile data network called SS7. These flaws allow attackers to listen to calls, intercept text messages, and pinpoint a device's location armed with just the target's phone number. Taking advantage of these issues has typically been reserved for governments or surveillance contractors. But on Wednesday, German newspaper The Suddeutsche Zeitung reported that financially-motivated hackers had used those flaws to help drain bank accounts. This is much bigger than a series of bank accounts though: it cements the fact that the SS7 network poses a threat to all of us, the general public. And it shows that companies and services across the world urgently need to move away from SMS-based authentication to protect customer accounts.
Re: (Score:2)
SMS isn't even one system. This is a problem with one specific transport.
Re: (Score:2)
And if anything, this is a need to move away from SS7 - not SMS.
Re:It's not a problem with 2FA (Score:4, Interesting)
No, there is a need to move away from SMS in general. A properly-implemented time-based key CANNOT be intercepted over the wire.
Re: (Score:2)
IIRC apple and amazon support code based in addition to sms based.
Re: It's not a problem with 2FA (Score:2)
In South Africa, there have been a lot of cases of what is referred to here as 'SIM-swap fraud'. It seems that there are syndicates operating that have accomplices who have:
- sufficient access to bank customer information for social engineering to re-set or change internet banking passwords and get the customers cell-phone number
- access to perform a SIM-swap of the victim's number, so that they can approve actions such as adding beneficiaries, change transaction limits while also preventing customers from
Re: (Score:2)
Sure, but that can apply to any second factor that becomes popular. Even SecurID devices.
Re: It's not a problem with 2FA (Score:2)
Yes, software-based TOTP implementations on smartphone platforms could be vulnerable to malware, but if using TOTP-based dongles, you would need to steal the dongle and possibly also know the PIN that must be used with the time-based code.
Re: (Score:2)
Or convince someone in customer service to issue a new one to a different address. It really does happen.
Re: (Score:3)
SMS isn't even one system. This is a problem with one specific transport.
This article is about one specific transport, but there are other issues with using SMS that makes it unsuitable as a 2FA method. One big issue is that cellular providers are often all to happy to move service to a new device with weak (if any) authentication that the person moving the service is the legitimate owner of the account. This has been used to breach SMS 2FA in the past. This is not, obviously, an SMS flaw but a provider one, but it happens enough that it's creating an insecure situation.
Re: (Score:2)
Social engineering hacks can compromise about any second factor you can come up with. Email is a definite bad choice. Google Authenticator pretty much requires a phone on you at all times (as does SMS, of course). And something like SecurID gets ridiculous when you have 20-30 web sites requiring 2FA.
Re: (Score:3)
Social engineering hacks can compromise about any second factor you can come up with. Email is a definite bad choice. Google Authenticator pretty much requires a phone on you at all times (as does SMS, of course). And something like SecurID gets ridiculous when you have 20-30 web sites requiring 2FA.
The problem with SMS is that once you compromise the phone, you get access to ALL of the SMS based 2FA accounts and password reset schemes. Most social engineering will get you one login, this gets you many. Plus it is usually harder to social engineer your way around a token based system as there usually isn't a 3rd party that can be compromised to get the required 2FA info. With a phone it's been done (numerous times) with just the person's name and basic public info, and what carrier they use, and some d
problem with SMS based 2FA (Score:2)
That allows the attacker to direct a target's text messages to another device, and, in the case of the bank accounts, steal any codes needed to login or greenlight money transfers (after the hackers obtained victim passwords).
... "Everyone's accounts protected by text-based two-factor authentication, such as bank accounts, are potentially at risk until the FCC and telecom industry fix the devastating SS7 security flaw," Lieu said in a statement published Wednesday...
In the meant
Bug or feature? (Score:3)
*yawn* (Score:2)
So someone would need to obtain:
1. My login to my bank account
2. My password to my bank account
3. My phone number (this is the easy one).
4. And work with a relatively sophisticated attack to spoof my device and obtain the 2FA token?
How did these people get cleaned out? Were they the same kind of people who wrote their pin numbers on the back of their credit cards?
Re: (Score:3)
I have no knowledge of the actual attack, but likely it was malware on their device. Probably whomever go the malware sold the information on the phone sold the info to a data broker. The attacker who had access to the SS7 system bought data that would allow them to leverage their access to make money.
These things have gotten fairly sophisticated in the last few years. Not everyone is going to fall for every scam, but when you have 10 million targets, the law of big numbers kicks in.
Min
Re: (Score:2)
but likely it was malware on their device.
Then they didn't need to break SS7.
Re: (Score:2)
Hackers will never get my passwords. They're stored down in the cellar which has no lights and no stairs. At the bottom of a locked filing cabinet, stuck in a disused lavatory with a sign on the door saying "Beware of the leopard".
Re: *yawn* (Score:2)
Re: (Score:2)
So if they have your login (which is your email normally)
For a bank? Were the security people smoking weed at your local branch? I've never had a bank give me an email for a login. Hell I've only once been able to chose my login.
they can request a new password or authentication code to be sent via SMS
Ditto to the above. My bank will not let me reset my password via any automated method. I can change my password, but can't even do that without 2FA. I can call them and follow through a string of security question which I have on occasion even failed myself.
Honestly if this attack is happening as you described it's time the bank was put
Re: (Score:2)
Well, there are many ways to obtain banking information. The Phish is a popular one and you can probably get a few accounts that way. I suppose if
Re: (Score:2)
At work I face this - attackers trying to social their way to banking info, either to change it or disclose it. We have strict and annoying protocols to authenticate callers, and an appreciable number of calls are found to be fraudulent.
We never send out email resets, but we do use links. All that gets you is a shot at answering security questions, and then if you reset your password that way, your banking change is sent to a human being for them to call out and confirm. Not very efficient, but more secure,
Re: (Score:2)
If you're phished the user there's no need to attack SS7. Just phish the challenge code from them too. This works just as well against RSA tokens.
This is Google's Chance (Score:2)
Just wait until Google says this is the excuse to move the entire legacy SMS system to RCS without delay. Though that still would require changing the transport too, because RCS can use SS7.
Re: (Score:2)
And what does the Massachusetts Institute of Technology Mormons have to do with it?
email (Score:2)
Do not use email or phone as authenticated endpoints.
Well technically, with using correct End-To-End encryption, you could use any channel as 2FA.
E-mail could be usable if correctly encrypted with a trusted openPGP key pair (or if you have a trusted S/MIME authority).
But people won't bother fumbling arround with PGP nor even getting Mailveloppe to use with their webmail.
SMS could also be used with a correctly authetified OTR layer.
But there are about 2 software in the whole universe using OTR-over-SMS (TextSecure. And there should be another one somewhere).
So
Uhhh... Actually, no (Score:2)
In order to take advantage of this "flaw" they have to connect to what is for all intents and purposes an isolated network... You have get one of the Carriers or SS7 access providers to give you that access. It's not done casually.
The "hack" is the equivalent of calling what Wells Fargo did (opening credit card accounts for people who hadn't signed up for them) a hack. The 2fa "hack" seems to have been carried out by someone with trusted access to the ss7 network.
Re: (Score:2)
From TFA: "But anyone with SS7 access, which can be purchased for around 1000 Euros according to The Süddeutsche Zeitung, can send a routing request, and the network may not authenticate where the message is coming from."
It would tend to suggest that SS7 access is not as closely guarded as one would hope. Likewise, IP routing packets are generally disallowed from consumer-level internet connections. Nonetheless, we've recently seen several times that bad actors in trusted positions still abuse that t
Re: (Score:2)
Altering advertised routing paths has nothing to do with access control lists at the perimeter... Which is how this is done.
Every article I've been able to find on security testing of SS7 security has somewhere in it, thanks to a carrier or access provider for allowing them to perform testing INSIDE the network. I've done this work for 30 years and the perimeter policy has always "disallow unless specifically allowed from specific pre-specified location. period". In most instances I was involved in, IPSe
Known issue (Score:5, Informative)
This is already known, see DRAFT NIST Special Publication 800-63B Digital Identity Guidelines
https://pages.nist.gov/800-63-... [nist.gov]
> Note: Out-of-band authentication using the PSTN (SMS or voice) is discouraged and is being considered for removal in future editions of this guideline.
"[T]he SS7 network poses a threat to all of us" (Score:2)
SS7 is going to KILL US ALL!
Have a nice day.
And EBay is forcing users off token 2FA to SMS.... (Score:3)
WTF....
Re: (Score:2)
Three most stupid part is that I will never give eBay my phone number, so I'll simply stop using 2FA, and if my account gets hacked it will be eBay that pays the price.
All anyone can do if they get into my account is buy stuff (refunded by credit card company, PayPal/seller eats the cost) or sell stuff (PayPal eats the cost).
Their desire to get my phone number puts them at risk.
Re: (Score:2)
SS7 is indeed intended for PSTN, and is possibly vulnerable to abuse where it is accessible via public networks. Better security in the gateways would help minimze these risks, but that inconveniences admin workers...
SMS is even worse from a Privacy POV (Score:2)
SMS has never been confidential. Is not encripted in any leg of the trip. Can be decoded from the airwaves with suitable hardware (I've seen said hardware operate first hand, 2 FPGAs, 4 DSPs, and two rugged laptops were needed in 2001, I guess nowadays a macbook with AMD laptop graphics and a SDR will be enough ;-) ), can be altered via SS7 (as described in TFA), and even read easily by the operators of the telecom equipmentt, with no wizard level 100++ knowledge , or special tools:
An Example:
In the SMSCs
Lack of end to end encryption (Score:2)
Saying SS7 is vulnerable is like saying BGP is vulnerable. It's a fools errand to believe it is even possible to build a global, inclusive non-tyrannical network that is also globally trusted. The best you can hope for is a mostly functional network.
On mobile it's effectively all plaintext all the time like it's 1993. Very disappointed POTS networks are still intact. We obviously don't have our shit together.
Re: (Score:2)
I'm still impressed that it works at all.
This is Slashdot... (Score:2)
Well it was built with inherent trust (Score:2)