Most cellphone voice mail is vulnerable to hackers [telecom]

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.


formatting link

Reply to
Monty Solomon
Loading thread data ...

............ 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.

I would be shocked if this was not the case!

Reply to
David Clayton

formatting link
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.

Reply to

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.

Reply to
David Lesher

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].


************************************************** Speaking from a secure undisclosed location.
Reply to
Jim Bennett

Per David Lesher:

Is the verse to defeat 'bots?

If so, is that a real email addr... and does the verse work?

Reply to
Pete Cresswell

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.

Reply to
Thor Lancelot Simon

This means one of two things. Either:

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.
Reply to
Thor Lancelot Simon

It will defeat only the *dumbest* of harvesters.

***** Moderator's Note *****

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.

Reply to
Robert Bonomi

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.

Reply to
Adam H. Kerman

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.

Don't learn emacs. That way lies madness.

Reply to
Adam H. Kerman


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 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. ;-)

Extend-meta-alt-control-spacebar! Extend-meta-alt-control-spacebar!! Extend-meta ...

Reply to
Telecom Digest Moderator

The ANI service delivers *either*:

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.


Reply to
Thor Lancelot Simon

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?

Reply to
Adam H. Kerman 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.