La L in Linux sta per (movimento) laterale

Questo post sul blog non vuole essere una guida all'hacking di Linux; ha lo scopo di informare gli addetti alla sicurezza della rete sulle potenziali minacce che possono interessare le proprie reti.

La maggior parte (se non tutti) dei protocolli che tratteremo in questo post non sono disponibili immediatamente, ma devono essere configurati in un modo specifico per raggiungere il movimento laterale. Non forniremo guide che descrivono come abusare dei protocolli descritti in questo post.

Speriamo di aumentare la consapevolezza di altri protocolli che possono essere configurati in modo tale da poter fungere da falla vulnerabile che può essere abusata dai criminali. Un hacker determinato può e troverà e abuserà dei protocolli trattati in questo post senza che noi glielo diciamo: vogliamo che gli addetti alla sicurezza siano preparati per risolvere questo problema.

Per aiutare ulteriormente gli addetti alla sicurezza, abbiamo collaborato con il nostro team di Infection Monkey. Infection Monkey è una piattaforma di attacco e violazione automatica open source che mette alla prova la rete contro molte tecniche comuni di movimento laterale e propagazione in rete. 

Il team di sviluppo ha utilizzato i risultati della nostra ricerca e li ha integrati come nuova tecnica di exploit all'interno dello strumento. Gli addetti alla sicurezza possono utilizzare Infection Monkey per testare la propria rete rispetto ad alcune delle tecniche di esecuzione remota menzionate in questo post.

[Nota: questa sezione riguarda il metodo che abbiamo usato per trovare interessanti obiettivi per acquisire il movimento laterale. Se non ti interessa questa metodologia e preferisci passare direttamente all'azione, puoi procedere alla sezione Protocolli che consentono l'esecuzione immediata del codice.]

Poiché stiamo cercando protocolli e servizi di movimento laterale, possiamo considerare sia l'aspetto del sistema operativo che l'aspetto della rete quando cerchiamo potenziali candidati; vale a dire, possiamo cercare i processi più comuni nei computer Linux o nelle porte di ascolto più comuni. Non dovremmo trascurare l'uno a favore dell'altro poiché possono esserci diverse implementazioni dello stesso protocollo (nome di processo diverso, stessa porta) o un singolo processo con porte multiple o variabili (come le porte effimere in RPC).

Quando abbiamo esaminato le principali porte utilizzate nella comunicazione con i computer Linux, abbiamo osservato che SSH (porta 22) dominava l'elenco, ma c'erano anche altri candidati promettenti per l'indagine: FTP (porta 21), SNMP (porta 161) e Sun RPC (porta 111). 

Ci sono anche alcune porte che sono state gestite da sshd (il processo daemon SSH) anche se non hanno nulla a che fare con SSH. Partiamo dal presupposto che queste porte sono utilizzate nei tunnel SSH e sono, quindi, al di fuori del nostro ambito di indagine. 

Prendiamo, ad esempio, le porte 135 e 5985, utilizzate rispettivamente in Windows per RPC e WinRM. Non ci aspettiamo quelle porte sui computer Linux, soprattutto quando sshd è in ascolto. È più probabile che sia stato aperto un tunnel SSH su un computer Linux disponibile esternamente per consentire l'accesso ai computer interni. Poiché i tunnel SSH reindirizzano solo il traffico verso un altro destinatario, non contano molto quando si considera il movimento laterale nell'host del tunnel.

Tra i nostri risultati, sono emersi due processi interessanti da prendere in considerazione: xinetd e rpcbind. Non sono praticabili come obiettivi per il movimento laterale, in quanto non offrono molte capacità; sono principalmente utilizzati per operazioni di ricerca per mappare la comunicazione e le porte ad altri processi. Invece, possiamo usarli per trovare altri servizi interessanti.

xinetd (e il suo predecessore, inetd) viene utilizzato per controllare e gestire i daemon. Osservando l'elenco predefinito di daemon che gestisce, possiamo trovare rexec, nonché rlogin e rsh, tutti parte della suite di comandi r di Berkeley. È inoltre possibile trovare vari daemon FTP, VNC e Telnet.

rpcbind è il processo portmapper RPC per Sun RPC. I server RPC si registrano con il portmapper e i client possono interrogare il portmapper per trovare la porta temporanea del server. A differenza di MS-RPC, Sun RPC utilizza i numeri di programma per identificare server RPC specifici e questi sono registrati con l'estensione IANA (Internet Assigned Numbers Authority). Guardando i programmi registrati, possiamo vedere alcuni nomi interessanti, come rexec e NFS.

