Security Archivi - Pagina 2 di 3 - DREAMSNET.IT - IT Solutions. Realizzazioni Siti Web, Siti Internet, Software gestionali, consulenza sistemistica Linux

Symlink attack su Webserver apache. Dallattacco alla difesa. Un esempio pratico e la configurazione corretta.

Un attacco di tipo symlink (collegamento simbolico n.d.t.) non è qualcosa di sicuramente nuovo in ambito unix-like. Curioso è invece vedere come online ed anche ultimamente ci siano sempre più forum dedicati che parlino di come arginare questa piaga : la gioia di tutti gli attacker odierni.

Se prendiamo questa due pagine ad esempio http://whmscripts.net/misc/2013/apache-symlink-security-issue-fixpatch/ , http://www.linuxkatta.com/cPanelFix/solutions-for-handling-symlink-attacks/ , vediamo come sia attualissimo il problema e che addirittura si millantano patch da parte di due colossi operanti nel settore hosting come Rack911 e cPanel.

Ciò ha del ridicolo, ed è praticamente assurdo in quanto già di default Apache prevede un elegante modo per risolvere il problema , ovvero disabilitare l’opzione FollowSymLinks e sostituirla con SymLinksIfOwnerMatch

La prima opzione permette di disabilitare completamente Apache dall’attraversare link simbolici, la seconda permette di sostituire la prima in maniera intelligente, ovvero “se e solo se” il proprietario del file target a cui punterà il link simbolico sia lo stesso del link.

Ciò permetterà di continuare ad usare quelle feature di Apache come l’url rewriting, (tramite mod_rewrite).

In questo modo e con una corretta separazione dei privilegi a livello di virtualhosting utilizzando Apache in modalità FastCGI o tramite PHP-FPM come abbiamo accennato in QUESTO PRECEDENTE ARTICOLO, si riuscirà a confinare forzatamente l’attaccante all’interno della propria home, ed evitare che scorrazzi indisturbato nel server o nelle home degli altri utenti.

Una delle preoccupazioni da adottare al momento di configurare Apache è anche quella di evitare che l’attaccante con un file .htaccess ad-hoc da lui caricato possa riabilitare l’opzione FollowSymLinks e che possa vanificare in pochi secondi i nostri sforzi.

Nel video alla fine di questo breve articolo troverete la dimostrazione pratica dell’attacco senza censura alcuna e una guida passo passo alla risoluzione del problema mostrandovi la configurazione corretta di alcuni file apache per un vhost che abbiamo usato per il nostro esperimento.

Buon proseguimento.

To all english readers :

Simply you can correctly configure Apache to limit this type of attack.

The steps you take are 3:

Eliminate the option FollowSimLinks
Add the option SymLinksIfOwnerMatch
Remove the possibility of reactivating FollowSimLinks through a htaccess file.

Edit the configuration file for the vhost and set the following configuration:

Options-Indexes-FollowSymLinks + ExecCGI + SymLinksIfOwnerMatch
AllowOverride All Options = ExecCGI, SymLinksIfOwnerMatch, Indexes

In this way, no attacker will be able to do this kind of attack.

Ottimizzare un server LAMP. mod_php vs suphp vs fcgid fastcgi vs php-fpm. La modalità ottimale per un ambiente in virtual hosting

Progettare bene un web server, significa anche effettuare una scelta opportuna su come far girare l’interprete PHP.

Se è vero che Apache di default fornisca il classico mod_php che va bene tecnicamente per tutte le configurazioni senza (apparentemente) troppi problemi, è anche vero che guardando nel dettaglio tutte le varie possibili soluzioni, con un pizzico di tempo potremmo effettuare una configurazione ottimale sopratutto per quei server WEB che si ritrovano a far girare più siti web in modalità virtual hosting (più siti su un solo server).

A differenza di un web hosting dedicato (un server web su cui gira uno o più siti dello stesso cliente) lavorare in ambiente condiviso implica ragionare tenendo conto di concetti importantissimi per la sicurezza e le prestazioni : la separazione dei privilegi e il modo in cui viene implementata questa caratteristica.

Va premesso che questo articolo non affronterà la parte tecnica dell’installazione e configurazione di ogni possibile modalità (per quello ci sono innumerevoli tutorial in rete), ma vuole essere una panoramica introduttiva che aiuti il lettore a fare una scelta oculata tra soluzioni apparantemente equivalenti ma profondamente diverse.

Al fine di gestire un sito PHP, il server deve interpretare il codice PHP e generare una pagina quando i visitatori accedono al sito.
Si interpreta il codice in base a quale libreria PHP si sta utilizzando, ad esempio PHP 4 o PHP 5.
Un handler PHP (o gestore) è colui che effettivamente carica le librerie in modo che possano essere utilizzate per l’interpretazione.
I gestori di PHP determinano come PHP viene caricato sul server.

