Writeup DGA - CTF - Gitbad

This article describes my solution for the 150-point challenge called “Gitbad”.

Introduction

La plateforme Gitlab créée par un stagiaire de DGA MI semble être ouverte à tous !

Vous devez en profiter pour retrouver des informations sensibles. Les comptes créés sur Gitlab sont validés toutes les trois secondes.

Start

We have at our disposal a GitLab instance. It is necessary to be registered and logged in to manage our account and see more things.

Once registered, accounts are validated every three seconds, no account confirmation e-mail is sent. Once logged in, you can see that 6 repositories are present. I thought of looking through theses repositories but some of them had more than 240 commits. Doing these searches by hand was going would have taken too much time. So I used gittyleaks, a tool to search for sensitive information in a git repository.

After running this tool on all repositories, it didn’t give me anything very interesting.

Seeing the category of the challenge (web) I said to myself that there must be an exploitation at the level of the application itself. So I decided to look for the version of the GitLab instance.

The version of a GitLab instance can be found at /help. So I get the version that is GitLab Community Edition 8.3.0 and the udpate asap is also displayed in red.

Exploitation

We can use searchsploit to find an exploit. Having tried several exploits without success, I only show the one we are interested in.

searchsploit gitlab
[...]
GitLab - 'impersonate' Feature Privilege Escalation | ruby/webapps/40236.txt
[...]

The id of this exploit is 40236. We can use the -m flag to copy the information related to it.

searchsploit -m 40236
  Exploit: GitLab - 'impersonate' Feature Privilege Escalation
      URL: https://www.exploit-db.com/exploits/40236
     Path: /usr/share/exploitdb/exploits/ruby/webapps/40236.txt
File Type: ASCII text, with CRLF line terminators

Copied to: /home/ap/40236.txt

The person who detailed this feat really didn’t get pissed off, it’s very poorly explained. To explain very briefly, this vulnerability in the impersonation feature introduced in GitLab 8.2 would allow any signed in user to sign in as any other user (including admins).

The easiest way to exploit this vulnerability is to modify the HTML code of the modification form of our profile, it implies to be connected.

Unlike what is “explained” in the exploit file, the authenticity_token token changes on every request, so it is not possible to exploit this vulnerability via a cURL request.

To perform this feat, you need to know the administrator account ID. It can be found in the Merge Requests tab, there is a drop-down list that displays all users and at the same time its ID which is 8e4684f1498aad818870376301b15426.

By browsing the /profile route, you access a forum to modify your profile, here are the steps to do:

• Locate the beginning of the HTML form.
• Modify the action attribute of this form by /admin/users/stop_impersonation?id=8e4684f1498aad818870376301b15426.
• Modify the name of one of the fields (I modified the identifier of the Skype) by _method.
• Add delete in the location field value.
• Click on Save changes.

Once the form is submitted, we are now an administrator. By displaying the admin area, you can see that a project you didn’t see before is now visible.

The stephan/my-secret-project repository contains a commit (81b6f011) with the message added my private key. By displaying this commit we can see the following content.

+flag: W3lL-d0N3-y0u-w1n-a_c4ke!

This flag is the one to validate this challenge.