Holger, Harald -
I've been observing TMSI-handling bugs in GSM handsets for a while and saw a really good one last night, so I'm going to offer some comments here.
On Sat, Jan 10, 2009 at 01:40:33AM +0100, Holger Freyther wrote:
Hey Guys,
I'm currently implementing the CM Service Request of GSM 04.08
and I wonder
about the following:
1.) Some phones send us the TMSI of their current network 2.) One can ask the phone for the IMEISV/IMSI 3.) One can accept the LOCATION UPDATING REQUEST (or wait) 4.) A rogue MS could now request a channel with the BTS of the
original
network 5.) Could send a CM Service Request with the TMSI of the
original phone and
claim to not support A5 and such... 6.) Could initiate a call on the behalf of the other phone...?
I think this would work, if
- we had a MS that we could fully control.
- the old network would accept the sudden classmark change for no
A5 support, which in fact also depends on the cell itself. I would assume that most BTS in real-world netwokrs never announce that they support A5/0
According to GSM 02.07 Section 2, all GSM handsets are required support A5/1 and A5/2. According to GSM 02.09 Section 3.3, the network is SUPPOSED to deny service to any handset that doesn't support either A5/1 or A5/2. I'd be curious to see who's enforcing that, though. And any prudent operator will do an authentication at the start of a call, even for A5/0. Again, I'd be curious to see who's really doing it, but I'll bet most European operators do.
You may not need to fully controlled a handset to do this, though. This is where TMSI handling bugs come into play. Last night, I was playing with a Treo 650. Having last registered in an AT&T network, the Treo sent a location updating request to my system (MNC=910, MCC=55) using that AT&T TMSI, which it is not supposed to do. I removed the SIM and cycled power. THAT should have cleared the old TMSI, but it came back to register by TMSI again. I sent a location updating accept, without sending a new TMSI. THAT should have cleared the old TMSI, but when I tried to place a mobile-oridinated call the Treo sent the same old AT&T-assigned TMSI in the CM service request. I am certain that if I had assigned a new TMSI to this handset and then switched off my system, that Treo would have taken my TMSI back the the AT&T network and tried to use it there.
I suspect this kind of bug is fairly common and may be exploitable by a rogue network, even if only to expose the IMSI-TMSI relationships in the real carrier's BSC.
As Harald points out, the attack described in the original e-mail should not work in a properly managed network. But I'll wager that most of the world's networks are not properly managed.
-- David
David A. Burgess
OpenBTS on the web: http://openbts.sourceforge.net http://openbts.blogspot.com http://en.wikipedia.org/wiki/OpenBTS http://www.gnuradio.org/trac/wiki/OpenBTS
Hi David,
great to see that you are also following this list, your iput and experience is greatly appreciated.
On Fri, Jan 16, 2009 at 07:13:25PM -0800, David A. Burgess wrote:
You may not need to fully controlled a handset to do this, though. [...]
Thanks for pointin this out. Maybe holger has an interest to try something like this - I personally am not too interested to play with regular 'closed' phones.
We are currently discussing the various options we have for building a "fully controlled handset". I think it is the logical conclusion to projects like OpenBTS and OpenBSC...
I don't want to talk too much at this early point, but I'm confident that we'll come up with something useful later this year, based on commercially available GSM transeiver and analog baseband chips. Using somethng like USRP for the MS side is nice for a handful of researchers who already have one, but not really an option for most hackers in the community who are used to only invest in cheap equipment like a wifi card + free software drivers + protocol stack.
We'll see. I'll keep you posted about our progress. We're still in early planning, but have the right kind of people for hardware/firmware/software and access to the required resources/documents and components.
Regards,
-
David A. Burgess -
Harald Welte