E’ fondamentale per le prestazioni del server, selezionare il gestore che si adatta meglio alla propria situazione.
Selezionando il gestore giusto è importante tanto quanto la versione di PHP stesso.
Un gestore non è necessariamente sempre migliore di un altro, ma dipende dalla configurazione e dalle esigenze.

Di quale caching avete bisogno ? Di quali moduli avete bisogno ? ecc …

mod_php (DSO)

DSO è anche conosciuto come mod_php. DSO significa: Dynamic Shared Object. Questa è una configurazione o, ma è generalmente considerato il gestore più veloce.
Gestisce PHP come modulo di Apache. Ciò significa che gli script PHP verranno eseguiti come utente Apache, che è l’utente: ‘apache o httpd o www-data o nobody’.

Riguardo mod_php si dovrebbe dire ben poco. Esso è infatti installato di default in tutte le distribuzioni Linux al momento che si installi un Webserver APACHE con PHP.
Va sottolineato Apache e non webserver alternativi come lighthttpd o NGINX, perchè mod_php non funzionano con questi altri.
E’ la soluzione classica, la più utilizzata dagli utenti pigri, ma sicuramente non la più ottimale. Nemmeno la più sicura.

mod_php infatti non dispone di caratteristiche di progettazione atte a garantire una separazione privilegi adeguata. Anzi, non la offre proprio.
Esso infatti si limita ad eseguire gli script PHP con gli stessi permessi del webserver che lo invoca, normalmente httpd, www-data, apache o nobody.

Ciò significa che per gestire vhosts multipli si dovranno impostare i permessi dei singoli vhosts con permessi non separati tra loro, dando la possibilità al webserver di leggere e scrivere file e cartelle con i permessi del webserver stesso.

DSO ha due inconvenienti. In primo luogo, tutti i file creati da uno script PHP avrà la proprietà dell’utente con cui gira Apache.
Essi non saranno leggibili dal webserver altrimenti. Siti web che hanno bisogno di caricare i file tramite PHP avranno problemi di autorizzazione di file a patto di non modificare i permessi in configurazioni fin troppo permissive.

Il secondo svantaggio è un problema di sicurezza. I file creati avranno la proprietà del webserver. Se un hacker trova un exploit nello script PHP, potrebbe realizzare un file con gli stessi privilegi file di sistema importanti che sono anche di proprietà del webserver. Questo darà loro la possibilità di modificare i file al di fuori di tale account utente.

Per ovviare a queste mancanze sono state implementate feature empiriche e obsolete come safe_mode() e l’open_basedir(), puri palliativi per tentar di arginare un male che va risolto alla radice.

Risolvere alla radice il male significa usare configurazioni che supportano la separazione dei privilegi.
Tra queste troviamo suPHP, FCGId (tecnicamente l’evoluzione di FastCGI) e PHP-FPM.

suPHP

suPHP è stato il primo abbozzo per tentare una reale separazione privilegi utenti.

SuPHP altro non è che un modulo per Apache che ci dà la possibilità di presentarci al sistema come un utente differente dal default (www-data, httpd o apache).
Esso funziona solo su Apache e come il precedente mod_php è inutilizzabile su altri webserver.

Tra i suoi vantaggi :

Ogni vhost esegue PHP con il proprio user/group
I file PHP possono avere permessi 640 (rw-r—–). Ciò è perfetto per i file di configurazione con password e dati sensibili
I file e le cartelle create da PHP sono scritte con user/group del proprio vhost.
Può essere usato un file php.ini per ogni vhost (configurazioni personalizzate, impostazioni di sicurezza e performance su misura)

L’obiettivo lo raggiunge bene se non fosse a scapito delle prestazioni davvero ridotte.

Esso infatti è circa il 30 – 40% più lento e meno performante del classico mod_php.

Questo succede per le tempistiche bibliche dello spawning di un nuovo processo per ogni richiesta e l’effettuazione di una fork() che rende il tutto davvero ingestibile e inaccettabile sopratutto su siti ad alto traffico o su server che ospitano centinaia o migliaia di siti in virtual hosting.

fcgiD e FastCGI

fcgid invece è una soluzione derivata dal più obsoleto e non mantenuto fastcgi da cui prende comunque l’assonanza nel nome.

FastCGI (aka: mod_fcgid o fcgi) è una variante del CGI (Common Gateway Interface) ad alte prestazioni.

Ha la sicurezza e proprietà nonchè vantaggi di suPHP riguardo alla separazione dei privilegi degli utenti.
Inoltre può essere utilizzato a differenza di mod_php e suPHP anche su webserver diversi da Apache.

