Skip to content
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

Proposal: Mobile Network MiTM check (aka static IMSI-catcher detection) #106

Open
E3V3A opened this issue Dec 24, 2017 · 6 comments
Open
Milestone

Comments

@E3V3A
Copy link

E3V3A commented Dec 24, 2017

I propose to also implement a minimalistic mobile network sensor, by using the AOS API to collect various network parameters and indicate unreasonable changes. Such as sudden changes in:

  • signal strength
  • LAC/CID
  • Neighboring cells
  • and many other things depending on your hardware

Background:

Because Haven is meant to be a static/stationary environment detector, it is ideal to also detect changes in the mobile network. A few years back there were extensive research and development to implement an Android IMSI-catcher detector, culminating into the development of AIMSICD, unfortunately that project was later discontinued due to a year of broken code merges, lack of maintenance, overview, structure and understanding. There were even some attempts to code sabotage. Learning from that experience the project made a new attempt to make a highly structured and modularised version that is compatible with all devices (rooted or not) while having a very clear and simple development and maintenance plan, mAICD. (Pronounced "acid".) But due to lack of developer commitments, this is still in the infant stage even if a working prototype module could be easily implemented in a matter of weeks.

Why would this be needed in Haven?

Because Haven relies on your phone being continuously connected to the network and sending messages over SMS (mobile network) or Signal (mobile/wifi and data network), each being generally vulnerable to MiTM type attacks of various kinds. In fact, SMS should probably not be used at all since they are sent in clear-text and can be easily intercepted or spoofed.

Bonus

The modular implementation of mAICD could also be extended to checking for WiFi attacks as well.

Summary

If Haven is serious about detecting environmental intrusions, it also have to take the network environment into account. Meaning that Mobile, WiFi, Bluetooth and NFC etc. should also be monitored. The mobile network is the most obvious start for these.

@dazcode
Copy link
Contributor

dazcode commented Dec 25, 2017

How much of this functionality would work on a non-rooted phone?

@E3V3A
Copy link
Author

E3V3A commented Dec 25, 2017

Certainly the first 3 items. The extent of the non-root support depend on the API.

The rest may depend to various degrees on the OEM (SELinux) permissions and for full functionality (as from the list shown) you'd need both root and Qualcomm || MTK baseband hardware at the moment. The original idea of mAICD is to support as wide a variety of HW as possible.

@dazcode
Copy link
Contributor

dazcode commented Dec 26, 2017

You mentioned Wifi attacks, and this is interesting to me as I have seen first hand how easy it is to spoof an AP using the tools in Kali Linux. So if someone uses the tools provided in Kali Linux for example to set up a fake Wifi AP, would this be effective against that? If yes, how exactly does that work?

Example: https://arstechnica.com/information-technology/2014/06/free-wi-fi-from-xfinity-and-att-also-frees-you-to-be-hacked/

@n8fr8
Copy link
Member

n8fr8 commented Dec 26, 2017

This is an interesting idea, as long as we keep it focused on user stories/scenarios that fit within what we are focused on with Haven. The idea that a stingray device, or similar mobile/cellular network interception or blocking tool, might be used as part of a physical intrusion, is definitely something to consider. The idea that an internet connection via the local wifi hotspot, might be severed or MITM'd is also interesting.

As long as we can find a simple way to detect a change in state that seems malicious, and to not have a great deal of false positives, then I am for exploring this functionality.

@E3V3A
Copy link
Author

E3V3A commented Dec 27, 2017

@dazcode

would this be effective against that?

How effective it would be, all depend to some extent how well the MiTM was setup (and it's proximity).
That said, with a continuous monitoring of Android equivalent quantities to what can be found from iwconfig wlan0, such as:

  • ESSID
  • BSSID
  • Signal Level [dB]
  • TX power
  • Bit Rate
  • and many others

These should be more than enough to get a picture of the local radio environment. If there are sudden disturbances in signal quality (when nobody is around), that would indicate someone may be executing an attack. When this info is combined with ping times and ARP spoof detection, it may be a strong indicator for a MiTM attack.

The relevant Android API framework parts can be found here:

https://developer.android.com/reference/android/net/wifi/package-summary.html
https://developer.android.com/reference/android/net/wifi/ScanResult.html
https://developer.android.com/reference/android/net/wifi/WifiInfo.html
https://developer.android.com/reference/android/net/wifi/WifiManager.html
https://developer.android.com/reference/android/net/wifi/SupplicantState.html

One can also monitor from a non-rooted shell via: cat /proc/net/wireless |grep wlan0 to get link stats.

@E3V3A
Copy link
Author

E3V3A commented Dec 28, 2017

Having looked over these, it seem that the best way to go about this, is to divide this "issue" into two new developer ones. One for WiFi attacks and the other for mobile network attacks.

Also, for those who may wonder. Bluetooth and NFC etc are redundant for the apps use, so should be best left out and turned off completely. (We need mobile network attack detection, for those who has a SIM card and want to use the mobile data for connections. For those who doesn't we use WiFi.)

@n8fr8 n8fr8 added this to the The Future! milestone Jan 12, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants