5 ms·

Wait wtf. If I understand this correctly anyone with an AD tenant (i.e. anyone) could just log in to bingtrivia.azurewebsites.net to modify the Bing page for ev

by RGamma 4y ago

Wait wtf. If I understand this correctly anyone with an AD tenant (i.e. anyone) could just log in to bingtrivia.azurewebsites.net to modify the Bing page for everyone and insert JS that retrieved e-mails from logged-in visitors?! W T F This seems even more ludicrous than this recent Outlook credential theft bug https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2023-23397 https://msrc.microsoft.com/update-guide/en-US/vulnerability/... or this recent RCE glitch in the Windows networking stack https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-23415 https://msrc.microsoft.com/update-guide/vulnerability/CVE-20.... Can't believe this is real to be honest...

matsemann 4y ago
A quite common error, actually. Lots and lots of services are configured to accept logins from arbitrary auths, but forget to verify that it's an auth they actually trust! You just check that it's a valid oauth token, and your code works for your login page, so you consider your login-feature to be done and move on to something else, leaving a wide open door. Edit: As the article itself stated, around 25% of all systems with this setup are vulnerable! > The results surprised us: 25% of all the multi-tenant apps we scanned were vulnerable to authentication bypass.
- jacquesm 4y ago
  And sometimes they fail 'open' so when the auth provider goes down all authentication evaporates and you have access to everything.
  - londons_explore 4y ago
    Fail open can be the right choice for some applications. Especially if you have logging of user credentials.
- RGamma 4y ago
  I need to update my hacker fantasy about systems intrusion from complicated multi-stage takeover to "just log in"
  - jacquesm 4y ago
    > just log in If only. How about: just download the backup of the server log from https://example.com/logfile.txt https://example.com/logfile.txt? Oh, and it contains everything. Including internal application logs.
- iudqnolq 4y ago
  Microsoft should never have offered an API to verify an auth token is syntactically valid without checking who it is.
  - tgv 4y ago
    That's not the problem. They do check identity. The problem i the application that accepts Azure's verification as authentication and authorization.
    - deleted 4y ago
      [deleted]
- matsemann 4y ago
  Btw, even single-tenant can be a bit scary in this regard: You can by default log in with guest users. For instance if someone has joined a teams meeting. So unless you explicitly check permissions or disable this (for instance if you think "everyone in our org should have access to this"), you inadvertently could have external people log into your apps as well.
  - hotfixguru 4y ago
    Tutorial on how to deny Guest users in Azure AD[1] In general, one should always use roles in Azure. Even if you have a flaw like this, your endpoint would be safe if you required a role to access your endpoint. For multi-tenants, I completely this misconfiguration, there’s no real warnings when configuring it. In order to lock down to specific tenants, I recommend having a list of issuers that you check the token against.[2] [1] https://intility.github.io/fastapi-azure-auth/single-tenant/guest_users https://intility.github.io/fastapi-azure-auth/single-tenant/... [2] https://intility.github.io/fastapi-azure-auth/multi-tenant/accept_specific_tenants_only https://intility.github.io/fastapi-azure-auth/multi-tenant/a...
jacquesm 4y ago
> Can't believe this is real to be honest... Why not? It's pretty much in line with expectations on my end.
- RGamma 4y ago
  Expectations updated.
  - jacquesm 4y ago
    S3 bucket misconfigurations alone probably account for a sizeable fraction of all dataleaks over time, with AD misconfigurations a close second. Things I still regularly come across: - developers with copies of the production database on their laptop - said laptop doesn't have an encrypted hard drive - every developer having access to production databases, including people hired yesterday - default userids / passwords hardcoded in firmware - the marketing department having access to the production database in bulk - datalakes with zero access controls that perfectly mirror the production db - sharepoints without proper authentication storing mountains of customer data Anyway, I could go on like this for a while. And usually the company employees are aware of these, they just haven't gotten around to plugging the holes or they were never going to unless someone told them to because it is convenient. Occasionally there is serious pushback, for instance against developers having a recent copy of the production database on their laptop is in some places considered perfectly normal.
    - mynameisvlad 4y ago
      I agree with most of your points but > every developer having access to production databases, including people hired yesterday Do you expect new developers to have a wait period before being able to access sensitive materials? That seems like a recipe for disaster, you’re openly saying “I don’t trust you” at the start of your relationship with someone, when it’s the most volatile. I’m almost positive that doing it will just cause your new devs to resent their new bosses from day 1.
      - 4y ago
