[HN Gopher] OAuth Attack Vectors
___________________________________________________________________
OAuth Attack Vectors
Author : arkadiyt
Score : 96 points
Date : 2021-03-25 04:54 UTC (18 hours ago)
(HTM) web link (portswigger.net)
(TXT) w3m dump (portswigger.net)
| ForHackernews wrote:
| 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.
| UncleMeat wrote:
| 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".
| HeapsGood wrote:
| 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.
| grandpoobah wrote:
| The worst part of any new project is building the auth - change
| my mind.
| mooreds wrote:
| 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 wrote:
| > 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.
| andybak wrote:
| 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.
| UncleMeat wrote:
| People say this, but I'm not convinced that the population of
| people who would be fooled by phishing after being trained by
| OAuth is meaningfully higher than the population of people who
| would be fooled by phishing without this training.
|
| People are _awful_ at recognizing phishing. Straight up.
| andybak wrote:
| > the population of people who would be fooled by phishing
|
| That population includes me. _I 'm_ in danger of being
| phished by 3rd party apps.
|
| > People are awful at recognizing phishing. Straight up.
|
| Yes - which is why password managers are a key part of the
| solution. They match on URLs and require an extra step to
| bypass.
| UncleMeat wrote:
| Password managers can autofill the OAuth page just fine.
| Wouldn't that mean that there is no problem with OAuth
| making phishing more dangerous?
| andybak wrote:
| Not sure I follow your reasoning here.
|
| The reason password managers make websites safer as
| opposed to apps is that the match the url and fill in the
| credentials automatically. If you are being phished, the
| urls won't match and the password manager will usually
| warn you if you try and force it to fill in the
| credentials.
|
| For a webview inside an app - they don't autofill
| anything and it's always manual - meaning the user has to
| be vigilant.
| UncleMeat wrote:
| > For a webview inside an app - they don't autofill
| anything and it's always manual - meaning the user has to
| be vigilant.
|
| But that has nothing to do with OAuth. A malicious app
| can already phish you by impersonating another app.
| andybak wrote:
| > A malicious app can already phish you by impersonating
| another app.
|
| Yes but that requires a host of other things to go wrong
| first.
|
| My point is basically "Don't enter your credentials into
| any app". There might be exceptions for 1st party apps
| but these are much less common and the OS already has
| protections in place (of varying levels of
| effectiveness).
| jt2190 wrote:
| > 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.
| elliekelly wrote:
| When I log in to my bank I recognize the little icon I chose
| but I'm not sure I'd notice its absence. I suspect I
| wouldn't.
| andybak wrote:
| 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 wrote:
| 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.
| andybak wrote:
| I've personally never seen this with any "in-app" oAuth
| page. I don't think it changes my fundamental point.
| vladvasiliu wrote:
| But how much of a hurdle is that? The login page is likely
| accessible by the attacker, who can then copy it.
|
| Sure, it's a bit more work than setting up a random HTML
| form, but if you're already running a somewhat targeted
| attack it may be worth it.
|
| It's also not clear to me why the apps don't launch the
| system browser. The IntelliJ IDEs do this. Added bonus is the
| sign-on is actually... _single_ , since I'm probably already
| logged in to the service.
|
| Even a command-line tool, awscli, is able to figure out how
| to launch a browser, use whatever session is active, populate
| the device code on the form, etc. All I have to do is click
| the button "yup, I actually asked for this happen". And this
| is running on Linux without a fancy DE or anything.
|
| MS Teams however, does it in its own browser, restarts five
| times, etc.
|
| It seems to me that this idea of simplification (the user
| doesn't even have to switch apps!) has been pushed too far,
| to the point of actually making things more complicated for
| the user and in the process decreasing security.
| donmcronald wrote:
| > enter their username and password in any old app that throws
| up a webview
|
| And 2FA codes. And TOTP codes. From what I've seen users have
| been trained to enter credentials everywhere and constantly.
| kerng wrote:
| Not just old apps, recently I saw Robinhood/BlockFi/othere use
| Plaid, and Plaid pops up a dialog to enter your bank account
| credentials! I'm not kidding. Of course there is a note that
| you dont have to worry and all is fine.
|
| Reminded me of Mint which did the same when I looked at it a
| few years ago.
|
| The financial system is so far behind tech wise its crazy,
| maybe even irresponsible.
| Operyl wrote:
| At the very least, Plaid's finally getting official oauth2
| integrations with a lot of the big banks. It'll be eons
| before we get such integrations with small banks, though.
|
| For example, Plaid now will open the banking app on a mobile
| device to continue authorization.
| homakov wrote:
| Also many of these design attacks still work
| http://sakurity.com/oauth
| sec400 wrote:
| 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.
| mt_ wrote:
| Am I going blind or is the choice of the website's color theme
| just bad?
| vmception wrote:
| 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 wrote:
| 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 wrote:
| > Furthermore, we can specify the filter based on user password:
|
| > /openam/.well-known/webfinger?resource=http://x/dsameuser)(sunK
| eyValue=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 wrote:
| 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 wrote:
| 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.
| jedisct1 wrote:
| 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 is an example of it.
|
| But looks like there is no (commercial?) interest in improving
| user's privacy.
| will4274 wrote:
| 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 wrote:
| 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..
___________________________________________________________________
(page generated 2021-03-25 23:04 UTC)