[VOIPSEC] Truths on "Truth in Caller ID Act"

[Dustin D. Trammell]

On Thu, 2006-10-05 at 10:24 -0400, Mpierce1 at aol.com wrote:
> The point is, the PSTN is based on a set of standards that provides the 
> technical means for carriers to determine the validity of the CLI. It is always a 
> fact of life that the crooks (and hobbyists) might find ways to circumvent the 
> intended operation. When discovered (no matter what color you call the box 
> used to do it), the industry finds ways to stop the abuse, so that the telephone 
> system continues to be a fairly secure, protected way for people to 
> communicate. The use of CLI for identification is appropriate for certain purposes.

And what if you use no "colored box" or special technology at all to do
so?  I can confirm that as recently as 2003, it was still possible to
spoof CLI through simple social engineering.  The way it was done was
having your local line operator complete a call to your favorite
long-distance operator.  Doing this seemed to nullify any CLI
information that was passed by the local telephony system to your local
operator, or from that operator to the long distance carrier.  The long
distance operator then, having not received any CLI information and
before completing your new call for you, would ASK YOU FOR YOUR NUMBER,
which of course you could tell them anything you liked as long as it was
not obviously false like "911".  Then, once the long distance operator
completed the call for you, the number you told them would show up on
the recipient's Caller-ID device.  Please don't bother trying to
convince me that this has never worked, because I had done it myself a
number of times back in the mid '90s, and it worked exceptionally well.

> yesterday, I called American Express (from my home phone) to activate a new 
> card. They didn't just use the CLI provided them to identify me, but asked for 
> entry of my account number. If the two did not match their data base, they 
> would have asked other security questions to ensure that someone did not steal my 
> new card from my mailbox. That use of CLI is completely appropriate and 
> provides the level of security required for that application. Unfortunately, the 
> lack of even that much assurance in VoIP will kill this type of use.

Unfortunately, this should have never been accepted as an appropriate
use of CLI.  Even using CLI to determine whether or not to answer the
phone or allow an automated device to take the call should not be
treated as authoritative.  Aside from the prevalence of VoIP-related CLI
spoofing that is done today, the method I mentioned above, among various
other methods, has worked since the inception of Caller-ID.  Another
attack very specific to the situation you mention here is, given that
someone steals your new credit card out of your mailbox while you're at
work, they're in a perfect geographical location to simply attach a
lineman's handset or a cheap phone with alligator clips to the copper
attached to the side of the house and verify the card immediately.  They
have the card's account number having just stolen the card from the
mailbox, and being at your house to do so they have access to the line
that can likely be used to activate it.  This is similar to the example
mentioned of someone using a courtesy phone in a bank lobby to
impersonate the bank.

The problem is that verification of the line being used to make a call
never really authenticates who's using that line to make the call, thus,
it should never be used for authentication of an individual.

> When is a group like this going to admit that there is a problem that needs 
> to be solved and then try to solve it?

I'll readily admit that there are a number of problems that needs to be
solved.  I even outlined this exact problem in a presentation I gave at
ToorCon 8 in San Diego last weekend.  I just don't believe that it can
be solved with the technologies that we have available today without
first building an interoperable, trusted user identity system.

-- 
Dustin D. Trammell
VoIP Security Research
TippingPoint, a division of 3Com