0x30 Preliminary Notes

0x40 Lab Setup

0x41 Build

• The host machine must have Docker and Docker Compose pre-installed
• Download this repository: git clone https://github.com/lyy289065406/CVE-2020-13277
• Generate cracked key pair: ./keygen.sh or ./keygen.ps1
• Build and run GitLab (ensure port 80 is not occupied): ./run.sh or ./run.ps1
• After about 5 minutes, you can log in to GitLab from the browser: http://127.0.0.1 (the first login requires resetting the password of the admin account root)

0x42 Crack

When generating the cracked key pair earlier, the public key has already been written into the GitLab container backend. The private key still needs to be uploaded to GitLab through the frontend to complete the cracking:

• The key pair is generated in the ./gitlab/keys/ directory, copy the content of .gitlab-license (the private key) from it
• Open http://127.0.0.1/admin/license/new as the root user
• Choose Enter license key, paste the private key, and click the Upload license button to complete the cracking

At this point, the Mirror Repository - Pull function is activated

0x43 Outbound Settings

• Open http://127.0.0.1/admin/application_settings as the root user
• Find Outbound requests at the very bottom and check Allow requests to the local network from hooks and services, then save

Now Mirror Repository - Pull supports pulling local Repository

0x44 Setup Runner

• Open http://127.0.0.1/admin/runners as the root user
• Find the registration token and copy it
• Register the Runner: ./register.sh $TOKEN or ./register.ps1 $TOKEN

Now all Repository can use this Runner to execute CI scripts (Pipeline Jobs)

0x50 Lab Verification

The verification process can refer to the official Issue, but the following verification process will be slightly adjusted for this lab.

0x51 Pre-build Accounts for Verification

Open http://127.0.0.1/admin/users as the root user to create 3 accounts:

• victim: victim account
• attacker1: attacker account 1
• attacker2: attacker account 2

When creating an account, you cannot set an initial password. GitLab will push the initial password to the set Email by default. For convenience, you can fill in any Email, create the account, and then immediately edit the account. At that point, you can set the initial password for the account as root without going through Email.

0x52 Pre-build Victim Repository

• Log in to GitLab with the victim account
• Create a new project New Project:
  • Name: target
  • Visibility Level: Private
• Create a new README.md file in the repository, set its content arbitrarily as mykey is abcxyz

Obviously, target is the private repository of victim, and our goal is to exploit the vulnerability to obtain the content of this repository.

0x53 Create Attacker's Poc Repository

• Log in to GitLab with the attacker1 account
• Create a new project New Project:
  • Name: poc
  • Visibility Level: Public
• Create a new file .gitlab-ci.yml in the repository with the following content:

[Purpose] In the following operations, some tricks will be used to make victim execute this CI script with its privileges without its knowledge.

Because the current lab has no certificate configured, only the http protocol can be used; additionally, 172.168.30.2 is the IP assigned by docker-compose.yml to the GitLab container. Since this CI script will eventually be executed by the Runner, and the Runner and GitLab are not in the same container in the current lab, the IP assigned by Docker must be used.

0x53 Create Attacker's Poc Mirror Repository

• Log in to GitLab with the attacker2 account
• Create a new group New Group:
  • Name: test
  • Visibility Level: Public
• Create a completely empty project New Project within the test group:
  • Name: poc
  • Visibility Level: Public

Configure the mirror repository via Settings => Repository => Pull from a remote repository:

• Mirror repository: Checked
• Git repository URL: Enter http://GITLAB/attacker1/poc
• Password: (Leave blank, the pulled repository is Public, no password required)
• Trigger pipelines for mirror updates: Checked (triggers CI script execution on mirror sync)

After successful configuration, it will check every 30 minutes if the source repository has changed; if it has, a forced sync will be performed.

The Git repository URL points to the poc repository created earlier. The reason for not using 127.0.0.1 is that Pull is prohibited from pulling local repositories, but this can be bypassed using DNS: GITLAB is the hostname assigned to the GitLab container by docker-compose.yml, and it is set in /etc/hosts by default. Although the host machine cannot resolve GITLAB, inside the container it effectively accesses http://127.0.0.1/attacker1/poc

0x54 Force Transfer Ownership of Poc Mirror Repository to Victim

• Continue using the attacker2 account
• Open http://127.0.0.1/groups/test/-/group_members to manage users of the test group
• Add the victim user to the group:
  • Add new member to test: victim
  • Permissions: Owner
  • Expiration date: (Leave blank, i.e., no expiration)
• Click the account avatar in the top right corner => Setting => Account => Delete account to delete the current account (attacker2)

[Purpose] In the test group, there are only two Owner users: victim and attacker2. After the attacker2 user is deleted, the ownership of the test group and all repositories under it will be forcibly transferred to victim. Currently, under the test group, there is a test/poc repository that is mirrored from attacker1/poc. This effectively means the test/poc repository is forcibly adopted by the victim user.

0x55 Launch Attack

First, let's summarize the current situation:

• The attacker forcibly and secretly created a test/poc repository for the victim victim
• The content of the test/poc repository is synchronized via mirror from the attacker1/poc repository (checks every 30 minutes for changes requiring sync)
• The content of the attacker1/poc repository is controlled by the attacker, including the CI script .gitlab-ci.yml
• Because the test/poc repository has Trigger pipelines for mirror updates enabled, the CI script will be executed during each sync
• Because the Owner of the test/poc repository is victim, the CI script will run with the privileges of victim

Review the content of the previously set CI script .gitlab-ci.yml. This poc uses victim's privileges in the Runner to access the directory structure and README.md of its Private repository target:

After that, the attacker only needs to arbitrarily modify some irrelevant content in the attacker1/poc repository. In the worst case, just wait 30 minutes, and the set CI script will be executed with victim's privileges.

Although the attacker does not have direct permission to access the execution results of Pipeline Jobs, they only need to adjust the output target of the script, such as sending the repository content to a specified Email or FTP server, to steal the repository code.