5 ms·

OAuth Attack Vectors

106 points by arkadiyt 6y ago

vmception 6y ago
I briefly worked for an Oauth2 middleware company The whole time I was there I was gaslighted about some protocol level implementation concerns I had Part of their job was posting on hackernews about how awesome and perfect Oauth2 was Oauth2 and Json Web Tokens!!!11! They didn’t actually know better but were also not open to their own employee’s questions Everything that proves them wrong always make me think of them Everything has its place
- bawolff 6y ago
  Its better than what it replaced (SAML & XMLSignature), but that's such a low bar. The federation ecosystem is so full of needless complexity. Simple is secure.
bawolff 6y ago
> Furthermore, we can specify the filter based on user password: > /openam/.well-known/webfinger?resource=http://x/dsameuser)(sunKeyValue=userPassword=A*)(%2526&rel=http://openid.net/specs/connect/1.0/issuer http://x/dsameuser)(sunKeyValue=userPassword=A*)(%2526&rel=h... Rofl. I get that its an injection vuln so you dont expect users to be able to trigger this, but why tf would wildcard searching of passwords be implemented in the first place in ldap.
- xyzzy123 6y ago
  Normally you would not be able to read that attribute value (just do a bind) without admin level privs. Also LDAP passwords are usually hashed. I guess the app/server is quite badly configured, like having your app run as dba.
- BeefWellington 6y ago
  As xyzzy123 said, this is the app doing LDAP wrong. To provide a more complete answer to your question: there's really nothing special about a password field as far as an LDAP server is concerned. It's just a field like any other; it can have rules applied to it, as well as processes, to alter what data is ultimately stored but it depends on people implementing the rules. There are standards, etc., but it's rare anyone follows them properly. Having worked with it extensively at one point in my career my impression is that few people really understand how LDAP works at its core. People associate it with authentication because that's mostly what they use it for but it can effectively work as a data store for anything you want to keep a directory of. Another common use is device registrations and ownership (in AD this is Machine accounts). It's a very flexible system that could be used to replace any kind of structured data store if you want it to. This all leads back to the fact that while you can apply some rules to the structure of the LDAP and to individual fields, it's not as though the LDAP knows or cares that an attribute called "password" should have special treatment when it comes to querying if you don't tell it that. Ultimately the software should be performing a bind (authentication) to the LDAP as the user, rather than trying to look the user up using queries while bound as a superuser or some other high-privilege user.
ForHackernews 6y ago
Is this about OAuth or OAuth2? Despite their similar names, the two systems have almost nothing in common and the headline should be clear. Edit: Clicked and it's about OAuth2, but also OpenIDConnect (an extension to OAuth2, but actually a distinct protocol) > From a pentesting point of view, whenever you test an OAuth application, there is a good chance that the target server also supports OpenID Again playing very loose with the terminology. OpenID (no "Connect") is yet another completely unrelated protocol.
- HeapsGood 6y ago
  Eh, not so much. I don’t think many people have mentioned “OAuth” in quite a while without implicitly meaning OAuth2. Same with OpenID and OIDC. Precision is great, but some assumed terminology will happen in forums that frequent the terms.
- UncleMeat 6y ago
  Terminology is always loose. We still use "SSL" when we want to say "TLS". When we say "HTTP" we definitely aren't speaking about "HTTP 1.0". In most contexts, "OAuth" means some combination of "OAuth2 and OpenID Connect".
homakov 6y ago
Also many of these design attacks still work http://sakurity.com/oauth http://sakurity.com/oauth
- sec400 6y ago
  I owe you many thanks, your guide helped me exploit a bug on a bug bounty years ago and then helped me get my first security job.
