CallerID and Bad Authentication

A new web service allows anybody to make phone calls with forged CallerID (for a fee), according to a Kevin Poulsen story at SecurityFocus. (Another such service had been open briefly a few months ago.) This isn’t surprising, given the known insecurity of the CallerID system, which trusts the system where a call originates to provide accurate information about the calling number.

This is more than just a prankster’s delight, since some technologies are designed to use CallerID as if it were a secure identifier of the calling number. Poulsen reports, for instance, that T-Mobile uses CallerID to authenticate its customers’ access to their voicemail. If I can call the T-Mobile voicemail system, while sending CallerID information indicating that the call is coming from your phone, then I can access your voicemail box.

Needless to say, it’s a bad idea to use an insecure identifier to authenticate accesses to any service. Still, this mistake is often made.

A common example of the same mistake is to use IP addresses (the numeric addresses that designate “places” on the Internet) to authenticate users of an Internet service. For example, if Princeton University subscribes to some online database, the database service may allow access from any of the IP addressess belonging to Princeton. This is a bad idea, since IP addresses can sometimes be spoofed and various legitimate services can make an access seem to come from one address when it’s really coming from another.

If I were to run a web proxy within the Princeton network, then anybody accessing the web through my proxy might (depending on the circumstances) appear to be using a Princeton IP address. My web proxy might therefore allow anybody on the web to access the proprietary database. Some users might deliberately use my proxy to gain unauthorized access, and some users might be using the proxy for other, legitimate reasons and be surprised to have open access to the database. In either case, the access would be enabled by the database company’s decision to rely on IP addresses to control access.

In practice, people who design web proxies and similar services often find themselves jumping through hoops to try to prevent this kind of problem, even though it’s not their fault. One isn’t supposed to rely on IP addresses for authentication, but many people do. The result is that developers of new services may find themselves either (a) inadvertently enabling unauthorized access to other services, or (b) spending extra time and effort to shore up the insecure systems of others. Some of my colleagues who developed CoDeeN, a cool distributed web proxy system, found themselves wrestling with this problem and ultimately chose to add complexity to their design to protect some IP-address-based authentication systems. (They wrote an interesting paper about all of the “bad traffic” that showed up when they set up CoDeeN.)

It will be interesting to see how the CallerID story develops. My guess is that people will stop relying on the accuracy of CallerID, as spoofing becomes more widespread.