int0x2e 4y ago
I have worked on a project where we integrated with AAD for auth. One of our developers did things that looked fine - used the common Asp.NET middleware for AAd, configured it, used the latest version, set authorization policies on sensitive routes, etc. Then I did my own code review, and saw that they had passed "verify: false" in the options. When asked why, they said "I just copied this from StackOverflow and it worked...". This guy is not dumb BTW. It's just that security is easy to get wrong, especially if you don't know where the dragons are. We later had a full suite of positive and negative automatic tests, and had an independent pen test verify that things were done properly - but most small teams will never get those resources...
- iforgotpassword 4y ago
  We're celebrating that we've moved away from insecure languages with manual memory management to secure high level languages, sandboxes and whatnot, and the first thing we do is "yay coding got easier let's increase complexity by 1000x". At least sometimes I really feel like this, but probably just getting old.
  - turtles3 4y ago
    I don't think it's as simple as that - we have higher level languages that protect us from trivial security issues like buffer overruns, but that's a net good. There is no advantage we would gain in security from rolling that back. Instead, it gives us exposure to a new set of higher level security problems, that over time we will need to develop higher level primitives to navigate. We would still have these problems with lower level languages, we'd just be too overwhelmed with smaller issues to properly address them
- themoonisachees 4y ago
  Forget small teams. As a business owner buying solutions that integrate with AAD, how could you possibly be confident that the team you're buying from has done their due dilligence wrt security?
- layer8 4y ago
  > "I just copied this from StackOverflow and it worked...". This guy is not dumb BTW. These seem quite contradictory statements. Copying something from StackOverflow and using it in production code without making sure you fully understand what it does? And something like "verify: false" should be an instant red flag that you need to triple-check to make sure that’s really the correct thing to do for your use case.
adql 4y ago
I now feel better about adding additional check to disallow logins from not our domain to our apps even tho technically app setup in azure wouldn't allow that anyway... fuckup can happen at any level
deleted 4y ago
[deleted]

by RGamma 4y ago

matsemann 4y ago

A quite common error, actually. Lots and lots of services are configured to accept logins from arbitrary auths, but forget to verify that it's an auth they actually trust! You just check that it's a valid oauth token, and your code works for your login page, so you consider your login-feature to be done and move on to something else, leaving a wide open door. Edit: As the article itself stated, around 25% of all systems with this setup are vulnerable! > The results surprised us: 25% of all the multi-tenant apps we scanned were vulnerable to authentication bypass.

jacquesm 4y ago
And sometimes they fail 'open' so when the auth provider goes down all authentication evaporates and you have access to everything.
- londons_explore 4y ago
  Fail open can be the right choice for some applications. Especially if you have logging of user credentials.
RGamma 4y ago
I need to update my hacker fantasy about systems intrusion from complicated multi-stage takeover to "just log in"
- jacquesm 4y ago
  > just log in If only. How about: just download the backup of the server log from https://example.com/logfile.txt https://example.com/logfile.txt? Oh, and it contains everything. Including internal application logs.
iudqnolq 4y ago
Microsoft should never have offered an API to verify an auth token is syntactically valid without checking who it is.
- tgv 4y ago
  That's not the problem. They do check identity. The problem i the application that accepts Azure's verification as authentication and authorization.
  - deleted 4y ago
    [deleted]