La differenza principale con suPHP è che con FastCGI si può risparmiare notevolmente sulle prestazioni della CPU e dare velocità prossime a quella della DSO (mod_php).
Può essere utilizzato anche con un opcode cacher come eAccelerator o APC, che può ulteriormente aiutare velocità il caricamento delle pagine, ma a causa della separazione privilegi dei processi non potrà accedere alla memoria condivisa di cacher come APC, xCACHE, eAccelerator.

Ciò si traduce in un elevato utilizzo della memoria. Questo anche perché invece di creare il processo di PHP ogni volta che viene chiamato, come suPHP, mantiene una sessione persistente aperta in background.

Se vi piace la sicurezza offerta da suPHP e volete avere performance simili a quelle di DSO (ovvero molto veloci) questa è una soluzione da tenere in considerazione sopratutto su versioni di php inferiori alla 5.3

PHP-FPM

A partire da php 5.3 infatti è stata implementata e messo in produzione il gestore PHP-FPM acronimo di FastCGI Process Manager.

PHP-FPM è una implementazionealternativa di PHP FastCGI con alcune funzioni utili per i siti di qualsiasi dimensione e specialmente per i siti e webserver particolarmente carichi.

PHP-FPM è destinato principalmente ai siti web gravati da numerose richieste HTTP. E’ possibile lanciare più pool di processi FastCGI in ascolto su porte separate per soddisfare le esigenze di ambienti virtuali multi-dominio in virtual hosting.

Offre inoltre:

Processo di gestione avanzato con possibilità di fare uno stop/start controllato.
La possibilità di avviare lavoratori con differenti uid/gid/chroot/ambienti e impostazioni di php.ini diverse (sostituisce safe_mode)
Registrazione di stdout e stderr .
Riavvio di emergenza in caso di distruzione accidentale della opcode cache
Supporto per l’upload accelerato.
Supporto per lo “slowlog” che registra le pagine che richiedono troppo tempo per essere completate

È possibile utilizzare PHP-FPM come back-end a qualsiasi server web e non essere più legati ad Apache.
Un altro vantaggio (che ha anche mod_php), è quello di gestire la memoria condivisa e dunque gestire in modo trasparente e indolore sistemi di caching PHP come APC, eAccelerator, xCACHE.

Riassumendo in breve:

	Sicurezza	Prestazioni	Integrazione Caching	Adatto Virtual Hosting	Non Apache
mod_php	Bassissima	Altissime	Si. Molto facile e indolore	No. Sconsigliatissimo	No
suPHP	Altissima	Bassissime	No.	Si. Non consigliato	No
FastCGI	Altissima	Alte	Si. Complessa, pochi vantaggi	Si. Consigliato	Si.
PHP-FPM	Altissima	Molto Alte	Si. Molto facile e indolore	Si. Consigliatissimo	Si.

Le informazioni fino ad ora elencate sono più che sufficienti per mettervi in condizione di fare una scelta intelligente. Scelta che in un webserver adibito al virtual hosting nel mio caso si traduce senza esito a PHP-FPM.

Solo in situazioni in cui si ospita un solo dominio in un server VPS ad esempio, posso permettermi il lusso di usare ciò che offre la casa (mod_php) senza troppi problemi riguardo la sicurezza dato che quel sito rimane comunque l’unico sito che gira sul server.

Problemi nell’inviare e ricevere mail. Guida di riferimento alla diagnosi e alla risoluzione.

Va premesso che l’invio di una mail e la sua ricezione comporta una serie di operazioni “dietro le quinte” assolutamente non banali che determinano in modo indiscutibile l’esito positivo o meno dell’invio e della ricezione.

Sebbene l’invio di una mail sia alla portata di tutti è anche vero che esistono migliaia di mailserver ognuno col proprio software e ognuno con la propria configurazione che a volte possono non comunicare tra loro per problemi di natura tecnica e di mal configurazione.

Cerchiamo dunque di ipotizzare uno scenario.

Quando un utente con email tizio@tizio.it ad esempio prova ad inviare una mail a caio@caio.it, ecco cosa succede dietro le quinte :

Il client di posta di tizio si connette al mailserver delegato a gestire la posta per il dominio tizio.it ad esempio mail.tizio.it
A sua volta viene fatta una richiesta al mailserver autoritario che è in ascolto sulla porta 25 e chiesto di inviare una mail al destinatario caio@caio.it. Questa richiesta viene fatta seguendo una sintassi per il protocollo SMTP in cui brevemente vengono descritti, mittente (MAIL FROM), destinatario (RCPT TO), oggetto (SUBJECT) e il corpo della mail (DATA).
Una volta terminata la trasmissione della mail dal client di posta al mailserver, il mailserver (che altro non è che un programma server che rimane in ascolto sulla porta 25, adibito alla ricezione e alla consegna delle mail) fa una query al DNS cercando di ottenere il record MX (Mail eXchanger) per il dominio in oggetto.
Il DNS per il dominio caio.it risponderà ad esempio che il mail server autoritativo per il dominio caio.it sarà mail.caio.it
Il mailserver mail.tizio.it allora si collegherà alla porta 25 del mailserver mail.caio.it instaurando una connessione di tipo TCP e girerà la mail che aveva in coda (queue) speditagli dal client di posta (outlook o thunderbird ad esempio) dell’utente tizio@tizio.it
A questo punto il mailserver del destinatario mail.caio.it avrà in coda la mail destinata ad un utente del suo dominio (caio@caio.it) e dovrà in qualche modo consegnarla in un file dentro una cartella del server, in formato normalmente Maildir o Mailbox.
A quel punto il ricevente si collegherà tramite il suo client di posta ad un server di posta in entrata pop3 o imap che serve alla ricezione del messaggio precedentemente consegnato dal mailserver.

