Tramite Jeremiah Grossman leggo che PayPal ha pubblicato una pagina contene la “vulnerability disclosure policy“. Essa permette ai (Web application) security researchers di segnalare vulnerabilità trovate in PayPal senza rischiare azioni legali.
Ovviamente l’immunità è garantita solamente a chi rispetta la policy:
Guidelines for responsible disclosure
- Share the security issue with us before making it public on message boards, mailing lists, and other forums.
- Allow us reasonable time to respond to the issue before disclosing it publicly.
- Provide full details of the security issue.
Non è tollerato, come è normale aspettarsi, l’uso della vulnerabilità per accedere a dati di cui normalmente non si possiede l’autorizzazione, pretendere una somma di denaro in cambio delle informazioni dettagliate della vulnerabilità o causare un D0S all’intero sistema PayPal.
La policy porta a porsi qualche domanda come evidenziato da Chris Shiflett, ma sicuramente le buone intenzioni ci sono e per migliorare siamo sempre in tempo. Credo che sia la prima volta che una grossa azienda mette nero su bianco un comportamento del genere per incoraggiare chiunque a segnalare preventivamente le vulnerabilità al team di competenza.
Google, Microsoft e Yahoo hanno delle policy simili, ma ancora, al contrario di PayPal, non si fa menzione di possibili rivolti legali per le vulnerabilità segnalate.
Questa notizia non dovrebbe interessare solamente agli addetti ai lavori ma anche ai semplici clienti/utenti, una grossa azienda che gestisce i nostri dati personali (o ancor peggio i nostri risparmi) non deve nascondere eventuali attacchi o vulnerabilità di sicurezza. Solitamente infatti, non solo non esiste una policy ben precisa sul comportamento che l’azienda terrà nei confronti di chi segnala una vulnerabilità ma addirittura non è ben chiaro a chi segnalare i dettagli di essa.
Avevo letto la notizia qualche giorno fa senza dargli peso, oggi passandomi tra le mani un approfondimento ho capito che merita parlarne.
Tutto è iniziato a causa dello spostamento di una statua eretta alla fine della seconda Guerra Mondiale in memoria dei soldati dell’Armata rossa caduti nella liberazione dell’Estonia dall’invasione nazista. La repubblica estone perse la propria indipendenza per mano sovietica nel 1939 in seguito del Patto Molotov-Ribbentrop, riguadagnandola solo nel 1991. La rimozione della statua, dettata da una legge del 2006 contro la pubblica esibizione di monumenti rappresentanti l’occupazione sovietica, ha causato l’indignazione della minoranza russa in Estonia e del senato Russo e successivamente un attacco DDoS su larga scala.
L’attacco informatico iniziato il 27 Aprile scorso, ha preso di mira, come spiegato da Hillar Aarelaid del CERT Estone, siti Web di banche, scuole e quello del primo ministro causando non pochi danni all’interno della nazione.
Secondo Jose Nazario, l’attacco DDoS è stato fatto tramite tre diverse tecniche: ICMP floods, TCP SYN floods e floods tramite richieste generiche. Sembra che tra le sorgenti di attacco (presumibilmente una botnet) vi sia oltre a Brasile, Canada, U.S. e Vietnam anche la Russia.
In un primo momento era stato puntanto il dito contro il governo Russo, ma più approfondite analisi hanno portato a pensare che vi fossero “semplici” cittadini (nazionalisti) dietro gli attacchi. Fatto sta che il CERT Estone riceverà l’aiuto niente meno che dalla NATO (North Atlantic Treaty Organization, tengo a sottolineare). Lo scopo dell’organizzazione internazionale, nata da una temuta invasione sovietica dell’Europa occidentale, è riassunto in maniera esaustiva nell’articolo 5 del Trattato Atlantico:
Le parti convengono che un attacco armato contro una o più di esse in Europa o nell’America settentrionale sarà considerato come un attacco diretto contro tutte le parti, e di conseguenza convengono che se un tale attacco si producesse, ciascuna di esse, nell’esercizio del diritto di legittima difesa, individuale o collettiva, riconosciuto dall’ari. 51 dello Statuto delle Nazioni Unite, assisterà la parte o le parti così attaccate intraprendendo immediatamente, individualmente e di concerto con le altre parti, l’azione che giudicherà necessaria, ivi compreso l’uso della forza armata, per ristabilire e mantenere la sicurezza nella regione dell’Atlantico settentrionale. Ogni attacco armato di questo genere e tutte le misure prese in conseguenza di esso saranno immediatamente portate a conoscenza del Consiglio di Sicurezza. Queste misure termineranno allorché il Consiglio di Sicurezza avrà preso le misure necessarie per ristabilire e mantenere la pace e la sicurezza internazionali.
Siamo di fronte ad un pezzo di storia?
Nella recente intervista Stefan Esser, ha annunciato che a Marzo inizierà il “Month of PHP bugs”.
Stefan Esser è un consulente di sicurezza tedesco che da anni ha a che fare con software OpenSource.
Circa 6 anni fa è entrato a far parte degli sviluppatori di PHP, grazie a questa mansione è stato a stretto contatto con i sorgenti di PHP capendo così che essi non erano scritti con la sicurezza come obiettivo. Ha così deciso di creare il security team all’interno di PHP per poter gestire in maniera ottimale il report di bug e il rilascio di patch.
Qualcosa nel frattempo è andato storto tanto da farlo ritirare dal gruppo di sviluppatori PHP.
Dal 2004, Stefan, ha iniziato un progetto personale chiamato “Hardened PHP” il quale fornisce patch per aumentare la sicurezza del codice ufficiale. “Hardened PHP” è stato recentemente rimpiazzato da Suhosin, progetto nato dall’idea di dividere “Hardened PHP” in due parti distinte. La protezione dello Zend Engine, per difendere il “core” da buffer overflow, implementata come patch ai sorgenti originali e un’estensione che integra tutti gli altri tipi di protezione.
Suhosin risulta trasparente sia all’utente sia allo sviluppatore: implementa il controllo sui parametri passati alla funzione mail() per evitare injection di header, effettua la crittografia dei dati delle sessioni e dei cookie, blocca le url nei parametri delle funzioni include e require, ecc…
Stefan Esser mentre parla del futuro “Month of PHP bugs”:
Its goal is to make people and especially the PHP developers aware that bugs in PHP exist. While this sounds obvious for everyone on the outside, it is actually required. PHP has a very bad reputation when it comes to security, which is mostly caused by all the advisories about security holes in PHP applications.
