Explotación de vulnerabilidad en Java

Tendrías mucha suerte de encontrar un caso en el que puedas ejecutar código directamente a través de un simple error de codificación en Java. Es posible que un error en la implementación de la JVM permita la corrupción de la memoria a través de un código benigno, pero en el peor de los casos es extremadamente raro.

Sin embargo, incluso dentro del JRE (OpenJDK), una parte de las bibliotecas están escritas en C, y por lo tanto contienen vulnerabilidades de corrupción de memoria cuando se usan con datos no confiables. Renderizar un JPEG malicioso sería el ejemplo canónico.

Hay muchos errores no relacionados con la memoria, como la inyección (HTML, SQL, LDAP, encabezados HTTP, etc.), pero en general los que no lo llevan directamente a la ejecución remota de código.

Una situación demasiado común es cuando una biblioteca práctica ejecuta deliberadamente código remoto sin que el programador de aplicaciones lo habilite deliberadamente. Ejemplos proporcionados en las Pautas de codificación segura para Java SE (5.0) Pauta 3-8 / INJECT-8 : Tenga cuidado al interpretar el código que no es de confianza hay ciertas características en: la API de scripting, LiveConnect, las extensiones XSLT, la persistencia a largo plazo de los componentes JavaBeans, el sonido Java, RMI, LDAP y ciertas implementaciones JDBC / SQL. Una aplicación puede cargar código móvil de forma deliberada, lo que conduce a otro mundo.

La respuesta corta sería "todos los demás", pero sin incluir los tipos simplistas de errores de la explotación de desbordamientos de búfer de memoria en bruto. Hay muchas otras formas en que la memoria podría usarse incorrectamente sin sobrepasar un búfer.

Un ejemplo que podría clasificarse como un problema de desbordamiento de búfer en java ser si la aplicación utiliza try / catch para interceptar intentos de desbordamientos de búfer, y como resultado De atrapar uno, se pasa por alto algún código importante. Podrías imaginarte un mal escrito. La función "checkpassword" que devolvió "éxito" si se le asigna una contraseña con demasiados caracteres.

Una opción es explotar la JVM en sí misma: puede ser posible tener un código Java que haga que la máquina virtual real se "rompa" y ejecute operaciones arbitrarias fuera de la zona de pruebas; ha habido tales explotaciones, aunque parecen depender de enviar a la víctima algún código Java para su ejecución (es decir, en un contexto de un entorno de pruebas del navegador), no explotar programas Java aleatorios.

Otra opción es identificar y abusar de problemas lógicos en los programas. En los exploits de C, un escenario típico es usar una verificación de límites incorrecta como una forma de obtener un comportamiento totalmente indefinido (como la ejecución de código arbitrario) no relacionado con la verificación en particular; sin embargo, en ausencia de eso, algunas comprobaciones de límites erróneas o problemas lógicos pueden lograr una ruta de código que (involuntariamente) está en el código original y hace lo que usted quiere.

Y, por supuesto, todas las ventajas de la complejidad de la aplicación de múltiples capas tienen posibles vectores de ataque: inyecciones de SQL si esa aplicación java se vincula a una base de datos, etc.

Las fallas de seguridad comunes de Java incluyen:

• Ataques de inyección : inyección SQL, secuencias de comandos entre sitios, inyección XPath, entidad externa XML y mucho más. Soy consciente de unos 20 tipos diferentes de inyección.
• Fallos en la lógica de negocios : manipulación de parámetros, navegación forzada, números negativos aceptados, etc.
• Errores de autenticación y sesión : no se permiten bloqueos de cuenta, corrección de sesión, ID de sesión predecible, etc.
• Otros : fuga de información, carga de archivos ejecutables, etc.

Las fallas que acabo de mencionar se aplican a las aplicaciones Java en sí mismas. Un escenario común es una aplicación web Java, que puede ser atacada por clientes web maliciosos. Incluso si la JVM es 100% segura, las aplicaciones pueden tener sus propias debilidades.

Otro escenario son los applets de Java. Esta es realmente una situación muy diferente, un applet de Java que no es de confianza se está ejecutando en su navegador, dentro de un recinto de seguridad, y está intentando salir de él. Aquí la seguridad de la JVM en sí misma es crucial.