Fue presentado en la DEF CON un bug con más de 20 años de antigüedad que afecta todas las versiones de Windows, pero que Microsoft ha decidido no parchar.
Normalmente cuando un investigador de seguridad descubre un bug, lo envía para su revisión a los fabricantes y estos elaboran lo que conocemos como parches de seguridad. A menos que estos decidan que el costo y la logística para la distribución del parche no merece la pena. Esta es la historia de cómo Microsoft ha decidido que una vulnerabilidad que podría ocasionar una denegación de servicio no es tan importante como para dedicarle tiempo a desarrollar un parche.
La vulnerabilidad, a la cual llamaron SMBloris, es un fallo en el protocolo SMBv1 que podría causar que un equipo con poco poder de cómputo pueda producir una caída de servicio en un servidor sumamente robusto. De hecho, según los investigadores, hasta con un Raspberry PI se podría causar una denegación de servicio en un servidor bastante potente y tendrían que reiniciarlo para recuperar su normal funcionamiento.
La razón por la cual Microsoft considera que no es importante parchar este fallo es porque el protocolo SMB tendría que estar expuesto a Internet para que un atacante pudiese aprovechar la vulnerabilidad. Sin embargo, en los entornos de dominio, como los entornos corporativos, un servidor podría tener expuesto este servicio hacia la LAN, ocasionando que un usuario malintencionado pueda aprovecharla desde adentro de la red.
Aprovechando la falla SMB: David contra Goliat
El protocolo SMB viene activo por defecto en todas las versiones de Windows. Así es como, sin saberlo, todos somos vulnerables. Pero Microsoft decidió simplemente ignorar este hecho y calificarlo como una «falla de configuración» ya que no deberías exponer el protocolo SMB a Internet. Pero, tal y como comentamos, en los entornos corporativos las cosas son un poco diferentes.
La falla se aprovecha del NBSS o el NetBIOS Session Service protocol, un protocolo que permite a los dispositivos «hablar» entre ellos. Cada conexión a una sesión de NetBIOS ocupa unos 128 KB de memoria, la cual es liberada cuando la conexión se cierra. Si no existe actividad por 30 segundos, la conexión se considera terminada.
Pero al poder realizar un intento de conexión por cada puerto, estos 128 KB se traducen en unos 8 GB debido a que podríamos realizar 65.535 intentos de conexión, uno por cada puerto TCP disponible. Esto se puede duplicar si atacamos usando IPv4 e IPv6 a la vez, llegando a 16 GB. Y si tenemos dos IP’s disponibles para realizar el ataque, podríamos llegar a los 32 GB de memoria secuestrada. Esto haría temblar hasta el servidor más robusto, ya que causaría la saturación de la memoria para el NBSS y habría que reiniciar el servidor.
La mejor defensa es desactivarlo
El protocolo de comunicación SMB se sigue usando actualmente, pero la versión 1 existe solo por motivos de compatibilidad. A estas alturas ya no debería haber ningún equipo por ahí funcionando con Windows 2000, por lo que no debería haber mucho problema en desactivarlo. Sin embargo, siempre es bueno hacer una prueba de compatibilidad si es que estas en un entorno corporativo, y en el caso de que no puedas desactivarlo, habría que implementar otras medidas un poco más específicas para cada caso, como, por ejemplo, reglas de firewall.
Para desactivarlo solo debes seguir los siguientes pasos:
- Abre el panel de control: Dependiendo de tu versión de Windows, este puede estar en lugares distintos. Sobre todo, si hablamos de Windows 10, pues los desarrolladores han decidido hacerlo más difícil de encontrar en cada Build
- Ve al grupo Programas y Características
- Selecciona activar o desactivar características de Windows
- Encuentra el Ítem que dice: Compatibilidad con el protocolo para compartir archivos SMB 1.0/CIFS y desmarca la casilla
- Presiona Aceptar y Reinicia el equipo
Aquí te dejamos una demostración de lo destructivo que puede ser el fallo.
Recuerden dejar sus comentarios, alimentan el debate y nos ayudan a mejorar.
Fuente: Security Affairs
Sin respuestas