IppatsuBlog

A Agosto 2007 Luis Miras, lead vulnerability researcher della Intrusion, ha tenuto un interessante speech al convegno BlackHat 2007: Other Wireless: New ways to get Pwned (PDF). L’idea di Miras era molto semplice: ci sono dati trasmessi via etere “insospettabili” che possano rappresentare un rischio per la sicurezza? La risposta banalmente era sì: tutto ciò che viene digitato sulle tastiere wireless può essere intercettato da qualche curiosone di passaggio. Miras presentò dei replay attack e poco altro: tastiere e mouse wireless comunicano usando un protocollo crittato che non aveva avuto la possibilità di reversare.

Per poter effettuare l’attacco replay ha dovuto creare una periferica wireless personalizzata. Questo non è particolarmente difficile in quanto pressoché tutti i dispositivo di questo genere sono composti da tre parti: un semplice microcontrollore, una piccola eeprom e un trasmettitore. Il dongle ricevente è molto simile, con un ricevitore al posto del trasmettitore. Inoltre per l’utilizzo negli Stati Uniti questi dispositivi devono essere approvati dall’FCC: il risultato è che cercando il numero di serie di un prodotto è possibile spesso ricavare gli schematici della sua architettura.

Qualche giorno fa Max Moser e Philipp Schrödel di Dreamlab Technologies e remote-exploit.org hanno pubblicato un articolo che spiega il funzionamento del protocollo e come sia possibile sniffare le connessioni in modo estremamamente semplice.

Analizzando il protocollo hanno scoperto che caratteri come shift e alt sono inviati non crittati al ricevente wireless. La crittazione usata nell’invio di ogni carattere è uno XOR del valore del carattere con un byte ricavato da un motore casuale inizializzato con un singolo byte durante l’handshake tra la periferica wireless e la stazione ricevente connessa al computer. Sniffando l’handshake è quindi possibile intercettare facilmente tutti i tasti premuti sulla tastiera. In realtà questo non è necessario, poichè ci sono solo 256 possibili chiavi di crittazione, per cui sniffando i tasti crittati e usando gli stessi metodi statistici utilizzati per “rompere” il cifrario di Cesare, è possibile determinare la chiave corretta intercettando solo 20-50 caratteri.

I ricercatori hanno anche pubblicato un video dove mostrano il loro programma proof-of-concept sniffare e crackare la comunicazione di tre diverse tastiere. Con delle piccole antenne non dovrebbe essere difficile sniffare le comunicazioni della tastiera anche oltre il suo circa metro e mezzo di raggio di comunicazione.

Potete usare RSA a 4096 bit per usare via SSH il vostro PC, ma è tutto inutile se poi la chiave viene banalmente letta dal primo venuto abbastanza malizioso (un motivo in più per usare SSH passwordless).

Ma se usate una tastiera con filo, non pensiate di essere al sicuro (e c’è anche chi è in grado di montare questi gingilli all’interno di un laptop).

[via midnightresearch]

C’è stata una piccola tempesta nei vari blog/siti 2.0/del.icio.us/newswine (…) relativo alla supposizione che *ubuntu possa portare a un logoramento prematuro degli hard disk.

Tutto è partito da un post di linux-hero (opportunamente amplificato da digg.com) che faceva riferimento al bug #104535 di Ubuntu: il riassunto del bug è che quando viene collegato alla batteria Ubuntu attiverebbe delle impostazioni che portano a un continuo arresto e riavvio dell’hard disk, cosa che da una parte aumenta l’autonomia del sistema, dall’altra causa uno stress meccanico che può accorciare la vita utile dell’hard disk.

Inizialmente il caos ha regnato e tutti hanno iniziato a incolpare Ubuntu della rottura del proprio hard disk. In realtà le cose sono un po’ più complicate di così (come ha segnalato Matthew Garrett — sviluppatore per Debian e lead developer per Ubuntu). Per sapere se il fantomatico bug vi affligge eseguendo il comando:

grep ENABLE_LAPTOP_MODE /etc/default/acpi-support

se vi viene restituito “false” allora non correte alcun pericolo.

laptop_mode è una variabile con cui si comunica al kernel Linux che si intendono attivare alcuni comportamenti che portano a un “miglioramento” del comportamento del sistema sui laptop (ad esempio bufferizzando le scritture su disco e scrivendole a burst, diminuendo così gli accessi all’hd e allungando conseguentemente la durata della batteria).

Tale variabile si può impostare modificando il file /etc/default/acpi-support . Il problema nasce dal fatto che quando viene alimentato dalla batteria, Ubuntu esegue il file /etc/acpi/power.sh , che contiene tra le altre cose il codice:

function laptop_mode_enable {...$HDPARM -S $SPINDOWN_TIME /dev/$drive 2>/dev/null

$HDPARM -B 1 /dev/$drive 2>/dev/null

}

Se vengono avviati, questi comandi cambiano le impostazioni del risparmio energetico dell’hard disk. Il primo comando riduce il tempo di spindown, cioè il tempo che deve passare dall’ultimo accesso prima che l’hard disk smetta di ruotare. Il valore di default, che si può leggere nel file /etc/default/acpi-support , è di appena 12 secondi. Questo continuo fermarsi e ripartire causa stress meccanico all’hard disk, accorciandone la vita utile. Il secondo comando invece imposta la politica di ACPI per l’hard disk al valore più aggressivo (eseguite man hdparm per ulteriori informazioni).

Ma questa funzione viene richiamata solo da un’altra funzione:

if [ x$ENABLE_LAPTOP_MODE = xtrue ]; then
    (sleep 5 && laptop_mode_enable)&
fi

Questo vuol dire che se la variabile ENABLE_LAPTOP_MODE allora verrà richiamata la funzione laptop_mode_enable riportata sopra. Di default, come si può controllare sempre nel file /etc/default/acpi-support , tale variabile è impostata a false, per cui l’odiatissimo codice che corrode gli hard disk non verrà abilitato.

Questo vuol dire che di default Ubuntu non modifica le impostazioni di risparmio energetico, e coloro che hanno osservato un aumento del valore di load_cycle_count (visualizzabile con sudo smartctl -A /dev/sda dove sda potrebbe cambiare e essere hda, hdb,… o sdb, sdc…) sono “vittime” delle impostazioni aggressive per il risparmio energetico impostate nel bios o nel firmware presente sui laptop. Ubuntu, di default, non modifica alcunché per questo aspetto.

Come osserva Matthew Garret, si potrebbe affermare che Ubuntu dovrebbe forzare politiche che non portino all’usura dell’hardware, ma del resto si suppone che il produttore del portatile ne sappia più degli sviluppatori di Linux su cosa quell’hardware possa o non possa fare.