Sign in as anyone: Bypassing SAML SSO authentication with parser differentials

GitHub's SAML implementation is useless. The idea is that you can bring your own account into an enterprise, and that sort of works on the site itself, but it does not prevent apps where you log in with GitHub from reading your organization membership once you have authorized an app on the organization level (and if you didn't, it hides the membership from oauth tokens, so it has this capability!).

A SAML session is only required if said app fetches data via a token obtained from that user - and in my glance around, this was almost never the case - SAST tools almost always use app instance tokens and are happy to show anyone with a GitHub account in your organization your code. Tailscale fixed this when I pointed it out, Sonarcloud told me to please don't tell anyone and GitHub took a few weeks to say this is totally expected behavior - when no vendor I told did, and their docs contradicted them.

I swear, reporting security bugs is a thankless endeavor, even if you just randomly stumble over them. I couldn't imagine doing this as a job.

This is the operating procedure at every conceivable level. You would not believe how difficult it is to convince young developers raised on Javascript that client side validation is not enough, much less the business owners setting out functional requirements and budgets.

They'd be fired if they spent a penny more fixing it.

> The idea is that you can bring your own account into an enterprise

The issues goes beyond authorization. I’ve had Github randomly once in a blue use my personal email address as the default when merging a work PR. If anyone asks, I advice against mixing personal and professional stuff in the same Github account (or anywhere).

Musk should be fired. He has irreversibly destroyed the Tesla brand.

But has he realized yet?

the premise of comfort from shared credentials, and perhaps of increased security from sso; breaks down the moment you have a vulnerability like this.

Any type of password store, even a physical one, or just reusing passwords, ends up being safer.

Minimalism wins again

Why not just use the GitHub generated email address you get when you hide your email?

My company does not allow any employees to use their personal GitHub for work (or Facebook, instagram, or anything else) after running into issue when employees leave.

I wouldn't be surprised if the recent stock downturn is mostly him illegally offloading shares without disclosing it.

”You would not believe how difficult it is to convince young developers raised on Javascript that client side validation is not enough”

At first read, I think you’re JSplaining, but I’m willing to give you the benefit of the doubt.

How difficult is it exactly? Can you provide examples, perhaps even of the particular difficulties? Are the difficulties on the side of the convincer or the convincee, or both?

Yeah someone said why the funny account name why not use your personal account and I thought "wat are you crazy". And that isn't because of SAML etc. just simple don't mix work and pleasure ethos! I don't use my personal email to send an email to a customer.

I think it is something they have to experience. Tell them if they are happy with it, give me a $10 bug bounty. Then go hack a deploy of their branch. Then tell em to keep the $10 but remember the lesson.

Wouldn’t you just remove them from the org?

