-
Notifications
You must be signed in to change notification settings - Fork 968
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Detect unusual 3G to 2G downgrade attempts #82
Comments
It is the mutual authentication of 3G Base Stations, not the encryption that makes the difference. But also on UMTS a Man in the Middle is possible. Even if there are 3G stations with a good signal it is still common to switch to 2G for voice calls. 3G is often used for the data connection and for voice calls there is a "fall back to GSM" method. It depends on the release version of the mobile network and if there is a free slot for voice calls on 3G. There was another question before: "And if I'm not wrong, we have A5/3 encryption in 3G mode so shouldn't be a call in 3G network secure from IMSI Catchers? " That's why I said it is not the encryption in the first 2 sentence :) I am afraid this "simple" approach does not work. |
Thanks for your input. Yes, I removed the sentence, I felt I was wrong - I don't like to be wrong ;). |
Just to clarify the project goals. We are trying to provide an IMSI-catcher detection mechanism, and not a secure line. There are plenty of other projects trying to provide a "secure calls", as stated on the Wiki. Of course it could be useful to "prevent 2G", but this is in no way preventing your phone calls of being monitored, just making it a bit harder for amateurs. So in the current situation, the only interest we have in 2G vs 3G is perhaps to try to detect an unusual 3G to 2G downgrade attempt, which would only trigger another warning flag in our additive detection scheme. So, if you were to force your phone into 3G mode (which is easy to do), then there would be fewer of these detection parameters, and more difficult to obtain others, with the result that IMSIC detection would be much harder. Now in a distant future version of AIMSICD, we plan to add some counter measures, that may include forcing certain telephony functionality states, perhaps including that one. |
@E3V3A I see your point. For an IMSI-Catcher detector it is really better if can detect downgrade attacks than prevent them by forcing 3G. But I want some clarification regarding 3G-only security. 3G uses A5/3 as encryption which can't be decrypted passively by IMSI-Catchers in comparisson to A5/1 (known plaintext attacks). As He3556 said, 3G is also more secure because "By allowing the UE (User Equipment) to authenticate the network it is attaching to, the user can be sure the network is the intended one and not an impersonator." (Wikipedia). So how can an IMSI-Catcher intercept calls of an 3G only phone? If the phone can't get downgraded to 2G the calls can't be intercepted. Am I right? But we want to detect IMSI-Catchers because they are used to pin point the exact location of phones. Still we can inform the user that if he want to make a secure call, he should activate 3G-only? |
I also captured logs of my modem and can verify that on my phone "WCDMA only" is really WCDMA only. The phone doesn't use GSM in any way in this mode. Of course there can be networks which don't support 3G calls, but my network here supports gsm and 3g-only calls so this isn't uncommon. |
I think this issue should be changed to "Warn when phone uses 2G(with good signal quality) on networks known to support 3G" - do you agree? |
@andr3jx "I also captured logs of my modem and can verify that on my phone "WCDMA only" is really WCDMA only. The phone doesn't use GSM in any way in this mode." I can also confirm above. |
we could inform if somebody is using 2G but not warn them, because there would be too many warnings, without any reason. 2G is shown in the display of all smartphone - so the informing part is there already. Disable 2G is not a option because:
UMTS MITM is possible but i don't know if this is already in use out there. I only found some scientific papers about this topic. |
@andr3jx, since @E3V3A elaborated on the current project goals, I've updated this Issue to the title |
@He3556 My point is: We should have data in which areas 3G is offered by different operators. If the phone is in a known 3G area but has only 2G with good signal the user should get a warning. There are free available coverage maps by different operators that we could use to obtain the data. There is also OpenSignal project which collects this data. We could also record which networks offer 3G. If the phone has good signal and has only 2G although it is known that the network supports 3G, there should be a warning. This is only relevant when an IMSI-Catcher clones all parameters of a cell (LAC, CID etc.) An IMSI-Catcher should be seen as a 2G only base station with strong signal from the same operator. Irrelevant but the "only 2G available"-problem could be solved with this approach: Use only 3G. If phone has no signal, switch to GSM/3G. If phone has 3G signal switch back to only 3G. @SecUpwN: The title fits perfectly, thanks! |
but if you use 3G - how could we detect a 2G Catcher? we don't want to hide - we want to fight! ;) |
@SecUpwN yes detecting "fall back to GSM" could be a goal. But i would suggest to keep it on a low priority right now. There are many other things to do first. We would need to have something like a local db where we keep the data about Smartphone position, Cell ID's, Connection time, Signal Strength... like a history. Q: @SecUpwN: Is this implemented as "Cell tracing" already? And then we need some calculation to get a statistic overview. Before we can detect unusual behavior at all. This belongs to the issue #71. Should we open a new issue like "detection strategies with db & statistics"? One could be if you get rejected by the same cell with a good or even the best signal strength. Because if you are near a catcher but you are not the victim, your mobile will try to connect but the catcher doesn't want that. |
I want to add that this feature is also relevant because IMSI Catchers can force the phone to remain in 2G-mode until reboot. See: |
AFAIU, nobody can force anything, IFF we can have control over our modem. That's what this is about, taking control over our modem settings and showing us "bad" behavior, so that we can prevent it. AT command control, let us do this to some limited extent. |
@freddymartinez9 My understanding of papers I quoted is that they don't need to jam 3G connections to keep the phone in GSM mode. |
@andr3jx it depends on the IMSI catching system I suppose. "With our 3G Although to your point, I'm not certain if the IMSI-Catcher is "jamming" as you understand it. But in the same catalog they certainly advertise these capabilities: "The PKI 1720 is a high capacity jammer for the 3G/UMTS frequency range, as well as for GSM frequencies. This highly developed jamming device is perfect for combination with our GSM monitoring systems and the GSM IMSI-Catcher. By selectively jamming the 3G/UMTS frequencies, all UMTS telephones in the operating area are switched into GSM mode" |
That is marketing BS. Because, unless the baseband developers have blatantly decided to ignore the AT command (or other interface) settings when forcing to use one or another RAT, this is not possible. You can set this is the Service Menu on most Qualcomm, XMM and MTK based Androids. Having said that, almost nobody (>>99.99%) of Android users, would ever think to go there. But we do! |
All this "fall back" mechanisms in cell networks ensure a trouble free operation of all services. Suppressing can cause failures. And even if it works, we couldn't detect downgrading any more. I have 2 ideas:
|
@He3556 Can you be more specific with |
The 3GPP standards see: |
@andr3jx there is nice method to force phone off 3G network... just give him reject from 3G BTS with forbidden LAC and phone will not try to register to that LAC for some time (6-48hrs - manufacturer dependant) and if you served phone with information about just one 2G neighbour in BA list, it will go to specified channel on 2G and stay there if there is a BTS, otherwise phone will start band-scan similar to one at power on. Tested and used ;). |
What timer is that? |
@E3V3A I am not sure is it timer that can be accessed from outside world or is it just a loop within radio firmware required by GSM TS, but I bricked my phone once with that. I would say it is just a loop within a firmware because some phones do not have it implemented (mostly far east products). Removal of battery fixed my phone. Just another thing worth mentioning: Forcing to 2g and silent call is the solution for locating mobile phone with catcher. |
@E3V3A @ga900 Thanks for your info here. I'm experiencing this forbidden LA issue on my phone. After walking through high frequented areas in my city and the main railway station I noticed that my phone started displaying the roaming indicator. Back at home the indicator still remained. After switching off and on the radio the roaming indicator still remained active. After I checked the MCC and MNC of the active cellular network I noticed that the MNC was different from my home operator. It displayed the MNC of a sister network of my home operator. I recorded some traces while I switched the radio on and off. @E3V3A I also found the timer duration for erasing the forbidden LA list - on my phone it is 9360000. |
Is there anyway to implement downgrading feature in openbts-umts in order to pull back an MS from 3G to 2G so that it can be easily captured ? |
I propose to add an option to change preferred network type to "WCDMA only" (3G). This can be done at least in the hidden Android Testing menu. After you change this option you need to disable and enable the radio again. This should prevent downgrading attacks from IMSI Catchers. In case a user can't do without 2G: We should record which networks support 3G. If the phone has good signal and the network offers only 2G (known to support 3G) the user should get a warning.
Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.
The text was updated successfully, but these errors were encountered: