Tiger Security Blog

RSA SecurID: quando il mondo dipende dalla (in)sicurezza di una sola azienda.

RSA SecurID: quando il mondo dipende dalla (in)sicurezza di una sola azienda.

CHI E’ RSA
E’ ben noto che RSA sia una delle società di riferimento per servizi, tecnologie e ricerca nel campo della sicurezza delle informazioni. Milioni di utenti nel mondo, tra gli altri alcuni consulenti del dipartimento della Difesa degli Stati Uniti ed una lunga serie di banche, hanno affidato la protezione delle proprie infrastrutture a questa azienda e alle proprie soluzioni.

COS’E’ RSA SecurID
La principale soluzione di RSA per la gestione dell’autenticazione è basata sul meccanismo del token, “RSA SecurID”. Con questa tecnologia la società ha garantito la protezione di reti vpn e wlan, e-mail, reti intranet ed extranet, server web e moltissime altre risorse di rete. Ricerche recenti stimano che l’utilizzo di RSA SecureID ha raggiunto circa il 70% dell’intero mercato, nei prodotti di autenticazioni basati su questo principio.
RSA SecurID basa il proprio funzionamento su un oggetto “token” ed un pin. Un token può essere realizzato ad hardware (come nella foto) o implementato via software. In entrambi i casi è in grado di modificare la password di accesso ai sistemi ad intervalli di tempo regolari (tipicamente ogni 60 secondi). In questo modo prevedere la password diventa, per un eventuale attaccante, particolarmente complesso poiché cambia continuamente ed è utilizzabile soltanto in un certo intervallo di tempo (one time password). Inoltre, anche conoscendo la password in un dato istante, l’attaccante non è in grado di calcolare la successiva.

COME FUNZIONA RSA SecurID
Come si vede dal grafico, il sistema si basa su una informazione “originaria”, definita seed, condivisa tra server e token e sulla loro sincronizzazione dei due. Ogni token al mondo ha un diverso seed. Questi due dati sono memorizzati sia sul token che sui server di RSA, gli “ACE Server”, principali attori del processo di autenticazione.
La sicurezza del seed memorizzato sul token è affidata ad un sistema in grado di cancellare l’informazione qualora il dispositivo sia forzato fisicamente. Gli “ACE Server” di RSA sono difesi direttamente da RSA.

COSA E’ SUCCESSO
Lo scorso 17 marzo RSA ha dichiarato di aver subito un’intrusione dei propri sistemi e, successivamente, che sono stati resi insicuri oltre 40 milioni dei propri token poiché gli attaccanti sono riusciti a sottrarne i seed ed altre informazioni sensibili. L’unico rimedio a questo tipo di attacco è sostituire il token.

COSA OCCORRE FARE
Nelle soluzioni software based, probabilmente, basterà aggiornare i sistemi con le nuove versioni del software che saranno rilasciate da RSA. Per i milioni di token hardware, invece, non resta che trovare una buona società per lo smaltimento.

P.S. Secondo voi quanto la notizia ha reso tristi quelli di “VASCO” (praticamente l’unica società competitor di RSA nella produzione di soluzioni di autenticazione)?

QUALCHE ARTICOLO INTERESSANTE

[Presentazione Tecnica] – Exploiting ARM Linux Systems

[Presentazione Tecnica] – Exploiting ARM Linux Systems

Si sta notando negli ultimi tempi una crescente attenzione verso le vulnerabilità di tutta una serie di dispositivi che ormai sono diventati essenziali nella vita di ogni giorno.

Inizialmente la diffusione di attacchi verso dispositivi quali telefoni cellulari e componenti embedded era scoraggiata dalle diversità di questi sistemi tra loro. Era si possibile sviluppare exploit, ma questi erano specifici solo per dei target molto ristretti.

Oggi, con la vasta diffusione di piattaforme come Android o iOS (IPhone) esiste il serio rischio di attacchi su vasta scala. Questi dispositivi hanno in comune (con anche moltissimi altri dispositivi embedded) l’architettura per la quale sono sviluppati: il set di istruzioni ARM.

