Thursday, December 11, 2008

HOWTO spoof the Pakistani Foreign Ministry

Reader Chris "Chris" Williams recently came up with an interesting idea regarding the unnerving incident during the Mumbai terrorist assault when somebody called Mr 10%'s office and, posing as the Indian foreign minister, threatened war. Chris reckons that not only are the two linked, but the phone call was actually the main effort; in fact, the commando speedboat assault on the city centre was a sort of privilege-escalation attack intended to boost the effectiveness of the fake telephone call.

As Scott Sagan wrote in The Command and Control of Strategic Nuclear Forces, you can't go on alert without reducing the reaction times and increasing the sensitivity of your command system, because that's what the word "alert" means. Going on alert involves system risk as well as mitigating the risk of surprise attack.

That doesn't just work for radars and satellites, or even for organisations; it happens in your head as well. As well as forcing an Indian military alert and, more importantly, a Pakistani alert, the attack on Mumbai forced an emotional, psychological, and biochemical alert on both parties. Among other things, this tends to mean that even peaceful precautions are overlooked; just pick up the phone!

What is really worrying here, though, is that the Pakistanis still apparently believe that the call came from the Indian foreign ministry, because the Caller ID display said so. This is truly frightening; caller-line identification, CLI, is a surprisingly flaky feature of the public-switched telephone network (see the many, many discussions on uk.telecom). It's the kind of thing that Bellheads like to accuse Internet people of, just it's the Bellheads' work. Rather, CLI works quite well within one telephone network; it's when you start interworking that things happen.

And obviously, international calls involve interworking. CLI works like this (there's a nice explanation on the Asterisk developers' list: a message including the e164 telephone number originating the call and two flags is generated either by the subscriber's equipment or by the carrier's local exchange. The first flag has a value of 0, 1, or 2, which correspond to OK, "Not available due to user action", and "Not available due to interworking". If you choose to withhold your number, BT will set a flag of 1 on the CLI, so standards-compliant equipment at the far end will not show it. Note that the number is still sent. 2 is sent if the carrier (or the user) doesn't have a valid CLI for this call, or doesn't send CLI to the terminating network.

The second flag can be 0, 1, 2, or 3. 0 means the CLI was passed by the originator's equipment and this has not been checked. 1 means the CLI was passed by the originator's equipment and the network setting the flag verified the number is correct. 2 means it was checked and found to be incorrect. 3 means that the setting network's local exchange assigned the CLI and therefore it is known to be good.

In the case of calls that are coming in from another network, then, the first flag should be 0 only if the second is 1 or 3, else 2. It's left as a question of policy what you do with the others - for example, if someone is making unwanted calls to subscribers in a network that you provide service to, using the withhold flag and CLI set by their own PBX, do you honour the withhold flag, do you send the dodgy CLIs in case the subscribers want them to find out who's doing it, or do you treat the CLI as probably all lies?

In practice, this is resolved by keeping lists of networks by degrees of trust. After all, if someone is really dodgy, there's probably no point in relying on their own claim that they checked the CLI, so you might as well treat them all as nonsense. Some you can trust. Some you can trust partially, perhaps only the 1s and 3s.

But this, of course, only works if other people can trust you. If you don't care, you might just pass every little thing, or if you're really irresponsible you might set 1 flags on everything. Eventually this sort of behaviour will get you on everyone's Do Not Trust list, but it's always possible that the people you're trying to send dodgy CLIs to aren't great either.

So, first of all, you need an el cheapo phone company. Specifically, what you're after is someone who provides really cheap and flaky bulk SIP interconnection, because what we need is a way of connecting a device that's going to send someone else's CLI into the traditional phone network, and this is much the easiest via the Internet. Of course, our target might be on a VoIP system, but the important bit is that it turns up at the far end with a traditional phone number as the CLI. We might start here, or - why not? - even here, or of course here.

Now, all we need is a copy of Asterisk, the open-source PBX and general phone toolkit; we change the zapata.conf file to set the CLI to our desired number and whatever flags we like, set "usecallingpres=yes", put the details we were given by the dodgy SIP operator in the trunks section, and we're good to go. There's an obvious way to test if they're passing the arbitrary CLI; call your mobile phone and see what comes up on the screen. To finish the job, we tell Asterisk to route incoming calls from the mobile numbers (or VoIP clients) we want to use, according to the dialplan we just specified.

We can now call the president of Pakistan and say whatever we damn well like, from whereever we damn well like. And caller ID will say exactly what we want it to. You may stroke a white cat while you do it; it's not mandatory.

Scared yet? Right, we have learned a couple of things here. First up, interconnected networks imply netizenship. Keep your gear clean and know your customers, and you'll save people downstream a lot of trouble, and if everyone behaves like that, what a wonderful world it would be.

Second, Caller ID is no kind of security for anything vaguely serious. Telcos don't bother with it for really important purposes, like "working out your phone bill" - they use a different and secret billing identifier. It is truly astonishing that there was apparently neither any technical security beyond that, nor any authentication procedures either. (After all, an alternative to this would have been to have someone walk into the Foreign Ministry and just pick up the phone.) No security questions, no pre-arrangement, no passwords, no crypto, no shared secret. Nothing.

No comments:

kostenloser Counter