Google vs Microsoft; El equipo de investigación de Google hace públicas dos vulnerabilidades más de Windows 7/8

La guerra entre Google y Microsoft se intensifica a medida que Google revela dos vulnerabilidades más de Windows 7 y Windows 8.

El equipo de investigación de Google ha puesto dos vulnerabilidades de Windows no parcheadas en el dominio público el jueves, después de la expiración del período de espera autoimpuesto de 90 días de Google Project Zero antes de divulgar los detalles del error.

Microsoft, que no ha tomado amablemente este tipo de divulgaciones públicas, ha dicho que parcheará una de las dos vulnerabilidades en su próximo boletín de seguridad del Patch Tuesday de febrero. La segunda falla, parece, no es un gran problema de seguridad.

Los lectores pueden recordar que el equipo de investigación de Google había hecho pública una vulnerabilidad de escalada de privilegios en Windows 7 después de la expiración del período de espera autoimpuesto de 90 días. La divulgación de Google el 29 de diciembre reavivó los debates sobre la divulgación entre los entusiastas de la seguridad e incitó la acrimonia y la postura pública de ambas empresas.

Microsoft quiere que Google siga un programa de divulgación de vulnerabilidades coordinado y le ha pedido a Google que retenga su divulgación de la vulnerabilidad hasta los boletines de seguridad de enero, que se publicaron esta semana. Google, por otro lado, confía en su moratoria autoimpuesta de 90 días, por lo que se negó y procedió con su divulgación.

Chris Betz de Microsoft ha declarado que: “Aunque seguir adelante se ajusta a la línea de tiempo anunciada por Google para la divulgación, la decisión se siente menos como principios y más como un ‘gotcha’, siendo los clientes los que pueden sufrir como resultado. Lo que es correcto para Google no siempre es correcto para los clientes. Instamos a Google a que haga de la protección de los clientes nuestro objetivo colectivo principal.”

La guerra entre los gigantes tecnológicos está lejos de terminar, ya que el equipo de investigación de Google ha hecho públicas dos vulnerabilidades más de Windows. Ambas vulnerabilidades se reproducen a continuación:

Número de problema 127 reportado a Microsoft el 17 de octubre de 2013, hecho público el 15 de enero de 2014

Plataforma: Windows 7 32/64 bits, Windows 8+ no vulnerable
Clase: Bypass de seguridad La llamada del sistema NtPowerInformation realiza una verificación de que el llamador es un administrador antes de realizar algunas funciones de energía específicas. La verificación se realiza en la función PopUserIsAdmin. La implementación aproximada es: BOOLEAN PopUserIsAdmin() {
SECURITY_SUBJECT_CONTEXT ctx; SeCaptureSecurityContext(&ctx); return SeTokenIsAdmin(SeQuerySubjectContextToken(&ctx));
} En Windows 7, esta verificación se puede eludir porque la función SeTokenIsAdmin no tiene en cuenta el nivel de suplantación del token y el resto del código tampoco lo tiene en cuenta. Por lo tanto, puedes suplantar el token de un administrador como un usuario normal (a través de un token vinculado o secuestrando un token del sistema) y llamar a las funciones protegidas. En Windows 8+, el método SeTokenIsAdmin ha sido cambiado para verificar el nivel de suplantación, por lo que no es vulnerable. No está claro si esto tiene un impacto serio en la seguridad o no, por lo tanto, se está divulgando tal como está. Algunas funciones también son verificadas por una verificación de privilegios, sin embargo, el contexto del sujeto se captura por separado, por lo que existe una ventana TOCTOU entre las verificaciones que podría ser explotada. Para fines de PoC, he elegido usar la función 45 “PopRequestPowerListInfo” (que no requiere trucos especiales). Además, esta función tiene una vulnerabilidad teórica de desbordamiento de enteros dependiendo de cuánto puedas aumentar el tamaño de PopPowerRequestObjectCount. Adjunto un PoC simple que demuestra el problema para su ejecución en Windows 7. Para reproducir, sigue los pasos. 1) Asegúrate de estar ejecutando como un administrador de token dividido, esto se debe a que el PoC utiliza el token vinculado para obtener un token de administrador. Para un usuario normal, podrías simplemente capturar un token de un servicio.

2. Ejecuta el PoC, debería hacer llamadas, una sin suplantación y otra con. Resultado esperado:
   Ambas llamadas deberían devolver STATUS_ACCESS_DENIED (0xC0000022) Resultado observado:
   La primera verificación falla con STATUS_ACCESS_DENIED mientras que la segunda tiene éxito con STATUS_SUCCESS. PoC para descargar => 1 2

Número de problema 128 reportado a Microsoft el 17 de octubre de 2013, hecho público el 15 de enero de 2014

Plataforma: Windows 7, 8.1 Update 32/64 bits
Clase: Bypass de seguridad/Divulgación de información La función CryptProtectMemory permite a una aplicación cifrar memoria para uno de tres escenarios, proceso, sesión de inicio de sesión y computadora. Al usar la opción de sesión de inicio de sesión (bandera CRYPTPROTECTMEMORY_SAME_LOGON), la clave de cifrado se genera en función del identificador de sesión de inicio de sesión, esto es para compartir memoria entre procesos que se ejecutan dentro de la misma sesión de inicio de sesión. Como esto también podría usarse para enviar datos de un proceso a otro, admite la extracción del id de sesión de inicio de sesión del token de suplantación. El problema es que la implementación en CNG.sys no verifica el nivel de suplantación del token al capturar el id de sesión de inicio de sesión (usando SeQueryAuthenticationIdToken), por lo que un usuario normal puede suplantar a nivel de identificación y cifrar o descifrar datos para esa sesión de inicio de sesión. Esto podría ser un problema si hay un servicio que es vulnerable a un ataque de plantación de tuberías con nombre o está almacenando datos cifrados en una sección de memoria compartida legible por todos. Este comportamiento, por supuesto, podría ser diseño, sin embargo, no habiendo sido parte del diseño, es difícil de decir. La documentación establece que el usuario debe suplantar al cliente, lo que interpreto como que debería poder actuar en nombre del cliente en lugar de identificarse como el cliente. Adjunto un PoC simple que demuestra el problema. Para reproducir, sigue los pasos. 1) Ejecuta Poc_CNGLogonSessionImpersonation.exe desde la línea de comandos

2. El programa debería imprimir “El cifrado no coincide” para indicar que los dos cifrados de los mismos datos no coincidieron, lo que implica que la clave era diferente entre ellos. Resultado esperado:
   Ambas llamadas deberían devolver el mismo dato cifrado, o la segunda llamada debería fallar Resultado observado:
   Ambas llamadas tienen éxito y devuelven datos cifrados diferentes PoC descarga => Archivo Zip

Microsoft solo parcheará una de las vulnerabilidades en su Patch Tuesday de febrero, que dijo que la otra vulnerabilidad no es un riesgo de seguridad. Tanto Microsoft como Google dijeron que no tienen pruebas de que alguna de las tres vulnerabilidades hechas públicas haya sido explotada en la naturaleza.