Welcome back dear readers to another exciting CTF walkthrough for a machine from vulnhub.org DevGuru.

I found this box particularly interesting as it attempts to bring out real-world scenarios of common misconfigurations and vulnerabilities. So let's dive straight in.


After downloading and setting up the .ova file on virtualbox, Let's quickly find out the IP address that has been assigned to our target.

Using Netdiscover to find the IP address

From the Mac Vendor tab we can easily notice that our target is at

There are other ways of finding this information e.g. using nmap, arp-scan e.t.c.

Next let's perform a quick NMAP scan on our target to find the open ports and running services.

This means that we have port 22, 80 and 8585 open.

Let's quickly check what web application we have port 80 as the running service is Apache.

It's a simple web application containing information about DevGuru company.

The technologies employed on this particular web application as per Wappalyzer's results is shown below:-

October is a free, open-source and self-hosted content management system (CMS) based on the PHP programming language and Laravel web application framework. It supports MySQL, SQLite and PostgreSQL for the database backend and uses a flat file database for the front end structure.

To further the information gathered, let's do a quick directory brute force using the default wordlist for the dirb tool.

The other amazing tools that you can use to find this particular information include gobuster, dirbuster (dirb GUI).

Exposed /.GIT/ directory

As discussed in the previous post on how we can exploit misconfigured .git directories, let's go ahead and dump the content of the .git directory and extract the source code of the site for further analysis.

Using the gitdumper.sh script provided at https://github.com/internetwache/GitTools

dumping the .git/ directory content

And further using extractor.sh script from the same link above let's extract the source code.

extracting source code from dumped git content

Checking on the .git/config file we discover that the source code is committed to an application running on port 8585 that we discovered earlier during the NMAP scan.

In my normal day-to-day pentest and security audit job, I normally check on this to understand if the target organization is using their own self-hosted git servers i.e. Gitea, gogs or using cloud based services i.e. Github, bitbucket.

Just to confirm what runs on port 8585, let's head over to

And indeed, port 8585 hosts Gitea git service.

Source code review

Opening the content the source code we just extracted above we see the following:-

Once we have the full source from dumped git repos, the necessary information that we start hunting for is normally:-

- credentials
- API keys
- interesting files
- business logic (upload vulnerabilities e.t.c.)

So from the directory structure shown above, we find an interesting adminer.php, as the name suggests, this should be the single PHP file database manager, let's confirm this.

The config directory looks interesting as it is commonly associated with database connection credentials, API keys and all other interesting information.

Plus from the understanding that OctoberCMS is based on Laravel framework, we can presume that the database connection credentials and other sensitive information is stored on this particular directory. And yeah, here we find the database connection credentials.

Using the interesting adminer.php page we discovered earlier, let's login using these particular credentials.

login successful

CMS Admin Access

Exploring the database content, we find an interesting table called backend_users. There is only one entry of a user called frank.

From the directory brute force section from the recon section, we noted an endpoint with /backend. Checking it, we immediately discover that it's the admin login page for the CMS.

Password reset functionality has also been implemented, so the approach I employed, was to reset the password then use the newly password reset token from the database to update frank's password.

Remember when I mentioned business logic as an important information that we need to look for when we get our hands on source codes.

Going through the authentication and password reset source code, we realize how the link to reset the password is structured once we have a valid password reset code.

Let's pick the reset code from the database and construct a link that would be:-<reset code>

Let's enter a new password for frank and login to the backend admin dashboard

Shell Access

After some hours on trying to execute code from the admin access, I finally dropped to google, which had a direct answer, and the tutorial on achieving this can be found on this particular forum question https://octobercms.com/forum/post/running-php-code-on-pages

Under CMS tab, click on the pages submenu and add a new page.

Let's call the page shell and the URL /shell.

On the markup section let's enter the following code.

This will be used by the template engine to print out the content of the variable myVar.

On the code tab of the editor, let's enter the following code.

Commands sent to the endpoint /shell/?cmd=whoami, will be stored on the myVar variable and printed out by the template engine above.

Let's save and confirm if indeed it works.

And there we go, we have successfully achieved code execution.

Let's gain a more stable interactive code execution by uploading weevely backdoor.

generate and host the weevely backdoor

Then from the web shell, let's use wget to download the backdoor to the server and confirm the existence of the backdoor.

And we connect to it using weevely.

Post Exploitation: Privilege Escalation

From the screenshot above, we notice that we do have sudo permissions and that we need to escalate our privileges.

We go ahead and run LinEnum to automate gathering information about the system, like misconfigured SUID binaries, kernel version, misconfigured file permissions e.t.c.

Above shows that there's a app.ini.bak with read permission to all the system users and groups. Let's open and see it's content.

Wonderful, this is gitea app.ini config file backup which contains the username and the password for the MySQL database that it uses as it's backend DB.

Abusing the adminer.php page that we found earlier, we are in a position to login to the gitea database.

Browsing through the tables, we find the user table with again one entry for user frank

As we tried before, password reset functionality is not enabled for this particular application...

So we have to look for a new method to gain access to the user's account.

Let's change the passwd_hash_algo to bcrypt.

From my research, I realized that the default hashing algorithm for gitea is pbkdf2, let's change this to bcrypt and use this online site https://bcrypt-generator.com/ to generate a new password.

And we are successfully logged into the gitea dashboard.

GIT Hooks

Gitea and Gogs are vulnerable to authenticated remote code execution via the git hooks feature, let's leverage this to gain elevated shell access.

So after login, create a new repository, let's call it privesc.

Next, after you create the repository, click on setting and then select the git hooks tab

Create a post-receive hook and on the editor enter the code as shown, remember to change the IP address and the port to that of the attacker machine and the netcat listening port.

What basically this means is that, after change is pushed to the repository, the bash command will be executed, which in turn will connect back to the attacker with a reverse shell. So go ahead and save the git hook and let's test this functionality.

The next step is to create a new directory on our attacker machine, cd into that directory, initialize git on that directory, create a new file, add it to the repository using git add, commit the changes and set the remote repo where the code will be pushed to.

Let's setup our listener before we push any code

And finally push our local git to the remote git and see if our hook gets executed.

And we receive a reverse shell as so...

We have the flag for gaining privileges for the user frank.

Hunt for ROOT

With this new privilege, let's run LinEnum to find more information about the system.

Let's check GTFOBins for any sudo command we can run with sqlite3 to execute /bin/bash.

Checking the sudo version we realize that it vulnerable to CVE-2019-14287  which is a sudo security bypass vulnerability.

By exploiting this bug and the sqlite3 discovery let's execute the following command and we gain privileges to root user.

And that's it, we are finally root.

There will be a follow up blog on the in depth technical details about some of the misconfigurations and vulnerabilities exploited in this CTF.