Reconocimiento de huellas dactilares del sistema operativo – Bloque de mensajes del servidor (SMB): Parte 1

por | Sep 14, 2021 | Consejos técnicos para la prueba de penetración

Ya sea que realice pruebas de penetración o un escaneo de vulnerabilidades automatizado, conocer su objetivo es el primer paso esencial. Este proceso o tecnología se llama Asset Profiling. En la etapa de perfilado de activos, lo más importante es reconocer el sistema operativo (SO) a través de su huella digital. En lo que respecta al reconocimiento de la huella digital del sistema operativo, lo primero que hay que tener en cuenta es el protocolo Server Message Block (SMB). Veamos por qué.

Si utiliza el motor de búsqueda Shodan, sus estadísticas sobre el puerto 445 muestran que, sólo a través de SMB, se puede determinar el SO de 1,1 millones de hosts en todo el mundo. Por lo tanto, SMB es la primera opción para la detección de la versión del sistema operativo, especialmente para Windows.

¿Qué es SMB?

El protocolo SMB, que antes se llamaba Common Internet File System (CIFS), surgió de los esfuerzos de IBM en 1983, y fue utilizado por Intel® y Microsoft® como pioneros. Finalmente, con el paso de los años, y gracias a la influencia de Microsoft, se ha convertido en uno de los dos protocolos de sistemas de archivos de red más extendidos en la actualidad.

Sin embargo, el protocolo SMB1 tiene muchas deficiencias. Además de la grave vulnerabilidad de seguridad que causó el escándalo del ransomware WannaCry en 2017, el protocolo SMB1 es famoso por su enorme consumo de recursos de red y su escaso rendimiento en escenarios de comunicación extremos.

La función básica de SMB como sistema de archivos de red se completó entre 1983 y 2007, incluyendo varias operaciones del sistema de archivos, autenticación de usuarios, firmas de mensajes, caché de clientes, etc. Incluso es independiente de la capa de protocolo NetBIOS y utiliza directamente el puerto 445 para funcionar sobre TCP/IP.

En 1996, SMB pasó a llamarse CIFS como respuesta de Microsoft a la competencia de Sun Microsystem, que amplió su protocolo NFS (Network File System) a los servicios web (WebNFS). Este cambio de nombre ha hecho que la gente se refiera a veces al protocolo SMB como CIFS, y el cliente SMB en la plataforma Linux ha mantenido incluso el nombre CIFS hasta ahora.

Con la rápida evolución de Internet, los problemas de seguridad y el rendimiento cada vez más inadecuado de SMB obligaron a Microsoft a revisar drásticamente el protocolo SMB 1.0 para convertirlo en SMB 2.0 en 2007. Cabe destacar que muchas de las nuevas características de SMB 2.X y SMB 3.X abordaban básicamente dos cuestiones: la mejora de la seguridad y la mejora del rendimiento.

Puede que te preguntes por qué SMB3 no tiene un documento de protocolo independiente. Una de las razones es que no hay una diferencia significativa entre SMB2 y SMB3 en el formato de los mensajes como para abrir un documento separado; la otra razón es que, de hecho, SMB3.0 se llamó SMB2.2 durante la fase beta de Windows 8. Pero más tarde los ingenieros de Microsoft la justificaron como una versión mayor por tener una gran cantidad de cambios de código y características.

Lo más destacado:

  • Forzar la detección de SMB v1: En lugar de utilizar el SMB preferido, se fuerza el uso de SMBv1 para su detección. En comparación con SMBv2, la respuesta de SMBv1 contiene la cadena de texto plano del sistema operativo del servidor.
  • Detección del sistema operativo SMB v1: Hay muchos tipos de peticiones SMBv1 y no todos los tipos de peticiones pueden obtener la información de la versión del sistema operativo. En este caso, se refiere específicamente a la detección del SO SMB v1
  • Solicitud de detección del SO SMB v1 de tipo NTLMSSP: Si envía una solicitud AndX general en lugar de una solicitud SMBv1 que contenga una solicitud AndX NTLMSSP, es posible que no pueda detectar el sistema operativo de Windows® Server 2012 o posterior, incluso si la otra parte admite SMBv1
  • El resultado de la detección de SMB v2 contiene ntlmss.version: En el caso de los servidores que no admiten SMB v1, sino que solo admiten v2, aunque ntlmssp.version no puede utilizarse directamente para determinar su sistema operativo, puede reconocer el nombre específico de Windows (Windows Edition) cuando se combina con otra información (como ServerDNSDomainName contiene WIN- y Desktop- en la respuesta) siempre que descarte que el sistema operativo sea Linux/Unix.
  • Nivel de detalle del análisis de la respuesta SMB v2: Si se analiza la respuesta SMBv2 y se enumeran los valores de los campos clave, como ntlmssp.version y ServerDNSDomainName.
  • Escanear directorios compartidos: Este elemento no se utiliza como criterio estándar para evaluar el análisis del SO SMB; se aplica a algunos escenarios de uso específicos.

En nuestro próximo blog, compartiremos más detalles sobre estos productos de uso común.

Esté atento…