Come è stato violato Matasano?
È impossibile rispondere dalle informazioni del post a Full Disclosure. Tuttavia è sempre interessante speculare, in quanto forniscono alcune informazioni:
# ./th3_f1n4l_s0lut10n www.matasano.com
[-] Connessione a 69.61.87.163:22 ..
[/] Alla ricerca di un utente non root valido .. adam
******** R3D4CT3D h4h4h4h4 ********
Eseguono il " th3_f1n41_s01ut10n" binario contro il server di Matasano, che si collega alla porta ssh. Trova un utente non root valido attraverso alcuni mezzi sconosciuti e il resto dell'output viene redatto.
# ./th3_f1n4l_s0lut10n -u adam -t 3 www.matasano.com
[*] Listener di Connectback il 209.112.118.10:3338 ..
[!] SSH2_MSG_SERVICE_ACCEPT [OpenSSH_4.5p1, OpenSSL 0.9.8g 19 ott 2007]
Il binario viene eseguito nuovamente utilizzando il nome utente trovato, che accede e si riconnette al loro server sulla porta 3338 (spero che non sia registrato a loro nome ...).
adam_at_www: ~ $ uname -a
Linux www 2.6.20.1-1-686 # 1 SMP dom 4 mar 12:44:55 UTC 2007 i686 GNU / Linux
**** h4h4h4hh4h4h4 l3tz us3 m0r3! 0D4Y! H4H4H4H4H4H4H4 ****
Potrebbero insinuare di avere uno 0-day contro questo kernel, che è piuttosto vecchio se si considera lo stock in trade di questa società.
adam_at_www: ~ $ cd / tmp
*********** B0R1NG ***********
root_at_www: ~ # cat / etc / shadow
Whoops: all'improvviso l'utente è ora root. Hanno un exploit di escalation di privilegi locali in / tmp che potrebbe essere il giorno 0 a cui si riferivano.
Quindi ci sono almeno due exploit in corso qui: l'exploit OpenSSH per ottenere un utente non root valido sul sistema e accedere come tale utente, quindi l'escalation dei privilegi locali.
Considerando che OpenSSH presenta alcuni problemi di sicurezza noti dalla versione 4.5:
Dalla pagina di sicurezza di OpenSSH :
- OpenSSH precedente alla versione 5.2 è vulnerabile alla debolezza del protocollo descritta nel CPNI-957037 "Attacco di recupero del testo in chiaro contro SSH". Tuttavia, in base alle informazioni limitate disponibili sembra che questo attacco descritto sia impossibile nella maggior parte dei casi. Per ulteriori informazioni, fare riferimento all'advisory cbc.adv e alle note di rilascio di OpenSSH 5.2.
- OpenSSH 4.9 e
~/.ssh/rcversioni successive non vengono eseguiti per le sessioni il cui comando è stato sovrascritto con una direttiva ForceCommand sshd_config (5). Questo era un comportamento documentato, ma non sicuro (descritto nelle note di rilascio di OpenSSH 4.9).
- OpenSSH 4.7 e versioni successive non si affidano alla creazione di cookie di autenticazione X11 attendibili in caso di mancata generazione di cookie non attendibili (ad es. A causa dell'esaurimento deliberato delle risorse), come descritto nelle note di rilascio di OpenSSH 4.7.
Immagino che questo vecchio kernel Linux e un vecchio demone SSH abbiano fatto per loro. Inoltre, era in esecuzione sul loro server www, che è disponibile su Internet, il che è una cosa abbastanza sicura da fare secondo me. Le persone che hanno fatto irruzione volevano ovviamente metterli in imbarazzo.
Come prevenire questi attacchi?
Ciò avrebbe potuto essere impedito dall'amministrazione proattiva, assicurando che tutti i servizi connessi a Internet siano corretti e limitando il numero di persone che possono connettersi piuttosto che consentire alle persone di connettersi da qualsiasi luogo. Questo episodio aggrava la lezione secondo cui l'amministrazione sicura del sistema è difficile e richiede la dedizione dell'azienda per fornire tempo all'IT per mantenere le cose riparate - in realtà, non qualcosa che accade facilmente, almeno nelle aziende più piccole.
È preferibile utilizzare un approccio cintura e parentesi graffe: utilizzare l'autenticazione a chiave pubblica, la whitelist sul demone ssh, l'autenticazione a due fattori, le restrizioni IP e / o mettere tutto dietro la VPN sono possibili percorsi per bloccarlo.
Penso di sapere cosa farò al lavoro domani. :)