Femtocell detection & protection

[SecUpwN]

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.

[xLaMbChOpSx]

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.

[SecUpwN]

@xLaMbChOpSx, sounds awesome! Please let me know if you need any other data for adding this.

[E3V3A]

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...

[SecUpwN]

@E3V3A, there's no public way to obtain these, right? We'd need a whisteblower leaking them..

[E3V3A]

No I don't think so. But we have to dig into their documentation, if we can find any...

[SecUpwN]

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?

[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.

[SecUpwN]

@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?

[xLaMbChOpSx]

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.

[SecUpwN]

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?

[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.

[SecUpwN]

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. 😸

[rjh427]

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.