Vulnerabilidad HTTP de Windows Wormable – Lo que necesita saber – Naked Security

Ayer fue el primer martes de parches de 2022, durante el cual se corrigieron más de 100 errores de seguridad.

Como todos los meses, hemos recopilado un resumen de las actualizaciones en nuestro sitio hermano news.sophos.com: El primer parche del martes de 2022 corrige 102 errores.

Para bien o para mal, una actualización ha llamado la atención de los medios más que cualquier otra, a saber CVE-2022-21907, mejor conocido como Vulnerabilidad de ejecución remota de código en la pila de protocolo HTTP.

Este error fue una de las siete vulnerabilidades de este mes que podrían conducir a la ejecución remota de código (RCE), un tipo de error que significa que alguien fuera de su red podría engañar a una computadora en su red para que ejecute un programa sin pedir permiso primero.

No es necesario registrarse con antelación; sin advertencia emergente en el otro extremo; No Are you sure (Y/N)? Preguntas.

Solo da el comando y el malware se ejecutará.

Al menos esa es la teoría.

Los errores RCE se consideran desparasitables

La mayoría de las vulnerabilidades de RCE deben incluir lo siguiente: Si ataca la computadora de otra persona desde el exterior y le indica que ejecute un programa malicioso de su elección…

… entonces es posible, quizás incluso probable, que le diga que ejecute el mismo programa que acaba de usar para lanzar su propio ataque.

En otras palabras, podría explotar la vulnerabilidad para ubicar e infectar a la víctima 1 con malware W que le indica a la víctima 1 que localice a la víctima 2 e infecte con malware W que le indica a la víctima 2 que localice a la víctima 3 e infecte… y así sucesivamente, tal vez incluso indefinidamente.

En tal ataque le damos al programa W un nombre especial: lo llamamos un gusano.

Los gusanos son un subconjunto adecuado de un tipo de malware (o Malware corto) comúnmente conocido como Virus de computadora, el término genérico para malware autorreplicante de cualquier tipo.

Esto significa que la mayoría de los errores RCE en teoría al menos desparasitablelo que significa que podrían explotarse para iniciar una cadena de infecciones de malware automáticas, autopropagantes y autosuficientes.

La razón de esto es obvia: si un error RCE le permite crear un arbitrariamente Programa de su elección en la computadora de otra persona, p. B. Ventana emergente CALC.EXE o empezar NOTEPAD, entonces es casi seguro que puede Específico Programa de su elección, p. B. un gusano.

Algunos insectos son más desparasitables que otros

Como puede imaginar, algunas clases de errores de RCE se consideran mucho más propensas a los gusanos que otras, especialmente los errores que pueden desencadenarse directamente a través de una simple interacción de red.

Este fue un problema importante en la reciente saga de Log4Shell, donde una sola solicitud web con trampas explosivas y un texto ASCII extraño pero inaceptable podría desencadenar la ejecución de código remoto arbitrario.

Desafortunadamente, CVE-2022-21907 es un error en la misma categoría, y el propio boletín de seguridad de Microsoft dice específicamente lo siguiente en su sección de preguntas frecuentes:

*How could an attacker exploit this vulnerability?*In most situations, an unauthenticated attacker could send a specially crafted packet to a targeted server utilizing the HTTP Protocol Stack (HTTP.sys) to process packets.*Is this wormable?*Yes. Microsoft recommends prioritizing the patching of affected servers.

¿Tiene esto que ver con IIS?

Dónde y cómo funciona pila de protocolo HTTP para ser activado?

¿Es esto solo un problema del servidor de Windows, como sugiere el boletín de Microsoft cuando se trata de parchear los «servidores afectados»?

¿Depende el ataque de que usted utilice un servidor web conocido como Microsoft IIS (Servicios de Información de Internet) ya instalado y activado?

Las respuestas a estas preguntas son las siguientes:

• HTTP.sys es parte de Windows y está disponible para cualquier programa que utilice ASP.NET.
• HTTP.sys funciona en clientes de Windows 7 y después.
• HTTP.sys funciona en servidores Windows 2008 R2 y después.
• HTTP.sys no es parte de IIS, y no requiere la instalación de IIS.

El último punto anterior deja en claro que puede tener cualquier cantidad de aplicaciones en acción, tal vez sin darse cuenta, que proporcionan una interfaz basada en HTTP sobre HTTP.sys, ya sea que haya implementado IIS o no.

De hecho, la propia documentación de Microsoft establece que «HTTP.sys es útil […] donde el servidor debe ser accesible directamente a Internet sin IIS «.

