Esta semana en seguridad: un error de voz adicional, un fragmento de código UDP y la gran vulnerabilidad de Citrix

América Aguilar
América Aguilar

Recientemente se ha corregido un error de seguridad crítico en Chrome, CVE-2020-6378. El informe CVE todavía está marcado como privado, al igual que el informe superior. Todo lo que tenemos es “Use after free en reconocimiento de voz”. ¿Tenemos la suerte de intentar aprender más sobre esta vulnerabilidad? Si observa detenidamente el informe de errores privado, notará que está en la pista de errores de Chromium. Chrome se basa principalmente en el proyecto Chromium, con algunas características patentadas agregadas. Debido a que Chromium es de código abierto, podemos encontrar el cambio de código que solucionó este error y tal vez aprender más sobre él.

A la fuente Chromium, reflejada en Github. Podríamos mirar cada comisión y, finalmente, encontrar la que estamos buscando, pero los mensajes de comisión de Chromium generalmente incluyen una referencia al error corregido por esa comisión. Entonces, podemos usar la función de búsqueda de Github para encontrar una recomendación que mencione 1018677. Así, encontramos una única edición y más información.

La interrupción mencionada en el mensaje de comisión puede estar relacionada con el cierre del navegador, pero también podría estar relacionada con la pestaña que reconoce el discurso, o incluso con el propio sistema de voz. Debido a que varias partes se descargan en paralelo, existe una condición racial entre llamar al objeto abortado y ese objeto descargado de la memoria. Esta carrera puede resultar en un uso clásico después de la ejecución gratuita, omitiendo la ejecución del código en una ubicación de memoria ya publicada.

Todo interesante, pero ¿cómo merece eso una calificación crítica? Ingrese a la API web. Supongo un poco, pero probablemente esta API use el código de reconocimiento de voz relevante. Quizás incluso interactúe con el incentivo de seguridad que está causando el bloqueo. Imagine que una página de ataque intenta utilizar la API verbal y luego libera el objeto API antes de que el usuario pueda responder a la solicitud. Ese * podría * ser el escenario descubierto, aunque ahora estamos especulando profundamente.

Puerta de enlace de escritorio remoto

Recientemente, se han corregido un par de vulnerabilidades de confirmación previa en el producto de puerta de enlace de escritorio remoto de Microsoft. Estas vulnerabilidades rodean el soporte UDP, la fragmentación y sobre qué elementos de un paquete entrante son confiables.

La primera vulnerabilidad es la más importante: el código de reensamblaje del fragmento UDP depende parcialmente del número de fragmentos requeridos en el paquete. Se asigna un búfer en función de ese número. El código que copia los paquetes entrantes en el búfer primero verifica que la cantidad de bytes copiados no exceda la cantidad de bytes asignados. Parece que esto debería ser un control suficiente, pero ignora el desplazamiento en el que está escrito el paquete. Un solo paquete puede afirmar que solo hay dos paquetes, pero establecer su propio número de fragmento en un valor arbitrario. El desplazamiento de escritura se basa en este valor, y debido a que el número total de bytes escritos no excede la longitud del búfer, el código escribe felizmente los datos entrantes en una ubicación arbitraria.

Robert Graham hizo el punto interesante en twitter que esta vulnerabilidad existe a pesar de que el código aquí usa una de las rutinas de memoria supuestamente seguras, memcpy_s. Esta rutina segura hace evitar que el código se escriba más allá del final de un búfer, pero en este caso toda la operación está fuera de la matriz, que es un comportamiento oficialmente indefinido. Siempre que vea “comportamiento indefinido”, simplemente reemplácelo mentalmente con “Realmente peligroso, destinado a quemarlo en el futuro”.

La segunda vuln supone que el número de fragmentos nunca será superior a 64. Se asigna un conjunto de 64 enteros para rastrear qué fragmentos se recibieron. Cuando se procesa un fragmento entrante, siempre que el número de fragmentos sea menor que el número indicado de fragmentos, se escribe 1 en la ubicación correspondiente en esa matriz, incluso si ha pasado el final de la memoria asignada.

Internet Explorer 0 días

El legado jscript.dll un motor de secuencias de comandos en IE 9, 10 y 11 tiene una vulnerabilidad que se explota salvajemente en relación con el uso de objetos en la memoria. Jscript es la implementación de Javascript de Microsoft, y las páginas pueden solicitar su código alimentado en el motor anterior, por compatibilidad.

