Index
Home
About
Date: Sun, 09 Aug 1998 11:41:21 -0700
From: abuse@bovine.ati.com (John Higdon)
Newsgroups: alt.dcom.telecom,comp.dcom.telecom.tech
Subject: PBMS Voicemail
If you have a PacBell PCS telephone, you should be aware that any messages
in your voicemail box and your outgoing message are extremely vulnerable
to tampering by folks with less than honorable intentions.
The system works like this: your PCS telephone is permanently forwarded
(forward, No Answer) to a voicemail input POTS number. If your phone is
off or you don't answer the call, the caller is forwarded to a voicemail
input port. This port is nothing more than a POTS number. The voicemail
system sees that the call is being forwarded through your PCS number and
delivers your greeting and offers the caller the opportunity to leave a
message.
You retrieve your message by pressing the voicemail button on your PCS
phone. This button is nothing more than a speed dial to a message
retrieval port on the same voicemail system. The numbers are selected to
be a local call from the PCS phone when operating in the home area, and
usually have the form: [PCS prefix] - 1234. In other words, "NXX-1234".
The voicemail system recognizes the CNID of your PCS phone and instantly
gives your message count and offers your retrieval/box-maintenance menu.
And this is the crux of the problem: currently, there are no passwords or
other means of security to protect the privacy of your box. It relies
soley on the CNID info supplied by the calling telephone. Those of you who
have access to PRI-connected PBXes should be fully aware of the
implications and ramifications of this procedure.
Over three weeks ago, I attempted to present this problem to folks at
PacBell. The only people who would return my calls were some "fraud
department" folks, who had already pulled my account records and treated
me like some kind of hacker scum, especially after I demonstrated that the
problem really did exist in the face of adamant denials. After their
attempts at brushing me off, I posted my "teaser" about a security hole in
alt.dcom.telecom. This resulted in a threatening call from an attorney at
Pillbury, Madison, and Sutro, who attempted to tell me that I would be
breaking Federal law by revealing any information about the
poorly-designed voicemail. Needless to say, I did not fall for that
nonsense.
Then, I was called by someone in the technical department who said that it
would take two weeks to fix the problem. It has been two weeks. No one has
since called to tell me that it would take any longer, so I assume that by
the time you read this, the problem will be fixed. Or not--but that is
PacBell's problem.
It boils down to this: any real company, run by folks who have the
slightest concern for its product, its customers, or anything at all
beyond its image, would have been very delighted to learn about such a
security problem. The fact that I have been brushed off, threatened,
ignored, and placated indicates to me that the company was already well
aware that security that depended upon CNID was a cheap hack and had hoped
that they could skate indefinitely before someone discovered it.
A personal letter sent on July 22 to Mr. John Palumbo, president of PBMS,
has been ignored and remains unanswered. In other words, it would appear
that PBMS has been interested in one thing and one thing only: making sure
that this problem was kept under wraps using the minimum effort necessary.
Indeed, one of my associates complained to a PBMS rep about the security
problem as was told, "Oh, you must have read about that on the Internet.
You know how unreliable Internet stories are."
As a user of PBMS products, and a fan of the PCS service, it has been a
great disappointment for me to discover the hard way the core of
ineptitude that apparently lies at the heart of the operation. The
slightest amount of effort spent in leveling with me and keeping me, a
concerned customer, apprised of the progress in handling what is in
actuality a very serious problem would have gone a very long way. I even
offered my own considerable insight into possible solutions, some of which
could have been enacted transparently, but the emphasis seems to be on
coverup rather than cure.
My purpose in this post is not to compromise the security of the PBMS
voicemail (its designers did that from the very beginning), but to provide
an imperative for PBMS to act. After talking to many people, I have found
that the voicemail security hole is not unknown. One fellow quipped that
he had been using the "backdoor" to retrieve his own messages without
having to use his PCS phone. It was very convenient since he, among
others, lives in a PCS coverage hole.
If you have you have PCS service, you might ask what is taking so long to
get this problem fixed. Be prepared for PR damage control, but be sure
that you get your point across. PBMS proudly advertises its great
"security". It is time that company starts delivering what it promises.
--
John Higdon | P.O. Box 7648 | +1 408 264 4115 | FAX:
| San Jose, CA 95150 | +1 500 FOR-A-MOO |+1 408 264 4407
abuse@ati.com | http://www.ati.com/ati/
Date: Sun, 09 Aug 1998 22:34:12 -0700
From: abuse@bovine.ati.com (John Higdon)
Newsgroups: alt.dcom.telecom,comp.dcom.telecom.tech
Subject: Re: PBMS Voicemail
In article <6qln03$c6i$1@samba.rahul.net>, c.c.eiftj@88.usenet.us.com
(Rahul Dhesi) wrote:
> >Those of you who
> >have access to PRI-connected PBXes should be fully aware of the
> >implications and ramifications of this procedure.
>
> And the rest of us?
A PRI-connected PBX allows individual extensions to show up on CNID. The
number that they display to the callee is determined in the PBX
programming. It takes two seconds for one to reprogram the switch so that
any extension, DISA port, or any other local object identifies itself as
any phone number the programmer desires.
I might also point out that the voicemail used for Pac*Bell Centrex
suffers from this same security problem. After the treatment I got last
time I tried doing them a favor, I'm not going to bother mentioning that
one to them.
Whoever implemented this outrageously weenie system of voicemail security
ought to be strung up.
--
John Higdon | P.O. Box 7648 | +1 408 264 4115 | FAX:
| San Jose, CA 95150 | +1 500 FOR-A-MOO |+1 408 264 4407
abuse@ati.com | http://www.ati.com/ati/
Date: Sun, 09 Aug 1998 22:41:10 -0700
From: abuse@bovine.ati.com (John Higdon)
Newsgroups: alt.dcom.telecom,comp.dcom.telecom.tech
Subject: Re: PBMS Voicemail
In article <MPG.10383533b8bc4687989874@news.ultranet.com>,
nospam.tonypo@nospam.ultranet.com (Tony Pelliccio) wrote:
> It's standard "Bell System" operating procedure. Mother's children, all
> of them. It's why they're dinosaurs that are destined to failure in a
> competitive environment.
Yes, I dare say that Sprint PCS, GTE Wireless, and Cellular One do not
have this problem.
> Good luck in getting this all resolved. Perhaps a tip to a few local
> newspapers might get the ball rolling a bit faster.
They are next on the list. My client list also includes radio and
television stations, as well as a couple of networks. Given the response I
got from PBMS, my first call should have been to KPIX or some such. It
would have been great to see my demo appear on TV!
When I call my buddies at the Merc, I will throw in the Centrex problem
for good measure. Everyone I have talked to has given me an "I told you
so" in that I should have gone to the media first. Admittedly, that is the
ONLY thing that ever seems to get PacBell's attention. Customers be
damned!
--
John Higdon | P.O. Box 7648 | +1 408 264 4115 | FAX:
| San Jose, CA 95150 | +1 500 FOR-A-MOO |+1 408 264 4407
abuse@ati.com | http://www.ati.com/ati/
Date: Mon, 10 Aug 1998 08:21:47 -0700
From: abuse@bovine.ati.com (John Higdon)
Newsgroups: alt.dcom.telecom,comp.dcom.telecom.tech
Subject: Re: PBMS Voicemail
In article <6qm3bg$d0i$1@samba.rahul.net>, c.c.eiftj@88.usenet.us.com
(Rahul Dhesi) wrote:
> The entire number, or only the last N digits?
The entire phone number, including area code, is dictated by switch
programming.
> I would have expected
> (knowing nothing about PBXs) that if the PBX is assigned a range of DID
> numbers, the telco switch would accept only numbers within that range,
> and fill in the higher-order digits itself. This seems to be an obvious
> precaution. If PacBell does not take this simple precaution, is it
> because of policy, or because it buys telco hardware that can't do this?
This goes beyond policy and dwells in the domain of international
standards. Either the customer or the telco fills in the CNID field--it
isn't a joint effort. But you are making the same assumptions that the
folks at PBMS did when I first brought this to their attention. The way to
fix the problem is not to prohibit customers from originating CNID info
unless you could prohibit such a thing worldwide. Since you cannot, you
must close the barn door on the voicemail side of things.
> I wonder if all PacBell 'message center' voicemail is done this way.
The message center requires a password, even when accessed from the user's
telephone.
--
John Higdon | P.O. Box 7648 | +1 408 264 4115 | FAX:
| San Jose, CA 95150 | +1 500 FOR-A-MOO |+1 408 264 4407
abuse@ati.com | http://www.ati.com/ati/
Date: Mon, 10 Aug 1998 08:24:15 -0700
From: abuse@bovine.ati.com (John Higdon)
Newsgroups: alt.dcom.telecom,comp.dcom.telecom.tech
Subject: Re: PBMS Voicemail
In article <6qn0da$rul@ivan.iecc.com>, johnl@iecc.com (John R Levine) wrote:
> My understanding is that it's possible to program a CO switch to range
> check the CNID that a PBX sends, and replace invalid CNID with a
> default value such as the number of the trunk or the main number of
> the PBX. But nobody bothers.
But remember, even if PacBell were to do that, the PBMS voicemail could be
spoofed from ANY location worldwide that did not have such a thing in
place. Our tests show that Pacific Bell Mobile Services voicemail can be
tricked from anywhere in the country. All you have to do is ID as the
number of the PCS phone whose voicemail you are attempting to access.
--
John Higdon | P.O. Box 7648 | +1 408 264 4115 | FAX:
| San Jose, CA 95150 | +1 500 FOR-A-MOO |+1 408 264 4407
abuse@ati.com | http://www.ati.com/ati/
Date: Mon, 10 Aug 1998 12:21:12 -0700
From: abuse@bovine.ati.com (John Higdon)
Newsgroups: alt.dcom.telecom,comp.dcom.telecom.tech
Subject: Re: PBMS Voicemail
In article <35CF356D.3398@attws.com>, jeffrey.rhodes@attws.com wrote:
> Sounds like PBMS has Voicemail systems with PRI feeds and isn't using
> FGD digit sequencing to trigger the login bypass like the more common T1
> inband signaling feeds. Usually FGD ANI is used to bypass the login
> prompt at a Voicemail system, and this is immune to the false ICLID
> attack, since Calling Line ID conversion to ANI is not a wireless switch
> *feature*.
I had suggested this out of the box when I first discussed the problem
with PBMS. Unfortunately, I was talking to security goons and shyster
lawyers rather than anyone with any kind of technical savvy. The
"technical" person to whom I finally spoke said little more than "we're
working on the problem".
After thinking about it for two weeks and hearing nothing from them
whatsoever, I began to wonder just exactly how long it really takes to
re-option the switches. I mentioned to my business partner that if any of
the systems we installed or maintained were found to possess this
vulnerability, it would be fixed in hours, not days or weeks. His reply
was that OUR systems would not have had this type of problem in the first
place! Touche!
> Just another one of those things that AT&T Wireless' seasoned,
> well-tuned, systems gets right, while other systems try to one-up with
> product differentiation. Maybe PBMS cellphones can't be programmed for
> voicemail autologin? ;-)
That would seem unlikely. But PBMS PCS suffers under a double whammy of
disadvantage. First, the wireless switches are Ericsson. I understand that
it is blasphemy to speak ill of the great Nordic God, but having worked
indirectly with that company on a project, I formed some
not-so-very-complimentary opinions regarding the way problems are solved
and regarding the cooperation in handling a big picture such as a
multi-state wireless telephone system.
The second problem stems from the dictum to PBMS that they would contract
with the Pacific Bell voicemail provider for VM services. As we all know,
Pacific Bell voicemail services are about the most poorly-designed,
poorly-maintained, and consequently most unreliable operations on the
planet. This is revealed in spades with the PCS manifestation. And in the
manner of the whole being greater than the sum of its parts, the signaling
in terms of indicating messages holding, numeric paging, and other
iconography on the phones sucks big time. These are obviously poorly
thought-out hacks--once again by programmers who have no concept of
telecom solidity.
For a while, and this is why I signed on in the first place with PBMS, it
was rumored that PBMS would use Wildfire. Tests of Wildfire in San Diego
were most impressive. But at the end of the test, all of the San Diego
test customers were shunted back to the crap that we now enjoy, and not a
word has come down since.
> ps. I kind of doubt that an international ICLID can be made to look like
> a national ICLID to the PBMS voicemail system, so I suspect that the
> PBMS vulnerability is limited worldwide.
A little birdie tells me that it works just fine (at least from one
country overseas), which tells me how bad the problem really is.
--
John Higdon | P.O. Box 7648 | +1 408 264 4115 | FAX:
| San Jose, CA 95150 | +1 500 FOR-A-MOO |+1 408 264 4407
abuse@ati.com | http://www.ati.com/ati/
Date: Mon, 10 Aug 1998 15:04:39 -0700
From: abuse@bovine.ati.com (John Higdon)
Newsgroups: alt.dcom.telecom,comp.dcom.telecom.tech
Subject: Re: PBMS Voicemail
In article <35CF356D.3398@attws.com>, jeffrey.rhodes@attws.com wrote:
> Sounds like PBMS has Voicemail systems with PRI feeds and isn't using
> FGD digit sequencing to trigger the login bypass like the more common T1
> inband signaling feeds. Usually FGD ANI is used to bypass the login
> prompt at a Voicemail system, and this is immune to the false ICLID
> attack, since Calling Line ID conversion to ANI is not a wireless switch
> *feature*.
At the prompting of a PacBell person, I just tried it again. It would
appear that they have finally implemented at least one of the half-dozen
fixes that would have prevented this problem in the first place. A call
from the PBX spoofing the PCS number is greeted with the same wave-off
that one gets when attempting to call the retrieval number from a POTS
phone.
I guess PBMS CAN respond to a problem if pushed hard enough!
--
John Higdon | P.O. Box 7648 | +1 408 264 4115 | FAX:
| San Jose, CA 95150 | +1 500 FOR-A-MOO |+1 408 264 4407
abuse@ati.com | http://www.ati.com/ati/
Date: Mon, 10 Aug 1998 17:04:16 -0700
From: abuse@bovine.ati.com (John Higdon)
Newsgroups: alt.dcom.telecom,comp.dcom.telecom.tech
Subject: Re: PBMS Voicemail
In article <abuse-ya023180001008981808360001@news.radparker.com>,
abuse@radparker.com (Al Iverson) wrote:
> Good to know. Too bad they were jerks about it. Guess you learned your
> lesson. Didn't your mother tell you that no good deed goes unpunished???
They got the problem fixed, but I don't think I would subject myself to
that sort of treatment with lawyer threats and general attitude. Next
hole I find I think will go to the newspaper or to the competition. Yes, I
have phone numbers of some folks now that will listen to me, but knowing
Pacific Bell, by the time another issue surfaces, those people will have
long left.
--
John Higdon | P.O. Box 7648 | +1 408 264 4115 | FAX:
| San Jose, CA 95150 | +1 500 FOR-A-MOO |+1 408 264 4407
abuse@ati.com | http://www.ati.com/ati/
Date: Mon, 10 Aug 1998 17:37:20 -0700
From: abuse@bovine.ati.com (John Higdon)
Newsgroups: alt.dcom.telecom,comp.dcom.telecom.tech
Subject: Re: PBMS Voicemail
In article <35CF8741.1626@attws.com>, jeffrey.rhodes@attws.com wrote:
> Are you still able to retrieve voicemail whilst roaming on a non-home
> system?
Interesting question. I am frequently down south, outside the SF system,
but it is all PBMS. No trouble with VM retrieval from down there.
It occurs to me that if one wants to avoid toll charges when checking
messages, it would pay to dial in the LOCAL retrieval number manually
instead of using the home number that is dialed when using the VM button.
It makes no difference which port one uses to check mail.
--
John Higdon | P.O. Box 7648 | +1 408 264 4115 | FAX:
| San Jose, CA 95150 | +1 500 FOR-A-MOO |+1 408 264 4407
abuse@ati.com | http://www.ati.com/ati/
Index
Home
About