In June of this year I announced the participation of CellAnalysis in the project of Sysmocom Accelerate 3g5 program to detect the 3G IMSICatching attacks. This article describes the first steps studying the 3G attacks within the Osmocom infrastructure and the basic principles of detection that are being implemented in CellAnalysis 3G.
Following the steps in the Getting_Started_with_3G tutorial, we setup the 3G network but we will modify the MSC node source code. We don’t need to add any subscriber in the HLR/AuC database, since we are not going to deliver a 3G service to our victims. The negotiation procedure of the mobile to register in our 3G network will always be rejected, in order to be able to downgrade to 2G, in the same way as we saw in 4G (4G / LTE IMSI Catchers). In this first article we will use the “Location Update Reject” attack, with the different causes of rejection forcing the mobile to register in the 2G network (the downgrade attack).
- femtocell nano3G (Sysmocom)
- Osmocom 3G network, running on Ubuntu 14 (intel core i5 4200U 1,6GHz, 8Gb RAM)
- BladeRF x40
- YateBTS, 2G network running on Ubuntu 16 (intel atom 1.6GHz, 8GB RAM)
Once configured the 3G network following the Getting Started tutorial, it’s better to verify that the cell 3G is transmitting correctly in the UARFCN 9800 (default channel):
To implement our custom reject cause, we must modify the source code of the MSC to overwrite the registration reject cause in the “Location Update Request” response. Usually the reject cause should be “(2) IMSI unknown in HLR” since we have not provisioned any subscriber in our HLR or “(3) Illegal MS” if we only add the victim’s IMSI in the HLR Sqlite db but not the auth values. It’s needed to manipulate the source code of the MSC so that it always returns the cause value of our interest, according to whether we want to do a D.o.S or a 2G downgrade attack:
- · Disable the USIM entirely until power-off or USIM removal.
- · Attach requests disable the USIM for packets domain until power-off or USIM removal.
- · Periodic Location Update requests will trigger the UE to attempt GERAN instead.
Once we choose and implement our attack, switch-on the victim mobile (S2) and activate Tobias Engel xgoldmon to detect the attack. Check the following image, how the response to the registration request (the Location Update Reject) is correctly sent to our victim with our reject cause choosen (this example is #14, “Service option temporarily out of order“):
After the LocUp Reject, the victim mobile connects to the 2G network (YateBTS). See bellow how after the RRC message “Location Update Reject“, the mobile starts to use LAPDm and begins the authentication in the 2G network:
But, before switching to 2G network, the registration procedure has asked the victim mobile to identify, by requesting the IMSI. This is the 3G IMSICatching attack, see the “Identity Response” message (IMSI has been removed in the image):
CellAnalysis 3G uses active monitoring solutions (in this article xgoldmon), instead of the passive ones as SDR boards used in the 2G fake stations detection, to monitor 3G attacks.
Advantages using active monitoring;
- ciphering algorithms (UEA) usage
- authentication parameters and rates
But on the other hand, there is a big disadvantage:
- one SIM card and device per operator in order to scan all the 3G fake stations
Of course a regulation compliance check is being carried out to determine wether the 3G radio parameters are used accordingly to each country frequency distribution regulation, as in the 2G detection.
8 thoughts on “IMSICatching attacks on 3G networks (part 1)”
it s possible to make this attack for le lu reject cause by using openbts-umts !?
Sorry for the delay. I didn’t use OpenBTS-UMTS, but I guess should be feasible as you can modify the source code to adapt the reject procedure, in order to deny access with custom reject cause.
is it possible to see your modification about MSC code!? any diff or like that for having inspiration !? and the what is the periodicity of the location update !?
Inspiration could be found by using “grep” command, so you should locate in the source code the specific files managing the reject causes (very easy).
About your second question, I suggest you start reading the document “3GPP TS 23.012” -> “Detailed procedure in the MSC” and “3GPP TR 29.994” could be interesting for you, among others.
hi predo, is it possible to configure any periodic location update by configuring the T3212 or it’s only for the GSM-GPRS configuration?
Yes, there is a periodic location update timer in both 2G (osmo-bsc) and 3G (osmo-msc):
osmobsc-vty-reference.pdf: “1.15.45 periodic location update <6-1530>”
osmomsc-vty-reference.pdf: “1.14.9 periodic location update <6-1530>”
Thank you very much! hopping the part2 is coming soon ! is it possible to have any video about your conferences about ‘CellAnalysis at DefCon DemoLabs’ when i try to google it i can’t find any links. Great tutorial, and thanks for all explanation
And it’s not possible to integrate any redirect carrier info with this lu-reject !? what standartisation specifie this on 3GPP on TSXX.XX!?