Questo è quello che avviene in un regime normale, ovvero senza controlli specifici antivirus e antispam.

Già fino ad ora per far funzionare tutto questo meccanismo si ha bisogno dei seguenti requisiti :

2 mailserver pienamente funzionanti , uno per il mittente uno per il destinatario
Le informazioni host ed IP sui mailserver siano pubblicati nelle voci DNS (dette zone) dei domini in questione.
Effettuare una query DNS implica cialis prices il fatto di avere un server DNS funzionante con le corrette informazioni pubblicate, in particolar modo il record MX

In una configurazione avanzata, si ha a che fare inoltre con controlli aggiuntivi, come ad esempio :

Greylisting : si rifiuta di accettare la mail del mittente per alcuni minuti. Nel caso di un mailserver reale e non spammer, sarà rinviata. Nel caso di spam bot spesso non viene rinviata per cui si inizia a fare una selezione di posta buona e posta cattiva. Ciò comporta un ritardo di circa 10, 15 minuti (ma anche più) del primo messaggio di un nuovo mittente per il nuovo mese.

DNSBL : si verifica se un IP del mittente risulti pubblicato in liste mondiali di Spammer tramite richieste di tipo UDP (simili a quelle usate per le query DNS). Se presente, il messaggio viene rifiutato e il mailserver mittente lo rispedirà al mittente, specificando il motivo del rifiuto di consegna.

Antispam/Antivirus : in base al contenuto, parole chiave ed allegati, si darà un punteggio al messaggio. Superato un certo punteggio (normalmente 5) il messaggio sarà etichettato come SPAM e sarà consegnato o nella cartella SPAM o nella posta normale con l’oggetto del messaggio modificato in qualcosa del tipo [SPAM]Oggetto del messaggio , oppure ***SPAM***Oggetto del messaggio.

In questo caso affinchè il messaggio sia ricevuto dall’indirizzo del destintario il mittente deve accertarsi che l’ip del suo mailserver non sia elencato come fonte di SPAM nelle DNSBL, deve avere l’accortezza di seguire delle regole standard per la scrittura di una mail come ad esempio scrivere l’oggetto, inserire un testo nel corpo del messaggio, evitare l’invio di file quasi sempre vietati come gli eseguibili (.exe, .com, .pif, .bat, ecc..).

Va inoltre messo nero su bianco un concetto : quando la mail non arriva o non si riceve la colpa può essere nostra come può essere dell’interlocutore.

Se un nostro fornitore o cliente, ci invia una mail da un indirizzo elencato in DNSBL, la colpa è sua che non invia rispettando le regole, e non nostra che rifiutiamo automaticamente il messaggio perchè appunto è SPAM.

Inoltre va detto che la mail non è uno strumento di comunicazione in tempo reale, la consegna non è garantita e che ogni uso diverso da quella per cui è stata progettata è un uso errato.

Ogni messaggio di errore che ritorna indietro ha un codice di identificazione, nonchè a breve una descrizione del problema.

Leggendo queste informazioni, possiamo sapere senza ombra di dubbio, se il problema siamo noi o l’altro interlocutore.

Basterebbe avere la voglia e prendersi la briga di leggere questi errori per evitare di brancolare nel buio evitando inopportune comunicazioni all’helpdesk aziendale.

Hosting. Prodotto o servizio ? Quattro conti insieme all’hoster per un acquisto sereno.

Acquistare un piano hosting è diventata un’operazione comune. Facile ed immediata, nonchè alla portata di tutti.

Ma come orientarsi tra i tanti fornitori e le varie offerte ?

Prima di addentrarci nella risposta è bene fare una piccola introduzione.

Va precisato infatti che l’attivita di hosting provider non è filantropia, ma è un’attività imprenditoriale e come tale ci si prefissa un utile.

Ogni azienda di hosting propone la propria offerta secondo un business plan “studiato” a tavolino con cui conseguire gli obiettivi imprenditoriali ed economici prefissati.

Attualmente la moda è quella di proporre prezzi stracciati e di vendere piani hosting a cifre che oscillano tra le 10 e le 20 euro (annuali).

