Semana de la seguridad 34: vulnerabilidades extraordinarias en Windows

El 13 de agosto, Microsoft lanzó la próxima actualización de seguridad (revisión de noticias ) para sistemas operativos Windows y programas de oficina, y esta vez el parche resultó ser realmente gigantesco: obviamente, alguien no pudo irse de vacaciones este verano. En total, se cerraron 93 vulnerabilidades, de las cuales 23 se clasificaron como críticas. Se cerraron errores graves en los Servicios de Escritorio remoto, en el cliente DHCP , en el controlador de archivos .LNK, dos vulnerabilidades en Hyper-V con un escape de sandbox.

Así que el trabajo monumental en los errores es una muy buena noticia. Entre otras cosas, varias vulnerabilidades son interesantes en sí mismas, y otra tiene un historial interesante de detección. Además de los problemas ya mencionados en los Servicios de escritorio remoto, hoy veremos más de cerca la vulnerabilidad en el servicio MSCTF. El investigador de Google Project Zero, Tavis Ormandy, quien descubrió esto último, afirma que el problema ha existido durante 20 años. Bueno, al mismo tiempo, evaluaremos la vulnerabilidad en Bluetooth, que afecta no solo a Windows.

WTF es CTF?


Tavis Ormandi descubrió una vulnerabilidad en el servicio MSCTF casi por accidente ( noticia , publicación en el blog de Tavis). Todo comenzó con un estudio de los mecanismos de Windows que permiten que diferentes programas interactúen entre sí. Esta interacción se limita al sistema de aislamiento de privilegios de interfaz de usuario, que impide, por ejemplo, que los procesos del usuario interfieran con los procesos del sistema. Estudiando casos extraños cuando, a pesar de las restricciones, los mensajes aún pasaron, Tavis tropezó con el módulo MSCTF.

Este módulo pertenece al Marco de servicios de texto, que a su vez controla los diseños de teclado y similares. Todas las aplicaciones en ejecución están conectadas a él. Por qué Bueno, por ejemplo, para facilitar el proceso de ingresar texto en chino o japonés.


Para dichos lenguajes, un programa separado procesa la entrada en la ventana de la aplicación y cambia la entrada a jeroglíficos. En esencia, MSCTF es un canal de comunicación separado entre aplicaciones que, como se vio después, no está suficientemente protegido. La primera versión de MSCTF que Tavis logró encontrar es parte de la suite ofimática Microsoft Office XP, que es compatible con Windows 98. A partir de Windows XP, MSCTF forma parte del sistema operativo. Las posibilidades de interactuar con otras aplicaciones a través de MSCTF son muy amplias, y lo más importante: no hay autorización. Como resultado, Tavis escribió una utilidad para trabajar con CTF y comenzó a buscar vulnerabilidades:


Se encontraron vulnerabilidades, aunque no de inmediato. En el "mejor" caso, en un sistema con uno de los idiomas que requieren herramientas de entrada avanzadas (japonés, chino, coreano y algunos otros), puede reemplazar el texto en la aplicación, enviar comandos a la consola con derechos de administrador, sin ser un usuario privilegiado, o robar contraseñas de usuario. En el peor de los casos (aunque lo anterior ya es lo suficientemente malo), puede obtener derechos del sistema, es decir, aumentar sus privilegios al máximo. Tal prueba de concepto se muestra en el video:


La vulnerabilidad es de uso limitado, y lo más probable es que la mayoría de los escenarios estén disponibles solo con acceso al sistema. Sin embargo, hay casos potencialmente posibles cuando un usuario sin privilegios obtiene, por ejemplo, los derechos de un administrador de dominio en una empresa. La vulnerabilidad se cierra con la actualización de agosto para todos los sistemas operativos que comienzan con Windows 7.

Bluekeep o no Bluekeep


