-
Notifications
You must be signed in to change notification settings - Fork 949
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
Femtocell detection & protection #6
Comments
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:
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 PLMN list: |
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:
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:
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:
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:
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.
|
No, sure you can, you just have to get the data needed to detect somehow.
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.
|
Why do we want to detect femtocells? If there's one thing we can be sure On Tue, Jun 17, 2014 at 7:32 PM, Tom Ritter [email protected]
|
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 Because there are a lot more femtocells than there are attackers, a I also think you need to decide whether you want an app that reports a On Wed, Jun 18, 2014 at 4:28 PM, SecUpwN [email protected] wrote:
|
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
Q: @AlexHarrowell |
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 |
@SecUpwN You did great. |
@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
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 ☺ |
@He3556: I don't think this is solved!? |
A Femtocell is also a special case and depends on the different providers. |
And... in both cases it shouldn't be closed. |
I have to second @agilob |
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 [email protected] thanks |
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:
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.
The text was updated successfully, but these errors were encountered: