retorno - Funciones Java aprovechables

procedimiento y funcion en java

Question

Esta pregunta es similar a las Funciones explotables de PHP .

Los datos contaminados provienen del usuario, o más específicamente de un atacante. Cuando una variable contaminada alcanza una función de sumidero, entonces usted tiene una vulnerabilidad. Por ejemplo, una función que ejecuta una consulta SQL es un receptor, y las variables GET / POST son fuentes de contaminación.

¿Cuáles son todas las funciones de sumidero en la biblioteca de clases de Java (para cualquier sabor de Java)? Estoy buscando funciones que introduzcan una vulnerabilidad o debilidad del software . Estoy particularmente interesado en las vulnerabilidades de ejecución remota de código. ¿Hay clases / bibliotecas enteras que contengan funcionalidades desagradables que un hacker quiera influenciar? ¿Cómo la gente accidentalmente crea código Java peligroso?

Answer 1

Aquí hay una lista basada en mi investigación personal sobre la seguridad de Java del lado del cliente en general, y el uso del IDE de Eclipse para ver qué métodos verifica SecurityManager.

ClassLoaders define clases (= ejecución de código java arbitraria) :

java.lang.ClassLoader.defineClass
java.net.URLClassLoader

= ejecución de código

La introspección de Java Beans puede desviar ClassLoaders en clases de carga desde una fuente no confiable ( ejemplo vuln - cve-2010-1622 )

java.beans.Instrospector.getBeanInfo

= ejecución de código

Acceso a archivos

java.io.File (constructor)
java.io.File.delete
java.io.File.renameTo
java.io.File.listFiles
java.io.File.list

= borrar / cambiar el nombre de los archivos, listado de directorios

Clases de flujo de archivos / lector

java.io.FileInputStream
java.io.FileOutputStream
java.io.FileReader
java.io.FileWriter
java.io.RandomAccessFile

= Acceso de lectura / escritura de archivo

Propiedades del sistema Java

System.setProperty
System.getProperties
System.getProperty

= Algunas propiedades del sistema pueden contener cierta información que es casi confidencial, y algunas propiedades del sistema pueden alterar la ejecución de cosas críticas, aunque no tengo ejemplos

Cargando bibliotecas nativas

System.load
System.loadLibrary

= Ejecución de código arbitrario

Ejecutar ejecutables del sistema operativo

Runtime.exec
ProcessBuilder (constructor)

Generación de eventos de entrada del sistema nativo

java.awt.Robot.keyPress/keyRelease
java.awt.Robot.mouseMove/mousePress/mouseRelease

(Tal vez exagerado ya que un servidor podría no tener un entorno gráfico)

Reflejo de Java: acceso a campos y métodos arbitrarios (incluso privados)

java.lang.Class.getDeclaredMethod
java.lang.Class.getDeclaredField
java.lang.reflection.Method.invoke
java.lang.reflection.Field.set
java.lang.reflection.Field.get

= De revelar información confidencial a la ejecución del código eventual, dependiendo de las circunstancias

Motor de scripting Java

javax.script.ScriptEngine.eval

= ejecución de código arbitrario

Answer 2

Estoy seguro de que esta lista crecerá a medida que investigo verdaderos exploits:

1. Cargador de clases Spring

2. Excepciones tragadas: como se ha observado, la ingestión de excepciones puede no causar directamente una explotación, pero puede conducir al no descubrimiento de la explotación.

3. String[] commands = {args[0]};
Runtime.getRuntime().exec(commands);
   Me doy cuenta de que es un elemento bastante trivial, pero el código de ejecución similar al anterior puede permitirle pasar algo como esto: && del / if en Windows o ;rm -rf / on * nix

La manera más grande en que la gente crea un código Java peligroso es siendo flojo. Como mencionaste, no limpias la entrada del usuario antes de ejecutarlo.

Answer 3

Vulnerabilidades de ejecución de código:

1. Reflexión privada, pero no es común que los datos viciados lleguen de una manera peligrosa
2. Código nativo de interoperabilidad que no valida sus parámetros lo suficiente
3. Des-serializadores . Probablemente el más peligroso ya que es posible que desee deserializar datos no confiables. Algunos serializadores son relativamente seguros y solo usan constructores públicos / setter, pero otros tienen acceso a campos privados. Y si no hay una lista blanca de tipo, podría instanciar tipos arbitrarios y establecedores de llamadas sobre ellos.
4. Cualquier forma de IO, archivos en particular
5. Carga dinámica de bibliotecas. En particular, utilizando la ruta relativa. En particular, en relación con el directorio de trabajo en lugar del directorio ejecutable

(Esto es sobre .net, pero espero que Java sea muy similar)

Inyección de datos

Luego está la familia de funciones de inyección que, por lo general, pueden prevenirse al no operar en cadenas pero utilizando funciones de biblioteca especializadas. Esos típicamente no conducen a la inyección de código arbitrario.

1. html injectiong / XSS (ampliamente impedido por un motor de vista que escapa automáticamente de salida y separando limpiamente cadenas escapadas y no escapadas (quizás usando diferentes tipos)
2. Inyección SQL (evitada por declaraciones preparadas)
3. Inyección de ruta de archivo