24% dei computer Linux testati

Indipendentemente dalle funzionalità integrate, anche SNMP è un obiettivo per i criminali, che, a volte, utilizzano le vulnerabilità nelle implementazioni SNMP presenti nei router e nei dispositivi IoT per violare le reti. L'abuso di SNMP è arrivato al punto che la CISA (Cybersecurity Infrastructure Security Agency) ha rilasciato una notifica sul protocollo.

Per aiutare a testare questa minaccia, abbiamo collaborato con il nostro team di Infection Monkey per sviluppare un plug-in di exploit per il plug-in EXTEND remoto SNMP. L'esecuzione di Infection Monkey ti consentirà di osservare come sarebbe questo attacco all'interno del tuo ambiente e di verificare che la tuo sistema di sicurezza sia adeguato per respingere l'attacco. L'attacco SNMP è disponibile nell'ultima versione di Infection Monkey, la v2.2.1.

10% degli ambienti Linux testati

No, non stiamo parlando specificamente di RDP, il protocollo desktop remoto proprietario di Microsoft (ma apparirà, non preoccuparti). Esistono altri protocolli di desktop remoto che possono essere eseguiti su computer Linux. Sono molto meno comuni rispetto agli ambienti Windows, poiché sono pensati per condividere desktop grafici e la maggior parte dei server Linux viene installata senza alcun ambiente desktop. 

Tuttavia, abbiamo osservato che quei protocolli sono stati utilizzati in alcune reti, quindi abbiamo stilato un elenco e sono inclusi qui:

• X Window System è un sistema di finestre desktop disponibile per Unix anche in grado di ascoltare connessioni remote. Utilizza le porte TCP 6000+ (inizia con la porta 6000, ma il numero di porta aumenta successivamente per ogni server desktop in esecuzione).

• VNC si basa sul protocollo RFB (Remote Framebuffer) e utilizza le porte TCP 5900+ (analogamente a X, il numero di porta aumenta con ogni server desktop in esecuzione).

• Xrdp è un'implementazione del protocollo Microsoft RDP che può essere utilizzato su computer non Windows. Come implementazione di RDP, utilizza la porta 3389.

Alcuni dei protocolli di desktop remoto sono più sicuri di altri, ma tutti possono potenzialmente essere oggetto di abusi da parte dei criminali. Esistono anche molteplici implementazioni dei protocolli in Linux, motivo per cui abbiamo incluso qui i numeri di porta invece dei nomi dei programmi.

4% degli ambienti Linux testati

Come SSH e rlogin, anche Telnet è un protocollo per console e controllo remoti. È anche non sicuro e non crittografato, in modo simile a rlogin e vulnerabile ad intercettazioni o attacchi di sniffing di pacchetti. L'abbiamo osservato solo in circa il 4% delle reti che abbiamo esaminato, ma significa che è ancora in uso e potrebbe influire sulla vostra rete. Il protocollo utilizza la porta TCP 23 o 2323.

1% degli ambienti Linux testati

I comandi in R di Berkeley indicano una suite di programmi che consente di eseguire operazioni remote sui computer in rete. Originariamente sviluppati come parte di BSD, sono stati in gran parte sostituiti da SSH, principalmente a causa dei problemi di sicurezza di quei protocolli (nessuna crittografia e autenticazione minima o inesistente). 

Tuttavia, abbiamo osservato alcuni dei daemon della suite qua e là, quindi è troppo presto per escluderli del tutto. Vorremmo evidenziare in particolare tre daemon:

1. Rexec: fornisce l'esecuzione di comandi in remoto; utilizza la porta TCP 512

2. rlogin: fornisce accesso remoto e console; utilizza la porta TCP 513

3. rsh: simile a rexec, ma non richiede autenticazione; utilizza la porta TCP 514

Anche se non consente direttamente il controllo remoto o l'esecuzione, il solo fatto di poter trasferire i file al computer preso di mira può rivelarsi prezioso per lo sviluppo di un attacco. Diamo un'occhiata, ad esempio, alla comune tecnica (e strumento) di movimento laterale PsExec, anche se è basata su Windows.

Innanzitutto, copia il file binario del servizio sul computer di destinazione tramite SMB e solo successivamente esegue il servizio comunicando con il gestore del servizio in remoto. Ecco perché riteniamo che sia importante mappare anche i vari modi in cui gli strumenti e i file binari degli autori di attacchi possono essere posizionati sui computer di destinazione. Abbiamo anche teorizzato alcuni metodi per abusare del trasferimento di strumenti per ottenere l'esecuzione remota, di cui parleremo più avanti in questo post.

