| HT news
| SoftwareApache.org compromesso, "spiegare i nostri errori potrà essere utile ad altri"
di Stefano Bellasio
Nella giornata di Lunedi, il sito web della Apache Software Foundation, la fondazione che gestisce, tra gli altri, il noto progetto Apache, ha dichiarato di aver subito un attacco da parte di terzi che ha costretto alla chiusura del sito per qualche ora, mentre i tecnici intervenivano per capire cosa fosse successo.
La Apache Software Foundation, ha subito deciso di rendere noti i dettagli di quanto successo, con un lungo post in cui emergono dettagli del proprio modus operandi in caso di attacco e istruzioni su come lo staff ha deciso di correggere gli errori che hanno consentito l'accesso agli hackers. Tutto ha avuto inizio con l'accesso al server(una CentOS non patchata) che gestisce ApacheCon.com, il sito della conferenza organizzato dalla fondazione; si tratta di una macchina al di fuori dell'infrastruttura di quelle di Apache, ma al suo interno, in particolare nei backup, gli hacker sono riusciti a trovare le password di accesso usate dallo staff dell'associazione per l'accesso al sistema di backup. Primo tentativo fallito, secondo tentativo andato a buon fine utilizzando queste come chiavi ssh, da qui infatti hanno guadagnato l'accesso al server people.apache.org, uno dei principali dell'infrastruttura. Nel frattempo il server di ApacheCon è stato completamente formattato.
Gli hackers, a questo punto, hanno inserito uno script CGI nella document root del server; rsync, a intervalli regolari, copia i contenuti dei server e li porta sui server di produzione di Apache, tra cui anche eos.apache.org. Lo script CGI aveva il compito di ottenere le shell remote e inviare dati tramite istruzioni HTTP POST. Una volta scoperti gli scripts CGI, il team di Apache ha subito iniziato a verificare quali macchine non fossero state compromesse, cercando di spiegare quanto accaduto sulla pagina principale del sito, e spostando la sua visualizzazione su una macchina rimasta illesa.
Uno dei server di Apache è potuto tornare online in tempi brevissimi grazie alla presenza di Solaris 10 e ZFS, il team ha semplicemente utilizzato uno snapshot precedente della macchina per rimetterla online senza alcuna traccia dello script inserito. Il team di Apache ha anche effettuato una analisi di cosa ha funzionato in questa strategia di difesa e cosa no, tra i vantaggi c'è stato l'utilizzo di macchine con sistemi operativi non comuni, come Solaris e FreeBSD, su di queste macchine gli hackers non sono riusciti a guadagnare facilmente i privilegi. Anche l'uso di ZFS ha contribuito ad un ritorno online rapido, così come l'uso di server in Europa e USA.
Ma tra gli errori c'è sicuramente la possibilità di eseguire script CGI in ogni virtual host dei server (da qui è scaturito l'attacco) e la possibilità di pubblicare, tramite rsync, i contenuti presenti su un server su quelli collocati negli USA. Il team scrive che anche l'uso di chiavi SSH è stato un grosso vantaggio e un errore che non verrà ripetuto.
Il software dei repository e il codice presente sulle macchine non ha subito alcuna intrusione o alterazione, e Apache sta verificando tutti i server dell'infrastruttura prima di metterli nuovamente online.