matsemann 4y ago
Btw, even single-tenant can be a bit scary in this regard: You can by default log in with guest users. For instance if someone has joined a teams meeting. So unless you explicitly check permissions or disable this (for instance if you think "everyone in our org should have access to this"), you inadvertently could have external people log into your apps as well.
- hotfixguru 4y ago
  Tutorial on how to deny Guest users in Azure AD[1] In general, one should always use roles in Azure. Even if you have a flaw like this, your endpoint would be safe if you required a role to access your endpoint. For multi-tenants, I completely this misconfiguration, there’s no real warnings when configuring it. In order to lock down to specific tenants, I recommend having a list of issuers that you check the token against.[2] [1] https://intility.github.io/fastapi-azure-auth/single-tenant/guest_users https://intility.github.io/fastapi-azure-auth/single-tenant/... [2] https://intility.github.io/fastapi-azure-auth/multi-tenant/accept_specific_tenants_only https://intility.github.io/fastapi-azure-auth/multi-tenant/a...

jacquesm 4y ago

> Can't believe this is real to be honest... Why not? It's pretty much in line with expectations on my end.

RGamma 4y ago
Expectations updated.
- jacquesm 4y ago
  S3 bucket misconfigurations alone probably account for a sizeable fraction of all dataleaks over time, with AD misconfigurations a close second. Things I still regularly come across: - developers with copies of the production database on their laptop - said laptop doesn't have an encrypted hard drive - every developer having access to production databases, including people hired yesterday - default userids / passwords hardcoded in firmware - the marketing department having access to the production database in bulk - datalakes with zero access controls that perfectly mirror the production db - sharepoints without proper authentication storing mountains of customer data Anyway, I could go on like this for a while. And usually the company employees are aware of these, they just haven't gotten around to plugging the holes or they were never going to unless someone told them to because it is convenient. Occasionally there is serious pushback, for instance against developers having a recent copy of the production database on their laptop is in some places considered perfectly normal.
  - mynameisvlad 4y ago
    I agree with most of your points but > every developer having access to production databases, including people hired yesterday Do you expect new developers to have a wait period before being able to access sensitive materials? That seems like a recipe for disaster, you’re openly saying “I don’t trust you” at the start of your relationship with someone, when it’s the most volatile. I’m almost positive that doing it will just cause your new devs to resent their new bosses from day 1.
    - 4y ago

int0x2e 4y ago

I have worked on a project where we integrated with AAD for auth. One of our developers did things that looked fine - used the common Asp.NET middleware for AAd, configured it, used the latest version, set authorization policies on sensitive routes, etc. Then I did my own code review, and saw that they had passed "verify: false" in the options. When asked why, they said "I just copied this from StackOverflow and it worked...". This guy is not dumb BTW. It's just that security is easy to get wrong, especially if you don't know where the dragons are. We later had a full suite of positive and negative automatic tests, and had an independent pen test verify that things were done properly - but most small teams will never get those resources...

iforgotpassword 4y ago
We're celebrating that we've moved away from insecure languages with manual memory management to secure high level languages, sandboxes and whatnot, and the first thing we do is "yay coding got easier let's increase complexity by 1000x". At least sometimes I really feel like this, but probably just getting old.
- turtles3 4y ago
  I don't think it's as simple as that - we have higher level languages that protect us from trivial security issues like buffer overruns, but that's a net good. There is no advantage we would gain in security from rolling that back. Instead, it gives us exposure to a new set of higher level security problems, that over time we will need to develop higher level primitives to navigate. We would still have these problems with lower level languages, we'd just be too overwhelmed with smaller issues to properly address them
themoonisachees 4y ago
Forget small teams. As a business owner buying solutions that integrate with AAD, how could you possibly be confident that the team you're buying from has done their due dilligence wrt security?
layer8 4y ago
> "I just copied this from StackOverflow and it worked...". This guy is not dumb BTW. These seem quite contradictory statements. Copying something from StackOverflow and using it in production code without making sure you fully understand what it does? And something like "verify: false" should be an instant red flag that you need to triple-check to make sure that’s really the correct thing to do for your use case.

adql 4y ago

I now feel better about adding additional check to disallow logins from not our domain to our apps even tho technically app setup in azure wouldn't allow that anyway... fuckup can happen at any level

deleted 4y ago

[deleted]