31% degli ambienti Linux testati

FTP (File Transfer Protocol) è uno dei protocolli più classici (è stato il primo protocollo a livello di applicazione insegnato nel corso di networking). Utilizzato per il trasferimento di file, è un protocollo basato su testo non sicuro, poiché utilizza testo in chiaro.

20% degli ambienti Linux testati

18% degli ambienti Linux testati

L'NFS (Network File System) è un altro modo per creare file server. È basato su Sun RPC (porta TCP 111). Ci sono molte funzioni RPC che possiamo esaminare, ma non abbiamo trovato un modo immediato per ottenere l'esecuzione di comandi remoti tramite esso.

16% degli ambienti Linux testati

rsync è un'utilità per il trasferimento di file e la sincronizzazione tra computer in rete. Può essere eseguito come un servizio o un daemon e può fornire file tramite il suo protocollo dedicato (porta TCP 873), rsh o SSH.

Possiamo esaminare il trasferimento di file quanto vogliamo, ma non è molto utile a meno che gli autori di attacchi non riescano in qualche modo a eseguire i file trasferiti. Oltre a indurre l'utente a eseguire egli stesso il file, abbiamo pensato a due opzioni per ottenere l'esecuzione: entrambe richiedono una sorta di configurazione errata o un (grave) allentamento delle impostazioni di sicurezza.

Esistono molte posizioni legittime nel file system Linux che possono essere utilizzate per installare la persistenza, ma per il movimento laterale ci concentreremo su /etc/cron.hourly. Se un criminale può caricare un file in questa posizione, con i permessi di esecuzione, verrebbe semplicemente eseguito all'ora successiva, ottenendo così il movimento laterale a lungo ambito.

Ma, per fare ciò, un criminale richiederebbe permessi sudo o di root, che non sono facili da ottenere. Purtroppo, è possibile configurare i file server in modo non sicuro, il che consentirebbe esattamente questo scenario (vedere, ad esempio, rsync). Perché qualcuno dovrebbe configurare quei servizi con così poca sicurezza? Perché è conveniente e facilita la vita. Per favore, non essere tu quel qualcuno: proteggiti.

Uno scenario molto più plausibile, invece dell'accesso a /etc, sarebbe l'accesso remoto a una cartella radice web di un server web attivo. In tal caso, dovrebbe essere possibile caricare una web shell personalizzata e utilizzarla per eseguire comandi remoti. Esistono molti esempi di web shell disponibili online, quindi i criminali non devono nemmeno inventare la ruota.

Un altro aspetto che sta diventando sempre più popolare negli ultimi anni sono i container. Nella nostra ricerca, abbiamo osservato più istanze di programmi container che ascoltano e accettano connessioni e sembra che siano consentite per impostazione predefinita. Se i criminali possono accedere a un gestore di container remoto, possono caricare la propria immagine dannosa e utilizzarla per propagarsi ulteriormente all'interno della rete.

Ora che abbiamo illustrato i potenziali modi a disposizione dei criminali per accedere ai computer, è tempo di discutere su come contrastarli.

Come abbiamo già accennato, nessuno dei protocolli qui descritti viene installato e configurato con Linux pronto all'uso. Qualcuno deve installarli appositamente. Pertanto, il primo obiettivo aziendale sarebbe quello di avere una buona visibilità su ciò che è in esecuzione e comunica (o ascolta la comunicazione) in rete: come ha scritto Sun Tsu, "Se non conosci né il nemico né te stesso, soccomberai in ogni battaglia".

Dopo aver fatto l'inventario della rete e identificato uno dei servizi discussi qui, il passaggio successivo è controllare la configurazione di tali servizi. Ad esempio, un agente SNMP aggiornato configurato per utilizzare SNMPv3 con l'autenticazione Kerberos è perfetto. SNMPv2 con una stringa di community facilmente indovinabile? Non proprio.

Altri protocolli o servizi possono forse essere sostituiti con protocolli più nuovi e più sicuri, come l'utilizzo di SSH invece della suite r-command o Telnet. Alcuni protocolli, come FTP o rsync, possono anche essere incapsulati su SSH, per l'ulteriore vantaggio della crittografia fornita da SSH. È ovvio: dovrai assicurarti che anche SSH sia configurato correttamente, con PKI o password complesse che non siano facilmente decifrabili.