Bypassing com.android.okhttp.internal.io.RealConnection->connectTls (automatic exception patch)

Came across your article on how to defeat pinning with Frida and I’m trying to work my way through it as I’m a bit of newb, but I’m tryin!

For some context, I’m running Windows 10, an Android Pixel XL emulator, and OWASP ZAP as my proxy. I’ve installed the OWASP certificate onto the device, and I can now parse HTTPS traffic from the Chrome app. I’m wanting to now intercept traffic via apps!

I’m using the dating app Bumble as my first “target”, so I’ve installed the APK file onto the device (which does NOT have Google Play Store as I’ve read that’s important). I have the Frida server running in one terminal window as root (running frida-server-15.1.22-android-x86 which I don’t know for sure if that’s the correct server to be running, maybe x86_64 should be run instead? Anyway…)

So I fire up the App, where it just hangs on the main loading screen and I do not see any traffic from it in OWASP (again, even though it IS proxying internet requests fine, so that part IS working):

…and in a separate terminal window, I run the command:

frida --no-pause -U -l ./frida-script.js -f com.bumble.app

…and this is my resulting output (beware, it’s long, and the trailing end just infinitely prints until the frida server dies):

frida --no-pause -U -l ./frida-script.js -f com.bumble.app
     ____
    / _  |   Frida 15.1.22 - A world-class dynamic instrumentation toolkit
   | (_| |
    > _  |   Commands:
   /_/ |_|       help      -> Displays the help system
   . . . .       object?   -> Display information about 'object'
   . . . .       exit/quit -> Exit
   . . . .
   . . . .   More info at https://frida.re/docs/home/
   . . . .
   . . . .   Connected to Android Emulator 5554 (id=emulator-5554)
Spawned `com.bumble.app`. Resuming main thread!
[Android Emulator 5554::com.bumble.app ]-> ---
Unpinning Android app...
[+] SSLPeerUnverifiedException auto-patcher
[+] HttpsURLConnection (setDefaultHostnameVerifier)
[+] HttpsURLConnection (setSSLSocketFactory)
[+] HttpsURLConnection (setHostnameVerifier)
[+] SSLContext
[+] TrustManagerImpl
[ ] OkHTTPv3 (list)
[ ] OkHTTPv3 (cert)
[ ] OkHTTPv3 (cert array)
[ ] OkHTTPv3 ($okhttp)
[ ] Trustkit OkHostnameVerifier(SSLSession)
[ ] Trustkit OkHostnameVerifier(cert)
[ ] Trustkit PinningTrustManager
[ ] Appcelerator PinningTrustManager
[ ] OpenSSLSocketImpl Conscrypt
[ ] OpenSSLEngineSocketImpl Conscrypt
[ ] OpenSSLSocketImpl Apache Harmony
[ ] PhoneGap sslCertificateChecker
[ ] IBM MobileFirst pinTrustedCertificatePublicKey (string)
[ ] IBM MobileFirst pinTrustedCertificatePublicKey (string array)
[ ] IBM WorkLight HostNameVerifierWithCertificatePinning (SSLSocket)
[ ] IBM WorkLight HostNameVerifierWithCertificatePinning (cert)
[ ] IBM WorkLight HostNameVerifierWithCertificatePinning (string string)
[ ] IBM WorkLight HostNameVerifierWithCertificatePinning (SSLSession)
[ ] Conscrypt CertPinManager
[ ] CWAC-Netsecurity CertPinManager
[ ] Worklight Androidgap WLCertificatePinningPlugin
[ ] Netty FingerprintTrustManagerFactory
[ ] Squareup CertificatePinner (cert)
[ ] Squareup CertificatePinner (list)
[ ] Squareup OkHostnameVerifier (cert)
[ ] Squareup OkHostnameVerifier (SSLSession)
[+] Android WebViewClient (SslErrorHandler)
[ ] Android WebViewClient (WebResourceError)
[ ] Apache Cordova WebViewClient
[ ] Boye AbstractVerifier
Unpinning setup completed
---
  --> Bypassing Trustmanager (Android < 7) request
  --> Unexpected SSL verification failure, adding dynamic patch...
      Thrown by android.net.SSLCertificateSocketFactory->verifyHostname
      Attempting to patch automatically...
      [+] android.net.SSLCertificateSocketFactory->verifyHostname (automatic exception patch)
  --> Bypassing TrustManagerImpl checkTrusted
  --> Bypassing Trustmanager (Android < 7) request
  --> Bypassing android.net.SSLCertificateSocketFactory->verifyHostname (automatic exception patch)
  --> Bypassing TrustManagerImpl checkTrusted
  --> Bypassing TrustManagerImpl checkTrusted
  --> Unexpected SSL verification failure, adding dynamic patch...
  --> Bypassing TrustManagerImpl checkTrusted
  --> Unexpected SSL verification failure, adding dynamic patch...
      Thrown by com.android.okhttp.internal.io.RealConnection->connectTls
      Attempting to patch automatically...
      [+] com.android.okhttp.internal.io.RealConnection->connectTls (automatic exception patch)
      Thrown by com.android.okhttp.internal.io.RealConnection->connectTls
  --> Bypassing com.android.okhttp.internal.io.RealConnection->connectTls (automatic exception patch)
  --> Bypassing com.android.okhttp.internal.io.RealConnection->connectTls (automatic exception patch)
  --> Bypassing com.android.okhttp.internal.io.RealConnection->connectTls (automatic exception patch)
  --> Bypassing com.android.okhttp.internal.io.RealConnection->connectTls (automatic exception patch)
  --> Bypassing com.android.okhttp.internal.io.RealConnection->connectTls (automatic exception patch)
  --> Bypassing com.android.okhttp.internal.io.RealConnection->connectTls (automatic exception patch)
...........................

SO, what can a guy try from here? Would be cool to get some insight from the community on this one so I can get started on the app traffic track 😛 Thanks!!!

[pimterry]

Hard to tell any more from that, I’m afraid. Trying with Wireshark to look lower-level is probably a good move, although you’ll probably find everything involved is encrypted such that Wireshark can’t look at it, unfortunately.

I think my money is on this being non-HTTP traffic sent via TLS. In that case, there’s no way to view this with HTTP Toolkit - it’s just not HTTP at all. The certificate unpinning is firing for the TLS setup, so this non-HTTP traffic does trust your certificate and you can see tiny bits of its garbled messages in HTTP Toolkit, but not much more.

No idea what this non-HTTP protocol could be, but I’d be very interested if you do manage to find out! I think the next step would have to be building your own TLS proxy, manually examining the raw packets here, trying to work out what protocol it is, and then from there trying to handle that manually. If it’s something common then you can probably use an off-the-shelf implementation to accept the connection and reply or forward messages from there. No idea myself though, it’s nothing obviously recognizable.

Alternatively you might be able to run HTTP Toolkit’s internals manually, and then modify Mockttp to let you look and handle the raw packet data it receives, here: https://github.com/httptoolkit/mockttp/blob/5c82c16f898ebc19edb65ccfc54169140ccc4b40/src/server/mockttp-server.ts#L653-L658. That would let you use all the rest of HTTP Toolkit’s tools, but it’d take a little bit of setup to get it all working. None of these options are easy I’m afraid, sorry!

[pimterry]

Hmm, not sure! That is normally what you’d see if HTTP Toolkit receives non-HTTP traffic.

To explain a little: when HTTP Toolkit receives a connection, it keeps doing fake TLS handshakes (unwrapping any levels of proxying and direct HTTPS setup) until it receives something that’s not TLS, and then it assumes that it’s reached plain-text HTTP and tries to parse it as an HTTP request.

If that last step fails, you see something like this, where HTTP Toolkit gets something that should be an HTTP request, but it’s complete gibberish that it can’t parse so it just sends an error response.

It’s hard to know what could cause this. It could be a bug caused by certificate unpinning, or it could be that the Bumble app is using a non-HTTP protocol (wrapped in TLS - you can tell because there’s an https shown in the URL and the domain name from the requested certificate is shown). It’s a bit unusual to use anything but HTTP in mobile apps like this, but not unheard of.

Notably though, if it’s not HTTP then you can probably avoid intercepting this. In addition to setting the HTTP proxy on the device, which captures all well-behaved HTTP(S), HTTP Toolkit’s Android VPN also captures all TCP traffic on a few target ports. That lets you capture traffic that ignores proxy settings, but can capture unrelated traffic sometimes. The default ports used are defined here and there’s a button to configure the ports in the Android app when the app is connected. If this isn’t HTTP at all, then it should be ignoring the proxy settings, so if you remove the ports redirection there then these broken requests should stop appearing.

If they keep appearing, then this is coming from a client that is actively using the HTTP proxy settings. It they disappear, then it’s something that’s ignoring the HTTP proxy settings, which pretty strongly suggests it’s not HTTP at all.

Does that make sense?