If this RCE vulnerability was exploited on your instance, it’s possible that abuse or malicious user access to the system may persist even after upgrading or patching GitLab.
Unfortunately, there is no one-size-fits-all solution or comprehensive checklist one can use to completely secure a server that has been compromised. GitLab recommends following your organization’s established incident response plan whenever possible.
The suggestions below may help mitigate the threat of further abuse or a malicious actor having persistent access, but this list is not comprehensive or exhaustive.
GitLab-specific:
- Audit user accounts, delete suspicious accounts created in the past several months
- Review the GitLab logs and server logs for suspicious activity, such as activities taken by any user accounts detected in the user audit.
- Rotate admin / privileged API tokens
- Rotate sensitive credentials/variables/tokens/secrets (located in instance configuration, database, CI pipelines, or elsewhere)
- Check for suspicious files (particularly those owned by
gituser and/or located intmpdirectories) - Migrate GitLab data to a new server
- Check for crontab / cronjob entries added by the
gituser - Upgrade to the latest version and adopt a plan to upgrade after every security patch release
- Review project source code for suspicious modifications
- Check for newly added or modified GitLab Runners
- Check for suspicious webhooks or git hooks
Additionally, the suggestions below are common steps taken in incident response plans when servers are compromised by malicious actors.
- Look for unrecognized background processes
- Review network logs for uncommon traffic
- Check for open ports on the system
- Establish network monitoring and network-level controls
- Restrict access to the instance at the network level (restrict access to authorized users/machines only)
- Decommission servers that were compromised
- Migrate data on the compromised server to a new server with all the latest security patches