P: ¿Qué es la vulnerabilidad de Log4j (también conocida como Log4Shell)?
JNDI es la interfaz de nombres y directorios de Java. No es una aplicación, sino una biblioteca/servicio que permite la configuración en tiempo de ejecución. Log4j es una biblioteca común utilizada en aplicaciones de servidor. Ciertas cadenas, cuando se utilizan con la versión v2.x de la biblioteca Log4j, pueden invocar la API JNDI, lo que puede dar lugar a la filtración de información sensible y facilitar así otros ataques. Básicamente esto es una variación de la sanitización de entrada, excepto en una utilidad de registro que por razones tenía una característica útil pero peligrosa habilitada.
Probablemente haya oído hablar de los llamados Ataques de inyección SQL donde alguna cadena especialmente diseñada puede modificar los comandos dados al motor de la base de datos. Ejemplo:
Aquí, Robert '); DROP TABLE Students; --
puede insertarse en esta consulta insert into Students (id, name) values (42, $name)
. Cuando el software sustituye directamente $name
con el nombre, se convierte en esta consulta/comando: insert into Students (id, name) values (42, Robert '); DROP TABLE Students; --)
(insertar, y luego soltar la tabla, todo lo demás se comenta).
Los desarrolladores necesitan sanear la entrada es decir, comprobar todos los posibles valores peligrosos. Los desarrolladores pueden, por ejemplo, escapar del '
en el nombre antes de sustituirlo. Como alternativa, los desarrolladores que utilicen SQL pueden utilizar sentencias preparadas, en las que ni siquiera se realiza la sustitución.
P: ¿Es vulnerable el sistema operativo Android?
R: No por esta vulnerabilidad en particular - El sistema operativo Android, aunque algunas partes están escritas en Java, utiliza su propia biblioteca de registro. El sistema operativo Android tampoco utiliza el protocolo/servicio JNDI y aísla cada aplicación en su propia caja de arena. Esto significa que este exploit JNDI en particular no puede ser utilizado en Android, historia ha demostrado que Android no está exento de bugs y exploits, lo que se traduce en una mayor seguridad con cada versión.
P: ¿Son vulnerables las aplicaciones de Android?
R: Depende - Las aplicaciones de Android pueden existir sólo en el dispositivo o servir como front-end de un servicio en la nube. Las aplicaciones de Android tienen sin duda sus propios errores. En los dispositivos más antiguos, las aplicaciones pueden acceder al logcat global, donde las aplicaciones mal escritas pueden mostrar el nombre de usuario/contraseñas/otras claves que, aunque son útiles para la depuración, no son buenas en una aplicación de producción. A partir de Android 4.1 las aplicaciones de Android sólo pueden acceder a sus propios registros .
Los servidores de los que dependen las aplicaciones móviles son una historia diferente, como se ha señalado en los medios de comunicación.
P: ¿Pero qué pasa con las aplicaciones Android que utilizan Log4j
R: En el dispositivo un desarrollador tendría que esforzarse realmente para añadir en Log4j por separado. Como se ha visto aquí Log4j fuera de la caja necesita clases Java que Android no soporta. Y aunque hay un puerto para Android se basa en la versión 1.x de Log4j que es EOL, parece que esa versión tenía sus propios problemas lo que disuadiría a los desarrolladores de Android. Como alternativa, un desarrollador de Android puede utilizar slf4j para Android u otros cuñas de registro desarrolladas activamente sobre la facilidad de registro nativo de Android.
Referencias:
¿Qué es JNDI? ¿Cuál es su uso básico? ¿Cuándo se utiliza?
https://unit42.paloaltonetworks.com/apache-log4j-vulnerability-cve-2021-44228/
Cómics de xkcd: 327