PRP: Gitlab Account Takeover via password reset without user interactions

[am0o0]

Hi, according to the new security release of GitLab, there is a critical ATO vulnerability in nearly all recent versions of this popular software. I can work on this this weekend if you want to put this on priority as this is a very critical vulnerability in critical software. ref: https://about.gitlab.com/releases/2024/01/11/critical-security-release-gitlab-16-7-2-released/ POC: https://twitter.com/rwincey/status/1745659710089437368

[am0o0]

@tooryx I'm ready for a ping and I'll implement this as fast as possible.

[tooryx]

Hi @am0o0,

We will review this early next week (most likely Tuesday) with the rest of the team. We will let you know. Don't start the development just yet.

~tooryx

[tooryx]

Hi @am0o0,

Currently we are not sure this plugin would be a good match for Tsunami. We have mainly a concern with the fact that there is no way in Tsunami to receive an email to receive the password reset link.

Let me know your thoughts. ~tooryx

[am0o0]

We can use some temp free email services without any need to get API keys, but I don't think it qualifies as a tsunami plugin.

[tooryx]

Using a free email service would mean sending vulnerability signals to a third-party service. We should avoid this and keep tsunami standalone (in the sense of external service dependencies) whenever possible.

[am0o0]

I think we can use Gmail API. If we have a config file, I suggest that I have a local config file for this plugin if it is possible. Otherwise, consider adding A config file to fill it with a Gmail API Key ( with the user's responsibility, of course), And Users allow the plugins to use this. Gmail API is free and entirely safe. Checking for new emails is easy too, because we can append a random value at the end of the Gmail address like myEmail+randomValue@gmail.com that we want to send the payload.

[hh-hunter]

@tooryx My idea is to directly detect a specific version match, and if the versions are the same, output the existence of vulnerabilities.

[tooryx]

@am0o0: I personally think that this would make Tsunami more complex (especially to deploy) for one vulnerability. But I will check with the rest of the team and keep you both updated;

@hh-hunter: We do not want Tsunami to perform version-matching checks. This type of check is too flaky and has a higher chance for false positive. We want Tsunami to stay a high-quality scanner;

~tooryx

[hh-hunter]

@tooryx If I find a solution that is not a version match and verifies the vulnerability 100%, is the issue written by me and the prize belongs to both of us?or is there another answer?

[am0o0]

@am0o0: I personally think that this would make Tsunami more complex (especially to deploy) for one vulnerability. But I will check with the rest of the team and keep you both updated;

@tooryx Do you think if it is an optional feature, then it makes the Tsunami plugin ecosystem more complex?

[hh-hunter]

@tooryx @am0o0 By utilizing the feature of sending emails, this vulnerability will definitely perform a DNS resolution on the URL of the email. We only need to take advantage of this opportunity to detect OOB domains and determine if there are any DNS requests, which can indicate whether the vulnerability exists.If this plugin implementation is helpful, please consider accepting my suggestion.

[tooryx]

Hi folks,

You're both suggesting very good ideas. But in all cases, this vulnerability is not a priority at the moment. You both have a few PRs or issues that we are trying to review as part of our backlog, so let's focus on these. We are doing our best to catch up, please bear with us.

~tooryx