5 Applet ostili

Nonostante Java offra controlli sulla sicurezza a livello del linguaggio, è sempre possibile un uso errato di Java, o meglio degli applet Java. Gli applet che effettuano operazioni "illecite" vengono chiamati applet ostili.

Esistono due varietà di applet ostili: applet d’attacco e applet maliziosi. Ovviamente quelli d’attacco sono i più pericolosi, ma raramente sono stati visti al di fuori dei laboratori in cui sono nati. Comunque esistono e ne discuteremo ampiamente in seguito. Diversamente da quest’ultimi, gli applet maliziosi si possono incontrare con più facilità navigando per il Web.

5.1 Possibili attacchi

E' possibile raggruppare gli attacchi sferrabili da applet secondo alcune tipologie, la maggior parte degli addetti ai lavori ne considerano quattro e cioè:

La Tabella mostra le risorse del sistema che vengono coinvolte dai vari tipi di attacchi:

Nelle sottosezioni che seguiranno verranno introdotti alcuni tipi di attacchi, a nostro giudizio degni di nota in quanto non si possono associare univocamente (eccetto i Denial of Service attacks che sono Availability attacks) con una delle tipologie precedentemente illustrate, poiché hanno o caratteristiche a sé stanti o caratteristiche comuni a più tipologie.
Casi particolari sono gli attacchi Denial of service e gli attacchi di type confusion, i primi vengono introdotti per il grande "successo" riscontrato negli ultimi periodi, mentre gli attacchi di type confusion vengono illustrati per meglio capire la maggior parte degli attacchi che presenteremo nella sezione 5.3.

5.1.1 Denial of Service attack

Il termine "Denial of Service" (spesso abbreviato in DoS) indica un attacco il cui scopo è quello di produrre una perdita di funzionalità, più o meno prolungata nel tempo.
Dalla definizione risulta chiaro che, questa classe di attacchi, non ha come obiettivo quello di guadagnare un certo controllo della macchina, ma quello di impedire alla macchina di svolgere alcune operazioni.
Java non ha molti mezzi per identificare gli attacchi Denial of service, gli attacchi comuni sono del tipo busywaiting nei quali si consumano cicli di CPU e allocano memoria fin quando il sistema è fuori servizio, e mandando in starvation gli altri processi di sistema. Gli attacchi verso la memoria e la CPU sono difficili da trattare perché molte applicazioni "legali" potrebbero aver bisogno di grandi quantità di risorse.
Ci sono due varianti di questo tipo di attacco. La prima variante consiste nel ritardare un attacco nel tempo, in altre parole può essere effettuato quando l'utente sta guardando altre pagine allo scopo di mascherare la sorgente dell'attacco. La seconda viene denominata degradation of service dove non c'è proprio una negazione del servizio, ma il rendimento del browser viene notevolmente ridotto.

5.1.2 Trojan Horse

Un Trojan Horse è un qualsiasi programma che ha una funzione visibile e una funzione nascosta, un esempio può essere un programma che esegue un gioco mentre segretamente invia file interessanti via e-mail al realizzatore del programma. Quest’attacco funziona perché di solito un programma eredita i suoi diritti di accesso dall'utente che lo ha eseguito in base a quanto è stabilito nel SecurityManager.
Esempi di Trojan Horse sono:

• Un applet che visualizza un’animazione e che discretamente cerca file dell'utente interessanti e li rispedisce attraverso la connessione.
• Un applet che esegue un gioco con l'utente e che di nascosto apre un xterm controllato in remoto dal sito sorgente. In questo modo possono essere eseguiti comandi sulla macchina dell'utente.
• Un applet che crea una finestra di taglia nulla, rimanendo invisibile all'utente e che legge i tasti premuti destinati ad altri applet, rimandandoli tutti indietro attraverso la connessione.

5.1.3 Covert Channels (Canali nascosti)

Esistono nei browser diversi canali nascosti i quali permettono agli applet di stabilire comunicazioni a due vie con una qualunque terza persona su Internet, quest’attacco "a due parti" richiede che l'applet risieda nel server Web per partecipare all'attacco. Un attacco "a tre parti" può nascere da qualsiasi parte di Internet, e potrebbe espandersi se questo contiene delle funzionalità che vengono usate da molte pagine Web. Un attacco "a tre parti" è molto pericoloso rispetto all'attacco "a due parti" perché esso non ha bisogno di accordi con il Web server.

La Figura Mostra l'attacco "a tre parti":

Se il Web server che contiene l'applet usa anche l'SMTP mail daemon, l'applet può connettersi con quest'ultimo e trasmettere un messaggio e-mail ad una macchina in Internet. Inoltre il DNS può essere usato come un canale di comunicazione a due vie con host arbitrari in Internet. Un applet può far riferimento a un nome fittizio all'interno del dominio di chi attacca. Questo applet trasmette il nome al server DNS dell'attacker, il quale può interpretare il nome come un messaggio, e quindi può mandare una lista di numeri IP arbitrari a 32-bit come reply. Chiamate ripetute al DNS da parte dell'applet possono creare un canale tra quest'ultimo e il server DNS dell'attacker, bypassando, così, i controlli dei firewall.

Un altro canale a tre parti è ottenibile con la caratteristica della redirezione dell'URL. Normalmente, un applet può istruire il browser a caricare qualsiasi pagina dal Web. Il server di un attacker può registrare l'URL come un messaggio e quindi redirezionare il browser verso la destinazione originale.

5.1.4 Type Confusion attack

Un attacco di type confusion crea due puntatori allo stesso oggetto, etichettandoli con tipi incompatibili (Fig. 5.2). L’applet può accedere in scrittura alla porzione di memoria attraverso un puntatore ed in lettura attraverso l’altro, evitando di rispettare le regole sui tipi di java.

Figura 5.2

Illustriamo un esempio abbastanza pratico: come si vede dalla figura 5.3, entrambe le classi A e B si riferiscono al classname "C", però hanno idee diverse su cosa indica il nome "C". Se il codice in A alloca un oggetto di tipo "C" e lo passa a B, allora il Byte Code Verifier crede che sia tutto in regola e permette tale operazione. Quando B accede all’oggetto, lo fa in base alla propria definizione di "C" => type-confusion

Figura 5.3 Type Confusion

5.2 Applet maliziosi

Qualsiasi applet che agisce contro la volontà di chi lo scarica può essere considerato malizioso. Gli applet maliziosi attaccano il sistema locale di un Web user, con il rischio di danneggiare seriamente la macchina, usando tre delle classi di attacco precedentemente trattate: denial of service, invasione della privacy e disturbo. Questi applet vengono realizzati da ricercatori, crackers, e gente intenzionata a infastidire e a danneggiare utenti Java.

Vediamo cosa un applet malizioso è in grado di fare:

1. Inviare E-mail a chiunque, spacciandosi per il malcapitato Utente Web
2. Consumare cicli della CPU per rallentare gli altri processi attivi
3. Mandare in CRASH il sistema locale, utilizzando tutte le risorse

Queste attività impressionano e preoccupano, ma un applet malizioso è in grado di compiere molte alte attività. Esistono anche applet maliziosi sviluppati solo per creare fastidi che si pongono ai confini della rispettabilità, applet in grado di far ascoltare suoni in continuo o di visualizzare immagini indesiderate.

L’unica cosa da fare, per evitare che si verifichino problemi del genere, è disabilitare Java dal proprio browser se si è intenzionati a visualizzare siti Web PERICOLOSI. Sono allo studio soluzioni per porre fine a questi problemi nel futuro, come ad esempio la realizzazione di un programma che riconosce gli applet "nocivi" sulla base delle vulnerabilità note, oppure il miglioramento del modello di sicurezza Java. C’è da dire che notevoli passi sono stati fatti in Java 2 grazie alla firma del codice ed all’access control, i quali permettono di costruire complesse politiche di sicurezza.

Passiamo ora in rassegna i vari tipi di applet maliziosi, iniziando da quelli più semplici:

5.2.1 Annoyance Attack Applet

Questi applet operano al limite dell’accettabile nel senso che possono visualizzare immagini oscene o far emettere suoni in continuo, sfruttando i package multimediali che offre Java. Non bisogna a questo punto confondere applet maliziosi di questo genere con applet che involontariamente operano come tali.
Un esempio banale, ma simpatico, è l’applet denominato "April Fool", il quale visualizza una dialog box con la scritta "April Fool" ed un bottone di OK, un utente si aspetta che la pressione del tasto faccia terminare l’applet, ma la dialog box sfugge al puntatore del mouse, evitando la chiusura dell’applet stesso. L’unica cosa da fare è chiudere il browser.
Un ulteriore esempio di Annoyance Attack: NoisyBear.java

5.2.2 Integrity Attack Applet

Tali applet sono più pericolosi dei precedenti in quanto possono effettuare modifiche al file system, alla memoria o "disturbare" gli altri processi. Illustriamo il famoso Business Assassin, un applet detto di controllo. Il Business Assassin, una volta avviato su una macchina remota, controlla silenziosamente tutti gli applet che vengono caricati; se vengono caricati da un dato sito Web (precedentemente impostato) il business assassin rende inutili tali applet, uccidendo tutti i loro thread.
A prima vista il Business Assassin sembrerebbe alquanto innocuo, ma i suoi thread rimangono in esecuzione nonostante l’applet termini, ciò può far cadere le colpe su qualsiasi altro applet soprattutto se l’attacco viene posticipato nel tempo.
Applet simili al Business Assassin hanno un effetto tutt’altro che produttivo verso le società commerciali, che si affidano al Web (da qui il nome di Business Assassin!).
Un esempio di applet simile al Business Assassin: AppletKiller.java

