5 ms·

Source (linked in post): https://www.blackhat.com/docs/eu-16/materials/eu-16-Yang-Signing-Into-Billion-Mobile-Apps-Effortlessly-With-OAuth20-wp.pdf https://www.

Source (linked in post): https://www.blackhat.com/docs/eu-16/materials/eu-16-Yang-Signing-Into-Billion-Mobile-Apps-Effortlessly-With-OAuth20-wp.pdf https://www.blackhat.com/docs/eu-16/materials/eu-16-Yang-Sig... Only 15-20% of apps tested for Facebook/Google OAuth were vulnerable, perhaps because platform-specific login code might be available for those providers (so you don't have to roll-your-own OAuth client as an app developer). Also, the requirement for performing an MITM with SSL certificate bypass again raises the complexity of the attack. But it's true that your information is only as secure as the browser/client you use to access it, and the security of the API endpoints such clients talk to (and how they validate OAuth credentials passed by the client).

deleted 10y ago
[deleted]
idunno246 10y ago
Does MITM on the attacker's device really increase the complexity? Setting up one of the http debugging proxies isn't that hard, all you need to do is modify a response body from a http request. ive done this plenty with charles to hack the loaded save state from games with no server side validation
- lstamour 10y ago
  Sure. Let's put it this way: an app that doesn't validate SSL in such a way that your login service can be impersonated is... in some ways asking for attack, right? In addition to exploiting lax OpenID Connect validation to impersonate others, you could also steal credentials at this point, I would think. So while they're illustrating a weakness in Oauth client implementations, it relies on impersonating an SSL server that should already be mitigated by operating system or app-based certificate pinning, CRLs, etc. and as such isn't the root cause of the issue. This indirection/complication is what I meant by complexity.
  - je42 10y ago
    Not only the authentication of an app should be TLS/SSL. The rest of the communication as well. Certificate pinning and such should be done anyway for all services the app uses. A consistent view and specified view on how to securely communicate over the network would clearly help. But maybe they should should issue another version of OAuth2 and require TLS for all communication; and leave the legacy of the non-encrypted traffic behind.
- dzhiurgis 10y ago
  Certificate pinning is gaining popularity e̶f̶f̶e̶c̶t̶i̶v̶e̶l̶y̶ somewhat thwarting MITM attacks.
  - skrebbel 10y ago
    > e̶f̶f̶e̶c̶t̶i̶v̶e̶l̶y̶ wow, that must've been a lot of work
    - ThisIs_MyName 10y ago
      HN doesn't support markdown, so he probably used http://adamvarga.com/strike/ http://adamvarga.com/strike/ Unicode strikethrough looks really bad on my font :(
throwaway2016a 10y ago
From the article I don't think you need to MITM the victim's phone. You just MITM your own device and then are able to login as the victim on your own phone. Which is far less complicated. So assuming the app doesn't use certificate pinning it'd be easy enough. And even if the app does use certificate pinning you could probably crack some of the apps to bypass the check since it is your own phone after all.
- lstamour 10y ago
  Hmm. I see what you're saying. That's not really an MITM then, it's a poorly secured API, isn't it? If so, the target isn't the phone, the target is the endpoint that leaks data about users rather than validating OAuth credentials server-side to confirm the user's identity? I suppose there are two attacks in one: (a) an attack where you can substitute your identity for another's and thus capture activity taken in an app, while (b) is an attack on the API, retrieving profiles and data for users by spoofing the OAuth credentials with your "client app", modified, MITMed or otherwise.

deleted 10y ago

[deleted]

idunno246 10y ago

Does MITM on the attacker's device really increase the complexity? Setting up one of the http debugging proxies isn't that hard, all you need to do is modify a response body from a http request. ive done this plenty with charles to hack the loaded save state from games with no server side validation

lstamour 10y ago
Sure. Let's put it this way: an app that doesn't validate SSL in such a way that your login service can be impersonated is... in some ways asking for attack, right? In addition to exploiting lax OpenID Connect validation to impersonate others, you could also steal credentials at this point, I would think. So while they're illustrating a weakness in Oauth client implementations, it relies on impersonating an SSL server that should already be mitigated by operating system or app-based certificate pinning, CRLs, etc. and as such isn't the root cause of the issue. This indirection/complication is what I meant by complexity.
- je42 10y ago
  Not only the authentication of an app should be TLS/SSL. The rest of the communication as well. Certificate pinning and such should be done anyway for all services the app uses. A consistent view and specified view on how to securely communicate over the network would clearly help. But maybe they should should issue another version of OAuth2 and require TLS for all communication; and leave the legacy of the non-encrypted traffic behind.
dzhiurgis 10y ago
Certificate pinning is gaining popularity e̶f̶f̶e̶c̶t̶i̶v̶e̶l̶y̶ somewhat thwarting MITM attacks.
- skrebbel 10y ago
  > e̶f̶f̶e̶c̶t̶i̶v̶e̶l̶y̶ wow, that must've been a lot of work
  - ThisIs_MyName 10y ago
    HN doesn't support markdown, so he probably used http://adamvarga.com/strike/ http://adamvarga.com/strike/ Unicode strikethrough looks really bad on my font :(

throwaway2016a 10y ago

From the article I don't think you need to MITM the victim's phone. You just MITM your own device and then are able to login as the victim on your own phone. Which is far less complicated. So assuming the app doesn't use certificate pinning it'd be easy enough. And even if the app does use certificate pinning you could probably crack some of the apps to bypass the check since it is your own phone after all.

lstamour 10y ago
Hmm. I see what you're saying. That's not really an MITM then, it's a poorly secured API, isn't it? If so, the target isn't the phone, the target is the endpoint that leaks data about users rather than validating OAuth credentials server-side to confirm the user's identity? I suppose there are two attacks in one: (a) an attack where you can substitute your identity for another's and thus capture activity taken in an app, while (b) is an attack on the API, retrieving profiles and data for users by spoofing the OAuth credentials with your "client app", modified, MITMed or otherwise.