No subject

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

David A. Burgess dburgess at jcis.net
Sat Jan 17 03:13:25 UTC 2009


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







More information about the OpenBSC mailing list