5.2.3 Availability Attack Applet ( Denial of Service)

Tali applet hanno come obiettivo il rendere inutilizzabile la macchina dell’utente Java, utilizzando tutta la CPU e tutta la memoria, aprendo finestre molto grandi o facendo in modo che il sistema attenda che qualcosa di impossibile si verifichi. Alla luce di quanto detto, questi applet non devono essere sottovalutati. A titolo di esempio consideriamo il seguente attacco Denial-of-Service, che usa thread non terminanti:

1. Creare un applet che genera un thread con la massima priorità per consumare cicli di CPU
2. Ridefinire il metodo che gestisce la terminazione del thread(per renderlo non terminante)
3. Far compiere alla parte principale dell’applet operazioni innocue
4. Far dormire il thread per qualche porzione di tempo prima di attaccare (questo allo scopo di far cadere i sospetti su altri applet)
5. Far compiere al thread, non appena si sveglia, attività che rendano inefficiente il sistema vittima

Come precedentemente accennato, gli attacchi Denial of service non vanno trascurati, sebbene non consentano l’accesso alle informazioni della macchina locale. Tali attacchi possono essere ancor più dannosi quando vengono lanciati contro server Web (vedi gli ultimi attacco contro il sito della Yahoo). In sintesi, chiunque può bloccare server Web che usano Java, a meno che vengano effettuati controlli sugli utenti.

Consideriamo ora gli applet che rubano cicli CPU, tali applet usano la macchina dell’utente Web per risolvere in modo distribuito problemi complessi (Problemi NP), un esempio potrebbe essere la rottura di un sistema RSA basato sulla fattorizzazione e l’invio via E-mail dei risultati raggiunti. La fattorizzazione è solo un esempio, ma tali applet possono eseguire diversi compiti. A tal fine presentiamo un esempio di Availability attack applet che consuma CPU calcolando una funzione complessa.

Un altro tipo di attacco Denial of Service, più serio di quello appena citato, è quello che apre un gran numero di finestre dalla taglia spropositata. Molti motivi rendono tali applet più dannosi, basti pensare che mentre sono in esecuzione riescono a bloccare l’accesso alla tastiera ed al mouse, rendendoli, quindi, difficili da controllare.
Aprire tante finestre contemporaneamente ha come effetto di riempire lo stack degli eventi del window manager. Ciò disabilita la tastiera ed il mouse, visto che non possono più dialogare con la macchina, servendosi di eventi window. Cosa si può fare se ci viene lanciato un attacco di questo tipo? Si può uccidere il processo del browser da un’altra macchina sulla stessa rete oppure premere la FATIDICA sequenza CONTROL-ALT-CANC  per effettuare il reboot.
Da un lato, la capacità di aprire finestre untrusted senza gli obbligatori avvisi è molto interessante. Infatti, si possono far comparire insospettabili finestre in cui viene chiesto all’utente la propria password a causa di un qualche allarme di sicurezza. Molti cadono in questa trappola e quindi un applet malizioso di questo tipo può inviare via E-mail le informazioni ad un dato sito. Mettendo insieme questi applet con quelli di controllo si può raffinare l’attacco, nel senso che si può creare un applet che lanci un thread il quale comincia l’attacco dopo aver lasciato la pagina di origine. Il thread determina quando l’utente sta visitando un dato sito e quindi può far apparire una falsa finestra di log-in.

5.2.4 Disclosure Attack Applet ( falsificazione di E-mail )

Molti esperti della rete conoscono un trucco per inviare false E-mail, dialogando direttamente con il demone SMTP, utilizzando la porta 25: basta effettuare un telnet sulla porta 25 e dare istruzioni al demone direttamente. E’ comunque facile capire se riceviamo una E-mail falsificata, infatti il demone SMTP marca ogni E-mail con il proprio IP e basta una occhiata all’header per riconoscere l’inganno (La macchina da cui parte l’E-mail è la stessa della destinazione!). Utilizzando gli applet per falsificare la posta, si rende molto più difficile la distinzione tra vero e falso proprio perché l’applet invia E-mail dalla macchina di un utente Web, spacciandosi per l’utente stesso.

Immaginiamo cosa potrebbe succedere se un applet che carichiamo invia E-mail oltraggiose a persone politicamente importanti a nostro nome, o se invia migliaia di MAIL BOMB a nostre veci!!!
Tutto ciò è correntemente possibile perché la falsifica delle Mail opera all’interno dei limiti di sicurezza di java e di SMTP. Un esempio di E-mail forging: Forger.java