Maximum-severity GitLab flaw allowing account hijacking under active exploitation (arstechnica.com)
from mox@lemmy.sdf.org to programming@programming.dev on 02 May 22:05
https://lemmy.sdf.org/post/16177636

#programming

threaded - newest

solrize@lemmy.world on 02 May 22:54 next collapse

Somehow they let attackers send themselves password reset links to arbitrary Gitlab accounts, apparently. Not good.

notnotmike@programming.dev on 03 May 12:35 next collapse

A change was made in 16.1.0 to allow users to reset their password through a secondary email address. The vulnerability is a result of a bug in the email verification process. The bug has been fixed with this patch, and as mentioned above, we have implemented a number of preventive security measures to protect customers.

Struggling to figure out what the heck they did. Some kind of injection attack to send the email to an arbitrary account? How would you even mess that up in the first place

Lmaydev@programming.dev on 04 May 08:28 next collapse

If I had to guess I’d say the email address was sent as part of the request and not verified.

corsicanguppy@lemmy.ca on 04 May 19:30 collapse

It was leveraged as part of an auto responding email function as part of a ticket that, when used as a secondary email address, allowed a password reset chit to be viewed and then used to change the password on the account.

I remember this one.

But it was fixed months ago. We patch nightly because enterprise software lets you roll back easily.

Kissaki@programming.dev on 04 May 10:50 next collapse

A patch from January and MFA prevents account takeover.

If you’re not updating gitlab for over three months, across max severity security patches, you’re negligent.

Mubelotix@jlai.lu on 04 May 11:59 next collapse

I had a friend whose instance was hacked only a few hours after the issue was disclosed. Bots had swarmed the internet in just a day

valid@lemmynsfw.com on 04 May 20:16 collapse

konakona.moe