andybak 6y ago
A less technical vector is that users are continually trained to think it's ok to enter their username and password in any old app that throws up a webview. Phishing here we come... I spent a while complaining every time I saw one and nearly always got brushed off. Then I realised that even large companies do this. The most recent example was Microsoft doing it in the Windows Gamebar! So I give up. If anyone wants to harvest passwords just release a few apps that claim a legitimate need to login to Google, Facebook, Amazon or anything else you want access to. EDIT - what's the correct thing to do? Launch the user's browser where there is a slightly higher chance that they will be able to spot that things aren't legit. And if they are using a password manager that will refuse to fill in the site and is much more likely to alert them. The two simple rules: 1. Never enter your password in a 3rd party app 2. Always use a password manager are simple to explain to non-technical users and fairly robust.
- jt2190 6y ago
  > Launch the user's browser where there is a slightly higher chance that they will be able to spot that things aren't legit. Some sites allow and encourage the user to customize their login page. The attacker the must reproduce the unique login page for each user.
  - andybak 6y ago
    At that point they have already entered their credentials. Unless I'm misunderstanding you? The webview is equivalent to "show the login page in a sandboxed browser" - there is no memory of any customization.
    - tsimionescu 6y ago
      Usually this happens after you enter your username/email but before the password. It's very common with company logins - you first want to login to Azure, you get redirected to login.microsoft.com, you enter your company email, you get transfered to your company's login.company.com page. The same can be done with a personal login page.
jedisct1 6y ago
From a privacy perspective, OAuth/OIDC are also terrible. It would be possible to achieve the same thing in a privacy-preserving way, and without breaking current deployments; EL PASSO https://arxiv.org/pdf/2002.10289.pdf https://arxiv.org/pdf/2002.10289.pdf is an example of it. But looks like there is no (commercial?) interest in improving user’s privacy.
- will4274 6y ago
  As it turns out, privacy preserving federated auth is actually typically bad for most users - as then the federated auth provider can't identify or ban malicious apps.
- ForHackernews 6y ago
  The OAuth2 spec requires only a totally opaque "access token". There's nothing about the protocol that makes it bad for privacy. On the other hand, the implementations offered by Google, etc..
grandpoobah 6y ago
The worst part of any new project is building the auth - change my mind.
- mooreds 6y ago
  Depends on what you mean by building. There are plenty of snap in tools out there (OSS libs, frameworks, identity providers) that you can snap in. I think that makes 'building' auth easier. It's kinda like deciding on a data layer. You have to do it, you have to get it right, but it's not a feature your end users are going to love.
  - capableweb 6y ago
    > It's kinda like deciding on a data layer. You have to do it, you have to get it right, but it's not a feature your end users are going to love. Agree overall but I don't think you can ever get either "data layer" or "auth" "right" forever, it's a constantly evolving thing that changes over time. What's "right" today is not necessarily "right" tomorrow.
mt_ 6y ago
Am I going blind or is the choice of the website's color theme just bad?

106 points by arkadiyt 6y ago

I briefly worked for an Oauth2 middleware company The whole time I was there I was gaslighted about some protocol level implementation concerns I had Part of their job was posting on hackernews about how awesome and perfect Oauth2 was Oauth2 and Json Web Tokens!!!11! They didn’t actually know better but were also not open to their own employee’s questions Everything that proves them wrong always make me think of them Everything has its place

bawolff 6y ago
Its better than what it replaced (SAML & XMLSignature), but that's such a low bar. The federation ecosystem is so full of needless complexity. Simple is secure.

bawolff 6y ago

> Furthermore, we can specify the filter based on user password: > /openam/.well-known/webfinger?resource=http://x/dsameuser)(sunKeyValue=userPassword=A*)(%2526&rel=http://openid.net/specs/connect/1.0/issuer http://x/dsameuser)(sunKeyValue=userPassword=A*)(%2526&rel=h... Rofl. I get that its an injection vuln so you dont expect users to be able to trigger this, but why tf would wildcard searching of passwords be implemented in the first place in ldap.

xyzzy123 6y ago
Normally you would not be able to read that attribute value (just do a bind) without admin level privs. Also LDAP passwords are usually hashed. I guess the app/server is quite badly configured, like having your app run as dba.
BeefWellington 6y ago
As xyzzy123 said, this is the app doing LDAP wrong. To provide a more complete answer to your question: there's really nothing special about a password field as far as an LDAP server is concerned. It's just a field like any other; it can have rules applied to it, as well as processes, to alter what data is ultimately stored but it depends on people implementing the rules. There are standards, etc., but it's rare anyone follows them properly. Having worked with it extensively at one point in my career my impression is that few people really understand how LDAP works at its core. People associate it with authentication because that's mostly what they use it for but it can effectively work as a data store for anything you want to keep a directory of. Another common use is device registrations and ownership (in AD this is Machine accounts). It's a very flexible system that could be used to replace any kind of structured data store if you want it to. This all leads back to the fact that while you can apply some rules to the structure of the LDAP and to individual fields, it's not as though the LDAP knows or cares that an attribute called "password" should have special treatment when it comes to querying if you don't tell it that. Ultimately the software should be performing a bind (authentication) to the LDAP as the user, rather than trying to look the user up using queries while bound as a superuser or some other high-privilege user.

