Hacker News Reader

Comment by RGamma | Hacker News Reader

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/... or this recent RCE glitch in the Windows networking stack https://msrc.microsoft.com/update-guide/vulnerability/CVE-20....

Can't believe this is real to be honest...

View on HN

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...

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.

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

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?

> "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.

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.

And sometimes they fail 'open' so when the auth provider goes down all authentication evaporates and you have access to everything.

Fail open can be the right choice for some applications. Especially if you have logging of user credentials.

I need to update my hacker fantasy about systems intrusion from complicated multi-stage takeover to "just log in"

> just log in

If only. How about: just download the backup of the server log from https://example.com/logfile.txt? Oh, and it contains everything. Including internal application logs.

Microsoft should never have offered an API to verify an auth token is syntactically valid without checking who it is.

That's not the problem. They do check identity. The problem i the application that accepts Azure's verification as authentication and authorization.

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.

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/...

[2] https://intility.github.io/fastapi-azure-auth/multi-tenant/a...

> Can't believe this is real to be honest...

Why not? It's pretty much in line with expectations on my end.

Expectations updated.

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.

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.

I expect developers not to have access to production databases at all.

Then why was the “especially people hired yesterday” necessary?

Your original comment makes it seem like you feel someone should not have access simply because they’re new. Not that nobody should have access at all.

> - every developer having access to production databases, including people hired yesterday

I wonder how that correlates with companies bragging that they only take day or even few hours to have new hire code landing at production "coz they are so agile"

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

Reply on news.ycombinator.com