Femtocell detection & protection
SecUpwN opened this issue · 52 comments
Femtocells are home routers that use broadband connections to improve mobile coverage, allowing calls to be made indoors more easily. While a femtocell all by itself is not necessarily harmful, they can be hacked (as done in Great Britain by THC in 2010) and be used to call anyone using the victims caller ID, read all SMS, MMS, listen to the voice mailbox and even intercept and record all phone calls made by the person who connected to such femtocell.
And while crawling the interwebz, I found a very interesting project by @iSECPartners: The FemtoCatcher Android App for Verizon Android Smartphones. And the best thing of it all: It's OpenSource on GitHub! Their App has been presented at Black Hat and Defcon 21: "Traffic Interception and Remote Mobile Phone Cloning with a Compromised CDMA Femtocell", a short summary with presentation slides can be found on their website. Some features of it:
- FemtoCatcher uses the network ID information available through Android API calls to determine if the phone is connected to a Femtocell.
- They did not test how easy it would be for an attacker to change this information to fool the app, but certainly don’t rule out the possibility.
- Some Verizon Android phones display an icon in the status bar and/or display an ERI banner of “Network Extender” when connected to a femtocell. The strategy used by FemtoCatcher to detect the presence of a femtocell is based on the same techniques used by these indicators in Verizon ROMs.
- FemtoCatcher will not automatically take your phone out of airplane mode when you move away from a femtocell. You will be without service until you manually re-enable your connectivity. If FemtoCatcher is running and you are in range of a femtocell when you disable airplane mode, FemtoCatcher will quickly put your phone back in airplane mode.
I remember that when I discovered their project a while back, I even wrote an E-Mail to @tomrittervg of @iSECPartners introducing our project. He already saw our project and was very excited about it, telling me that they built FemtoCatcher with the explicit goal of having someone extend upon it. Sounds awesome, huh? ;-) At the time of my E-Mail he was travelling a lot, but he said that although they probably can not contribute much to our project developer wise, he'd send out a general link and tell folks if it looks interesting to get in touch for contributing. Very sympathic guy. Before your head starts smoking: What's your opinion, @xLaMbChOpSx? Could you add their femtocell detection and protection mechanism, maybe enhancing it to not only work with Verizon smartphones? Let me know if you need anything.
Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.
I have checked out the source code you linked and this could be easily incorporated into AIMSICD, as with Femtocatcher it will only work on CDMA type phones without further investigation into how to uniquely identify a GSM Femtocell.
There is a difference in the way a Femtocell ID is generated between the two:
- CDMA ID consist of MCC (Mobile Country Code), SID (System ID), NID (Network ID), and BID (Base Station ID)
- GSM ID consists of MCC (Mobile Country Code), MNC (Mobile Network Code), LAC (Location Area Code), and CID (Cell ID)
With further investigation it might be possible to extend detection to GSM networks where a specific range is identified for a GSM ID component, I have not looked into this any further yet or looked for any specifications which may hold this info but it would seem like a good fit with the ideals of AIMSICD. Definitely something to consider integrating once we have sorted out issuing AT commands.
@xLaMbChOpSx, sounds awesome! Please let me know if you need any other data for adding this.
Oooh, so long ago already. ==> Last time we discussed this I was about to collect info on FemtoCell Manufacteres. We need a list of those guys and what "id"s they use for their devices...
@E3V3A, there's no public way to obtain these, right? We'd need a whisteblower leaking them..
No I don't think so. But we have to dig into their documentation, if we can find any...
Maybe we should create a database of manufacturers and place found ID's as well as IMSI-Catcher types in it so that AIMSICD can look those up and display the corresponding manufacturer and model then? If you like this idea, how would you prefer construction of this database, @xLaMbChOpSx?
The current cell information database could be extended to include extra information that can be used to identify Femtocell's, the ID from CDMA phones could easily be added immediately then once identified the GSM info could also be included.
I didn't search very much on this as the Femtocell Catcher source has the info for CDMA devices but surely there must be some specification out there that defines unique identification for GSM ones, it was quite surprising having a little bit of a look around this and seeing all the countries that distribute them.
@xLaMbChOpSx, what happens with tracked cell information in the current version 0.1.3-alpha? I guess it is currently stored on the device, will it be useful to upload it somewhere for analysis?
Yes it is stored in /data/data/com.SecUpwN.AIMSICD/databases/myCellInfo if you open that with something that can view SQLite databases such as RootExplorer you will see three tables each containing the tracked data.
It could be uploaded somewhere for central collection and analysis just need to now where and how you would like it.
Good to know, @xLaMbChOpSx. But _if_ we should upload the tables for (automatic) analysis, I'd prefer an encrypted, protected storage. With our project being Open Source, be sure that IMSI-Catcher manufacturers like Rohde & Schwarz are closely monitoring this project (online profiles of our team members have already been visited by them) and might find a way to circumvent analysis of their IMSI-Catchers through our App. The safety of our developers as well as users of our App is my topmost priority. Should we include some sort of "protection mechanism" within AIMSICD, @E3V3A?
@SecUpwN: Let's keep things as simple as possible for now. I'm very glad you belong to the group people of ultra-paranoids, but let's try to keep things simple for our developers. I've got other cards up my sleeve for "protection", if necessary, once we've got the main features working. Let 'em look.
You got "other cards up your sleeve for protection"? Would be interested to hear what they are - feel free to tell me via PM, @E3V3A! Just because I think it fits into this conversation: The issue of not showing the ciphering indicator has been reported to Google on December 10, 2009. They're still discussing whether there's even a way of displaying it or not. I felt in a kind mood to send out an E-Mail to the poor guy who opened up the issue to introduce our project to him. I'm just too polite for this world. 😸
With regard to keeping any part of this project closed source: Lessons can be learned from the NSA, Intel, the random number generator and its backdoor. Not that I'm claiming anyone here is secretly working to subvert this project, but the danger of anything being left hidden should be readily apparent to all. The best encryption algorithms and protocols enjoy fully open status and peer-review, that openness for the sake of peer-review should extend to applications. Yes that gives the IMSI catcher manufacturers an advantage but it's only a small one, thanks to apktool it isn't that hard to reverse-engineer an Android app anyway.
I am also curious what other protections may be available (cards up sleeve) and would like to hear more about that.
@xLaMbChOpSx, in your pull request from yesterday you've been mentioning that any details regarding GSM femtocell unique ID values would greatly assist with extending this detection. I'm currently crawling the interwebz to find what you need. On this blog I just found an interesting comment in the fifth paragraph: "For GSM the unique ID consists of MCC (Mobile Country Code), MNC (Mobile Network Code), LAC (Location Area Code), and CID (Cell ID))." - Is this the missing piece?
@SecUpwN Sort of that defines what makes up the unique GSM ID but we need to know specific details to enable detection, for example if femtocells use as specific range for the cell id's etc then that would allow us to detect when connected to them just like the CDMA detection works from the femtocatcher code.
I searched a little bit looking for specifications or details people had gathered but didn't have any luck.
@xLaMbChOpSx, let me search for it. Can you give me the exact details for the CDMA femtocells to use as a reference, please? I'll report back ASAP when I have found something. Maybe @iSECPartners can shed some more light onto this? Just wrote an E-Mail to @tomrittervg to have a look.
I´m afraid the CID (Cell ID) and LAC are assigned by the Operator. The only chance would that Femtos used a dedicated PLMN as suggested in
http://research.cs.queensu.ca/TechReports/Reports/2012-590.pdf
In the same paper you´ll see other techniques to distinguish femtos and macro cells
PLMN list:
http://www.numberportabilitylookup.com/networks?s=
Yeah I had not had any luck working out anything to identify GSM Femtos, the Femtocatcher code uses the following for detection of a Femto using a CDMA device:
private int FEMTO_NID_MIN = 0xfa;
private int FEMTO_NID_MAX = 0xff;
Converting to int from hex gives MIN = 250 MAX = 255 Femtocatcher then compares the CDMACellLocation NetworkID to see if it falls within this range, if so it identifies the cell as a femtocell and will then take action.
I have a femtocell in my office, so I just need to figure out what to look for, and how..., when my office mates are not there. :D
To be clear, we identified the IDs in FemtoCatcher by reverse engineering Verizon's ROM that included logic to display a different icon if it was connected to a femtocell. So we're pretty confident in that for that reason. If you can find an AT&T ROM that displays a different icon if it's attached to a femtocell, and reverse it, that would give you the same detection for AT&T. Rinse and repeat for every carrier who has a femtocell you can get access to.
However, these IDs can be spoofed: they're just values assigned by the tower. We didn't look into how difficult it would be to change them on the femtocell. It may not be worth it to invest loads of time into detecting this, as opposed to looking at things that can't be spoofed (like ciphersuite in use) or things more difficult to spoof.
@tomrittervg The "id's" used for detection are they available in typical service menus, i.e. those showing some details of the connection? If so, I could just check with the FC I have here for example. I guess in your case it was a CDMA FC, AFAICR? So what should we look for in a non-CDMA FC?
BTW. Would you know id those NID ranges (above) are assigned by Manufacturer or the operator?
As far as being available in service menus - it's going to vary on a handset basis. Maybe. But you can just write an app to query the values for GSM like we did for CDMA. A quick google shows results like: http://stackoverflow.com/questions/13294545/retrieve-cell-towers-information
You'll probably see a unique-ish identifier for the Femtocell than for the Normal Tower. https://play.google.com/store/apps/details?id=cellmapper.net.cellmapper can record 'normal' towers you see (I think) and let you build a baseline for comparison...
@tomrittervg, just for my own clarification: How did you (respectively @iSECPartners) obtain the CDMA values? Did you obtain them with some special program which you ran on a real femtocell? If there's anything else I can do with my phone (HTC One) to obtain the values for GSM femtocells, let me know!
When you say CDMA values, do you mean the identifiers that correlate to a femtocell? If so:
To be clear, we identified the IDs in FemtoCatcher by reverse engineering Verizon's ROM that included logic to display a different icon if it was connected to a femtocell.
Or do you mean the CDMA values of the tower we're currently connected to? If so: Look at mTelephonyManager around https://github.com/iSECPartners/femtocatcher/blob/master/src/com/isecpartners/femtocatcher/MainActivity.java#L162
@tomrittervg, I meant how you found the values to detect a FemtoCell in the CDMA network. As stated in this conversation, our App cannot detect FemtoCells in GSM networks yet, because we're missing the identifiers for GSM. We know the following applies to CDMA FemtoCatchers:
private int FEMTO_NID_MIN = 0xfa;
private int FEMTO_NID_MAX = 0xff;
Converting to int from hex gives MIN = 250 MAX = 255 Femtocatcher then compares the CDMACellLocation NetworkID to see if it falls within this range, if so it identifies the cell as a femtocell and will then take action.
You and @iSECPartners reverse engineered Verizon's ROM, and here you state that this process would have to be done on every single Carrier. Does that mean that we cannot write and implement code to detect FemtoCells on all networks out there?
I already crawled the Interwebz a while ago and found this paragraph here:
In the case of CDMA, the unique ID consist of MCC (Mobile Country Code), SID (System ID), NID (Network ID), and BID (Base Station ID). For GSM the unique ID consists of MCC (Mobile Country Code), MNC (Mobile Network Code), LAC (Location Area Code), and CID (Cell ID)
As you already stated, using CellMapper to build a baseline of normal towers and then writing an App to query the GSM values would be the "easiest" way. But it appears we're still stuck on this. Not sure you already read this, but actually @E3V3A has stated that he's got a FemtoCell in his office and would just have to run a few tests, I guess. So what would be the most convenient approach for him to catch the values we need, without being detected by his colleagues? Do you have further recommendations?
@tomrittervg & @SecUpwN Yes, I think that is the problem with femto/pico cells in GSM/UMTS/LTE what-have-you networks, in general there are no obvious way to tell if a CID is a femtocell. Also each type would probably have its own way of showing this. But I haven't looked into the RF/Radio TAP messages either, and its quite possible that a femto/pico cell would give up additional information when transmitting its presence. The problem with testing on my femtocell is that it is using a different service provider than what I use, while not offering non-subscriber SIMs OTC. We definitely need to look closer on this. We need to fill in the blanks of what minimum information can be obtained vs required to identify a connection as a pico or femto-cell.
| Network Type | Smallest ID | Value (hex) | Other Notes |
|---|---|---|---|
| CDMA | NID | fa:ff | What about BID? |
| GSM | CID | ? | (maybe other identifiers in L1-2 messages)? |
| UMTS | ? | ? | |
| LTE | ? | ? |
Does that mean that we cannot write and implement code to detect FemtoCells on all networks out there?
No, sure you can, you just have to get the data needed to detect somehow.
So what would be the most convenient approach for him to catch the values we need, without being detected by his colleagues?
The problem with testing on my femtocell is that it is using a different service provider than what I use, while not offering non-subscriber SIMs OTC.
- Just write an app for GSM (or use CellMapper) to grab the MCC/MNC/LAC/CID. Attach the phone to every femtocell you can find for every carrier you can find and record the data. Then log the 'normal' towers you see and double check there's no overlap.
Those (femtocell) values should give you good detection with low or none false positives. But it might have false negatives, because there are femtocell IDs in other parts of the world you didn't see.
- Use a AT&T/Carrier branded phone/ROM. Connect it to their femtocell. See if you get a special icon. If you do, reverse the ROM and you'll get as perfect false positive and false negative rates as you could possibly expect.
@tomrittervg Please confirm. When you say the "special icon" I assume it on the phone and not on the "femtocell device"? So we need people with branded phones like AT&T and Verizon to test this. Damn we need a list of all femto/pico cell service providers...
Yes, the special icon, if it exists (it's not guaranteed to), is on the phone. For Verizon it looks like a little house: http://forums.androidcentral.com/attachments/verizon-samsung-galaxy-s4/77212d1377040249t-little-house-icon-1377040248438.jpg
And you don't need branded phones for everything, Googling for 'AT&T microcell icon phone' is leading me to think that an iPhone will display "AT&T M-Cell": http://scottfillmer.com/2010/08/20/att-microcell-more-like-bad-skype-call-than-cell-tower/ That's actually, probably, the cell tower name that's set and broadcast.
Why do we want to detect femtocells? If there's one thing we can be sure
of, it's that if the femtocell does anything different to a macrocell, an
IMSI catcher based on femto hardware will certainly NOT do that. It's like
relying on the evil bit.
On Tue, Jun 17, 2014 at 7:32 PM, Tom Ritter notifications@github.com
wrote:
Yes, the special icon, if it exists (it's not guaranteed to), is on the
phone. For Verizon it looks like a little house:
http://forums.androidcentral.com/attachments/verizon-samsung-galaxy-s4/77212d1377040249t-little-house-icon-1377040248438.jpgAnd you don't need branded phones for everything, Googling for 'AT&T
microcell icon phone' is leading me to think that an iPhone will display
"AT&T M-Cell":
http://scottfillmer.com/2010/08/20/att-microcell-more-like-bad-skype-call-than-cell-tower/
That's actually, probably, the cell tower name that's set and broadcast.—
Reply to this email directly or view it on GitHub
#6 (comment)
.
Why do we want to detect femtocells?
Because we also want to inform users of our App if they are connected to one. Traffic Interception and remote Mobile Phone Cloning with a Compromised CDMA Femtocell is not a cool thing..
No, but the fundamental exploit we're trying to detect is "a BTS spoofs as
another BTS to carry out a man-in-the-middle attack". This has nothing to
do with femtocells as such, and an attacker trying to spoof a macrocell
using femto hardware cannot be expected to co-operate by telling us that
they're using a femtocell.
Because there are a lot more femtocells than there are attackers, a
rational, Bayesian user would take an alert to be evidence they weren't
being attacked. A normal human one would just learn to ignore the alerts,
making the app useless. Anyone who is actually worried about being targeted
by IMSI-Catchers has plenty to do without trying to resolve false positives.
I also think you need to decide whether you want an app that reports a
variety of engineering data about the cellular network, or an app that
detects IMSI catchers. The requirements are quite different.
On Wed, Jun 18, 2014 at 4:28 PM, SecUpwN notifications@github.com wrote:
Why do we want to detect femtocells?
Because we also want to inform users of our App if they are connected to
one. Traffic Interception and remote Mobile Phone Cloning with a
Compromised CDMA Femtocell https://www.youtube.com/watch?v=gfcq8clu1RI
is not a cool thing..—
Reply to this email directly or view it on GitHub
#6 (comment)
.
Thanks for your input, @AlexHarrowell. What do you think, @E3V3A? Shall we completely remove FemtoCell detection and focus on our main objective? In my personal point of view, we're not focusing on FemtoCell detection, but rather on conveniently detecting IMSI-Catcher attacks. But when we have the possibility of warning a user if he really connected to a FemtoCell, why not add it?
Maybe we should inform about FemtoCells - and not warn. But there is another interesting point in your message @AlexHarrowell
I also think you need to decide whether you want an app that reports a variety of engineering data about the cellular network, or an app that detects IMSI-Catchers.
Q: @AlexHarrowell
We need some data for detection, you think we should focus on something special? And what info we are looking for would be useless? Beside the FemtoCell discussion?
Yes, thank you @AlexHarrowell. I agree with you, more or less completely, but since we have already incorporated the Verizon FemtoCell detection, I think it will have to remain, and we can choose to expand on it later if necessary or interesting, like the paper linked by @SecUpwN . However, right now, priority one is to stay focused to detect a fake BTS. One does not exclude the other, and the reason is that we are using a set of parameters, to generate a detection score. So this is not a simple Boolean operation, or presentation, which is why we have many different colors for the icons... As we solve the data collection issues (BTS location, AT, ServiceMenu RF items), the next step is to come up with a good algorithm for detecting a fake BTS among all the neighboring cells (which also include FemtoCells). So that is why we're so concerned with FemtoCells. If we don't understand FemtoCells, we will probably not understand MacroCells either.
For what it's worth, I agree with @AlexHarrowell - as I've stated much earlier it's (almost certainly) possible to change the values the femtocell reports - we didn't look into how hard that would be.
@tomrittervg That is fine, but I could also imagine creating a femtocell blacklist, that is automatically downloaded and updated on a per-country basis. TAG: in-the-future.
I just tossing in this relatively new Femtocell-Networks-Simulation-Platform by @Zehua-Zeng as well as AHWireless, an NS3 Implementation of an Ad-Hoc FemtoCell network within a larger LTE macrocell by @mbryk. Couldn't find variables to further fill out this table though. Maybe someone else finds more?
@E3V3A, I've added this Issue to our Detection List. Please check if DB_id is valid like I did it. Thanks!
@SecUpwN Is it worth updating https://github.com/SecUpwN/Android-IMSI-Catcher-Detector/wiki/Similar-Projects (Software Projects section) with the results of https://www.google.com/search?q=gsm+femtocell+detect ?
The specific results I'd think are relevant are:
https://play.google.com/store/apps/details?id=com.neutona.mobile.smallcelldetector
https://play.google.com/store/apps/details?id=com.bluejaysystools.mobilecrush (Oops, this is a game, in spite of the icon ;)
https://play.google.com/store/apps/details?id=bluejaysoftware.b4a.utility.femtowidgetlite
https://play.google.com/store/apps/details?id=bluejaysoftware.b4a.utility.femtowidget
https://play.google.com/store/apps/details?id=bluejaysoftware.b4a.utility.femtowidgetpro
These are all officially commercial, but do seem to have worked with GSM femtocells. (The last 4 are from the same developer.) Would it even be worth to contact them?
(This comment is re: your note to me from #457 about helping this issue.… ☺)
i was checking your links and found this. A RF Analyser APP that works with a cheap RTL-SDR over USB. This could be a serios solution for some of our hardest problems.
https://play.google.com/store/apps/details?id=com.mantz_it.rfanalyzer
So for GSM/UMTS femtocells, we have to map each countries operators LAC's to what they reserve for their femtocells, at least if we're to believe this:
So this would make it very easy for us! Similarly, for CDMA (if it's only about the NID) we can skip the old femtocell detection code/part, and just use our collected DB to determine what we're on.
Also pay attention to another very related Google bug that was closed without explanation and shown to be still valid. This may also explain some weird behavior I've seen on my UMTS network..
@TPS, thank you very much for your valuable contributions here. I just notified those developers. ;-)
@SecUpwN Since most of everything else I've attempted to contribute has seemed to be extraneous, I hesitated to even post the above when I thought this up last week (seems so obvious to attempt in retrospect, doesn't it, but Google does seem to continue to improve some parts of what they do to find stuff [I do understand the sentiment is unpopular here ;]), but I scoured the site docs & couldn't find any references to these.
I'm just glad I'm helping, for once! ☺
@He3556 You should know that https://play.google.com/store/apps/details?id=com.mantz_it.rfanalyzer is GPL ≥2, in spite of being paid on Play, with source @ https://github.com/demantz/RFAnalyzer ☺
A Femtocell is also a special case and depends on the different providers.
So we had a long way getting a list or something, to be able to detect them.
A nice to have - but in general a Femtocell must not be a security problem.
If there are other projects doing this - we could implement a working solution at a later time.
So we had a long way getting a list or something, to be able to detect them.
we could implement a working solution at a later time.
And... in both cases it shouldn't be closed.
I have to second @agilob
We have choosen to take care of Femtocell and also invested to much time to throw it all away!
We have choosen to take care of Femtocell and also invested to much time to throw it all away!
Indeed, I agree on this. But I am wondering how we're going to solve this Issue of we chose to make AIMSICD prompt that it only supports GSM networks as discussed in #489 while at the same time we only have code for CDMA FemtoCells in our app since the ones for GSM are missing - crazy loophole here.
Hi, @SecUpwN id like to contact you im very interested in financing your project please let me know if you are free and interested about it still thanks. i couldnt find a direct way to contact you my email is javigc3@gmail.com thanks