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
