Yesterday we received the information that there is a new Gitlab „hack“ which could affect older versions of Gitlab. If affected it will behave like this:
The publicly visible procedure is always the same: Johny creates one or more issues that are linked with each other and at the end of the link cascade there’s either an attached file or a link to a file which holds Gitlab’s
secrets.yml.
Source: https://blog.philipp-trommler.me/posts/2020/07/13/security-possible-gitlab-hack-johnyj12345/
It seems like the vulnerability was fixed with these security release:
https://about.gitlab.com/releases/2020/03/26/security-release-12-dot-9-dot-1-released/
The NWS team wrote some scripts to see if any of the Gitlab CE / Gitlab EE apps are affected, which was not the case, also because NWS apps are running on the latest version of Gitlab.
This issue is very critical since the secrets.yml can be found with a simple web search and contains informations like:
- secret_key_base
- db_key_base
- otp_key_base
If you are affected, you should
- take down your Gitlab instance
- remove the user
- remove the issues
- update your instance.
Best would be to also reset the „secrets.yml“, but as far as i know, there is currently no way to do so.
Here is a short script to check quick if the user exists (if you don’t want to check via web interface):
#!/bin/bash
echo "User.all" | gitlab-rails console | grep "Johny12345" 2>&1
response=`echo $?`
if [ $response == "0" ]; then
echo "[ALERT] Johny was here ... "
else
echo "[OK] No Johny found ..."
fi
Hi,
thanks for sharing. Here’s some more details on the cause.
Recently, a GitLab user posted a blog about the exploitation of a known vulnerability which has been previously disclosed and assigned CVE-2020-10977 at https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-10977. GitLab EE/CE 8.5 to 12.9 is vulnerable to a path traversal when moving an issue between projects.
This issue was remediated and patched in the 12.9.1 release in March 2020: https://about.gitlab.com/releases/2020/03/26/security-release-12-dot-9-dot-1-released/
Upgrading to the latest security release for your supported version is part of good security hygiene. We strongly recommend that all users confirm they are running the latest version of GitLab to ensure they are up-to-date with current security releases. Users should update immediately if needed.
GitLab releases patches for vulnerabilities in dedicated security releases. There are two types of security releases (https://about.gitlab.com/security/#gitlab-security-releases):
– a monthly, scheduled security release, released a week after the feature release (which deploys on the 22nd of each month),
– and ad-hoc security releases for critical vulnerabilities.
You can see all of our release updates on our update page at https://about.gitlab.com/update and view regular and security release blog posts at https://about.gitlab.com/releases/categories/releases/. In addition, the issues detailing each vulnerability are made public on our issue tracker at 30 days after the release in which they were patched.
Keep your instance safe and updated
You can read more best practices in securing your GitLab instance in our blog post at https://about.gitlab.com/blog/2020/05/20/gitlab-instance-security-best-practices/. You can subscribe (https://about.gitlab.com/company/contact/) to receive Security Notices in your inbox, receive security blog updates through our rss feed (https://about.gitlab.com/security-releases.xml) or follow us on twitter (https://twitter.com/gitlab) for release updates.
Cheers,
Michael