Queste offerte commerciali però non tengono conto di un concetto fondamentale, ovvero che un piano hosting non è solo un prodotto, ma sopratutto un servizio.

Senza un’adeguata assistenza che risponda in tempi ragionevoli alle proprie esigenze, un piano hosting è potenzialmente un problema più che una soluzione.

Ciò che va considerato infatti prima dell’acquisto è la reale competenza dell’acquirente nella gestione/configurazione ed uso di ciò che ha comprato.

Ad acquisto ultimato infatti l’hosting provider vi comunicherà i dati di accesso e i parametri di configurazione dei vari servizi (web, email, ecc.), ed è compito vostro saper giostrarvi tra concetti come POP3, Client, FTP, modalità passiva/attiva, DNS e simili.

Siamo sicuri di aver padronanza di ciò ? Oppure sarebbe meglio delegare e spendendo qualcosa in più avere la garanzia di un’assistenza disponibile e cordiale e che non sia menefreghista e sfuggente, pur di rientrare nel misero budget con cui vi hanno venduto un prodotto ?

La qualità di un servizio di hosting infatti si vede sopratutto dell’assistenza.

Cosa succederebbe se foste attaccati da hacker ? Se un trojan infettasse il vostro sito, o se più banalmente non riusciate a configurare Outlook per ricevere e inviare posta ?

Quanto tempo sarebbe in grado di dedicarvi il reparto tecnico di fronte ad un canone annuale di 10 euro ? Normale che non vadano troppo per le lunghe, limitandosi a rimandarvi a insoddisfacenti FAQ ed a improbabili ricerche su Google.

Nel comprare un servizio di hosting dunque valutiamo la nostra reale competenza informatica e l’importanza di un assistenza umana e professionale che ad oggi è l’unica componente che faccia ancora la differenza.

Mailserver, blacklist, dnsbl e spam. Uscire dalle liste e vivere serenamente.

Lo SPAM è diventato un business non solo per chi invia milioni di email indesiderate, ma anche per quelle aziende che si propongono come guardiani della rete offrendo gratuitamente il loro servizio di DNSBL per limitare la ricezione di messaggi indesiderati nella propria casella email.

Una DNS-based Blackhole List (anche DNSBL, Real-time Blackhole List o RBL) è un mezzo attraverso il quale è possibile pubblicare una lista di indirizzi IP, in un apposito formato facilmente “interrogabile” tramite la rete Internet. Come suggerisce il nome, il meccanismo di funzionamento è basato sul DNS (Domain Name System).

Le DNSBL sono principalmente utilizzate per la pubblicazione di indirizzi IP legati in qualche modo a spammer. La maggior parte dei mail server possono essere configurati per rifiutare o contrassegnare messaggi inviati da host presenti in una o più liste.

Questi servizi offerti gratuitamente agli utenti e sistemisti di tutto il mondo, permettono realmente di decimare l’invio di SPAM, nonchè la ricezione, contribuendo a una funzione realmente utile all’utente finale.

Può capitare però che si finisca dentro a queste liste e di entrare in una vera e propria valle di lacrime.

Entrare li dentro significa vedersi rifiutare la consegna dei messaggi alla maggior parte degli indirizzi email del mondo che fanno affidamento alle liste DNSBL per bloccare gli spammer.

spamhaus_dnsbl_basic

Ciò può essere un enorme problema sopratutto se ci lavoriamo. Significa infatti che il resto del mondo ci vedrà come Spammer e rifiuteranno a priori e in modo del tutto automatico le nostre email.

Il problema può essere ancora più grande se siamo un fornitore di servizi mail e vediamo bloccare l’intero server magari per colpa di un account di un cliente violato che mandando quantitativi di spam notevoli ci ha fatto finire dritti dritti in una o più di queste liste.

Uno dei modi ufficiali per uscirne è quello di fare la richiesta di rimozione.

Si va sulla pagina web di ogni Blacklist in cui siamo finiti e si compila la richiesta di rimozione dalla lista.

La rimozione non è immediata, ma può impiegare da un paio d’ore per le liste gratuite, fino anche ad una settimana per le liste “a pagamento”.

Il virgolettato è d’obbligo, in quanto è vero che il servizio di DNSBL tutte le liste lo rendono gratuito ma è vero che alcune liste pretendono un pagamento variabile tra 40 e 100 dollari per effettuare la rimozione dell’indirizzo nell’immediato.

Cosa succede dunque se un mailserver finisce in 5 o 6 blacklist a pagamento ?

O facciamo la richiesta di rimozione gratuita e aspettiamo fino ad una settimana per continuare a inviare email, o ci facciamo carico di spendere circa 500 dollari per venire rimossi nell’immediato (o quasi) da queste liste.

Nella pratica nessuna delle due ipotesi è realmente accettabile.