ForHackernews 6y ago

Is this about OAuth or OAuth2? Despite their similar names, the two systems have almost nothing in common and the headline should be clear. Edit: Clicked and it's about OAuth2, but also OpenIDConnect (an extension to OAuth2, but actually a distinct protocol) > From a pentesting point of view, whenever you test an OAuth application, there is a good chance that the target server also supports OpenID Again playing very loose with the terminology. OpenID (no "Connect") is yet another completely unrelated protocol.

HeapsGood 6y ago
Eh, not so much. I don’t think many people have mentioned “OAuth” in quite a while without implicitly meaning OAuth2. Same with OpenID and OIDC. Precision is great, but some assumed terminology will happen in forums that frequent the terms.
UncleMeat 6y ago
Terminology is always loose. We still use "SSL" when we want to say "TLS". When we say "HTTP" we definitely aren't speaking about "HTTP 1.0". In most contexts, "OAuth" means some combination of "OAuth2 and OpenID Connect".

homakov 6y ago

Also many of these design attacks still work http://sakurity.com/oauth http://sakurity.com/oauth

sec400 6y ago
I owe you many thanks, your guide helped me exploit a bug on a bug bounty years ago and then helped me get my first security job.

andybak 6y ago

A less technical vector is that users are continually trained to think it's ok to enter their username and password in any old app that throws up a webview. Phishing here we come... I spent a while complaining every time I saw one and nearly always got brushed off. Then I realised that even large companies do this. The most recent example was Microsoft doing it in the Windows Gamebar! So I give up. If anyone wants to harvest passwords just release a few apps that claim a legitimate need to login to Google, Facebook, Amazon or anything else you want access to. EDIT - what's the correct thing to do? Launch the user's browser where there is a slightly higher chance that they will be able to spot that things aren't legit. And if they are using a password manager that will refuse to fill in the site and is much more likely to alert them. The two simple rules: 1. Never enter your password in a 3rd party app 2. Always use a password manager are simple to explain to non-technical users and fairly robust.

jt2190 6y ago
> Launch the user's browser where there is a slightly higher chance that they will be able to spot that things aren't legit. Some sites allow and encourage the user to customize their login page. The attacker the must reproduce the unique login page for each user.
- andybak 6y ago
  At that point they have already entered their credentials. Unless I'm misunderstanding you? The webview is equivalent to "show the login page in a sandboxed browser" - there is no memory of any customization.
  - tsimionescu 6y ago
    Usually this happens after you enter your username/email but before the password. It's very common with company logins - you first want to login to Azure, you get redirected to login.microsoft.com, you enter your company email, you get transfered to your company's login.company.com page. The same can be done with a personal login page.

jedisct1 6y ago

From a privacy perspective, OAuth/OIDC are also terrible. It would be possible to achieve the same thing in a privacy-preserving way, and without breaking current deployments; EL PASSO https://arxiv.org/pdf/2002.10289.pdf https://arxiv.org/pdf/2002.10289.pdf is an example of it. But looks like there is no (commercial?) interest in improving user’s privacy.

will4274 6y ago
As it turns out, privacy preserving federated auth is actually typically bad for most users - as then the federated auth provider can't identify or ban malicious apps.
ForHackernews 6y ago
The OAuth2 spec requires only a totally opaque "access token". There's nothing about the protocol that makes it bad for privacy. On the other hand, the implementations offered by Google, etc..

grandpoobah 6y ago

The worst part of any new project is building the auth - change my mind.

mooreds 6y ago
Depends on what you mean by building. There are plenty of snap in tools out there (OSS libs, frameworks, identity providers) that you can snap in. I think that makes 'building' auth easier. It's kinda like deciding on a data layer. You have to do it, you have to get it right, but it's not a feature your end users are going to love.
- capableweb 6y ago
  > It's kinda like deciding on a data layer. You have to do it, you have to get it right, but it's not a feature your end users are going to love. Agree overall but I don't think you can ever get either "data layer" or "auth" "right" forever, it's a constantly evolving thing that changes over time. What's "right" today is not necessarily "right" tomorrow.

mt_ 6y ago

Am I going blind or is the choice of the website's color theme just bad?