TinyCheck: Easily capture network communications coming from a smartphone | Hacker News Reader

TinyCheck: Easily capture network communications coming from a smartphone

github.com

217 pointssciurus52 comments

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

Maybe they meant easy as "once you have this setup, capturing traffic from this point forward becomes easy".

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?

It's going to be the ability to act as an AP and a client at the same time. Frequently this means two physical devices.

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.

Simultaneous AP/Managed mode is available on RPI3 and RPI Zero W boards, I'm not sure about the others models.

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.

By skimming the README, it looks like only one WiFi interface is really necessary so you can connect the smartphone to TinyCheck.

The other interface is to connect the TinyCheck box to the internet, so it could well be a wired connection.

I suspect that if your WiFi device can support AP and client mode simultaneously it should work just as well.

Problem is it is not mac or w10. Get a device setup ... may still try as lots of those around.

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

I read it as capture data coming __from__ your smartphone.

Yep. I've edited the title to make that clearer.

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.

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.

I believe the author is suggesting that it’s more common than one would think.

I (parent comment) also like the idea, it sounds cool and useful - I just think it's rather more complicated than indicated by the original lead text.

It would definitely be nice to see it deployable in a quick and easy way for less tech savvy users.

Only Wi-Fi, no SSL.

Some info only goes cellular, the only way to capture that is using a hotspot which simulates the normal network.

The real sneaky spyware I found only goes over cellular and hides itself by using double encrypted SSL traffic to AWS endpoints.

What if we disable mobile data and keep WiFi on... Would those sneaky traffic not go?

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.

That is super-sneaky

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.

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.

"double encrypted SSL"

Not sure if serious ...

I think they mean that AWS acts as a proxy and only terminates the outer layer.

Wouldn't it be pretty easy to fingerprint a TLS session that always starts with another TLS handshake?

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.

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.

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

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

If the device is rooted, tcpdump is also an option.

NetGuard is a great utility in general.

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.

This doesn't appear to do any SSL interception unfortunately.

This plus a Frida [1] script or two would be amazing.

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.

Yeah. Malware analysts and API reverse engineers are probably quite comfortable with rooting phones and using Frida or equivalents already.

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.

Tools like burp suite and charles proxy make it fairly easy, but some companies like Apple pin the CA. I’m not sure of the best approach there.

What is the difference between this and Burp Proxy, Fiddler or Wireshark?

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.

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.

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.

Use virtual box and run kali with hardware pass through

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

If I understand correctly, this can't be used on OpenWRT right?

What would be required to make that happen?

The server is a python script, why couldn't it run on OpenWRT?

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?

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.

https://github.com/KasperskyLab/TinyCheck/blob/main/analysis...

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.

Reply on news.ycombinator.com