Keywords: ESN, MIN, Cellular, PCS, Telus, Clearnet, flaw, exploit, hijack, DoS, fraud, security

Synopsis: A flaw in the ESN/MIN tracking creates opportunities for hijacking
	and denial of service attacks.

Overview: Since Time Immemorial, customers of telcos have made determined
	efforts to improve their cost-to-service ratio, through means such as
	switching carriers, upgrading equipment, and possibly attacking the
	network itself. To protect their "commitment to shareholder value",
	(translation: too cheap to give you vaseline before the shafting) the
	telcos have implemented various security systems to prevent or at least
	minimize the effects of toll fraud.

	Cellular systems are prime targets for fraudulent use, since a given
	Mobile Terminal can be quite difficult to locate once deployed, and
	when used to commit fraud, the guilty party can be very difficult to
	locate. Since cellular and PCS/GSM MTs necessarily broadcast their
	credentials, a window of opportunity is created. It is my cynical guess
	that about 15 minutes after the first cell phone was demonstrated, the
	first ESN/MIN snarfer was designed, and 15 minutes after the first cell
	phone was purchased, the first cloned cell phones were available. With
	the current price of airtime, there's not much of a reason to doubt the
	lack of incentive to send your cell bill to someone else every month.
	Of course, Ma Bell hates it when we say "Suck it down, bitch!" so she's
	cleverly come up with ways to suck on her own terms.

	Being Ma Bell though, she's a history of making mistakes, and we have
	no reason that today's the day she gets a clue. Today's problem lies
	with the notion that a system that will "fail safe" ... well, will, at
	some point, fail. And anything that can fail, can at least become some
	kind of denial of service attack. The interesting part about this attack
	is the fact that it's a remote attack and that there are possibilities
	for unauthorized intercepts, even on supposedly secure digital networks.

	"A remote denial of service and a remote intercept," you say? "Gosh, I'd
	hate for that to happen to me." Yes, this isn't a nice thing to do. You
	probably don't want to reproduce this attack at all, nevermind while out
	in front of the local telco's building, lest they become sufficiently
	peeved and get the notion of shoving your phone up your ass, sideways.

Reference: We shall consider this attack from two perspectives: what the MSSC
	thinks, and also from the perspective of an IP/MAC conflict.

	In order to prevent fraudulent use, the MSSC (Mobile Services Switching
	Center) keeps a record (as entered by the operator) of what MIN is
	assigned to a given ESN and in what cell a given mobile terminal is
	found. This is also necessary to allow features such as automatic call
	delivery (the fact that your phone rings when you call it). Obviously
	this database is a prime target for all sorts of attacks, and the
	designers of cellular telephony infrastructure, as well as the carriers
	who deploy it have chosen a failsafe model of operation. Granted, "safe"
	is is define by the implementors of a system, and as such failsafe may
	not be operational at all, but rather a known-stable configuration under
	adverse circumstances.

	Contrast this behaviour with the more permissive actions of ARP and IP
	whereby most IP stacks will accept hostile ARP broadcasts. When a phone
	powers up and registers its presence on the network, part of that login
	sequence is the MIN (known as MSISDN to GSM fans). This is similar to an
	xterm making a bootp request to get its IP address based on its hardware
	address. After the bootp exchange, most of the hosts on the network now
	have a valid mapping between IP and MAC address. If another host claims
	to have the same IP address, many IP stacks will issue a warning about
	an address conflict ("ARP info for A.B.D.C overwritten by c:0:f:f:e:e")
	but will continue to accept packets from these conflicting hosts. This
	allows both hosts to continue communicating, albeit incredibly slowly.

	Cellular switching systems respond to this threat by delivering paging
	information to only one terminal at a time. It seems that the only time
	the switch system will accept a new ESN/MIN pair is when a handset
	enters a service area. It also seems that switch systems do not like it
	when a given ESN changes its MIN on the fly without direction from an
	operator's console (read: this sets off loud alarms and you should get
	ready to run from the hounds of hell.) It seems a reasonable thing to
	do, on the assumption that a Revenue Unit (shafted customer) will only
	be on one physical handset at a time. At this point the network knows
	that it is to send messages for "A.B.C.D" to ESN c:0:f:f:e:e, and it
	obligingly does so. Once a page gets sent to the attacking handset, it
	might need to reply. It is this reply that will actually trigger the
	DoS, since this is what notifies the switch that the address has
	changed. And it is this change that causes the fraud detection code to
	trigger and disable outgoing calls from the attacking handset. This does
	nothing for the victim who is now unable to receive calls since his MIN
	is now registerered to someone else's ESN.

Exploit: There are two ways to make this attack work. One takes a little bit of
	big-blue-room detective work, the other takes some luck. The end result
	is the same though; the victim's phone does not receive any incoming
	calls, SMS notices or system broadcasts, even though it is able to make
	calls. As an added bonus, there's a better than even chance that this
	particular attack session will cause the victim's messages to be sent to
	the attacker's handset. This can add quite a bit of confusion for the
	victim who "knows" everything is OK because he can make calls. He finds
	it odd though that he hasn't got a single text message or phone call or
	voicemail alert for days. And no telco I know of makes any guarantees
	about the performance of their network. Furthermore, it's not likely to
	be a really huge issue meaning that it will be a long time before an
	analyst ever gets around to checking the problem out.

	You will need, for each victim either the handset they previously had
	activated on that account, or a handset which uses the same radio
	interface (CDMA, TDMA, GSM) and has a modifiable MIN.

	1) Wait for the victim to power up his phone and log on to the network.
	It's probably a safe bet to assume that the phone is on and vulnerable.
	Why would someone have a cell phone if they weren't going to use it?

	2) Ensure that the attacking phone has the same MIN as the victim phone.
	You can do this by going trashing (to find a slip of paper with the MIN
	and ESN on it), by buying the victim's old cell phone with that MIN (not
	really wise; people will ask questions) or by programming the same MIN
	into another handset enabled on the victim's network. This is best done
	while out of coverage areas (ie. subway stations or parkades)

	3) Turn on the attacking phone, and wait for a digital signal to be
	acquired. Make sure you have a relatively strong signal - the victim and
	attacker phones will be getting into a virtual shouting match, and it is
	important that the attacking phone wins.

	4) dial *228 or *2280? (where ?=[0-9]). *228 spells '*ACT' which is, of
	course a call to activate the phone. Clearnet and Telus don't support
	this feature; trying this from a deactivated phone will get you a fast
	busy, other phones will give you a message saying that you should call
	customer service to have your phone activated.

	5) leave the phone on for as long as you want the attack to continue. I
	have seen this attack persist over eight hours, and several reboots of
	the victim phone. Once the attacker goes away, either another reboot of
	the victim phone is needed or a delay of at least $LocUpdate. $LocUpdate
	is a network parameter which controls how often a phone rebroadcasts its
	presence on the network.

	You now have a phone that is capable of intercepting messages bound for
	your victim's handset. Enjoy! Personally, I don't recommend doing this
	much if at all. It sucks when your phone goes out of service, and you
	also break a number of laws regarding telecommunications security, and
	risk stiff penalties. Consider yourself warned.


   root@opentelco.net
   11.30.00