Thomas Mackenzie ha allertato il team di sviluppo su una grave falla di sicurezza presente in WordPress 2.9 che permetterebbe ad utenti loggati sulla proprio piattaforma di visionare tutti i post presenti nel cestino. La falla è stata prontamente tappata ed è già disponibile la versione 2.9.2 ( solo in inglese per il momento ).

Per maggiori dettagli potete visionare il post del team di sviluppatori.

Io mi sono sempre chiesto cosa volesse indicare quel piccolo lucchetto giallo in basso a sinistra delle icone in Windows 7. Ebbene poco fa lo ho scoperto.
Microsoft con l’introduzione di Windows 7 ha voluto uniformare il suo sistema operativo con lo standard di sicurezza attuale, implementato già da un bel po’ da Linux e Mac OS X. Se ricordare in Windows XP, come in Vista ( e tutti i predecessori ) l’utente poteva creare le cartelle ovunque. Ora invece l’utente, come succede in Linux e nel Mac, dovrebbe lavorare solo nella sua home, con pieni diritti di lettura e scrittura. Se un file viene copiato dalla “home” dell’utente (C:\Users\NomeUtente) in una cartella nella root il sistema operativo segnala l’operazione aggiungendo un lucchetto giallo sull’icona del file o della cartella. Su Linux invece sappiamo benissimo che questo non è possibile, in quando l’utente può solo interagire in scrittura solo nella propria home ( questo ovviamente non vale se stiamo usando l’utente root o un utente con privilegi speciali ).

Il team di sviluppo, dopo la segnalazione di Dawid Golunski ( ne ho parlato ieri in questo post ), sforna una nuova security release del trunk 2.8 di WordPress.

I problemi fixati sono sostanzialmente due, il primo riguarda una vulnerabilità XSS scoperta da Benjamin Flesch, maggiori informazioni sono consultabili a questo indirizzo. Mentre la seconda riguarda proprio la vulnerabilità di Unrestricted File Upload Arbitrary PHP Code Execution.

L’annuncio ufficiale del rilascio è consultabile a questa pagina del team degli sviluppatori.

Si consiglia a tutti gli utenti della piattaforma WordPress si aggiornare al più presto.

Nella giornata di ieri presso Full Disclosure è comparso un interessante advisory riguardante una vulnerabilità presente in WordPress nelle versioni <= 2.8.5 ( l’attuale ). Questa vulnerabilità infatti acconsentirebbe l’esecuzione di codice php arbitrario uploadato tramite l’upload manager di default presente in WordPress.
Per maggiori informazioni e un proof of concept vi rimandiamo all’advisory.

Anche se la vulnerabilità non è critica, in quando per uploadare un file è comunque necessario avere dei diritti superiori a quelli di un utente normale, attendiamo una security release da parte del team di sviluppatori.

Sempre più spesso si legge di persone che contraggono un virus per colpa della chiavetta. Il meccanismo alla base è molto semplice, ogni volta che si inserisce un disco ottico o una chiavetta ( o anche un HD esterno ) il sistema operativo va a leggere il file autorun.inf e se riscontra una stringa del tipo: [autorun] esegue automaticamente il codice seguente. Ovviamente questo non è un bene, in quando il sistema può eseguire un file bat o cmd che contiene un codice malevolo. Il processo che ne deriva può essere bloccato dall’antivirus, ma noi vogliamo agire più profondamente, bloccando qualsiasi autoplay.
Il procedimento è semplice e vale per XP, Vista e Seven; ecco i vari passaggi.

Aprite Start e digitate “gpedit.msc” ( senza virgolette, se siete su Win XP prima premete il tasto Win + R ). Seguite poi questo path.

Configurazione computer -> Modelli amministrativi -> Componendi di Windows -> Criteri autoplay

Ora facciamo doppio click sulla voce Disattiva autoplay e mettiamo la spunta su attivata ( si intende attiva la disattivazione dell’autoplay ). Nel menù a tendina appena sotto selezioniamo Tutte le unità, in questo modo il sistema non eseguirà l’autoplay per nessuna periferica che si andrà ad attaccare al PC.

Con questa piccola chicca saremmo al sicuro da eventuali chiavette infette.

Si tratta sostanzialmente di una versione di mantenimento del trunk 2.8, speriamo sia anche l’ultima prima della nuova 2.9.
Come le versioni di mantenimento precedenti anche questa risolve alcuni problemi legati alla sicurezza.

Ecco il changelog:

• Una correzione per l’attacco di Denial-of-Service via Trackback che si è verificato nei giorni scorsi su molti siti.
• Rimozione di aree nelle quali il veniva valutato del codice contenuto in variabili php.
• Eliminazione dei due importatori di tag di vecchi plugin non più in uso.

Essendo una security release l’aggiornamento è caldamente consigliato, e si può effettuare tranquillamente tramite l’utility di aggiornamento automatico.

Per più informazioni potete dare un occhiata alla pagina del blog degli sviluppatori.

Gli sviluppatore consigliano di installare anche un plugin: WordPress Exploit Scanner, che ha lo scopo di determinare se nella nostra installazione di WordPress ricorrono file sospetti o codici malevoli.

