CVE-2018-20200: CertificatePinner.java allows man-in-the-middle attackers to bypass certificate pinning

[carnil]

Apparently there was CVE-2018-20200 for an issue described as

CertificatePinner.java in OkHttp 3.x through 3.12.0 allows man-in-the-middle attackers to bypass certificate pinning by changing SSLContext and the boolean values while hooking the application.

A report is at https://cxsecurity.com/issue/WLB-2018120252 was this forwarded already?

[yschimke]

Ok. So seems fairly well contained. If you have control of the device you can affect the application runtime to allow sniffing the secure traffic. FWIW at this point you could probably also intercept the requests on the phone and upload to your own server.

The report seems real but mainly an attack against an App developer by a security researcher. Or someone running a rooted device will be susceptible also.

_{Sent with GitHawk}

[swankjesse]

It's not an interesting attack if it requires you to inject code into the process. The attacker must have already obtained complete access. The report is just guidance for attackers to exercise their control over a defeated process.

It's annoying that there’s a CVE for this because there’s no useful action to take. We can’t even obfuscate the code because API signatures are sufficient.

Imagine a report claiming “the toaster is a useful place to put eavesdropping equipment” in a house you've already gained full access to. You shouldn’t immediately toss out your toaster, or even design new toasters to defend against listening devices being added.

No action to take on this.

[yschimke]

It’s mainly interesting in so far as corporate infosec teams stimied in deploying corp certs to Hack their own employees might do similar.

_{Sent with GitHawk}

[carnil]

Thanks all for the quick turnarounds. So maybe the CVE should be asked to be rejected or at least disputed.

[mschwaig]

In my opinion the Pinning works as well as expected/possible. It creates a situation where it is not sufficient to

• install a root certificate on the client and
• install a proxy somewhere on the network between the client and the TLS server

to MITM a connection.

The attacker additionally has to modify/hook the client application or the environment it is running in.

If you are an application developer concerned about this CVE specifically:

This is only one of many ways how an attacker could modify the client application to get a similar level of access.
There is no way to 'fix' this issue, as this kind of thing is always possible, but as a mitigation you can make it difficult to execute by

• obfuscating you code well, including OkHttp and
• verifying the integrity of your environment/app using
  • Attestation APIs like SafetyNet API on Android or
  • commercial tools.

However, make sure to prioritize your security work since you could sink infinite time/money into this topic, while it might very well be a non-issue for your project.

EDIT: Hope it is OK that I offered some advice here. I think the pinning support in OkHttp is a great feature, because it simplifies the process so much. Thanks!

[yschimke]

FWIW this class of CVE (access to a rooted phone, or sideload a modified app binary, debug running app with AS) isn't novel to OkHttp here.

It's freaking cool and interesting, but isn't something that OkHttp can successfully try to guard against.

Personally I've posted example code that does similar for server type usage of OkHttp, injecting into a running process via Java agents

https://github.com/yschimke/agentdebug/

And a sample in OkHttp codebase for example Wireshark keylogging.

https://github.com/square/okhttp/blob/master/samples/guide/src/main/java/okhttp3/recipes/kt/WiresharkExample.kt

@mschwaig Thanks for the awesome analysis, @swankjesse and myself have been talking about Android Device attestation coincidentally recently, this seems like something that any app used in a financial context should consider how to apply.