To be fair to the vendors, Github makes it extremely difficult to do the right thing here. I built a repo/commit/pr-analysis tool (https://dev.log.xyz) and it took a lot of effort to make it so that "iff you can see it in Github you can see it in Devlog." The entire experience was beyond frustrating.

Github also makes their OAuth permissions picker extremely confusing. When I "login with Github" I am never sure exactly what I'm sharing, from which organizations I'm a member of.

They may decide to change their github login to <company_name>LIES, and suddenly that’s all over your old PRs and Issues. Including in public repos where customers go looking for help.

Wow. I would never guess it was so hard to convince someone of this.

“The code I write doesn’t have XSS or SQL injection vulnerabilities,” sure. At least those are plausible things to believe.

Client side validation?? How could anybody believe in that?

That's even more true with a dedicated work github account than a mixed personal/work one; either way they can still login and edit the account name even if removed from the company org, and if it's not shared it doesn't burn their personal account too... right?

Is this speaking from experience?

With a dedicated work account the organization can always take over the account (via reset email if need be, since they own your work email account) and do whatever they want with it

I convinced fellow engineers who were adamant that the code they had written was OK by writing actual exploits against their code. Twice. Worked both times, without betting on money.

A dedicated work account _where you use your work email address_... that was the missing part throughout this thread.

But then if you do that you also lose all your open source work history, which is important from a hiring/resume perspective.

One option for those so inclined is to cryptographically sign commits with a key that lists both work and personal email address (assuming your enterprise’s policy allows it). The employer retains control but you have a claim to credit for your work.

If a spiteful ex-employer wants to scrub ex-employee authorship from the entire commit history in their public repos when someone leaves I don't think there's anything you could do to stop that either way, though it seems like it would be more trouble than it's worth and likely wouldn't scale. If they don't do that, assuming your old company email address still has your name in it I don't see why you'd lose credit for the work you did.

Funny that, exactly why NOWHERE should consider a phone number any form of ID.

If we're discussing companies willing to go to lengths to scrub you from their GitHub history, they can still replace all commits you've signed with new commits. You likely have no legal rights to that work, and git does allow you to rewrite history arbitrarily.

For anyone trying to connect the above to this vuln research, this seems unrelated ("GitHub doesn’t currently use ruby-saml for authentication, but began evaluating the use of the library with the intention of using an open source library for SAML authentication once more")

Yeah, it's a massive UX issue. The way to actually check if someone has a SAML session is to attempt to get their membership. If you get a 403, there isn't one. But good luck explaining to the user that they need to click "authorize" next to the organization in the OAuth flow. No way to send a hint that it may be required, and no way to do a step-up flow.

I did a full writeup here: https://notes.acuteaura.net/posts/github-enterprise-security...

> Github makes it extremely difficult to do the right thing here ... it took a lot of effort to make it so that "iff you can see it in Github you can see it in Devlog." The entire experience was beyond frustrating.

Do they? You don't have to mess with syncing teams, memberships, or assignment to repos if you don't want to. You can make one api call:

> The authenticated user has explicit permission to access repositories they own, repositories where they are a collaborator, and repositories that they can access through an organization membership.

https://docs.github.com/en/rest/repos/repos?apiVersion=2022-...

> git does allow you to rewrite history arbitrarily.

Technically yes, but the price is too great - everybody who has cloned the repos will now have to nuke their local copies too.

I should've tested this endpoint. GitHub's SAML implementation is done by a different team, always lags behind in quality and does some pretty unclean patching of the data - i.e. the notification filtering is done in the templating engine, so if all your notifications are SAML gated you get the header, no "all caught up" below it and (this is live from my account) "1-0 of 113".

So I'd give it about a 50:50 chance of working.

Edit: I just realized it eats your non-gated notifications too, if they're further down than position 25, and the "Next" button just leads to the same page with "?query=". Yay, another ticket about how glued on GitHub Enterprise Cloud is. The last one (GitHub eats API calls to accept invites to SAML organizations, deletes the invite, and sends a 200, writes success to the audit log... but ends up being a no-op) only has been 2 months or so ago. Thanks Microsoft.

It depends on the jurisdiction. In the US, copyright assignment is usually permanent. In the EU and Canada, you can claw back your rights to a degree and even revoke the usage altogether, if you manage to claw it back because they did "evil" things with it (moral rights).

In some cases (even in the US), if the employer does something that would be considered a "breach of contract", you can force them to remove all your code as well.

So, it would not be in the company's best interest to scrub their git history.

Using more than one Github account violates their ToS though.

This is exactly why I’m so paranoid about account and device separation.

I don’t even trust Git profiles. I buy a new license for GitKraken at any job I go to, even if I could avoid it; to me the possibility of accidentally trying to commit to work GitHub with my personal GitHub or vice verse is not worth it.

It’s the same with Microsoft accounts and their infamously bad-tech-debt-caused spaghetti.

Like if you try login to Outlook on iOS and you get a threatening message to the effect of “your system administrator will be able to remotely control and wipe your entire device if you proceed”. If it’s even a possibility that an incompetent or malicious IT department wipes your personal device, then no thank you.

See also that HN thread where a father let his child use his laptop, where they signed into their Microsoft school account, and somehow his personal Microsoft account was merged into their school account and from what I could tell he was never able to fix it and the school IT department didn’t care.

And you could still just change it right, as long as you did so before the employer revoked your access via the work email address.

It seems to be very common to use a personal phone for work 2fa or lots of other workplace tasks. Employers seem mystified if you request a corporate device when you obviously already have your own. I even see this a little with personal vehicles.

The idea of separating work and personal seems to be becoming old-fashioned.

Depends on the org I think now the controls are more fine grained. For example I have teams and outlook on my personal phone and the only thing they can do is delete the apps, taking a screenshot is blank, copy/paste doesn’t work etc.

I think even in the EU and Canada, you don't have any copyright interest in work your perform as part of your employment. The copyright on the work you produce for your employer is entirely theirs, from the moment it is created.

Now, if you're a contractor performing work for a company, this may be quite different. But as an employee, I don't think you have any claim of authorship to the code you right as part of your job.

Sure, but the same is true for unsigned commits as well, isn't it? Or can you modify the commit metadata without changing the commit hash in those cases?

Can you elaborate on the connection you see here?

Tying someone's identity to a thing they barely control and find it difficult to get more than one of.

Particularly something someone might reasonably need 3 or more different instances of. E.G. Personal SemiProfessional, Personal NSFW stuff, Work but they didn't give an X this service demands.

MAM vs MDM. MAM is good when you want your developers to be reachable on Slack but they all (for good reason) refuse to install an MDM on a personal device—at least that seems to be how my employer feels.

Yes, they do make it difficult. Keeping an updated set of {(user, repo, capabilities)} is necessary for correctly implementing "iff you can see it in Github you can see it in Devlog". Polling this REST endpoint user-by-user doesn't really work — both architecturally (are you going to poll this endpoint? how frequently?) and pragmatically (the REST API is both much slower and much less stable than the GraphQL API, and pagination works poorly.)

I ended up using the GraphQL API and making a query like this:

    query($cursor0: String, $cursor1: String) {
      search(query:"org:peterldowns", type: REPOSITORY, first: 100, after: $cursor0) {
       pageInfo {
        hasNextPage
        endCursor
       }
       repositories: nodes {
        ... on Repository {
         id
         name
         collaborators(first: 100, after: $cursor1) {
          pageInfo {
           hasNextPage
           endCursor
          }
          edges {
           permission
           node {
            login
            id
           }
          }
         }
        }
       }
      }
     }

Removing permissions that are no longer present in this result set is left as an exercise for the reader.

I stopped working on the product so I never implemented the event stream consumer that would let me listen for "this user was removed as a collaborator" or "this team no longer has admin access to that repo". The entire permissioning model for Github is extremely complex and learning about all of its intricacies was half the battle.

You may notice the button with the two opposing arrows on top of the user menu. You should click on it.

> Sure, but the same is true for unsigned commits as well, isn't it?

Yes, I think so. As I understand, GP's idea was to sign your commits proactively.

My question was, is signing the commits really useful? Isn't it just as hard or easy to scrub you from the repo history regardless of whether the commits are signed or not?

Not only on iOS, also Outlook on Android does the same. Ironically, Teams doesn't try the same trick, so if they have some emergency while I'm away, my folks know to only try sending me stuff in Teams, as Outlook will never be installed here.

Look up "moral rights." You have some ability to revoke the usage of your work if it violates moral standards.

GitHub is my current go-to example of an individual oriented application with business features shoehorned into it.

For awhile GitHub was rather unavoidably the only place in my company where there was no reliable line between personal and professional accounts/systems.

I moved us to Forgejo after trialing it against Github (and GitLab, and Gitea).

At a prior employer everyone just used their personal GitHub accounts for the business. Once it became a “capital-E-Enterprise” making promises about things like employee SSO, they quickly retreated to an on-premise platform (not GitHub EE).

Some countries allow authors to transfer/assign or waive asserting their moral rights. Typically (and sensibly) this must be in writing.

An axiom of secure programming is to never trust the client. You don't really know what the client is.

Often it takes several penetrations via compromised/replaced clients to get the message through.

Just look at all the discussions about why browser-based javascript encryption is problematic.

And the results are in.

"Our engineering team has indicated they will not be able to fully dive in and implement any resolutions in the near-term."

Considering they didn't in the past 7 years, I have little hope for the next 7.