De hecho, IIS se basa en HTTP.sys y no al revés, como explica Microsoft:

En pocas palabras, en teoría, incluso podría instalar aplicaciones en una computadora de escritorio o portátil que proporcione algún tipo de interfaz basada en web atendida por el código del controlador HTTP.sys.

El lado positivo, al menos para algunos usuarios, es la parte de HTTP.sys que contiene el error CVE-2022-21907:

• Solo se aplica a Windows 10 y superior Versiones de escritorio.
• Solo se aplica a Windows Server 2019 y superior Versiones del servidor.
• No está activado por defecto en el servidor de Windows 2019.
• Se puede vacunar contra este bicho simplemente instalando las actualizaciones del martes del parche de enero de 2022.

Por lo que podemos decir, la razón por la que esta vulnerabilidad no existía en versiones anteriores de Windows y Windows Server es porque el error se encontró en el código que trata con los tráileres HTTP (son como encabezados HTTP excepto que se envían). después de los datos HTTP en lugar de antes); La compatibilidad con el tráiler de HTTP solo se agregó después de que se admitiera HTTP / 2; y la compatibilidad con HTTP/2 no llegó hasta la era de Windows 10.

¿Qué tengo que hacer?

Si realmente no puede parchear de inmediato y sabe que no está ejecutando (o al menos no quiere ejecutar) ningún software basado en web que use HTTP.sys, puede bloquear temporalmente HTTP.sys en su computadora configurando la siguiente entrada de registro:

HKLMSYSTEMCurrentControlSetServiceHTTPStart = DWORD(4)

El valor habitual de esta entrada de registro es 3, lo que significa «Empezar cuando sea necesario»; Si cambia el valor a 4, el controlador se guardará como un «Servicio desactivado».

Después de reiniciar, puede verificar el estado de HTTP.sys en un símbolo del sistema regular con el SC (Control de servicio) Comando:

C:Usersduck> sc query HTTPSERVICE_NAME: HTTP TYPE : 1 KERNEL_DRIVER STATE : 1 STOPPED <--before applying the registry hack above, this line said: "4 RUNNING" WIN32_EXIT_CODE : 1077 (0x435) SERVICE_EXIT_CODE : 0 (0x0) CHECKPOINT : 0x0 WAIT_HINT : 0x0C:Usersduck>

Tenga en cuenta que solo hemos probado superficialmente esta solución. Instalamos Server 2022, habilitamos IIS, hicimos una página de inicio y verificamos desde otra computadora que estaba funcionando. Cambiamos el valor de inicio del servicio para HTTP a 4 como se sugirió anteriormente y lo reiniciamos. Ya no se pudo acceder a nuestro servidor IIS. Restablecimos la entrada del registro a 3, reiniciamos una vez más y verificamos que IIS volvió a la vida automáticamente. A partir de esto, concluimos que la desactivación del servicio HTTP en realidad bloquea el acceso de red basado en HTTP a software de nivel superior que, de lo contrario, estaría expuesto a este error, y suponemos que esto hace que la vulnerabilidad sea temporalmente «poco confiable».

Nuestras principales recomendaciones son:

• Suponga que todas las vulnerabilidades de RCE son desparasitables. Como se mencionó anteriormente, los errores que pueden activarse directamente a través de conexiones de red de rutina son, con mucho, el mayor riesgo de ser «desparasitados», pero en teoría, cualquier error que permita la ejecución remota de código arbitrario podría permitir la ejecución de código gusano.
• Por ejemplo, supongamos que los ciberdelincuentes ya están activamente involucrados en esto y en todos los demás RCE Vulns anunciados este martes de parches. Probablemente hayas escuchado la broma sobre Patch Tuesday que fue seguida por Exploit Wednesday. Hay más que una pizca de verdad en esto, ya que incluso los parches de código cerrado a menudo se pueden luchar al revés: descompilado, en jerga, para exponer los detalles internos de la falla que previenen. (Y ver el punto 1.)
• Parche temprano, parche a menudo. No utilice las soluciones alternativas como una parte rutinaria de su proceso de aplicación de parches para ganar tiempo adicional cada vez. Aplicación de parches no intencionada y soluciones alternativas de reserva para situaciones en las que realmente necesite retrasar la aplicación de parches durante un tiempo. (Y ver punto 1 y 2.)

No lo dudes… ¡hazlo hoy!

MÁS INFORMACIÓN SOBRE EL MARTES DE PARCHE DE ENERO DE 2022