Nine Charged in Alleged SIM Swapping Ring | Hacker News Reader

Nine Charged in Alleged SIM Swapping Ring

krebsonsecurity.com

60 pointsOrgNet38 comments

Mobile phone numbers aren't unique and secure identification of users, stop treating it as such.

Or, phrased another way: we are NOT in possession of a phone number any more than we are in possession of an IP address. Both are transiently assigned to us to the computer with a cellular modem in our pockets

Not really. For all intents and purposes you do "own" the number. You can take it to any carrier you want (local number portability), and carriers can't expropriate it. Try doing that with a /32 you got from your ISP, even a static one.

True, but it's important to note phone numbers have the amount of security as e-mail/SMTP for self-identification. That's why it's so easy to spoof phone numbers and how robo-callers work.

Only this year, telecos are finally adding signature verification to caller-ID/reverse lookups. Once every teleco in a given country supports and is required to implement phone number verification, there will be a higher degree of assurance a phone number on your caller ID really is the person calling, but it's not there yet.

The point is you own it in one sense, but the phone company can reassign to someone else (even if temporary, it's still gone). It's not locked to a physical device at your house that no one else can change, it's not like a diamond ring on your finger.

Better analogy would be a MAC address instead of an IP address.

They don't have to be totally unique and secure for most users.

It's an imperfect solution to a difficult problem - throttling user account creation.

It's an imperfect solution to a difficult problem - throttling user account creation.

A very imperfect solution when it comes to FastMail.

In moving my accounts from Gmail to FastMail it wouldn't allow me to add more than x number of accounts verified with the same cellular number. Even though they were paid accounts. So some of my family remains on Gmail because I only have one phone number that receives SMS messages.

Using phone numbers for throttling user account creation has no security problem. Using phone numbers for 2FA has no security problem compared to password 1FA. The security problem comes when companies use phone numbers for 1FA (during account recovery).

Also true of social security numbers, especially with the credit bureau hack.

And even if they were, SMS is not a secure communications medium.

This is why I hate Apple’s new policy of requiring 2FA with a mobile number for new accounts.

Luckily I created my account before it was official policy, but I’m afraid their going to force it on me someday.

And if you turn on 2FA, you only have 2 weeks to turn it off.

> What if I can't access a trusted device or didn't receive a verification code?

> If you're signing in and don’t have a trusted device handy that can display verification codes, you can have a code sent to your trusted phone number via text message or an automated phone call instead. Click Didn't Get a Code on the sign in screen and choose to send a code to your trusted phone number. You can also get a code directly from Settings on a trusted device.

I thought that by now Apple's engineers had closed the sms loophole. But apparently it is still eminently there.

It's fine to require 2fa as long as using an app instead of SMS is allowed.

SMS only 2fa should really be discouraged

What is, though?

A private key with an associated public key signed by one or more entitities that have verified the owner of the private key.

And how many people have those? With appropriate knowledge of how to generate, store, sign, backup, and secure the keys? On the front page of HN at the moment we have "we lost millions of dollars of Oracle DB due to key management issues". Key management is hard. Every few months a crypto exchange discovers this by either leaking or entirely losing their keys.

It's basically just people with Estonian e-identity cards and a handful of people with organisational PKI.

> With appropriate knowledge of how to generate, store, sign, backup, and secure the keys?

I believe this could be solved by improving the interface used to accomplish these tasks (rather than using openssl req directly). Web browsers ask to save passwords and other sensitive information. There's no reason why they cannot relatively securely store a private key and the associated certificates.

> Key management is hard

That is true, but requiring key/certificate based auth in addition to the username and password for authentication means that attacks would have to be distributed amongst the users of a given website and the website itself rather than just attacking the website or some 3rd party used for 2FA (email or cell phone).

And breaches where backend databases are compromised and user credentials are retrieved also happen. But due to people re-using credentials on multiple services, they also get compromised on unrelated services. Using a private key and a certificate per service, it would be much harder to do something like that.

> There's no reason why they cannot relatively securely store a private key and the associated certificates.

The big ones have supported this for two decades: https://www.digicert.com/managing-client-certificates.htm

Hardly anywhere uses it.

signed by one or more entitities

Sounds like another opportunities for the advertising companies like Google and Facebook to uniquely identify us.

There are blind signature schemes.

as the guy before me mentioned private key and public key

perhaps blockchain can solve this problem too?

Too? What other problems has blockchain solved?

How do you trick employees at mobile phone stores into seizing control of a phone number? You give him a fake ID, he checks the ID card's serial number, citizenship number, name, surname, date of birth in the mobile operator's application (which checks it from the governmental API service) or himself from the e-government web site. In this way he understands wheter the ID is real or not and wheter it was stolen or not. If it is real it hands you a new SIM in few minutes. (now it is even harder with ID cards with chips).

If you want to change the owner of the number the employee scans both of your documents and sends it to a governmental bureau and if they approve then the number is transported to the new person. Which it takes at least few days (I think it is intentionally slow).

This one will not save your Google account but it will save your bank account. If you change your SIM card you cannot login to your bank account. You need to recreate a password by calling the bank and answering tons of questions and revalidating your phone number. You might wonder how does a bank knows that a SIM card has been changed. I wonder it too. But the mobile operator probably informs all banks via a API. U have faced this personally 2 or 3 times and my friends have faced it too. So, it is real. (not related but there is also mobile digital signature thing that you can login to bank account, mobile phone operator's web site or your e-government account)

This is how it works in Turkey. I know United Statians don't like 1984 style states but I wanted to share.

According to court documents, investigators first learned of the group’s activities in February 2018, when a Michigan woman called police after she overheard her son talking on the phone and pretending to be an AT&T employee.

Several sites that I use, even some that support TOTP, still require a phone number.

I hope that since you have to “unlock” your Google Voice number before it can be ported, it’s immune to theft (assuming you protect your GV account of course) and relatively safe to use.

https://support.google.com/voice/answer/1065667#xferout

> I hope that since you have to “unlock” your Google Voice number before it can be ported, it’s immune to theft...

I see this sentiment posted here a lot and I'm here to say that it is sadly not a good hope. When you do a number port, the automated/efficient/normal path is that your new provider (the "gaining" provider) submits a request to the number portability authority requesting that your number be moved to its routing away from your old provider (the "losing" provider). The authority passes along the information that the gaining provider submitted and gives it to the losing provider. The losing provider is then responsible for returning an automated "yes," "no," or "wait." If "wait," the losing provider is supposed to reply again within 1 to 7 days indicating actual yes or no; if no reply, then the port will complete with no further action. If yes, then the port will complete. If no, then the port is rejected.

Now, here's the major hole: It is entirely possible to do what's called a "force port," wherein the gaining provider attests to the number portability authority that the gaining provider Really For Sure Totally Does have authorization from you (the subscriber) to take routing for the requested number. This is only supposed to be used in the case of a recalcitrant losing provider or where the losing provider has no automated system and the subscriber wants/needs the number moved Very Fast Now. But, realistically, this very much can be abused and, if an attacker is motivated, will be abused.

There's nothing Google (or, more accurately, its underlying carrier, Bandwidth.com in most cases) can do to stop a force port. All the "unlock" feature on Google Voice does is cause an automated port request to be approved if the other subscriber information matches. If an unlock is not done, then Google Voice will simply return "nope" on all port requests. But a force port can still go around that and, disturbingly, the losing carrier may not even know that a force port was done until days later when it notices that the LRN (local routing number) database no longer points the lost number at its service.

So, SMS is still a terrible idea for verification even on Google Voice numbers.

Is getting a landline, and using a bank which offers 2FA via automated voice calls secure enough?

SMS as a second factor is not and is unlikely to be secure for a second factor anytime in the near future given the design of SS7 and the glacial pace that the global telecom industry moves at for upgrading core infrastructure. The lock prevents port-out attacks, but is still not sufficient for considering SMS as okay to use for a second factor. Use TOTP instead.

I use something more secure than SMS as my sole second factor where I can. Unfortunately some sites still require a phone number. I’ve edited my comment to be clear about that.

So if you have to use a phone number, is GV the least bad option?

I think it's better than the phone company, but as discussed, someone could force steal your number. Secondly, if someone hacks your gmail, they can access google voice themselves but just logging in as you.

My freaking gmail is my main barrier against the world. I sure as heck use a yubi key (I have multiple) plus password. If my gmail is hacked, I'd be in trouble like a lot of tech people. I think that's the ultimate - break into gmail and you'd have endless things to steal.

It's interesting seeing all these novel ways of stealing cryptocurrency. So far we have seen Twitter scams where people impersonate high profile accounts in the hope people will think it's a real cryptocurrency giveaway and actually send funds to various wallets.

Then there is the cryptominer/cryptojacking technique where the unused CPU power of personal computers is used to mine various cryptocurrency (often stealthily run in the background and the user is unaware they are mining cryptocurrency).

Then there was that recent story of the so called 'cryptocurrency bandit' who scraped wallet addresses and then broke into the wallets which were encrypted with a weak password.

If anyone on here knows of other novel techniques (aside from what I mentioned and the SIM-swapping method); then I would love to hear the methods.

People have programs that scan github uploads for AWS, etc credentials accidentally uploaded by victim and spawn images that mind crypto for the attacker’s.

https://www.theregister.co.uk/2015/01/06/dev_blunder_shows_g...

Wow. I’m always amazed at the lengths people will go to to abuse anything and everything.

You forgot about cracking ipmi hashes, this has been an incredibly popular way to steal wallets off servers.

This is the result when companies follow each other. We need to see more innovation in authentication and leadership in best practices. Hijacking of phone numbers is not new and devs need to stop shifting liability to phone carriers when authenticating users to every little thing. Phone carriers have no incentive to secure users data or make the user authentication process more stringent. This results in the consumers being at constant risk, which I feel impacts society as a whole.

The phone carrier has no incentive which is why liability needs to be shifted to them.

The broader telecommunication industry has gotten a free ride long enough. They provide a blatantly insecure and mediocre service, profit from it and tell the world it's not their problem when it fails.

> a form of fraud in which scammers bribe or trick employees at mobile phone stores into seizing control of the target’s phone number and diverting all texts and phone calls to the attacker’s mobile device.

why bother to do that? in australia, you just need to know the person's DOB, address and his mobile account number to get full control of his/her mobile number.

Reply on news.ycombinator.com