Dopo il rilascio della 2.8.3, avvenuto circa una settimana fa, il team di sviluppo di WordPress rilascia il quarto minor update per il trunk 2.8. Si tratta infatti di una security release che ha come scopo la risoluzione della vulnerabilità di Remote Admin Reset Password, di cui ho parlato in questo post ieri ( include il fix manuale alla vulnerabilità ).
Ricordo che la vulnerabilità non è critica, e non consente l’accesso alla piattaforma da parte di malintenzionati. Nel peggiori dei casi questa vulnerabilità può essere usata per escludere l’account d’amministrazione a tempo indeterminato, effettuando un reset infinito della password del medesimo.

Alla luce di questo, l’aggiornamento della piattaforma è caldamente consigliato. Ricordo sempre che gli utenti aventi un hosting Aruba dovranno seguire questa piccola procedura prima di effettuare l’upgrade.

Per maggiori informazioni potete consultare il post presente nel blog degli sviluppatori a WordPress 2.8.4 ) o aspettate.

Buon upgrade

Oggi nella mailing list di Full Disclosure è stata pubblicata, da Laurent Gaffie, una vulnerabilità che affligge la funzionalità di reset della password di WordPress.
La vulnerabilità coinvolge tutte le versioni <=2.8.3, eppure non si tratta di una vulnerabilità critica, in quanto l’attaccante, effettuato il reset della password, non ne sarà comunque in possesso.

L’advisory originale è consultabile a questo indirizzo, mentre a questo indirizzo potete trovare informazioni supplementari e un fix al problema.

UPDATE

Ora l’advisory è disponibile anche su Milw0rm a questo indirizzo.

Nella giornata di ieri Twitter e Facebook sono stati soggetti di un un attacco DoS ( Denial of Service ), un attacco che aveva lo scopo di mettere KO due dei più famoso siti di Social Network di tutto il mondo. Anche i TG serali italiani hanno dedicato 20 secondi ( si sono proprio sprecati no? ) alla questione, non svelando però i dettagli dell’attacco.

L’attacco è stato portato a termine in maniera congiunta sui due siti da un’unica fonte. Oggi si è cercato di fare un po’ di chiarezza sulle motivazioni dell’attacco di ieri.
Secondo alcune ipotesi il DoS è stato scatenato a causa di motivazioni politiche, tale ipotesi viene avanzate sulla base delle considerazioni fatte da un blogger di nazionalità georgiana, conosciuto nel mondo virtuale con il nickname di Cyxymu. Quest’utente, in possesso di diversi account su siti di social network famosi, come: YouTube, Facebook, Twitter e LiveJournal sarebbe stato preso di mira per via della sua posizione filo-occidentale.

Non è ancora stata rilasciata nessuna notizia ufficiale sul come due colossi del Web possano essere stati messi in ginocchio da un attacco DoS.
Alcuni ipotizzano che sia stato un attacco congiunto di spam e DoS ad aver fatto collassare Twitter per alcune ore e rallentare pesantemente Facebook.

Attendiamo notizie ufficiali….

Twitter nel proprio blog assicura che l’attacco non ha minimamente attaccato i dati degli utenti, ma che si è trattato di un attacco DoS in piena regola. Sia i tecnici di Facebook che di Twitter stanno lavorando per riportare i server allo stato di stabilità.

Queste sono le voci che circolano al momento, credo comunque che l’ipotesi dell’attacco all’utente Cyxymu sia poco probabile. Attaccare due colossi del social network per UN utente… un lavoro “di fino”

Stay Tuned ~

Vediamo come aumentare la sicurezza del nostro blog. Ogni installazione di WordPress crea automaticamente l’utente di default “admin”, infatti, durante l’installazione ci viene data la password dell’utente per effettuare l’accesso alla parte amministrativa del blog.
Quest’utente però è standard ed un eventuale malintenzionato saprà già a priori dell’esistenza dell’utente admin, e quindi gli basterà solo trovare la password ( non che questo sia facile ). Vediamo però di toglierli questa certezza.

Non è possibile modificare l’account dell’utente admin dal pannello amministrativo, dovete per forza modificare il record dell’utente admin nel database MySQL.
Per fare questo è necessario loggare in phpmyadmin, selezionare il database che utilizzate per WordPress e visualizzare la tabella wp_users, la tabella che contiene tutti i dettagli sugli utenti registrati al vostro blog. Di default la tabella ha il prefisso wp_.

Se volete fare le cose in modo geek, potete eseguire la query sottostante per selezionare subito il record dell’utente admin.

SELECT * FROM wp_users WHERE id =1;

Ora dovete solo modificare l’attributo user_login e user_nicename, inserendo la medesima stringa. Magari lasciate l’attributo display_name al valore di default admin. Facendo così, se utilizzate l’utente admin per scrivere post nel vostro blog, un visitatore non può sapere che avete modificato la login name dell’utente amministratore.

È comunque buona regola non utilizzare l’utente admin, ma bensì creare un altro utente ( anche con privilegi minori ) ed usare sempre quello.
Io utilizzo WordPress da più di sei mesi e non ho mai loggato con l’utente admin ( tranne ovviamente la prima volta ).