Technology @lemmy.world Nemeski @lemm.ee 10mo ago

Over 5,300 GitLab servers exposed to zero-click account takeover attacks

www.bleepingcomputer.com Over 5,300 GitLab servers exposed to zero-click account takeover attacks

Over 5,300 internet-exposed GitLab instances are vulnerable to CVE-2023-7028, a zero-click account takeover flaw GitLab warned about earlier this month.

Security News @infosec.pub Blaze @lemmy.zip 10mo ago

www.bleepingcomputer.com /news/security/over-5-300-gitlab-servers-exposed-to-zero-click-account-takeover-attacks/

31 0

49 comments

There was a chap on here the other day who said they hate 2fa and don't need it because they use passwords that are 50 characters and generated by the password manager.

This is a perfect example of why you should always activate it when possible.
- Alot of people don't like Microsoft, but they're pushing for zero password authentication for a reason. Passwords are getting really insecure really fast.
  
  This vulnerability has nothing to do with password strength or security and everything to do with password reset security, i.e. email and improper handling of parameters to that reset API call.
  
  Passkeys are interesting and potentially quite strong but they're going to have to fall back to the same old reset mechanism if you e.g. drop your passkey device (phone) into a lake.
  
  Have they given up on their “Passwords are insecure, use this 4 digit pin instead” push?
  
  How does Microsoft's implementation work?
  
  Is it possible to log into windows without a Microsoft account using that method?
- I see a lot of people around me resetting passwords of services they rarely use because they forgot what password they used and don't have a password manager (or not synced one). And I don't understand why all services don't propose to generate a one time link to log in instead of changing passwords (a few services do propose it already)
  
  Passwords are useless for all users using the same password for every account they have, and i'm sure it's a majority of users.
  
  Google is moving that way with passkeys. I think it'll catch on with many people.
  
  Just cut the passwords out and go straight to unlocking with a device.
  
  That said not sure what happens if you lose your device.
  
  How do you secure email accounts then? And wouldn't that make those just even more attractive targets?
- I don't have 2FA for my GitLab account since it's only accesible via my GitHub account which has 2FA. Is this good or should I add 2FA to GitLab also?
  
  If you have to use your GitHub 2fa to sign in that's fine I would assume.
- One of the biggest issues with 2fa is that normally it's either an easily spoofable phone/email or an app locked to a device.
  
  This is why I use a password manager (pass) that is synced across all of my devices (via a private self hosted git for version control) that I can send 2fa QR codes to cameraless devices via screenshots using zbarimg and have every device capable of 2fa verification with the pass-otp extension.
  
  I know this setup is a bit complicated as just dealing with git or importing a gpg key would give most people I know sense of existential dread. I am curious to see what others use for similar functionality.
  
  Is that second factor, though? If I understand it right, you are basically generating your MFA from your password manager, is that so?
We use gitlab ultimate at my work, I'm the main admin of the instance. Like 2 weeks ago when there was the cvss 10 vuln, gitlab sent us a .patch file to apply to the instance instead of releasing a new minor cause they didn't wanna make the vuln public yet. I guess that's coordinated disclosure, but I still found that remarkably jank.
bruh, feels like gitlab has security update every other day, it's some bullshit even for a project this size. And who knows how many 0-days are around.
- I’ve been hanging a version back for a while now. Although my instance isn’t public, it’s ridiculous how many CVEs I have dodged by not updating. SolarWinds all over again.
- And their license cost increases at almost the same rate.
  
  No it doesn't. Gitlab's pricing has been pretty stable, with one increase in the premium tier in the past six years ($19 --> $29 per user per month).
Check gitlab-rails/production_json.log for HTTP requests to the /users/password path with params.value.email consisting of a JSON array with multiple email addresses.

Jesus Christ. Their frontend was sending a list of recipients to the backend. That's an intern developer level of fuck up, in their login system, no less.

If this got past them, it's a sign of deep problems.
- Can you explain in a bit more detail what you understand was happening?
  
  Gitlab has a backend, which runs on a server, and a frontend, which runs in all the user's browsers. When the user does anything it sends some network requests to the backend in order to save the changes the user has made, send the necessary emails or create a session, etc.
  
  The thing with this architecture is the backend and frontend are effectively separate apps. Also as the frontend is running remotely on the attacker's computer the attacker can change it to behave however they want. The backend can't trust the frontend to "do the right thing", ever. The backend needs to assume the frontend will do every bad and silly thing possible, and treat anything coming from the frontend with maximum suspicion.
  
  So you simply can't allow the frontend code to provide a list of email addresses to send an email to, because it'll allow the attacker to send emails to anywhere. Where the email goes to needs to be determined by the backend. The frontend should only be concerned with hiding and showing stuff in the UI, and pretty much all intelligence and business logic needs to reside on the server where we control the code and environment. A good understanding of the roles and responsibilities of the front vs back is a fundamental concept and if the developer hasn't grasped this then they're going to introduce security problems everywhere they go.
  
  This is one of many pitfalls of the "frontend + backend" architecture. I vastly prefer to build monoliths instead.
  
  Not the commenter but it seems like the parameters of the HTTP Get/Post weren't protected/checked. The API was likely something like: Email to reset: string(email account to reset) But it accepted something like: [string(email account to reset), string (email to which the reset mail is sent to)]
- Holy shit, that's the rookiest mistake.

49 comments