Uno degli stratagemmi sicuramente più pratici e indolori, al di la di mettere in piedi smarthost e simili, è quello di disporre di indirizzi IP di riserva da poter usare per inviare le email al posto dell’IP finito in Blacklist.

A livello aziendale normalmente si assegnano classi di circa 5 ip utilizzabili per piani di tipo business, Alice Business, NGI, ecc.

A livello Datacenter invece è possibile fare richiesta di indirizzi IP aggiuntivi al costo di 1 o 2 euro al mese.

Avere la possibilità di configurare il proprio mailserver per inviare la posta con un indirizzo IP diverso da quello in blacklist è qualcosa di estremamente rapido e funzionale.

Nessuna configurazione complessa, nessun costo esoso. Il giusto prezzo (economico) per ripartire nel giro di 5 minuti e vuotare la coda di posta che i mailserver di tutto il mondo non accettava perchè visti come spammer.

Qualora fosse incappati in questa soluzione e non riusciate a venirne fuori, vi ricordiamo che offriamo consulenza sistemistica su mailserver di tipo Postfix, Qmail, Exim e Sendmail.

Contattaci.

Determinare se un utente sia loggato a facebook utilizzando solo javascript

Quello che voglio mostrare in questo articolo è la possibilità di determinare tramite puro Javascript (ed in appena 4 righe di codice) se un utente è loggato o meno a Facebook.

Ciò potrebbe essere utile per proporre dei contenuti diversi quando l’utente visita la nostra pagina web, in relazione al fatto che l’utente sia loggato o meno.

Va premesso che Facebook fornisce uffcialmente dei comodi ed esaustivi SDK Javascript e PHP per fare questo tipo di operazioni, ma che l’utilizzo di questi strumenti comporta alcuni passi obbligatori che sebbene possano andare più che bene per la maggior parte degli utenti, potrebbe non andare bene a chi vorrebbe farne un uso “diverso”.

L’utente deve registrare un applicazione a cui sarà associata un APPID univoca.
L’utente che naviga deve aver accettato precedentemente il consenso per l’applicazione
A livello applicativo il webmaster deve portarsi dietro tutto il framework configurato su misura per quella applicazione.

Ma se volessimo “SOLO” sapere se l’utente sia loggato a Facebook nel momento in cui naviga sulla nostra pagina ?

Premesso che non ci interessa sapere nulla di più e nulla di meno se risulta loggato, senza dover dunque registrare nessuna applicazione Facebook e senza far interagire minimamente il visitatore con le applicazioni Facebook.

Il modo migliore è quello di usare i codici di stato di risposta del Webserver.

L’idea alla base è quella che alcune pagine di Facebook possano ritornare un codice di stato differente se si è loggati o meno.

Se ad esempio si crea un profilo Facebook visibile solo agli utente correntemente loggati su Facebook quando un utente NON loggato tenterà di vedere il profilo privato riceverà uno stato HTTP di errore di tipo 404.
Viceversa quando un utente loggato cercherà di visualizzare il profilo privato otterrà uno stato HTTP di tipo OK, cioè 200.

Tutto quello che bisogna fare dunque è di caricare l’url di un profilo privato (che volendo potremmo creare maliziosamente fasullo appositamente per lo scopo) in un tag di tipo script e agganciarci l’evento onload() e onerror().

Se si verificherà l’errore (ovvero la restituzione di un codice di stato HTTP di tipo 404) l’utente non è loggato a FB e stamperà a video il messaggio “Non Loggato a Facebook”.
Se si verificherà l’evento onload() (è stato ricevuto un codice di stato HTTP di tipo 200) l’utente è correntemente loggato a FB e stamperà a video il messaggio “Non Loggato a Facebook”.

Il codice è molto semplice e banale ma di reale efficacia, visionabile in questo esempio caricato su jsFiddle :

Mail e antispam service unavailable client host blocked using list.dsbl.org

Sin da oggi Venerdì 10 Agosto 2012, molti utenti email vedono rifiutare la consegna delle email che tornano indietro con un messaggio di errore del tipo : Service unavailable; Client host [17.158.233.225] blocked using list.dsbl.org

E’ bene precisare che ciò è dovuto alla configurazione errata di molti mailserver che si appoggiano alla lista DNSBL list.dsbl.org per i dovuti controlli antispam.

Sebbene questa lista sia ufficialmente “morta” dal lontano 2009, fino ad oggi non ha mai dato problemi di sorta sopratutto per ciò che riguarda i falsi positivi che da oggi affligge ogni messaggio in arrivo.

Si consiglia dunque a tutti gli amministratori di server mail (Postfix, Qmail, ESIM, Sendmail, Exchange o qualsiasi altro) di disabilitare il controllo su questa lista.

Se usaste postfix ad esempio dovreste editare il file main.cf e rimuovere o commentare la seguente linea :

