I am no expert but I think the problem is assuming that the caller ID of the incoming call to the bank is authentic.
I'm curious if you could break a similar system that assumed that receipt of an outgoing call made to the customer's phone number was validation of identity.
Outbound call to a number is harder to break. One way is to port the number to another provider, illegally. If you have the person's information and bill, you probably have enough info to get the line transferred. And sometimes, providers will accidentally/idiotically allow a number to be ported even if the information isn't correct; there's plenty of room for mistakes.
Another attack is to target the way they place the outbound call. Suppose they place the outbound call with provider X. An attacker might sign up and start a port via provider X. If provider X has poor code, they might activate the number internally, and route all their customers calls to your account, before they find out the port's been rejected. Or you might be able to compromise the provider another way - many providers and VoIP software systems are hilariously weak on security.
The first attack will work across the entire phone network; the second requires the authentication call to be made via an insecure provider.
Right but you're talking about owning the DID, which one may or may not need to do in order to compromise your connection. For example, if I pwn the Asterisk box your call routing runs through, I can mirror the audio or redirect the audio pretty trivially.
Going a step further, given how few people aren't buying through a reseller, it's possible to pwn an upstream provider and impact boxes through a man in the middle attack. Even over TDM you're not safe because of physical taps which are difficult to detect (albeit easier than IP).
No, Phone numbers are not secure and should never be used as a form of authentication. You don't even need to port a number, you just need to be somewhere in the stream.
I think there's a significant scope difference in performing a MiTM attack (via hacking a provider or installing a tap) and forcing a port through.
After all, it's implicit in telephone banking when you authenticate via voice that you trust the connection. The argument you're making is that telephony is insecure, which is arguably true, but sorta irrelevant within the scope of telephone banking.
How is it irrelevant? Is it not the crux of the issue here?
Many upstream providers are just Asterisk boxes forwarding traffic. Those boxes can be overloaded with a malformed SIP header; hell, most application switches get wrecked by malformed headers.
What I'm trying to say is that money is one of those things where security is actually important. Trusting telephony, even as a signal and not source, is foolish. There are many better methods of deriving identity.
My point, and arguably the point of the article, is that telephony is insecure, and I think it's pretty far from irrelevant... Please correct me if I misunderstood, I'm not trying to offend I just don't understand.
Well this depends on delivery medium. If the outbound call is routed to a SIP URI instead of over TDM, you actually have no idea where that calls going.
A DID (direct inbound dial) is physically punched down into an exchange somewhere near the actual physical area (415 exchanges are physically punched down in or around San Francisco, for example). If calling a specific DID results in a forward to a carrier like, say, bandwidth.com, then the routing commands applied after that would not be traceable (or at least not easily).
In short, only if you know the method of delivery, and I'd argue that it's virtually impossible to know what kind of routing a number you're calling will trigger.
Does that help? Inbound caller ID is just Fubarr'd because you can fake it in two seconds.
>I'm curious if you could break a similar system that assumed that receipt of an outgoing call made to the customer's phone number was validation of identity.
That would certainly defeat the caller-ID spoofers. "Please hang up now. We will call you right back ...". Receiving a call from the bank's automated service out of the blue would also alert you to the fact that hackers are attempting entry via spoofing. Or are phone-phishing for whatever details the automated system requires in order to proceed.
Google now offers two-factor authentication for its accounts. You sign in with your username and password. Then Google texts a random code to your phone, which you enter into a third dialog. That way, the bad guys have to steal your phone in addition to your password.
> Then Google texts a random code to your phone, which you enter into a third dialog. That way, the bad guys have to steal your phone in addition to your password.
Nope, they just need access to your phone account at the carrier.
In the case of an AT&T business account, it's just your EIN from the IRS and the billing address of the company.
Then they just pop the "replacement" SIM from AT&T in their burner and receive the text message.
Sure, it's harder than just stealing a password. But don't think it requires stealing your phone. It's just one more account that needs hacking.
You'd need to get the encryption keys to burn that SIM if it should work. You can't extract those from most SIMs(Then again if steal the original SIM, you don't need to clone it).
The other option is to hack the network node where it's stored, which should be a very different place than the main account data - it's normally a lot harder than stealing a phone.
You misunderstand me. I am talking about walking into an ATT store and having them issue a "replacement" SIM for the account. No SIM hacking necessary.
It is fraud, however. But so is lying to a bank IVR.
I'm curious if you could break a similar system that assumed that receipt of an outgoing call made to the customer's phone number was validation of identity.