Microsoft espera que se solucione el próximo parche del martes, pero ha sugerido una solución. Configurar el jscript.dll permisos de archivo para que sea ilegible. Hay algunas desventajas, como interrumpir la reproducción de MP4 en Windows Media Player, evitar el escaneo SFC completo y algunas otras.

Todos estamos esperando a ver si Microsoft elige adelantar la solución a Windows 7 el próximo mes. Si no es así, márquelo como el primer problema evidente de que todavía se ejecutan máquinas con Windows 7.

Citrix y ruta transversal

Primero, varios productos Citrix contienen CVE-2019-19781, un defecto de cruce de carretera. Este tipo de daño generalmente involucra a un atacante que solicita una ruta que incluye un “..” para evitar los controles de seguridad. En este caso, un atacante puede abusar del daño antes de la autenticación, descargar certificados o incluso recibir un shell remoto.

Se está explotando activamente, por lo que Citrix ha cambiado la fecha de lanzamiento del parche a hoy (viernes 24 de enero). Hasta ahora no está claro cuántos dispositivos se han visto comprometidos, pero esta vulnerabilidad es casi tan grave como aparentaba.

Connectwise y ransomware

Connectwise es una solución de administración y escritorio remotos. Aparentemente, el vector de ataque utilizado en el ataque de rescate de Texas el año pasado afectó a 22 municipios separados. Las vulnerabilidades son simples, como solicitudes falsas de sitios web, scripts de sitios web y similares.

La parte más interesante de esta historia podría ser la respuesta de Connectwise. Durante una reunión, uno de sus ejecutivos amenazó con una demanda difamatoria. Las vulnerabilidades fueron validadas por un tercero, por lo que probablemente los investigadores tenían razón, y probablemente esta fue la causa del ataque de ransomware.

Grupos de piratería de Google – GGvulnz

Esta última historia desdibuja la línea entre la vulnerabilidad y la simple ingeniería social. [Milan Magyar] señaló que muchas empresas utilizan Grupos de Google, pero no definen los permisos correctamente. El simple hecho de exponer las discusiones internas puede ser problemático por sí solo, pero hay algo inteligente que se puede hacer aquí. Mira, muchos Grupos de Google usan una dirección de correo electrónico especial que usa el nombre de dominio de la empresa. Por lo general, eso no se considera un problema, pero ¿qué podría hacer un ataque con una dirección de correo electrónico en el dominio de una empresa?

Algunos servicios, como Slack, se pueden configurar para aprobar automáticamente nuevas cuentas si provienen de la dirección de correo electrónico de una empresa. La idea es que esto generalmente limita el acceso a los empleados. ¿Qué pasaría si hubiera una forma de acceder trivialmente a la dirección de correo electrónico de una empresa?

Sí, ese es el ataque. Configure una cuenta lenta, utilizando mailinglist@companyname.com como correo electrónico de registro. Luego, tome el enlace de confirmación de la página de Google Group y disfrute de su cuenta oficial de Slack.

La respuesta [Milan] obtenido de Google, Slack, etc. Es que si bien es un ataque muy inteligente, no es precisamente una vulnerabilidad en su sistema, sino un malentendido por parte del cliente. En cierto modo, este tipo de problema es el más interesante para mí. No hay nada técnicamente roto, pero la superposición de estas políticas conduce a un ataque muy inteligente.

Si tiene conocimiento de algo inteligente, interesante o una noticia segura, asegúrese de informarnos y lo abordaremos la próxima semana.

  • Ren dice:

    Mi empleador ha enviado algunos correos electrónicos en los últimos días advirtiéndonos que no usemos IE para CUALQUIER enlace externo.

    • Stuart Longland dice:

      Yo diría que tampoco debería usarse para interiores.

      • Descanso Breckill dice:

        Acabo de echar café en mi teclado.

      • RW versión 0.0.1 dice:

        Esperemos que no haya hardware de misión crítica durante ese período que se pensó que era una idea maravillosa para hacer la interfaz de configuración en activeX

  • Stuart Longland dice:

    Parece que las listas de correo públicas deberían ser a través del dominio @ lists.example.com, no @ example, com.

    Hacer lo contrario es simplemente relajarse …

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *