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.
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.
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".
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.
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.
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.
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.
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.
> 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).
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.
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.
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.
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.
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.
> 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.
33 comments
[ 4.9 ms ] story [ 72.3 ms ] threadThe 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
The federation ecosystem is so full of needless complexity. Simple is secure.
> /openam/.well-known/webfinger?resource=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.
I guess the app/server is quite badly configured, like having your app run as dba.
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.
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.
Precision is great, but some assumed terminology will happen in forums that frequent the terms.
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.
Some sites allow and encourage the user to customize their login page. The attacker the must reproduce the unique login page for each user.
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.
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.
People are awful at recognizing phishing. Straight up.
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.
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.
But that has nothing to do with OAuth. 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).
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.
For example, Plaid now will open the banking app on a mobile device to continue authorization.
And 2FA codes. And TOTP codes. From what I’ve seen users have been trained to enter credentials everywhere and constantly.
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.
On the other hand, the implementations offered by Google, etc..
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.