CyberSecurity 1337

Vi segnalo l'ottima serie di post di Feliciano Intini su Conficker (tutte le varianti) e il presunto uragano malware che si dovrebbe scatenare domani 1° Aprile. Nei suoi post potete trovare ottime indicazioni su come individuare e contenere l'infezione.  Certo se siete arrivati ad oggi a leggervi i post su Internet, dubito che ce la farete per domani! Comunque tranquilli la catastrofe non ci sarà domani: c'è già stata! Alcuni stimano (per eccesso) 10 milioni di PC infettati. 

Alice: "Devo fare un'applicazione estremamente sicura in cui i dati non possano essere copiati dalle varie schermate dell'applicazione" Bob: "Mumble mumble: non credo che tu ci riesca" Alice: "Sì, ho trovato invece! Sei sempre il solito SMR (Security Man Rompiscatole)" Bob: "E come?" Alice: "Cancello la clipboard e blocco il copia e incolla" Bob: "Sì e la macchinetta fotografica sul cellulare come la blocchi?" Estratti da "SMR e il mondo di Alice nel paese delle meraviglie" (ogni riferimento a fatti o persone è puramente RNG-casuale)

Forse pochi sanno che è relativamente facile cancellare lo swap file (o page file) in Windows. Così ad ogni shutdown sarete sicuri che le vostre amate password non saranno in quel dannato file. Su VISTA dovete impostare a 1 questa chiave di registro (aprite il regedit come amministratore): HKEY_LOCAL_MACHINE\SYSTEM\ControlSet\Control\Session Manager\Memory Management\ClearPageFileAtShutdown Anche su XP dovrebbe essere la stessa cosa. Ovviamente non vi lamentate se il sistema sarà più lento in fase di chiusura :-)

Interessanti considerazioni sulla sicurezza dei Mac: Dino Dai Zovi, an independent security professional in the financial services industry and co-author of The Mac Hacker's Handbook , demonstrated to a packed room at the SOURCE Boston conference how to defeat Mac OS X by gaining access to its root memory. A few lines of arbitrary code will enable any attacker to take over a computer, establish a TCP connection and download additional malicious code . Dai Zovi illustrated his technique by hacking into an Apple iSight camera to take photos of himself. "Steve Jobs' fairy dust only protects against the most naive attackers," Dai Zovi said. "Writing exploits for [Microsoft] Vista is hard work. Writing exploits for Mac is a lot of fun ." Ma non erano intrinsecamente sicuri?

La gestione delle eccezioni da parte di un linguaggio di programmazione si divide in due grandi famiglie: Checked e Unchecked . Sappiamo inoltre che la corretta gestione degli errori è anche una best practice per la programmazione sicura . Esempio di linguaggio (forse l'unico) che implementa la gestione di tipo Checked è Java. In Java se un metodo lancia delle eccezioni (di tipo Checked) siamo obbligati a gestirle mediante blocchi try-catch oppure rilanciare l'eccezione al chiamante segnalandola nella signature del metodo con la keyword throws . Nell'esempio qui sotto abbiamo due tipi di eccezioni: IOException è una eccezione di tipo checked che quindi DEVE essere gestita mediante try-catch o throws , mentre NullPointerException è di tipo unchecked perché NON DEVE necessariamente essere gestita: public void myMethod() { try { f1(); } catch (IOException e) { // This is a Checked Exception so I must manage it in a catch or with th...

premessa: Bob è il Security Man Rompiscatole (SMR) e Alice una sua collega. Alice: "devo cifrare i dati...uffa che scatole questa sicurezza" Bob: "(stavolta non parlo)" Alice: "Fammi vedere che cosa posso usare in Java" Bob: "(no no, non parlo)" Alice: "Ah, ecco. DES . Ma sì, tanto uno vale l'altro" Bob: "Eh no, DES oramai è considerato insicuro. Almeno usa un Triple DES !!!!!" Bob: "(non ce l'ho fatta a starmi zitto)" Alice: "Ma perché che cambia?" Bob: "(no, non la strozzare)" Bob: "Vedi di usare AES se ci riesci" Estratti da "SMR e il mondo di Alice nel paese delle meraviglie" (ogni riferimento a fatti o persone è puramente RNG-casuale)

Che un algoritmo di pacchettizzazione possa salvare il pianeta ci mancava . Ma a pensarci bene su l'affermazione non è così peregrina. Chi di voi conosce il problema dello zaino sa bene che ordinare gli elementi da inserire in uno zaino è un problema NP-completo. Ovvero la soluzione ottima è computazionalmente ardua da trovare perché il tempo necessario non è polinomiale (lo è invece su una macchina di turing non deterministica). Quello che si fa quindi è trovare una soluzione ottimale, ovvero che più si avvicina alla soluzione ottima, di solito con programmazione dinamica, algoritmi Greedy e altre diavolerie da algoritmisti. Ma che c'entra questo con il pianeta?  C'entra invece, perché trovare degli algoritmi più efficienti, ovvero che in minor tempo riescano a riempire gli imballaggi con maggiori quantità di oggetti, ridurrebbe il numero di imballaggi, trasporti, carburante e quindi inquinamento. E il nostro pianeta ne gioirebbe. Che c'entra con la Security? Non vor...

Di solito non faccio recensioni di plug-in e componenti vari ma CipherFox , plug-in per Firefox, è parecchio utile se volete tenere sempre sotto controllo la suite crittografica della connessione HTTPS. E fino a qui il plug-in potrebbe essere di media utilità. CipherFox fa qualche cosa però di più interessante: permette di disabilitare l'RC4 nelle connessioni SSL e fare in modo che il browser si connetta con una suite crittografica migliore (sempre che il server ve la offra!). Qualche esempio? La pagina web di Firefox per la ricerca dei pacchetti è in HTTPS e con l'installazione standard di Firefox vi beccate un bel RC4 a 128 bit. Ma basta aggiungere qualche flag in CipherFox per disabilitare questa suite e, come potete vedere dallo screenshot, avere un ben più sicuro AES-256 bit. Anche GMail di default con Firefox vi dà un RC4, ma dopo CipherFox avrete anche qui un AES-256. Insomma un plug-in veramente utile.

Per chi non avesse ancora chiaro quanto può essere pericoloso (e semplice da portare) un attacco Cross Site Request Forgery (CSRF), ritengo utile segnalare questa full disclosure di un piccolo problemino che assilla GMail. In pratica, una volta autenticati in GMail, l'accesso alla pagina del "change password", invocata tramite una request HTTP GET, è garantito solo dal cookie di sessione storato dal browser.  Questo permette di costruire pagine Web ad hoc e, con tecniche di social engineering, dirottare l'utente su queste pagine. Pagine che contengono riferimenti ad immagini che all'atto del caricamento e in modo silente tentano di cambiare la password del malcapitato. Ecco l'esempio portato nella Full disclosure: ... src = https://www.google.com/accounts/UpdatePasswd? service=mail&hl=en&group1=OldPasswd&OldPasswd=PASSWORD1 &Passwd=abc123&PasswdAgain=abc123&p=&save=Save " ... Non sarà facilissimo "indovinare" la pas...

Geniale!