TinyCheck allows you to easily capture network communications from a smartphone
Somewhat disappointingly (and different to my understanding of "easily" and "from a smartphone") followed further down by:
In order to make it working, you need a computer with a Debian-like operating system and two Wi-Fi interfaces. The best choice is to use a Raspberry Pi (3+) with a Wi-Fi dongle and a small touch screen...
The History section of the git README explains it well, and why that design/architecture choice is a good one for the intended use case:
"The idea of TinyCheck came to me in a meeting about stalkerware with a French women's shelter. During this meeting we talked about how to easily detect easily stalkerware without installing very technical apps nor doing forensic analysis on them. The initial concept was to develop a tiny kiosk device based on Raspberry Pi which can be used by non-tech people to test their smartphones against malicious communications issued by stalkerware or any spyware."
I think it's a great idea. I'm going to check in with a friend who has to deal with stalker ware-infected phones at a womens shelter she volunteers at to see if they'd like me to build/send them one.
By "two wifi interfaces" do they mean "two physical wifi cards/chips/dongles"? Put differently, is an "interface" defined in terms of hardware or software?
I bet it'd be pretty easy to make it work using a RaspberryPi's on board wifi and an ethernet cable to the router.
Dual wifi makes for easier installation/operation in a lot of situations though, so I think its a good "default config". If there's already a wifi network people can use, hooking one wifi chipset to that then connecting the phones under test to an access point broadcast by the other - is easier than expecting there to be a live ethernet port and someone at a womens shelter-style-place having access to it and skills to use it.
I have often setup similar devices for R&D at work, using Hostapd to create an AP using Pis internal WiFi and ethernet uplink. I find though that it's usually better to use an external WiFi device such as an Alfa.
This should be fairly simple too so long as there's no arbitrary restriction on requiring wlan devices preventing you from using WiFi+Ethernet rather than Wifi+Wifi.
Rpi has capability of being simultaneously an access point for your device and a bridge towards another wifi network but in my tests on RPi3 it was unstable. Better use wifi and cable
You can also do a mitm with two wifi enabled raspberry pies or Linux computers by mapping the network block device of one machine over nfs to the one performing the attack.
I wonder how practical it would be to add something like a limeSDR/USRP/HackRF to a tinycheck to be able to at least detect this. I doubt it would be affordable for most individuals but I could see cost justification for orgs.
If you don’t want to change SIM cards, you cold go to 2G and easily create a fake base station and disable 3G/4G on the phone. For 4G, it‘s a bit more tricky as you need to do a relay attack (https://alter-attack.net/) and even then only do some DNS redirection if you know what host is being looked up, or some fingerprinting based on the size of the traffic.
Of course, you can also just check if the phone sends something by looking at the RF energy or even build an uplink decoder, but I doubt that this is very useful information by itself for this use case.
Finally, what I propose instead, is to use a private LTE network, which you can create using a SDR and srsLTE and some programmable SIM cards, which you need to insert into the phone. This way, it‘s easily possible to view any traffic leaving the phone on any connection. Plus, srsLTE has been shown to work on Raspberry Pi as well (I think).
This one will buffer (to a certain extent) and only flush when cellular is on and cellular traffic is already occurring. When cellular is on but cellular data is disabled there is still cellular data traffic at OS level, I expect more advanced spyware will travel with that data-stream. Also that indicator and a switch is just software, if you have full control over the OS, you can change that.
When cellular data is disabled (assuming it really is, not just faked to the user), then the corresponding radio bearers for user plane data habe not been established, thus no data-stream can travel with it. You can only communicate with the eNb and MME in this stage, and even this isn’t exposed directly to the OS but embedded in the Chipset.
My assumption has always been that a clean phone in airplane mode but with WiFi enabled would not use the cellular radios at all. In that mode would a cell tower still be in communication with the phone at some level?
Not directly, as the flight mode really prevents any radio communication (it takes a bit to shut down as it sends a NAS Detach Request first and waits for a reply for a few seconds).
However, there is also WiFi Calling - in that sense, your phone establishes some connection with the cell network. However, I don‘t think any user data may travel on this bearer, but there might be some edge case where this is possible.
Certain BYOD email suites use https encapsulation of another protocol (also using TLS) to ensure that the data can go through firewalls that do MITM attacks on clients for security reasons. Bluecoat do this for example.
I believe they also certificate pin the tunneled protocol.
Well not easily, because once the outer TLS has been set up, you can‘t see the contents of the second TLS handshake. You could maybe deduce it via packet sizes and timings, but certainly not pretty easily.
An alternative without dedicated device (although I do redirect all traffic from wifi accesss point used for phone on router to another computer) and rather use it on device and analyze later:
https://github.com/M66B/NetGuard/releases
Btw, it is great application firewall too (it installs itself as vpn) and worth a donation (unless you build it yourself without a donation the pro features like packet capture wont be available).
I don't specialize in InfoSec work, but I was recently asked to do some pentesting/auditing for a mobile app without being given a debug build where I could add MITM certs, etc.
I wasn't familiar with the latest tooling, but I was able to accomplish this by running an Android Emulator on a low-ish version (5 I think) and using Burp suite.
This method seems like it will quickly become obsolete. Going forward will the only way to accomplish this type of work be via rooting the device?
It depends on a few factors; is the application pinning certificates? If not, can you load a CA onto the device. If not, can you issue a trusted cert to your MITM proxy?
Then you get into modifying the application itself by patching out checks, replacing embedded certs...
It's also very handy to have a rooted device or emulator to hand too for times when you might want to poke around in the private storage of an app.
SSL interception has become much harder recently. Android apps need to be specifically compiled to allow them to use mitm ssl certs, and more and more apps are using pinned certs anyway (mostly following some corp/gov "best practice" security checklist I suspect).
I think their indicators of compromise (IoC) list is probably a pretty good alternative for their intended use case. I wouldn't want to be relying on this to protect me against state level actors, but I could easily see their IoC list being capable of detecting the sort of tools readily available to jilted ex boyfriends or abusive husbands.
Yes, for the stated use case. For malware analysis or analysing apps to create interoperable solutions, probably the only solution is a rooted phone and something like Frida.
Slightly off-topic. I was thinking if people can enforce a model where users can choose to delegate encryption work to OS or some kind of network gateway, and inspection is allowed before encryption happens, this would be a clean and built-in solution for the inspection issue.
I wonder how easy it would be to add an SSL MitM to further understand what traffic is coming from the device? Seems like plenty of attacks could slip through if they are using SSL and a reasonably issued certificate.
This repo includes a preset opinionated list of IoC (indicators of compromise), designed to aid non-technical smartphone owners in understanding what kind of problematic traffic is coming from their device, if any.
Those tools are intended for professional use. Furthermore even if you know how to use them, they all require configuration to produce any useful information.
As the author describes, this was inspired by a need for non-technical users to look for signs of surveillance software on personal devices. I imagine this might also be useful even to people who know how to use the aforementioned tools.
Looks very interesting. I wanted to try it out on my laptop but it's clear that you can't run this program without majorly messing up your system configuration in some way or another.
Does anyone here know an easy way to maybe run this in a limited context, such as in Docker or LXC? I don't feel like having a script modify my systemd services+dhcp config+network adapters but I'm also very curious to try it out.
I have run hostapd in a Docker container on a laptop for perform this kind of work. It's not extremely complicated, but hard enough that if you need to ask, it's worth trying an alternative approach (such as a VM with passthrough of a USB WiFi adapter).
The whole package can't, but all you really need is analysis/analysis.py. The analysis operates on .pcap files, so if you opkg install tcpdump on your router, you can run tcpdump over ssh and analyze the resulting pcap file on your workstation.
Maybe it could! That was just the impression I got skimming the readme, specifically the talk of two wifi interfaces.
It seems to assume it is in-between your phone and your wireless router, so putting it on the wireless router would require some changes. My question was really what are those changes?
Why was this not implemented as a smartphone app ? Even if it is meant to used in kiosk mode, cost should not be a factor as < 50$ phones are available.
Somewhat disappointingly (and different to my understanding of "easily" and "from a smartphone") followed further down by:
In order to make it working, you need a computer with a Debian-like operating system and two Wi-Fi interfaces. The best choice is to use a Raspberry Pi (3+) with a Wi-Fi dongle and a small touch screen...