Dato che le tematiche riguardanti l’exploiting di architetture non Intel ci sono sempre interessate, abbiamo voluto dare il nostro contributo pubblicando le nostre ricerche nel documento:
EXPLOITING ARM LINUX SYSTEMS, An introduction“.

Il documento introduce le tematiche riguardanti l’architettura ARM da un punto di vista security-oriented e analizza alcune tematiche e tecniche legate all’exploiting e allo shellcoding per questa architettura.

Speriamo troverete interessante questa nostra nuova pubblicazione.


[Presentazione Tecnica] Force Insecure Temporary Files Creation.

[Presentazione Tecnica] Force Insecure Temporary Files Creation.

Introduzione

Due giorni fa avevamo fatto veicolare, tramite twitter, un video di come poter modificare una sessione php pur stando in due domini completamente diversi.

Subito dopo aver rilasciato la demo, sono arrivate dimostrazioni su come poter editare queste sessioni tramite la semplice lettura del file, dandoci così l’idea che l’attacco avesse destato interesse nell’ambiente.

Executive Summary

La tecnica ‘Force Insecure Temporary Files Creation‘, che risiede all’ interno della categoria “Insecure Temporary Files“, permette ad un utente non privilegiato, di poter leggere/scrivere file non appartenenti a quest’ultimo, senza restrizione alcuna.

Technical Summary

Come precedentemente descritto, la metodologia d’attacco permette la lettura/scrittura di file su cui non si possiedono permessi.

Come premessa il file non deve esistere, e i nomi dei file in questione, devono essere facilmente rintracciabili ( vedi le sessioni di php, rescrivibili tramite cookie, e le socket di pulseaudio, nomi standard che usano l’uid dell’utente ) e in una posizione dove è possibile leggere e scrivere ( ES: /tmp/ ).

La problematica presente in questi applicativi, è il non controllo dell’esistenza dei file e l’utilizzo di questo senza modifica alcuna dei permessi.

Si può iniziare a mostrare come funziona la tecnica, stabilendo come presupposto che in un hosting, tutti i siti, vengono eseguiti con utenti differenti e che dalle configurazioni normali delle sessioni, php tenta di leggere il file chiamato sess_SESSIONID.

Non è quindi possibile poter leggere il contenuto dei file creati da altri utenti.

Come primo passo, la verifica è diretta alla possibilità di poter leggere/scrivere all’interno della directory dove risiedono i file di sessione.

Qualora il risultato è positivo, ci sarebbero tutte le basi per proseguire con l’attacco. L’attaccante ha necessità di creare, dal proprio sito una “sessione fake” dallo stesso php, così da avere già un file di sessione.

Dopo di che, dovranno essere impostati i permessi del file a 0666 ( -rw-rw-rw ), in modo tale che TUTTI gli utenti possano leggerlo/scriverlo senza restrizioni.

A questo punto il gioco è fatto: due o più utenti, possono accedere ad un file di sessione, e quindi poterlo manipolare a loro piacere.
L’unico task rimanente può essere completato impostando i cookie relativi alla sessione nel sito da “attaccare” ( nella maggior parte dei casi viene lasciato il nome di default PHPSESSION ).

Esempio di come poter eseguire un attacco:


session_start();
$sess = session_id();
$sess_path = session_save_path() . "/";
$sess_file = $sess_path . "sess_" . $sess;
if ( chmod($sess_file, 0666) ) {
     $body .= "Exploited. <br />";
} else {
     $body .= "Exploit Fail. <br />\n";
     return;
}

Esempio di come poter leggere la sessione:


if ( isset($_GET['sess']) ){
     session_id($_GET['sess']);
}
session_start();
print_r($_SESSION)

Technical Demonstration

Dimostrazione video – Attacco demo con Tecnica di Force Insecure Temporary Files Creation

Techinical Utility

Exploit – Force Insecure Temporary Files Creation.