Sulla cifratura della reverse shell (a.k.a. perché il TCP non basta)

Guarda su YouTube → 20:02 25 novembre 2025

Descrizione

Molto spesso, specialmente nei contenuti per i principanti, le reverse shell sono descritte utilizzando payload che non prendono in considerazione il fatto che le informazioni inviate in un socket TCP posssono essere lette da tutti i nodi che vedono il pacchetto nella sua trasmissione. Questo può essere un rischio significativo, specialmente se stiamo testando un sistema. Per ovviare a questo, e per proteggere i dati inviati in una reverse shell, è necessario aggiungere un layer di crittografia, esattamente come accade in HTTPs. In questo video discuto alcuni possibli strumenti che possono essere utilizzati per proteggere una reverse shell. Se vuoi supportare il mio lavoro :) - https://www.patreon.com/hexdump Se vuoi imparare la Sicurezza Informatica: - https://www.udemy.com/course/introduzione-software-security/?couponCode=PSLASHQTWODASHQFOUR Se vuoi imparare la Web Application Security: - https://www.udemy.com/course/practical-wapt/?referralCode=15450B3828BA5A3B23CB Se vuoi imparare la Linux Privilege Escalation: - https://www.udemy.com/course/linux-privesc/?couponCode=33738F67D2C09EB25600 Se sei interessato ai miei servizi di formazione: - https://esadecimale.it TIMESTAMP 00:00 Plaintext Reverse Shell 04:00 Cosa protegge HTTPs 07:30 Opzione 1 - ncat 12:30 Opzione 2 - openssl

Commenti 8

I commenti vengono da YouTube e sono aggiornati periodicamente.

@antoniomarino1745 25 novembre 2025 5

L'entropia nelle password/crittografia e nella sicurezza in generale è un tema interessante 💪💪💪
1 risposta
1. @esadecimale Autore 25 novembre 2025 1
  
  Parlare di Entropia ci porterà a parlare di Claude Elwood Shannon e della teoria dell'informazione :D
@softdav 25 novembre 2025

Bravissimo. Molto chiaro
@paperellacinese 28 novembre 2025

Interessante
@Gica78R 25 novembre 2025 1

Purtroppo (o per fortuna, dipende dai punti di vista 😂), nelle organizzazioni che hanno una rete decente ci sono firewall che fanno decryption del traffico in ingresso e uscita, quindi anche una reverse shell su ssl verrebbe sgamata. In realtà anche senza decryption, se il firewall esamina gli hello nel setup tls, il traffico protetto con un certificato self signed verrebbe droppato immediatamente. In questo caso sarebbe meglio usare certificati Let’s Encrypt, sperare non ci sia decryption e non farsi segare dall’eventuale policy di url filtering.
3 risposte
1. @esadecimale Autore 25 novembre 2025
  
  Per avere meccanismi di decryption devi configurare proprio il client in un certo modo, una reverse shell di un attaccante non utilizzerebbe certificati fatti per creare punti di decryption. Si al massimo ti droppano il traffico, ma non lo posso decifrare in ogni caso, per decifrarlo dovrebbero analizzare la memoria del processo runtime e tirar fuori le chiavi di cifratura, il che non è banale. Non credo ci siano meccanismi che analizzano la memoria di ogni processo che fa partire una connessione di rete per analizzare ed estrarre le chiavi TLS dalla memoria. I meccanismi di decryption funzionano con client standard che sono stati configurati proprio per accettare determinati certificati e via dicendo. Detto questo si, l'idea è sempre quella di assomigliare a traffico "normale" il più possibile.
2. @Gianla. 26 novembre 2025
  
  droppare sì, ma decifrare come sarebbe possibile? Se un firewall tanto potente esistesse, questa strategia la attuerebbe chiunque e la crittografia non avrebbe senso.
3. @Gica78R 26 novembre 2025 2
  
  @Gianla. ci sono i cosiddetti Next Generation Firewalls che fanno esattamente questo: rompono la cifratura SSL facendo da proxy e sostituendo il certificato ssl del sito visitato dall’utente con un certificato generato con la sua CA (la CA del firewall). Il client accetta il certificato perché ha precedentemente trustato la CA del firewall: stiamo parlando di ambienti aziendali in cui tutti i client sono gestiti dall’organizzazione, quindi il trust della CA è imposto dagli amministratori. Laddove non è possibile rompere la cifratura, ad esempio dove l’applicazione ricorre al certificate pinning, comunque si controlla la chain del certificato remoto e se “non piace”, perché è un self signed, allora si droppa il traffico. Questa è ormai la prassi in reti di un certo tipo, dove si cerca di impedire il più possibile l’esfiltrazione delle informazioni. È anche possibile impedire che un utente possa inserire le sue credenziali di dominio su un sito considerato non fidato. Lo dico perché per mestiere gestisco questo genere di firewall.