Archivi tag: tampering

Verificare la presenza di una backdoor in vsftpd 2.3.4 su *buntu

Circa un mese fa è stata individuata una backdoor all’interno del sorgente di vsftpd, famoso demone FTP server.

vsftpd

  Questa backdoor consente l’accesso alla shell semplicemente digitando come username “X:)“, lasciando il campo password vuoto (maggiori dettagli sulla tarball compromessa li trovate qui). Avendo aggiornato vsftp alla versione 2.3.4 poco dopo il suo rilascio (orientativamente durante gli ultimi giorni di giugno), ho voluto verificare che il demone installato sui miei server non fosse infetto. Ho quindi cercato qualche tool che mi permettesse di effettuare tale controllo, trovando uno scrip per nmap che fa proprio al caso mio. Lo scrip in questione lo potete scaricare da qui. Una volta scaricato, modificatelo ed aggiungete una descripion, ad esempio:

descripion = "check vsftpd 2.3.4 backdoor vulnerability"

da inserire subito dopo categories. Ora assicuratevi che all’interno della directory /usr/share/nmap/nselib/ sia presente la libreria ftp.lua (in caso contrario potete scaricarla da qui). Infine, lanciate lo scrip seguendo la sintassi:

nmap --scrip ftp-vsftpd-backdoor -p 21 <host>

Se l’output di tale scrip sarà simile al seguente:

PORT   STATE SERVICE
21/tcp open  ftp
| ftp-vsftpd-backdoor:
|   This installation has been backdoored (CVE-2011-2523): VULNERABLE
|     Shell command: id
|_    Results: uid=0(root) gid=0(root) groups=0(root)

dovrete correre ai ripari sostituendo la versione “bucata” di vsftpd con quella corretta.

A presto.

PS: ho avuto fortuna, in quanto nessuno dei demoni vsftpd presenti sui miei server conteneva backdoor.

Attacco log injection

L’analisi dei log rappresenta una delle operazioni più importanti dell’ambito della sicurezza dei sistemi, in quanto consente di individuare eventuali tentativi di attacco provenienti dall’esterno (Internet) o dall’interno (la nostra LAN oppure il nostro stesso PC). Inultile dire che, affinchè l’identificazione degli attacchi ed eventualmente degli attaccanti abbia buon fine, è assolutamente necessario che i log siano integri e non siano soggetti a possibili operazioni di tampering (alterazione), il cui scopo è proprio quello di confondere le acque e rendere più difficile il lavoro del sys/net admin di turno.

Ora, esistono sostanzialmente due metodi per attaccare direttamente i file di log: il primo consiste nall’alterazione diretta degli stessi attraverso l’inserimento di stringhe forgiate appositamente per rispecchiare la sintassi dei log creati dall’applicazione vittima; il secondo ha come obiettivo quello di inviare un numero molto elevato di attempt in modo da far aumentare le dimensioni dei file di log e provocare una sorta di attacco DoS basato sull’esaurimento di una risorsa fondamentale, ovvero la memoria di massa (leggasi spazio sull’hard disk).

Affinchè la manomissione dei log possa avvenire nonostante l’attaccante non abbia i permessi di scrittura su tale tipo di file, è indispensabile identificare la sintassi utilizzata in fase di logging dall’applicazione che si vuole attaccare.

Facciamo un esempio pratico. Supponiamo che l’attaccante, dopo una scansione mediante nmap, identifichi apache tra i servizi attivi sulla nostra macchina. L’accesso al sito Web è inoltre subordinato e vincolato dall’inserimento delle giuste credenziali (username e password), misura di sicurezza realizzata attraverso un file .htaccess. La prima cosa che farà l’attaccante sarà quella di studiarsi la sintassi che caratterizza i file di log dell’applicazione in questione. Una volta identificata tale sintassi, creerà delle righe apposite da inserire nei campi di input visualizzati dal browser ed il cui scopo è quello di permettere ad un utente di autenticarsi e quindi accedere ai contenuti del sito Web.

Un file di log non alterato potrebbe apparire nel seguente modo:

 User login failed for: guest
 User login failed for: admin

Nel caso in cui, però, l’attaccante inserisse nei campi di input la seguente stringa:

guest (backslash)nUser login succeeded for: admin

otterrebbe come risultato:

 User login failed for: guest
 User login succeeded for: admin

proprio grazie all’ausilio del carattere di newline (backslash)n.

Inutile dire che una semplice contromisura a questa tipologia di attacco si basa sulla validazione dell’input e sul whitelisting di determinati caratteri (ad esempio mediante l’uso delle espressioni regolari).

Per ciò che concerne invece gli attacchi DoS menzionati in precedenza, una valida contromisura è rappresentata da un uso corretto del logrotate, il quale consente di archiviare i file di log solo per un certo lasso di tempo, provvedendo anche alla compressione degli stessi per risparmiare spazio sull’hard disk.

Fine del post. See ya.

PS: mi dispiace per l’assenza del carattere backslash, ma a quanto pare myblog lo rifiuta categoricamente (credo per motivi di sicurezza).