Spoofing Caller ID

Spoofing caller ID is trivial in SIP. The "caller ID" is specified in the From : header line in requests such as INVITES. Here is a sample From: header:

 From: "GS 2" <sip:3500@ser_proxy>;tag=6a81db91b12d3fac 

In our tests, the value preceding the URI, in this case "GS 2" , is presented as the caller ID if it is present. Several of the tools we have developed set the value in the From: header line, allowing you to spoof caller ID. For example, the inviteflood tool described in Chapter 12 sets the From: value. The spitter tool described in Chapter 14 also does this. You can also use the SiVuS tool to send various requests that have a spoofed From: header and, therefore, spoofed caller ID.

Spoofing caller ID isn't an attack per se; it is something that is done to make an attack more effective. For instance, many of the social threats discussed in Chapters 14 and 15, such as SPIT and voice phishing, are more effective when a victim sees a believable caller ID (ABC Bank, Sheriff's office, and so on). Also, some automated systems operated by credit card companies require their new customers to activate their card by dialing an 800 number from their home line. An attacker could feasibly pilfer his neighbor's mail box, steal a new credit card, and spoof the home number in order to activate the card.

Attack Spoofing Caller ID with the invitefl ood Tool

Popularity:	10
Simplicity:	10
Impact:	5
Risk Rating:	8

  If you would like to see an example of how easy it is to spoof caller ID, you can use the inviteflood tool introduced in Chapter 12. This tool includes an option that lets you manipulate the From: header in an INVITE request. Here is an example that makes a call, which appears with YourBank as the caller ID:

 ./inviteflood etho0 3000 10.1.101.2 10.1.101.2 1 a "YourBank" 

Countermeasures

At least in SIP, caller ID is trivial to spoof. The only countermeasures that are effective involve authentication of the sender and/or the From: header. These countermeasures are covered next .

Countermeasurs Authenticated Identity

RFC 3261 requires support for digest authentication. When coupled with the use of TLS between each SIP user agent and SIP proxy, digest authentication can be used to securely authenticate the user agent. Next, when this user agent sends a call to another domain, its identity can be asserted. This approach enhances authentication, but only provides hop-by-hop security, and it breaks down if any participating proxy does not support TLS and/or is not trusted.

The "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)" (draft-ietf-sip-identity-05) Internet draft proposes enhancements for authenticated identity. In a nutshell , the proposed approach includes an authentication service (normally resident with the SIP proxy) that authenticates the sender of an INVITE request, computes and signs a hash of the From: and other fields, and inserts the result in a new header field. This field can be checked later to authenticate the identity of the sender.

For authenticated identity to work, it must be broadly implemented. Enterprises, as well as service providers, must implement it. It may not be realistic to expect this to happen. We cover additional countermeasures for caller-ID spoofing in Chapter 14, where we discuss voice SPAM or SPIT.