Trapcall

| Comments (1) | COMSEC
Joe Hall posts about TrapCall, a system for circumventing caller-id blocking (it also does call recording and voicemail transcription). I thought it might be worth explaining what's going on for those who aren't too familiar with the innards of telephony.

The important thing to know is that telephony systems are nearly all digital now (the specific protocol is called signaling system 7 (SS7). The only part of the system that's analog is the part between the handset in your house and the nearest central switch, where the A-D and D-A conversion happens—and not even then if we're talking cellular telephony,. The way that caller-id works on analog phones is that the originating switch sends the caller's phone number (and potentially a name) in the SS7 setup message to the terminating switch, and the receiving switch encodes that information in the silent inter-ring interval where it's decoded by the callee's phone and displayed to the callee. The situation is basically similar with cell phones except that the connection between the cell phone and the switch isn't analog.

One of the basic assumptions of SS7 is that any device which gets to connect to the telephony network and speak SS7 is trusted. In particular:

  • The originating switch can put any information in the setup message it wants, including advertising random numbers that aren't actually connected to the switch.
  • Caller-id blocking (when the caller doesn't want their id propagated), is implemented by having a bit in the setup message that tells the receiving switch not to encode the caller-id information onto the callee's line.

The first point implies that you can't really trust anything you see on caller-id. If you can get a digital connection to the phone network, such as in a call center, a PBX or a home ISDN line, you can generally put any information you want in your messages [Technical note: this protocol is Q.931, not SS7, but you can think of it as SS7 for now], including false caller ID information. Since it's not at all hard to get this kind of access, caller-id from the telephone network is basically unreliable. The second point implies that caller-id blocking isn't that trustworthy either. If you have a digital connection to the network, there is a reasonable chance that you will get the caller-id information for any caller even if they have turned on blocking—you may see the bit that tells your phone not to show you, but nothing makes it obey that. In principle the receiving switch could suppress this information in the Q.931 but my understanding is that generally switches don't.

As far as I can tell TrapCall uses some combination of these features. You arrange to forward blocked calls to TrapCall, which acts as if it were your voicemail provider (I imagine that if someone really leaves a voicemail they just proxy it to your real voicemail box) which then reads the caller-id information and calls you back with spoofed caller-id matching the caller's (blocked) caller-id.

Acknowledgment: Jon Peterson filled in some of the details here. All mistakes are mine, etc...]

1 Comments

Good summary, but I have some nits with a couple of details.

Technically, the terminating switch doesn't receive calling name information from the SS7 (more specifically, ISUP) setup message (IAM, similar to an INVITE in SIP). The final switch in the chain -- the one your phone is actually connected to -- uses a different SS7 protocol (ISUP) to look the number up in a database, and retrieve a name. (This database dip may or may not actually happen, depending on whether the message indicates that it was inserted by the user and not verified; inserted by the user but verified by the network; and inserted by the network. In some networks, it can be marked as "inserted by the user but failed validation").

This is an important detail to note when discussing caller ID spoofing in general, because it means that you can't put arbitrary strings into the name that are then delivered to a called party (at least, not without hacking the name database). And because spoofing over interconnects like ISDN BRIs and PRIs necessarily codes the calling party number as user-provided, spoofed numbers *usually* end up delivering a number to the called party, but no name.

The second nit is that, while Q.931 technically copies the format of of the calling party number from Q.763 (ISUP syntax), including the indication of whether to render the number to the user, any switch that includes a calling number that is supposed to be restricted into a Q.931 SETUP message is *way* out of spec. The semantics of calling party number coding for Q.931 are defined in Q.951, which requires the following: "When CLIR (Calling Line Identity Restriction) is applicable and activated the originating network shall provide the destination network with an indication that the calling user’s ISDN number and sub-address (if provided by the calling user) are not allowed to be presented to the called user. In this case no calling user number and sub-address shall be included in the call offered to the called user."

Translated: you can share the number from network-to-network (Q.763 IAM), but cannot copy it into a user-to-network (Q.931 SETUP) message. It is my understanding that this practice is followed rather strictly.

This is interesting, because it implies that TrapCall actually has an SS7/ISUP interconnect into the PSTN, which is much more difficult than simply getting an ISDN PRI.

Leave a comment