microsoft_reverse-wait

Microsoft no lanzará un parche de emergencia para una vulnerabilidad de día cero revelada el miércoles en la implementación del protocolo Server Message Block (SMB) en Windows.

SMB es un servicio está disponible universalmente para los sistemas Windows y las versiones heredadas de los protocolos SMB podrían permitir a un atacante remoto obtener información confidencial de los sistemas afectados. Hay tres versiones de este protocolo, SMBv1, SMBv2 y SMBv3, Microsoft recomienda desactivar SMBv1 y pasar a SMBv2 o el preferido SMBv3. Este 0-Day afecta a la última versión SMBv3.

El protocolo SMBv1 original tiene casi 30 años de antigüedad, y como gran parte del software hecho en los años 80, fue diseñado para un mundo que ya no existe. Un mundo sin actores maliciosos y sin vastos conjuntos de datos importantes, y también sin un uso casi universal de las computadoras. Francamente, es sorprendente su ingenuidad, cuando se ve a través de los ojos modernos.

El investigador Laurent Gaffie anunció en un tweet, -se puede ver abajo-, que había encontrado una vulnerabilidad de día cero en SMBv3 y publico un exploit como prueba de concepto. Le dijo a Threatpost que reveló en privado el problema a Microsoft el 25 de Septiembre y que Microsoft le dijo que tenía un parche listo para su lanzamiento de revisión de Diciembre, pero decidió esperar hasta su actualización programada de Febrero del 2017 para liberar varios parches de SMB en lugar de una sola solución en Diciembre del 2016. Microsoft considera que la vulnerabilidad, un error de denegación de servicio activado remotamente, es de bajo riesgo.

gaffie-twitter
Traducción;
SMBv3 0day, Windows 2012, 2016 afectados, se divierten 🙂 Oh y si usted entiende este poc, quejarse SDLC es apropiado 🙂https: //t.co/xAsDOY54yl

– Responder (@PythonResponder) 1 de Febrero del 2017

“Windows es la única plataforma con el compromiso del cliente de investigar los problemas de seguridad informados y actualizar proactivamente los dispositivos afectados lo antes posible. Nuestra política estándar es que en temas de bajo riesgo, remediemos ese riesgo a través de nuestra actual actualización de los segundos martes de cada mes”, dijo un portavoz de Microsoft a Threatpost en la declaración de correo electrónico. La próxima actualización programada de Microsoft es el 14 de febrero.

Gaffie dijo que la vulnerabilidad es específicamente una Null Pointer Dereference en SMB y que afecta a Windows Server 2012 y 2016. Añadió que un análisis conjunto entre él y Microsoft concluyó que la ejecución de código no parece posible a través de una vulnerabilidad de esta vulnerabilidad. SMB generalmente no está expuesto a Internet, aunque Gaffie dijo que las conexiones salientes donde los clientes se conectan a servidores de archivos remotos tienen más probabilidad de ser permitidas que las conexiones SMB entrantes a través de un puerto abierto 445.

“Este error puede ser utilizado para activar un reinicio en un destino determinado, puede ser local (vía netbios, llmnr envenenamiento) o remoto a través de un enlace UNC (ejemplo: añadir una imagen con un enlace: \\ attacker.com \ file .jpg en un correo electrónico), “dijo Gaffie. “Es importante tener en cuenta que este error trivial debería haber sido capturado inmediatamente por su proceso SDLC, pero sorprendentemente no lo fue. “Esto significa que la nueva base de código simplemente no fue auditada ni difundida antes de enviarla a sus últimos sistemas operativos”.
Gaffie también dijo que decidió publicar los detalles antes de la disponibilidad de un parche porque no es su primera experiencia trabajando con Microsoft donde han retrasado un parche de uno de sus bugs.

“Me decidí a lanzar este bug (error), una semana antes de que se publique el parche, porque no es la primera vez que Microsoft se sienta en mis bugs”, dijo. “Estoy haciendo trabajo libre aquí con ellos (no me pagan de todos modos por eso) con el objetivo de ayudar a sus usuarios. Cuando se sientan en un error como este, no están ayudando a sus usuarios, pero haciendo el control de daños de marketing, y el lanzamiento de parches oportunistas. Esta actitud es incorrecta para sus usuarios y para la comunidad de seguridad en general “.

Johannes Ulrich, decano de investigación del SANS Institute y director del SANS Internet Storm Center, dijo que ejecutó el exploit de Gaffie y pudo confirmar que causó un DoS con un Blue Screen en mrxsmb20.sys en un sistema Windows 10 completamente parcheado.

“Las versiones modernas de Windows tienen varios mecanismos de protección para evitar la ejecución remota de exploits como este”, dijo Ullrich. “Probablemente sería difícil, pero no necesariamente imposible”.

screen-shot-2017-02-02-at-1_29_33-pm

Ullrich publicó un post en el sitio de SANS ISC describiendo sus pruebas con el exploit de Gaffie. El PoC requeriría que un atacante enviara un enlace a una víctima, atrayéndolos para conectarse a una instancia de servidor SMB maliciosa.

“Una URL como \\ [dirección IP del servidor \ IPC $ desencadenaría el exploit”, dijo Ullrich. “Lo he probado en Edge e Internet Explorer en Windows 10 con un archivo html local así y apagó el sistema inmediatamente.

“El exploit implementa su propio servidor SMB, por lo que es tan fácil como ejecutar el exploit, asegurándose de que el usuario pueda conectarse (por ejemplo, problemas de firewall) y luego enviar el enlace ‘correcto’ al usuario”, dijo Ullrich. “Esto es bastante fácil de explotar. Me llevó quizás 10 minutos para que funcionara. El exploit viene sin instrucciones.

Ullrich, explicó que el atacante va a responder con una Tree Connect Response hecha a mano — Tree Connect Requests, la cual se envía a servidores Windows cuando los usuarios se conectan a recursos compartidos — que es muy larga y también incluye un “long trailer” (remolque largo). Él explica en el post de SANS ISC que el mensaje de respuesta de Tree Connect Response consiste en un tipo de encabezado y mensaje de NetBIOS de una longitud total de 1580 bytes y una cabecera de SMB2 que es 64 bytes de longitud. El mensaje de respuesta de Tree Connect Response tiene un tamaño fijo de 8 bytes además de la cabecera fija.

“Aquí es donde el mensaje debe terminar. Pero aparentemente, dado que el tamaño total del mensaje de acuerdo con el encabezado de NetBIOS es mayor, Windows sigue en la decodificación en el encabezado creado (todos los ‘C’s’ en el exploit), lo que desencadena el desbordamiento del búfer “, dijo Ullrich.

Microsoft y el US-CERT recomiendan que los usuarios y administradores consideren:
Inhabilitar SMBv1.0
• Bloquear en el firewall todas las conexiones SMB al puerto TCP 445 y sus relacionados en los puertos UDP 137-138 y TCP 139.

Desde Powershell se puede deshabilitar el servicio en un servidor mediante el siguiente comando:

Remove-WindowsFeature FS-SMB1

En clientes desde Windows 7 a Windows 10 se puede utilizar el comando siguiente:

Disable-WindowsOptionalFeature -Online -FeatureName smb1protocol

Para abrir la ventana de comandos Powershell en un cliente Windows, escriba este nombre en el cuadro de búsquedas de Windows, después en el resultado resaltado de la búsqueda de clic derecho y en las opciones escoja Ejecutar como administrador (Run as administrator).

Fuentes:
Segu-Info
ThreatPost

Anuncios