Most cellphone voice mail is vulnerable to hackers Online services guide the way
By Hiawatha Bray Globe Staff / July 13, 2011
Breaking into someone's voice mailbox - in the style of the hackers at the British tabloid News of the World - can be as easy in the United States as it is on the other side of the Atlantic.
It is done using a readily available online service known as "caller ID spoofing,'' which can make a call appear to be coming from any phone number. Hackers can use it to access someone else's voice mail messages by fooling the system into thinking the call is coming from the owner's cellphone.
If the mailbox is not protected by a password, as is often the case, the attacker can hear and even delete messages in the target's voice mailbox.
There are numerous spoofing services in the United States; all you need to do is Google them. Although these services are used by hackers to commit crimes, they're also used legitimately by, for example, battered women who do not want their calls traced, or law enforcement agents operating undercover.
............ I seem to remember that Voice Mail services from network providers used the secure ID data (used for 1-800 etc.), not the stuff that can be spoofed and appears on your phone.
This was the case with Sprint phones some time ago. Actually assisted someone in hacking their SO's voicemail using a MagicJack adapter and a PERL script that allowed you to set your outbound CLID to anything your heart desired.
All you had to do was dial the Sprint cell phone number with your CLID data set to that number. It would let you right into the voicemail.
I recall John Higdon discussing this very scenero here, at least a decade ago. The carrier's response was to have a big time law firm call him up and hassle him.
I was hoping this would come up for discussion, because I just don't get it. Cell providers actually use CID info to determine that a subscriber is calling their own number in order to check their mail?
What ever happened to ANI? I'm confused [more than usual].
Jim
************************************************** Speaking from a secure undisclosed location.
No. There is no "secure ID data". The number used for 800 number billing is delivered by a service called ANI, which delivers the BTN, the *Billing Telephone Number* for a given account. This is much harder to spoof, but will also be identical for many different phones billed to the same company -- so is not useful for purposes like identifying a voicemail customer.
However, and of more relevance, the Caling Number Identification that is transmitted for display purposes with each telephone call has an associated flag: "customer provided" or "network provided". No voicemail system should *EVER* accept "customer provided" Calling Number as a reason to let the user into an account without the password.
To transmit calling number identification into the PSTN and have it marked as "network provided" a trunk must either be SS7 or ISDN and marked as connected to network-side, not customer-side, equipment. It is my understanding that certain unscrupulous VOIP providers have managed to have their SS7 or ISDN trunks connected to the PSTN by other carriers and marked as "network-side" so they can forge calling number identifcation and claim it is "network provided".
There is another problem, that many handsets (analog sets with caller ID, even cellphones which easily *could* display whether a "calling number" is network provided or customer-provided) do not display when a number is customer provided and thus likely forged. But this excuse does not apply to voicemail systems.
Cellphones should, anyway, be fixed to display clearly that number is "customer-provided". The protocols and firmware for these things are tweaked constantly and it would be a very minor and valuable change.
The carriers providing the "network-side" SS7 or ISDN interconnection that makes the forgery work against devices that *do* know about "customer provided" numbers (e.g. voicemail systems) should be forced to stop doing so -- the FCC should force all carriers with SS7 point codes allocated in the North American numbering space to certify that they are not doing this -- and the parties who were interconnecting to them and doing it sued into oblivion. You know, that's just my opinion, the rest of it above is just the facts, man.
1) Sprint's voicemail system is ignoring the "customer-provided" bit on calling number identification, or
2) Whoever is currently providing SS7 interconnect to Magic Jack should be forced to disconnect them post-haste, or use gateway screening to mark all calling party name and number fields received from Magic Jack as "customer provided" no matter what Magic Jack tells them.
Not necessarily: I've been working on regular expressions to help me process the daily digest, so this subject has been on my mind, and there's a big 'gotcha' in David's .sig file: his email address is next to a character (a period) that is valid in emails.
defeat the majority of harvesters. The "dumbest" harvesters confine themselves to "From:" lines, since that is low-hanging fruit, but picking emails out of the _body_ of Usenet posts isn't that easy. I could write a regular expression that finds any at-sign, and then includes everything on either side that is valid in an email address: the trick, however, is knowing when to stop.
This isn't a forum for regexp design, so I'll just say that I don't think there's a whole lot of sophistication in harvest bots.
Bill Horne Moderator
P.S. BTW, anyone who knows how to inlcude newlines in emacs replace-regexp commands, please contact me offline via bill at horne dit net.
I don't agree. BTN the telephone number associated with the master account record. ANI is the line number. An account comprises a single line or hundreds or thousands of lines, depending on the nature of the telephone subscriber.
In the case of outgoing trunks, you're right, ANI won't identify what extension the was dialed from. However, ANI received probably won't be BTN.
You've quoting "From ". Only the dumbest of mail clients used that expression to identify the Berkeley Mail-style delimiter and they should not be indulged. Can you please turn the feature off as it messes up quoting levels?
That picks out Message-IDs as possible email addresses, so don't do that.
In any event, email addresses are harvested from the From header because the article itself is not being parsed. There is a NEWSOVERVIEW database on the News server which includes selected headers from a Usenet article, including the From header, and not the article itself, so processing this is much less resource intensive.
Quick note: my email software puts a ">" in front of the word "From" if it is at the start of a line, because my emails are stored in a file that uses "From" lines to separate each email from the others.
So, this email will appear at your electronic doorstep with the following "header" info:
From snipped-for-privacy@remove-this.telecom-digest.org Fri Jul 22
17:53:17 2011 Return-path: Envelope-to: (... etc. There is a *LOT* of header info in *EVERY* email)
... which can cause confusion between the "From" line at the start of each message, and the word "From" at the start of a line *inside* the message.
I'll certainly check it out: I thought it was a "standard" practice, required to allow mailbox files to properly separate messages, but if it's arcane I'll be glad to turn it off - assuming I can find out how. ;-)
A) The "calling party number" from the SS7 IAM message, if that number is marked as network-provided, or
B) Otherwise, the BTN for the originating line, again from the SS7 IAM message.
Look at the message formats -- where in there are you going to jam some third number for it to deliver?
Remember, the BTN emitted in the AMA record from the originating switch may not end up being the BTN actually used to bill the account. But that all happens "magically" from the point of view of the SS7 network.
Pardon my error. I didn't understand that BTN was used for two different, but related, concepts.
For my information, please define what you are referring to in A, the calling party number and IAM. I take it A and B are unrelated to whether the line the call originates on is an outbound-only trunk?
Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.