[HN Gopher] Gitlab password reset bug leaves more than 5.3K serv...
___________________________________________________________________
Gitlab password reset bug leaves more than 5.3K servers up for
grabs
Author : LinuxBender
Score : 111 points
Date : 2024-01-27 19:34 UTC (3 hours ago)
(HTM) web link (www.scmagazine.com)
(TXT) w3m dump (www.scmagazine.com)
| tptacek wrote:
| I don't know the history of this bug but just want to chime in
| with a word about how absolutely terrifying the "associate email
| address with account" feature in account-based web apps is.
| Which, I guess that's my word: terrifying, one of the things
| pentesters make a beeline to mess with, with a vulnerability
| history stretching all the way back to the early 2000s when these
| features were often implemented on standard Unix MTAs that could
| be tricked into sending password resets to multiple addresses at
| once, an attack featureful web frameworks seem to have
| resurrected in Gitlab.
|
| If you're a normal HN reader that found themselves interested in
| this story, go check your password reset feature, specifically
| the email association logic!
|
| Gitlab has, as I understand it, a pretty excellent security team,
| which gives some sense of how hard this bug class is to avoid.
| j-bos wrote:
| How does this exploit work? Or do you have a link to a rundown
| of it?
| tptacek wrote:
| I'm guessing here, because I only read a high-level
| description of it, but I think it's a password reset flow
| endpoint that takes the email address to look up and send a
| reset to, and the framework will accept an array instead of a
| simple string; the endpoint looks up the first address, but
| the variable used to determine who to send the reset mail to
| is the array. Again: just a guess as to the underlying bug
| (I've seen that specific bug before is why I guessed).
| nightpool wrote:
| This is correct: The vulnerability lies
| in the management of emails when resetting passwords. An
| attacker can provide 2 emails and the reset code will be
| sent to both. It is therefore possible to provide the
| e-mail address of the target account as well as that of the
| attacker, and to reset the administrator password.
| Here's an example payload: user[email][]=m
| y.target@example.com&user[email][]=hacker@evil.com
|
| (per this POC github:
| https://github.com/Vozec/CVE-2023-7028)
| tptacek wrote:
| Yep, so it's the classic Rails bug pattern.
| chatmasta wrote:
| This is such a rarely used feature that I wonder if it
| would be helpful to have a CSP or preflight header that
| restricts the browser from sending multiple values for
| the same parameter.
| janpieterz wrote:
| If you'd want to configure this you'd probably want it as
| some kind of configuration in the backend that disables
| it.
| 5- wrote:
| a browser is typically not used to exploit this class of
| bugs.
| tptacek wrote:
| It's pretty commonly used in Rails form handling logic
| though, isn't it?
| technion wrote:
| Strong parameters has been a core security feature of
| rails for a long time, and all the guides go into detail
| about the boilerplate you need just to accept a form
| input past the strong parameter filters. It's weird to me
| that the pattern doesn't also include a "must he a
| string" option. I know you can add to_s everywhere, but
| making it part of the existing strong params would
| actually incentivise use.
| tzs wrote:
| I think I'd count that as a bug and a design error.
|
| The bug is accepting an array when it should only take a
| scalar.
|
| The design error is that the endpoint should not be taking
| email addresses at all. It should take account IDs.
|
| Even if a system uses email addresses as account IDs they
| are conceptually not the same and the code should not
| muddle them.
|
| Keep them separate and then even if you get an "allows an
| array where it should have been a scalar" bug the result
| should be either just the first account in the array gets a
| reset email or all the accounts in the array that are
| existing accounts get reset emails for their accounts.
| Sleaker wrote:
| It doesn't sound like they have a great security team, they
| added the "Associate a secondary email address" feature
| recently. This isn't something that has always been in the
| software. It seems more like they were cutting corners and not
| properly testing through ways to exploit their own new feature
| when it was related to account security.
|
| On top of that it looks like they had a 9.6 CVE that allowed
| integrations to perform commands as other users...
|
| From the outside it looks like they are trying to ship features
| faster than they can keep them safe and tested. Perhaps because
| they are having an incredibly difficult time monetizing well?
| It makes sense from business standpoint in some respects, but
| also the security stuff could just absolutely tank the business
| when the whole point of a (self)hosted git solution is
| essentially just account management.
| tptacek wrote:
| I don't put much stock in this "9.6" stuff; CVSS is a ouija
| board that will say whatever people want it to say. But
| regardless: the best security teams in the world still see
| critical vulnerabilities in their software, because software
| is all garbage.
| EdwardDiego wrote:
| I've recently stopped two design choices in external facing
| resources that posed significant security risks.
|
| One of which was around credentials resetting to emails
| that aren't stored in the API auth system itself, but
| rather come into Salesforce as a support case. "Don't
| worry, a support team member has to action the request" was
| meant to be reassuring, until I explained that this
| translated to "the only mechanism in place to prevent
| credentials being stolen comes with a massive social
| engineering vulnerability".
|
| But it's the previous choices I haven't come across yet
| that worry me.
| blibble wrote:
| > From the outside it looks like they are trying to ship
| features faster than they can keep them safe and tested.
|
| this sums up their entire product
|
| every feature you could possibly imagine, somewhat working
| EduardoBautista wrote:
| A few years ago there would be people defending GitLab for
| "transparency" every time something went wrong.
|
| They even went overboard with the transparency and made
| public some slack conversations which for me would have
| made it one of the worst places to work.
| ljm wrote:
| Every time I end up opening a gitlab page I wonder how
| they've redesigned their nav again. Seems to be a new
| design every 6 months.
| amatecha wrote:
| Yeah, every single time I get a spurious password reset email
| (presumably from someone trying to hijack my account), I'm
| worried they've somehow managed to add an unauthorized recovery
| email address outside of my control. It hasn't yet happened to
| me, but as we can see from this story, it is absolutely
| possible unfortunately.
| andix wrote:
| I can't remember getting something like that. Maybe because I
| use a different e-mail address for signing up to services
| than for regular communication.
|
| I just had an idea, maybe using a + alias (yourname+some-
| alias-address@example.com, made famous by gmail) could help
| against attackers. Even if they find out your email they will
| never guess the part after the plus. If you forget it though
| then you can't reset your password anymore either.
| thebruce87m wrote:
| Sometimes mine come in Spanish. I don't speak Spanish.
| kazinator wrote:
| If they hijacked the domain, so that they control the MX
| record for it, they could just use _that_ very address.
| lossolo wrote:
| What a strange perspective. If not e-mail, then what would you
| associate it with? I've been running a site for over 20 years
| with a large user base. We initially used usernames, but it was
| disastrous. Everyone knew each other's usernames, making it
| easy to attempt brute force attacks on passwords, reset them,
| etc. Using e-mails isn't the problem, the issue is
| overcomplicating the login and password recovery logic, tons of
| abstraction everywhere, overengineering, people rushing to push
| code without proper checks in security sensitive parts etc.
|
| > Gitlab has, as I understand it, a pretty excellent security
| team, which gives some sense of how hard this bug class is to
| avoid.
|
| You should examine the history of security issues on GitLab.
| There are critical exploits multiple times a year, requiring an
| urgent upgrade of your GitLab distribution. Gitlab is the worst
| product I've used security wise.
| SlightlyLeftPad wrote:
| I tend to agree. Regarding Gitlab, there's a bit of a
| dichotomy here. On one hand it's good that they're diligently
| catching and patching these things quickly and effectively
| notifying with transparency, that's a great thing. On the
| other hand, it means Gitlab is an absolute nightmare to
| maintain, the process to upgrade it is not always trivial and
| to add to that, consistently, the day after a Gitlab upgrade
| a critical vulnerability is found and patched.
|
| Every product has security issues and what should worry you
| more, things that never see security patches or something
| that does?
| andix wrote:
| E-mail password reset is a security nightmare even when
| implemented correctly.
|
| And the worst part: On most services you can't even disable it,
| the only way around is often only Enterprise SSO.
|
| On some services you can set up a phone number for SMS token
| instead. But I've never seen the possibility to require both.
| Password reset only with e-mail AND SMS token.
| throwaway63467 wrote:
| Honestly I would never put any kind of internal server on the
| public Internet, make it reachable only via VPN to have a second
| line of defense.
| andix wrote:
| Especially something like Gitlab might benefit a lot from
| external integrations that need to call the Gitlab API. It
| might be possible to whitelist exactly those requests, but also
| a bit cumbersome.
| alexpls wrote:
| For folks who wanna see what led to this exploit in a Rails
| codebase, here's the commit where it's fixed:
|
| https://gitlab.com/gitlab-org/gitlab/-/commit/c571840ba2f0e9...
| bluedino wrote:
| Reminds me of a bug where you could brute force an account by
| putting an array of passwords in the login form.
|
| It was some junky web interface to a spam appliance of all
| things, I'm not sure if it was intentional, or just some php
| rookie wrote the code.
|
| One of our users discovered it when they had a (rare at the time)
| special character in their password.
| PufPufPuf wrote:
| Ruby on Rails accepts arrays as parameters to the ORM's
| ".where(...)", which means "OR" between the array values. So if
| the code does something like "User.where(name: name, password:
| password)", I could totally see this happening.
| dijit wrote:
| I got hit by this, we also noticed it being used with a second
| "feature" that exposed us a bit more than it should have.
|
| Basically a requirement for this attack is to know the email of
| the user you want to reset, but, there is a hidden email address
| that is tied to your gitlab userid (a number incrementing from
| 1).
|
| Since its a safe bet that ID 1 or 2 is an admin: thats a good
| target.
|
| the email is something like 1-user@mail.noreply.<gitlabhost>.
|
| Really bad, seemed like it was automated.
|
| 2FA saved us here.
| xyst wrote:
| Password based authentication needs to be nuked from orbit.
| mooreds wrote:
| What is your alternative?
|
| I don't love passwords.
|
| I think that magic links are a decent alternative, as are
| passkeys (for web) or similar (for non-web). SSO is fine, but
| just centralizes the problem (like magic links do).
|
| I just see adoption of any of these taking a long time.
| frenchman99 wrote:
| Good reminder to always run internal services such as Gitlab
| behind a VPN which only trusted users have access to.
___________________________________________________________________
(page generated 2024-01-27 23:00 UTC)