5 ms·

I always find it highly ironic that I can trivially MitM my non-jailbroken iPhone to inspect app traffic (unless the app uses cert pinning), but MitM'ing on a n

by oefrha 4y ago

I always find it highly ironic that I can trivially MitM my non-jailbroken iPhone to inspect app traffic (unless the app uses cert pinning), but MitM'ing on a non-jailbroken Android phone is a huge pain in the ass, basically impossible without patching binaries (please correct me if I'm wrong).

codys 4y ago
what tools/methods exist for MitM-ing iphone traffic in this case?
- oefrha 4y ago
  Any tool? Install a profile, enable your cert, set a proxy, off you go. Charles, mitmproxy, Fiddler, whatever you prefer.
bspammer 4y ago
On the other hand if the app does use cert pinning, it's much easier on Android because we have https://github.com/shroudedcode/apk-mitm https://github.com/shroudedcode/apk-mitm
- oefrha 4y ago
  That’s true.
- xg15 4y ago
  If you're already patching the APK, couldn't you also patch it to trust the user store, even if the app doesn't use cert pinning?
jeroenhd 4y ago
Loading certificates into the phone is as easy as opening the files. The problem here is that Android apps have to opt in to loading user-imported certificates. Chrome and many other browsers will load these certificates just fine if you install them the official way. Apps that specify they trust the user store will also load them without any issues. The method that's now broken fails because the author is using a workaround: with root permissions, the system store can be altered, which apps do trust by default. Chrome, however, is following best practices and enforces that certificates are logged in the certificate transparency log. This isn't done for user-imported certificates for obvious reasons, but it's applied to system certificates to prevent rogue CAs from faking certificates without exposing themselves to the world. This means the workaround no longer works, or at least not as easily. There are still workarounds to fix the workaround, like the flags the author suggests here. It was never a supported way of doing things and unsupported workarounds are bound to break at some point. I don't know how iOS deals with certificates, I suspect it's something sensible when the normal API is used (opt-out of user certificates, that is). However, apps like social media and messengers will often include certificate pinning that is impossible to get around without jailbreaks + modifying runtime code through tools like Frida. They include the hash of their (intermediary) certificates in the application itself and validate that the chain is signed by a valid certificate with that specific hash. That way, a malicious certificate authority can give out a "valid" certificate that's useless for MitM-ing your app's users!
- oefrha 4y ago
  > The problem here is that Android apps have to opt in to loading user-imported certificates. Yes, but since Android N introduced this change, I haven’t met a single non-browser app that opted in to trusting the user store, or offered an option to do that. Maybe some enterprise apps do that? So it’s practically broken for any non-browser app; as for browsers I’ll just use a desktop one...
- thrdbndndn 4y ago
  Ah, thanks for the detailed explanation. Have been wondering this for a while. So if I read it correctly the major difference between the two platform is the opt-in/out part. On iOS I can sniffer some random small apps trivially, since most of them don't enable pinning; on the other hand for android it's default on ( so I have to manually patch the apks everytime. IIRC "have to opt in to loading user-imported certificates" wasn't the case a few generations of Android ago, correct?
  - jeroenhd 4y ago
    Correct, this changed in Android 7.
- feanaro 4y ago
  Frankly, it doesn't matter why exactly they've broken it. What matters is that it is broken, with no easy way to intercept traffic for all apps. This is an extremely user hostile position from Android and Google which is clearly meant to remove oversight over what apps send from the hands of the computer owner. I have no doubt they'll continue this cat-and-mouse game of trying to make it impossible to see the traffic generated by your own device. Now this is something the EU should work on changing instead of trying to dismantle E2E encryption.
  - zozbot234 4y ago
    This thread is simply about a user-visible warning screen in Chrome. It has nothing to do with apps, etc. And the warning looks like it's skippable, since it has an "Advanced…" option. Not sure how this is supposed to impact dev workflows or be user-hostile in any way.
Melatonic 4y ago
Don't tons of apps now use cert pinning though?

by oefrha 4y ago

codys 4y ago

what tools/methods exist for MitM-ing iphone traffic in this case?

oefrha 4y ago
Any tool? Install a profile, enable your cert, set a proxy, off you go. Charles, mitmproxy, Fiddler, whatever you prefer.

bspammer 4y ago

On the other hand if the app does use cert pinning, it's much easier on Android because we have https://github.com/shroudedcode/apk-mitm https://github.com/shroudedcode/apk-mitm

oefrha 4y ago
That’s true.
xg15 4y ago
If you're already patching the APK, couldn't you also patch it to trust the user store, even if the app doesn't use cert pinning?

jeroenhd 4y ago

Loading certificates into the phone is as easy as opening the files. The problem here is that Android apps have to opt in to loading user-imported certificates. Chrome and many other browsers will load these certificates just fine if you install them the official way. Apps that specify they trust the user store will also load them without any issues. The method that's now broken fails because the author is using a workaround: with root permissions, the system store can be altered, which apps do trust by default. Chrome, however, is following best practices and enforces that certificates are logged in the certificate transparency log. This isn't done for user-imported certificates for obvious reasons, but it's applied to system certificates to prevent rogue CAs from faking certificates without exposing themselves to the world. This means the workaround no longer works, or at least not as easily. There are still workarounds to fix the workaround, like the flags the author suggests here. It was never a supported way of doing things and unsupported workarounds are bound to break at some point. I don't know how iOS deals with certificates, I suspect it's something sensible when the normal API is used (opt-out of user certificates, that is). However, apps like social media and messengers will often include certificate pinning that is impossible to get around without jailbreaks + modifying runtime code through tools like Frida. They include the hash of their (intermediary) certificates in the application itself and validate that the chain is signed by a valid certificate with that specific hash. That way, a malicious certificate authority can give out a "valid" certificate that's useless for MitM-ing your app's users!

oefrha 4y ago
> The problem here is that Android apps have to opt in to loading user-imported certificates. Yes, but since Android N introduced this change, I haven’t met a single non-browser app that opted in to trusting the user store, or offered an option to do that. Maybe some enterprise apps do that? So it’s practically broken for any non-browser app; as for browsers I’ll just use a desktop one...
thrdbndndn 4y ago
Ah, thanks for the detailed explanation. Have been wondering this for a while. So if I read it correctly the major difference between the two platform is the opt-in/out part. On iOS I can sniffer some random small apps trivially, since most of them don't enable pinning; on the other hand for android it's default on ( so I have to manually patch the apks everytime. IIRC "have to opt in to loading user-imported certificates" wasn't the case a few generations of Android ago, correct?
- jeroenhd 4y ago
  Correct, this changed in Android 7.
feanaro 4y ago
Frankly, it doesn't matter why exactly they've broken it. What matters is that it is broken, with no easy way to intercept traffic for all apps. This is an extremely user hostile position from Android and Google which is clearly meant to remove oversight over what apps send from the hands of the computer owner. I have no doubt they'll continue this cat-and-mouse game of trying to make it impossible to see the traffic generated by your own device. Now this is something the EU should work on changing instead of trying to dismantle E2E encryption.
- zozbot234 4y ago
  This thread is simply about a user-visible warning screen in Chrome. It has nothing to do with apps, etc. And the warning looks like it's skippable, since it has an "Advanced…" option. Not sure how this is supposed to impact dev workflows or be user-hostile in any way.

Melatonic 4y ago

Don't tons of apps now use cert pinning though?