Los problemas en los Servicios de escritorio remoto ( noticias , un boletín en el sitio web de Microsoft) son en parte similares a la vulnerabilidad descubierta en mayo de este año por Bluekeep . Los agujeros en el servicio de acceso remoto (pero no en el protocolo RDP en sí) teóricamente permiten que el ataque se distribuya a todas las computadoras en la red sin la participación del usuario: existe un cierto riesgo de que se repita la situación con el cifrador de cifrado WannaCry en 2017, cuando el problema de implementar el protocolo SMB se explotó a gran escala.

Sin embargo, hay diferencias con respecto a BlueKeep. Un problema anterior no se aplicaba a las últimas versiones del sistema operativo, pero ahora, por el contrario, afecta a todos los sistemas operativos desde Windows 7 a Windows 10 (pero no a Windows XP, Server 2003 y 2008). Se identificaron errores durante la auditoría interna de Microsoft, aún no se han detectado ataques reales. Tanto Bluekeep como cuatro nuevos problemas se neutralizan mediante la inclusión de la autorización de nivel de red. Pero NLA en un sistema sin parches no lo salva completamente de una serie de scripts para ejecutar código en una máquina remota. En el peor de los casos (sin NLA, parche de agosto no instalado, acceso remoto habilitado), es posible evitar la autorización y obtener el control del sistema mediante el envío de una solicitud preparada.

Vulnerabilidad de Bluetooth


El problema, conocido como KNOB Attack (Negociación clave de Bluetooth), fue descubierto por investigadores de Singapur, Alemania y el Reino Unido ( noticias , sitio de investigación, trabajo científico). A diferencia de otras vulnerabilidades en el conjunto de parches de Microsoft, esto se aplica no solo a Windows, sino que generalmente es relevante en casi todas partes donde se usa Bluetooth. Aquí encontrará una gran lista de actualizaciones de fabricantes de teléfonos inteligentes, computadoras portátiles y teléfonos IP que han respondido al problema.

En las especificaciones de Bluetooth, dos dispositivos que establecen una conexión segura entre ellos pueden seleccionar una longitud de clave entre 1 y 16 bytes. En el caso de una clave de "ocho bits", se puede descifrar lo suficientemente rápido mediante una simple enumeración: si por alguna razón se establece una conexión "ligeramente segura", el atacante puede descifrar el intercambio de datos. Por ejemplo, entre un teclado y una computadora de escritorio. La pregunta es cómo implementar tal ataque, y el trabajo de investigación demuestra que hay al menos dos opciones moderadamente realistas.


En el primer caso, un atacante ubicado cerca de dos víctimas puede obligarlas a usar cifrado con una longitud de clave de 1 byte. El hecho es que durante el proceso de establecer una conexión no hay cifrado o incluso control de integridad de datos. En el segundo caso, se investigó el escenario de un ataque a la cadena de suministro: reemplazar el firmware del dispositivo proporciona un cifrado débil en todos los casos. El segundo ataque se llevó a cabo en un teléfono Nexus 5: cambiamos algunos bytes en el firmware, limitamos la longitud de la clave, nos conectamos a otro teléfono inteligente que tiene que aceptar las condiciones para establecer una conexión.

Esta es una vulnerabilidad grave que existe debido a las especificaciones inicialmente débiles del estándar Bluetooth. Además, muchos dispositivos seguirán sujetos a un ataque KNOB, ya que simplemente no lanzarán una actualización. Por otro lado, la implementación de tal escenario en la práctica es bastante complicada: en el primer caso, es necesario estar cerca de la víctima en el momento correcto, en el segundo, intervenir en la cadena de suministro y luego, nuevamente, estar al lado del dispositivo atacado cuando se transmiten datos confidenciales a través de él. En todos los casos, el parche establece la longitud mínima de la clave para que el ataque se vuelva prácticamente inaplicable.

Descargo de responsabilidad: las opiniones expresadas en este resumen pueden no coincidir siempre con la posición oficial de Kaspersky Lab. Los estimados editores generalmente recomiendan tratar cualquier opinión con escepticismo saludable.

Source: https://habr.com/ru/post/464365/


All Articles