#postfix/main.cf:smtpd_client_restrictions = reject_rbl_client sbl-xbl.spamhaus.org, reject_rbl_client list.dsbl.org

e poi riavviare il mailserver.

Nel paese dei pagliacci : Camera dei deputati, Giuseppe Scala e il suo algoritmo crittografico.

E’ bene fare una premessa, nell’articolo che segue non si intende fare critiche all’algoritmo in se o all’autore dell’algoritmo in oggetto ma bensì a tutta quell’esaltazione mediatica che da sempre reputo la rovina del nostro paese.

I fatti :

Giuseppe Scala, giovane ragazzo Napoletano, è stato premiato dall’associazione Pigreco alla Camera dei Deputati di Roma per la sua ricerca nel campo crittografico per migliorare la sicurezza delle telecomunicazioni.
Alla base del suo successo appunto c’è un nuovo metodo crittografico che a dire del ricercatore avrebbe rivoluzionato i tradizionali metodi trasformato il messaggio da criptare in qualcosa di completamente diverso.

A seguito di questi eventi e dichiarazioni tutta la comunità dell’IT Security si è movimentata alla ricerca di qualche accenno tecnico sul metodo pratico che permette di “trasformare il messaggio in qualcosa di completamente diverso”.

Ciò ha fomentato molti curiosi tra addetti al settore e non addetti al settore, tra cui l’immancabile stampa che se n’è uscita con servizi del tipo :

e vari riferimenti a :

http://multimedia.lastampa.it/multimedia/scienze-e-tecnologie/lstp/101428/

Passi pure l’ignoranza della stampa (nel senso più bonario ed etimologico del termine), non si capisce come un algoritmo reso non pubblico, ne testato ne verificato da esperti internazionali possa essere addirittura premiato dalla Camera dei deputati di Roma.

Premesso che l’associazione Pi-Greco “una associazione per la ricerca tecnologica costituita la fine di svolgere attività di utilità sociale attraverso la promozione della conoscenza delle tecnologie avanzate nel settore della informatica e delle discipline ad essa collegate, in ambito regionale, nazionale ed internazione, non ha fini di lucro.” ha lanciato una sfida che consiste nel decrittare un file crittografato con tale algoritmo, a cui il 19 Maggio 2012 al blog http://crittoscala.wordpress.com , veniva decrittato http://crittoscala.wordpress.com/2012/05/19/sfida/#comments il messaggio.

Premesso che nessuno degli autori della decrittazione si possano considerare esperti di crittanalisi di fama mondiale (senza togliere merito al loro lavoro e al loro ingegno, ma non parliamo di Bruce Schneier, Ronald Rivest, Adi Shamir, Leonard Adleman o Whitfield Diffie e Martin Hellman) sono riusciti indubbiamente nel loro intento : dimostrare l’inutilità e la debolezza dell’algoritmo Scala.

Vien da chiedersi come un progetto immaturo e non funzionale come l’algoritmo Scala possa essere addirittura premiato senza previa verifica e valutazione da parte della comunità scientifica internazionale.

Oltretutto parliamo di un algoritmo non pubblico che tuttora gode di “sicurezza” (giustamente virgolettato data la sua inefficienza e insicurezza dimostrata) tramite Security through obscurity, ovvero Sicurezza tramite segretezza, un principio che si basa sul controverso assunto che tenere segreto il funzionamento interno di un sistema lo renda più sicuro, dato che un eventuale attaccante avrebbe maggiore difficoltà nella scoperta di eventuali falle del sistema stesso.

In crittografia esiste un principio opposto (detto principio di Kerckhoffs), che afferma che il progettista di un sistema deve presumere che l’attaccante conosca il sistema alla perfezione, con l’unica eccezione della chiave crittografica. Un parallelo illuminante può essere quello di una normale serratura meccanica, con azionamento ben conosciuto ma apribile solo con la chiave giusta.

Rimane dunque lo sdegno e la perplessità non tanto nell’inefficienza e l’utilità dell’algoritmo del giovane studente (che merita comunque incoraggiamento o quantomeno apprezzamento per il tentativo), ma di come un organo prestigioso, carismatico e rappresentativo come la camera dei deputati possa premiare qualcosa di buttato li per caso senza averne valutato pregi e difetti.

Citando l’autore della decrittazione su http://crittoscala.wordpress.com/2012/05/22/deliri/

“Entrando nel merito dell’algoritmo di Giuseppe Scala penso sia pericoloso premiare un algoritmo ancora non pubblicato e studiato da veri esperti. Una premiazione, addirittura alla Camera dei Deputati, è una sorta di validazione che potrebbe convincere persone non preparate o aziende a usare l’algoritmo credendolo paragonabile ad AES.
Se a questo si somma la dichiarazione fatta sul sito della PigrecoTechnology secondo cui l’algoritmo avrebbe passato l’analisi di esperti di sicurezza informatica (inizialmente si citava l’ing. Iannone che sarebbe un “esperto indiscusso di sicurezza informatica a livello nazionale”, il riferimento è però stato tolto); amplificando tutto con articoli di questo tipo ( in questo caso non imputabili alla PigrecoTechnology ma al solito modo sensazionalista di certi giornalisti) il rischio diventa concreto.”

WordPress a rischio : timthumb.php vulnerabile ad attacchi di tipo Remote File Include

TimThumb, l’utility di ridimensionamento delle immagini compresa in molti template della famosa piattaforma WordPress, sta dando problemi di sicurezza in quanto evidenzia vulnerabilità che eventuali cracker potrebbero sfruttare per attaccare siti e blog che utilizzano tale piattaforma.

Mark Maunder, amministratore delegato di Feedjit, ha scoperto il problema quando il suo blog ha cominciato a caricare contenuti pubblicitari che originariamente non erano stati da egli stesso inseriti. Proprio sul blog ha parlato dal problema, spiegando che è correlato alla libreria timthumb.php, utilizzata dal tema che egli ha acquistato per il suo spazio web. «Dal momento che sono appena stato attaccato attraverso essa, immagino sia giusto parlare della vulnerabilità al grande pubblico», ha scritto Maunder.

TimThumb.php, continua, è “intrinsecamente insicuro” perché scrive i file in una directory quando si carica l’immagine e la si ridimensiona. Tuttavia, questa directory è accessibile alle persone che visitano il sito, diventando quindi fonte di attacchi per i pirati informatici. Un utente malintenzionato può anche compromettere il sito agendo direttamente dalla directory, “riempendola” di file infetti.

Non solo (aggiungiamo noi), il problema infatti non si limita solo a caricare file infetti ma anche file php maliziosi come le famose phpshell, e nel caso in cui non fosse stato fatto hardening a livello di configurazione PHP (separazione privilegi con su_php o php-fpm, o la disabilitazione di funzioni pericolose come l’allow_url_fopen,system,exec,ecc…) può compromettere seriamente la sicurezza dell’intero server Web oltre che del vhost specifico.

Il tipo di attacco è quello comunemente definito RFI (Remote File Inclusion), http://it.wikipedia.org/wiki/Remote_File_Inclusion

Maunder ha dunque spiegato che al momento conviene disabilitare TimThumb o, al limite, limitarne l’accesso.

Per quanto il discorso di Maunder possa essere corretto e sensato, esso tende a creare dei fraintendimenti ad utenti WordPress e webmaster non troppo esperti.

Va ricordato infatti che timthumb non è un plugin di WordPress ma bensì un file php “sfuso” inserito come parte funzionale di molti template WordPress (ma non solo wordpress).

Risulta dunque impossibile disabilitare questo plugin da pannello di controllo come si farebbe normalmente nell’attivazione e disattivazione di plugin wordpress e sopratutto non bisogna illudersi che basti aggiornare la versione di WordPress attuale all’ultima stabile per risolvere questo problema.

Bisogna (purtroppo) fare un’attività di ricerca manuale nelle cartelle del proprio template, individuare il file timthumb.php (se presente) e sostituirlo con la nuova versione che potete scaricare qui http://code.google.com/p/timthumb/
Uomo avvisato …

Perchè cambiare la password predefinita del vostro router Alice e Fastweb : WiRouter KeyRec !

Come ben saprete per accedere alla vostra rete wi-fi bisogna immettere una key di autenticazione una volta era WEP oggi WPA2.

Questa chiave viene fornita di default e stampata su carta e inclusa nella confezione del router Telecom o Fastweb noleggiatovi dal fornitore ADSL.

Qualcuno si chiederà dunque : ma chi è che configura il nome della rete SSID e setta la chiave WPA nelle impostazioni predefinite del router ?

Sicuramente non è un essere umano a farlo, ma bensì un automa software che associa una WPA a un nome di rete (SSID) mediante un algoritmo proprietario.

Salvatore Fresta, italianissimo sviluppatore e ricercatore, ha surrogato il lavoro di numerosi reverse enginner e ricercatori di sicurezza come lui in un software chiamato WiRouter KeyRec.

Esso è scritto in linguaggio C, rilasciato sotto licenza GPL (codice sorgente aperto dunque) e permette di recuperare la password predefinita per la rete WiFi del vostro router.

Al momento sono supportati i modelli: Telecom Italia Alice AGPF, Fastweb Pirelli, Fastweb Tesley.

Tutto quel che serve è il SSID della rete per cui volete calcolare la password predefinita che potete passare sia a linea di comando sia da file.

Se avete ancora impostato la password di default dunque è VIVAMENTE CONSIGLIATO provvedere a sostituirne con una nuova da voi scelta.