4 ms·

I'm not sure if this had been mitigated in the standard, but the pinning implementations I've seen used in Android apps rely on client-side (i.e. app) verificat

by spangry 11y ago

I'm not sure if this had been mitigated in the standard, but the pinning implementations I've seen used in Android apps rely on client-side (i.e. app) verification. It's an inconvenience, for sure, for someone trying to emulate the app (in order to connect to the server API). But it's not sufficient to stop a determined attacker with a bytecode decompiler. For instance: http://randywestergren.com/reverse-engineering-the-subway-android-app/ http://randywestergren.com/reverse-engineering-the-subway-an... EDIT: Just to clarify given the comment below (and downvotes...), I'm talking about a different attack scenario. Here's a decent source on some of pinning's weaknesses for your standard MITM scenario: https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning#Pinning_Gaps https://www.owasp.org/index.php/Certificate_and_Public_Key_P...

pfg 11y ago
I'm not sure I quite understand your point, but wouldn't an attacker with the ability to modify an app on someone's device have access to the plaintext anyway?
- spangry 11y ago
  Oh sorry, I probably should have been a little clearer. I'm thinking of a different attack scenario where the attacker wants to MITM your app to inspect traffic and utilise your server-side API for unintended purposes. So it looks like: Attacker --> Attacker's Phone --> App --> MITM proxy --> API/Server So you could use this to pull down real-estate listings from a real-estate app in an easily parsed format (usually JSON). Or write an app that pull down the odds from various sports betting app APIs, detects arbitrage opportunities and automatically places bets using their APIs... EDIT: Oh and on the plaintext thing, generally no. Most apps will use TLS for app-to-server comms. Pinning in this context means they bundle the cert (or signature) with their app. By the looks of this (http://security.stackexchange.com/questions/29988/what-is-certificate-pinning http://security.stackexchange.com/questions/29988/what-is-ce...) it's a similar story with chrome: they pre-bundle some signatures. The alternative is to pin on the first interaction, but this leaves you potentially vulnerable if an attacker is listening in on that first interaction. It also raises the question: what happens if the website needs to revoke and re-issue? Wouldn't pre-bundling mean you'd have to wait for the next browser update (and for out of band commms to have occurred between google and the website)?
  - pfg 11y ago
    Right, but the purpose of key pinning is to prevent a MitM from learning the plaintext, not Alice or Bob. There are any number of means an attacker could employ to reverse-engineer an API (decompilation, memory dumps, debuggers, ...). This is asking for more of a DRM-like solution (with all the issues that come with it).
  - dingsbumps 11y ago
    I might be misunderstanding you, but I don't think Public Key Pinning is intended to prevent this scenario at all. Public Key Pinning is a method for a client to authenticate a server. If you decompile the app and recompile it with the public key of your MITM server, the app would of course connect to your MITM server. Or, it seems to me, if you have that level of control over the client, you could just disable public key pinning checks completely.
tptacek 11y ago
In addition to the other comments on this subthread, a point I think is worth making: If you're providing both an app and a server for the app to talk to you, you control both ends of the TLS connection and can pin however you'd like; you're not limited to HPKP and key-continuity. Secure apps have been doing custom pins of TLS keys long before HPKP got rolled out.

by spangry 11y ago

pfg 11y ago

I'm not sure I quite understand your point, but wouldn't an attacker with the ability to modify an app on someone's device have access to the plaintext anyway?

spangry 11y ago
Oh sorry, I probably should have been a little clearer. I'm thinking of a different attack scenario where the attacker wants to MITM your app to inspect traffic and utilise your server-side API for unintended purposes. So it looks like: Attacker --> Attacker's Phone --> App --> MITM proxy --> API/Server So you could use this to pull down real-estate listings from a real-estate app in an easily parsed format (usually JSON). Or write an app that pull down the odds from various sports betting app APIs, detects arbitrage opportunities and automatically places bets using their APIs... EDIT: Oh and on the plaintext thing, generally no. Most apps will use TLS for app-to-server comms. Pinning in this context means they bundle the cert (or signature) with their app. By the looks of this (http://security.stackexchange.com/questions/29988/what-is-certificate-pinning http://security.stackexchange.com/questions/29988/what-is-ce...) it's a similar story with chrome: they pre-bundle some signatures. The alternative is to pin on the first interaction, but this leaves you potentially vulnerable if an attacker is listening in on that first interaction. It also raises the question: what happens if the website needs to revoke and re-issue? Wouldn't pre-bundling mean you'd have to wait for the next browser update (and for out of band commms to have occurred between google and the website)?
- pfg 11y ago
  Right, but the purpose of key pinning is to prevent a MitM from learning the plaintext, not Alice or Bob. There are any number of means an attacker could employ to reverse-engineer an API (decompilation, memory dumps, debuggers, ...). This is asking for more of a DRM-like solution (with all the issues that come with it).
- dingsbumps 11y ago
  I might be misunderstanding you, but I don't think Public Key Pinning is intended to prevent this scenario at all. Public Key Pinning is a method for a client to authenticate a server. If you decompile the app and recompile it with the public key of your MITM server, the app would of course connect to your MITM server. Or, it seems to me, if you have that level of control over the client, you could just disable public key pinning checks completely.

tptacek 11y ago

In addition to the other comments on this subthread, a point I think is worth making: If you're providing both an app and a server for the app to talk to you, you control both ends of the TLS connection and can pin however you'd like; you're not limited to HPKP and key-continuity. Secure apps have been doing custom pins of TLS keys long before HPKP got rolled out.