Esto se debe principalmente a lo que es calificado como una locura en los métodos utilizados en Java. En este contexto, los científicos de las universidades de Francia, Alemania, Luxemburgo y Suecia se sumergieron profundamente en las vulnerabilidades de deserialización de Java conocidas y ahora han resurgido con sus hallazgos. En resumen, han llamado la atención sobre las formas en que las bibliotecas pueden introducir accidentalmente graves fallas de seguridad. Por supuesto, para quiénes están tomando un curso de Java está información es trascendental.
La serialización se utiliza para convertir un objeto de datos en la memoria en una serie de bytes para almacenamiento o transmisión. La deserialización invierte ese proceso al convertir un flujo de datos nuevamente en un objeto en la memoria.
Origen de los problemas de seguridad.
En Java, esto se implementa mediante la interfaz java.io.Serializable. Pero la deserialización no es necesariamente segura porque la reconstrucción del objeto a partir de su flujo de bytes no involucra al constructor, el código modelo que inicialmente construye el objeto para que tenga las funciones y los métodos que debería tener. Si el constructor tenía comprobaciones de validación, no se ejecutan. Por lo tanto, es posible que la deserialización cree objetos que no son válidos o que tienen datos alterados.
Los errores de deserialización de Java pueden ser bastante graves. Por ejemplo, Log4Shell, la falla de ejecución remota de código que afecta a la biblioteca de registro de Apache Log4j fue posible gracias a la deserialización de Java. En noviembre de 2016, un ataque de ransomware comprometió más de dos mil computadoras administradas por la Agencia de Transporte Municipal de San Francisco (SFMTA) a través de una vulnerabilidad de deserialización de colecciones de Apache Commons.
Lo anterior implica que, para tener códigos adecuados, lo mejor es contar con sistemas desarrollados por expertos que se hayan actualizado en estos temas a través de un curso de Java. En las siguientes notas mostraremos las implicaciones en la seguridad del código.
Todo lo anterior enfatiza la necesidad de aprender a programar en Java de forma correcta. También es importante hacerlo a conciencia, sabiendo que los programas seguramente serán víctimas de ataques cibernéticos y que los programadores deben hacer lo necesario para evitarlos.
Ejemplos de vulnerabilidad.
Sirva de muestra lo ocurrido hace un par de años. En este caso, el punto de entrada para el pirateo de Equifax de 2017 que resultó en el robo de datos personales de 147,7 millones de estadounidenses provino de una falla de deserialización de Java en Apache Struts. Y en julio pasado, hubo una vulnerabilidad de Atlassian Jira en la que un atacante capaz de conectarse a un servicio de red Ehcache RMI podría ejecutar código arbitrario de su elección en Jira a través de la deserialización debido a una vulnerabilidad de autenticación faltante.
En un artículo titulado "An In-depth Study of Java Deserialization Remote-Code Execution Exploits and Vulnerabilities", los científicos informáticos Imen Sayar (Universidad de Toulouse), Alexandre Bartel (Universidad de Umeå), Eric Bodden (Universidad de Paderborn) e Yves Le Traon (Universidad de Luxemburgo) describe cómo examinaron las bibliotecas de software objetivo de 19 exploits RCE de deserialización de Java conocidos públicamente para comprender cómo los gadgets (construcciones de código explotables) se introducen en las bibliotecas de Java y cómo a veces fallan los intentos de deshacerse de estos gadgets.
Si bien la serialización y la deserialización son útiles, los autores observan que este proceso presenta riesgos si los datos deserializados provienen de una fuente no confiable. De hecho, un atacante podría crear un flujo de bytes que, cuando se deserializa en el host remoto, podría controlar el flujo de ejecución del código Java encadenando secuencias de código llamadas gadgets. Por lo tanto, es necesario revisar cualquier problema que pudiera existir en las bibliotecas. En la siguiente nota ampliaremos la información al respecto.
El término gadget tiene algunos significados específicos en el mundo de la explotación de vulnerabilidades. Para el titulado "An In-depth Study of Java Deserialization Remote-Code Execution Exploits and Vulnerabilities", los autores usan la palabra para referirse a un método Java potencialmente explotable accesible para el atacante. Una biblioteca puede contener dispositivos que se pueden encadenar, por lo que pueden operar en una secuencia.
Aprovechar una vulnerabilidad de deserialización puede implicar una cadena de ataque complicada o puede ser tan simple como realizar una solicitud GET a través de una red. Nuestra conclusión principal es que la modificación de un detalle de aspecto inocente en una clase, como hacerlo público, ya puede introducir un dispositivo. Los investigadores analizaron 19 exploits para vulnerabilidades en 14 bibliotecas (algunas con varias versiones): beanshell, clojure, commons-beanutils, commons-collections, groovy, rome, js-rhino, spring-beans, spring-core, spring-aop, click-nodeps, javax.servlet, vaadin-server y vaadin-shared.
Al analizar los 19 exploits RCE, identificamos varias formas de introducir un dispositivo en una biblioteca: agregar clases, métodos e interfaces, o cambiar la firma de los métodos. Dado que los gadgets son necesarios para crear un exploit de deserialización, la modificación del código que inserta nuevos gadgets claramente no es lo ideal. De las bibliotecas y sus variantes probadas, 14 se han parcheado para eliminar dispositivos potenciales. Esto se puede hacer de varias maneras, como eliminar java.io.Serializable de la lista de interfaces en una clase vulnerable, eliminar la clase vulnerable en su totalidad o introducir una verificación de seguridad, entre otras técnicas.
Seis de las bibliotecas evaluadas (commons-beanutils1.9.4, rome1.0, spring-beans-3.0.0.RELEASE, click-nodeps-2.3.0-RC1, javax-servlet-api-4.0.1 y vaadin-shared -7.4.0.beta1) aparecen como no parcheados. Entonces, si sus aplicaciones incluyen alguno de ellos, es posible que desees considerar cómo abordarlo. Sin embargo, esperar una solución puede no ser la mejor opción.
Soluciones a los problemas de seguridad de Java.
Al estudiar parches de dichas bibliotecas, observaron los investigadores que el tiempo que se emplea para retirar los gadgets varía entre varios meses y casi 12 años, con una media de casi seis años. Por lo tanto, parece que las vulnerabilidades de deserialización aún no reciben la atención de los profesionales que realmente deberían merecer. Por supuesto, quienes han tomado un curso de Java online están más capacitados para realizar dichas modificaciones, pues se especializan en programar en Java.
