El mundo de la seguridad contuvo la respiración colectiva a principios de esta semana para el gran anuncio de vulnerabilidad de OpenSSL. Resulta que son dos problemas separados, ambos relacionados con el manejo de punycode, y se han degradado a gravedad alta en lugar de crítica. Punycode, por cierto, es el sistema para usar caracteres Unicode no ASCII en nombres de dominio. La primera vulnerabilidad, CVE-2022-3602, es un desbordamiento de búfer que escribe cuatro bytes arbitrarios en la pila. En particular, el código vulnerable solo se ejecuta después de que se verifica la cadena de un certificado. Un certificado malicioso tendría que estar debidamente firmado por una autoridad de certificación o confiarse manualmente sin una firma válida.
A par de fuentes tienen resolvió los detalles de esta vulnerabilidad. Es un error de uno en uno en un ciclo, donde la longitud del búfer se verifica antes en el ciclo que la variable de longitud se incrementa. Debido al desliz lógico, el ciclo puede ejecutarse potencialmente demasiadas veces. Ese ciclo procesa los caracteres Unicode, codificados al final de la cadena punycode, y los inyecta en el lugar adecuado, deslizando el resto de la cadena sobre un byte en la memoria como resultado. Si la longitud total de la salida es de 513 caracteres, se trata de un desbordamiento de un solo carácter. Un carácter Unicode ocupa cuatro bytes, por lo que existe un desbordamiento de cuatro bytes.
Ahora, qué tan explotable se las arregla este desbordamiento depende de lo que haya en esos cuatro bytes. Cuando los investigadores de Datadog probaron la vulnerabilidad en Linux, encontraron que esencialmente cada binario compilado tenía una sección de 4 bytes de memoria libre aquí, que se inicializaba solo después del desbordamiento. En otras palabras, en esos binarios, esta vulnerabilidad es completamente benigna. En Windows, el compilador manejó esa sección de memoria de manera diferente, debido a diferentes optimizaciones. Aquí contiene un pila canario. Ese es un valor especial que existe entre el último búfer en la pila y el puntero y los valores de retorno. Al final de una función que utiliza un canario de pila, el valor se valida antes de volver a la función principal y los procesos se bloquean si se manipulan. La idea es que un desbordamiento de búfer que sobrescribe la dirección de retorno no podría predecir el valor canario, y los canarios tienden a incluir intencionalmente bytes de terminación como 0x00 para hacer que la explotación sea aún más difícil. Tenga en cuenta que los binarios de Linux también usan canarios de pila, lo que evitaría la explotación, pero debido al diseño de la memoria y la longitud de desbordamiento limitada, estos nunca se modifican.
El segundo problema solucionado fue CVE-2022-3786, y Checkpoint Security trató de explicar esto. En el caso de Punycode seguido de un punto, ese punto se agrega al final de la cadena de salida, posiblemente más allá del final del búfer. Es la inversa de la vulnerabilidad anterior. Aquí, la longitud del desbordamiento es casi arbitraria, pero el valor está bloqueado solo en el símbolo del punto. Como resultado, este es estrictamente un problema de denegación de servicio.
Afortunadamente, el cielo no se cae con estas vulnerabilidades, pero aún podría haber casos inesperados en los que OpenSSL no esté compilado con canarios de pila, o el bloqueo podría usarse como parte de una cadena de explotación más complicada, así que aún así asegúrese de tomar el parche actualizado o respaldado si está ejecutando la biblioteca vulnerable, versiones 3.0.0-3.0.6.
¿Los investigadores de seguridad se pasan al lado oscuro?
La ley de los titulares de Betteridge ciertamente está en juego aquí. Esta historia es simplemente extraña, ya que alguien lanzó un ataque de ransomware, que también es protestware, y también afirma ser el trabajo de algunos investigadores de seguridad notables. Entonces, ¿Bleeping Computer está realmente detrás de esta campaña de ransomware que también protesta por la falta de apoyo a Ucrania por parte de Occidente? Oof, hay mucho que desempacar aquí.
Primero, parece que ni siquiera es ransomware, ya que no hay forma de comprar una clave de descifrado. Así que más propiamente es un limpiaparabrisas. El nombre utilizado en la nota del limpiaparabrisas es "Azov", un regimiento de fuerzas especiales en Ucrania con un extraño pasado neonazi, que resulta que juega con la retórica rusa sobre su guerra allí. Entonces la nota dice ser de hasherezade, y enumera varios identificadores de Twitter de investigadores de seguridad. Luego menciona Crimea y se queja de que no hay suficiente ayuda para Ucrania. jHay un mensaje específico para el pueblo de los EE. UU., llamando al presidente Biden, llamando a la revolución y luego lanzando el eslogan "Keep America Great". Luego, un mensaje a Alemania, amablemente ejecutado a través de Google Translate, nos da: “¡Tú! ¡Un hombre de Alemania, vamos, sal!
Pero esa es una catástrofe que Biden les ha traído. ¿Qué tan agradable fue cuando Merkel estuvo allí? Y luego, aún más extraño, la nota termina con el hashtag “#TaiwanIsChina”, que parece ser un eslogan de la retórica patrocinada por el PCCh en Taiwán.
Es difícil saber exactamente qué pasa con esta campaña. Obviamente no es lo que dice ser. ¿Un hacker pro-Rusia o anti-Rusia tratando de obtener apoyo? ¿Algo completamente diferente, usando la geopolítica como cobertura? Todas las infecciones parecen ser el resultado de SmokeLoader, una de las botnets de malware como servicio. Pague algo de dinero, envíe su carga útil a las máquinas en la red de bots. Solo un recordatorio, si usted o alguien que conoce se ve afectado por una de estas campañas, las oficinas de aplicación de la ley quieren obtener un registro de ello. Para localizar y enjuiciar a los criminales detrás de estas empresas, necesitan algunos casos concretos para empezar. Y por mucho que parezca que los criminales de ransomware nunca serán atrapados, son identificados y atrapados.
Project Zero se resiste a llamarlo XML4Shell
[Félix Guillermo] Encontré un problema de Java, y para nuestro deleite compartido, no sintió la necesidad de idear un apodo de "4 shell" para él. Esta historia comienza con SAML, Security Assertion Markup Language, el protocolo basado en XML que impulsa gran parte del soporte de inicio de sesión único de la web. Desea visitar el sitio web X, un proveedor de servicios (SP) y usar su cuenta del sitio web Y, su proveedor de identidad (IdP). El SP genera una solicitud SAML, en forma de documento XML, y su navegador envía ese documento al IdP. El IdP confirma que tiene una cuenta allí y envía una firma XML a través del navegador. Como es un problema potencial obvio que el navegador del usuario sea el que maneje los datos de inicio de sesión, los datos en sí se verifican como parte de la firma. Todo el proceso es complicado y una de las complejidades es que una firma puede incluir referencias a otras firmas. Antes de que la firma se verifique por completo, es posible que el documento XML firmado deba pasar por varios pasos de transformación, y se admite el lenguaje de transformaciones de lenguaje de hoja de estilo extensible (XSLT). Sí, es un lenguaje completo de turing directamente en sus objetos SAML. Y si el código que realiza la verificación no se encendió secureValidation, el código se compila en código Java para aumentar el rendimiento.
Parte de este proceso de compilación es convertir valores en la entrada XSLT al conjunto de constantes de Java. Ese grupo tiene un tamaño limitado y el proceso de compilación no verifica correctamente los límites. ¿Qué sucede cuando escribes más allá del final de la piscina? Esos datos se entienden como campos de clase, campos como definiciones de métodos. Haga el trabajo para crear valores válidos para los tres campos que este desbordamiento aplastará, y tendrá la capacidad de ejecutar un código de bytes arbitrario. Esto funciona para cualquier aplicación Java que maneje firmas XML, en teoría. La gran advertencia es que secureValidation deshabilita todas las transformaciones XSLT, pero eso solo se activó de forma predeterminada en JDK 17.
urlscan.io guarda secretos
El servicio prestado por urlscan.io en realidad es bastante útil. Entréguele un enlace web y lo cargará, obtendrá una vista previa de la página y mostrará algunas estadísticas al respecto. ¿Alguien envió un enlace extraño y no quieres abrirlo en tu máquina? Aquí está tu solución. Lo único que debe tener en cuenta es que, a menos que marque explícitamente el escaneo como privado, el enlace y los resultados se pueden ver públicamente. Github fue mordido el año pasado, filtrando accidentalmente nombres de repositorios privados al servicio. Esto hizo que [FABIAN BRÄUNLEIN] se preguntara: ¿Otros servicios habían cometido un error similar?? Sí. Hay enlaces a documentos privados de Google, claves API, invitaciones de Sharepoint y Zoom, y más. Aparentemente, varios servicios de seguridad automatizados envían enlaces al servicio sin ninguna interacción del usuario y no usan la API correctamente. ¡Vaya!
