El caso del fingerprinting al SQL Server TDS7 de Microsoft

Como sabéis, nuestra Foca As A Service by Telefonica (Faast) es uno de mis juguetes preferidos, así que siempre me paso revisando los resultados y haciendo de beta tester malo, malo, maligno de las nuevas versiones que el equipo de Faast va sacando. La historia que os cuento hoy lleva un tiempo detrás de mis orejas rondándome como una daemon en background, y esta mañana, aprovechando que el estrés me ha levantado a las 5 A. M. he vuelto a revisarla un poco más en detalle.

Figura 1: El "caso" del fingerprinting al SQL Server 7 de Microsoft

Como sabéis, yo suelo testear las ideas con empresas Hacking Friendly que cuando les reportas un bug te lo agradecen, así que Microsoft y Apple son dos de esas empresas en las que pruebo las ideas ya que su infraestructura expuesta en Internet es tan grande que suelen tener de casi todo. Además, cuando les he reportado algo, lo han corregido y han sido de lo más cordiales. 

La historia y la pregunta a responder

En este caso la historia comienza con el descubrimiento por parte de Faast de una dirección IP con un servidor Microsoft SQL Server expuesto a Internet que nuestro sistema detectó como un MS SQL Server 2012. 

Figura 2: Microsoft SQL Server 2012 descubierto por Faast

Como os podéis imaginar, a mí me llamó la atención que estuviera publicado con el puerto por defecto a Internet, además de que el sistema operativo diera que es un Kernel 6.1, así que quise revisar si esto era así o no, ya que las diferencias entre la arquitectura de seguridad de Windows son grandes entre cada versión. Para ello, primero me fui a Shodan y busqué en la dirección IP para ver si con una visión del hacking con buscadores podría contrastar esta información. La sorpresa es que Shodan no tenía asociado ningún servidor MS SQL Server a esta dirección IP. El misterio crecía.

Figura 3: Shodan no reconoce ningún motor de SQL Server en esa dirección IP

Tocaba hacer una comprobación manual. Salí el primero de la zona sur en el malignomóvil y me planté esta mañana a las 7.00 en las oficinas de Eleven Paths para acabar de responder a por qué en Faast aparecía y no así en Shodan. En la soledad de la oficina, aproveché para actualizar la versión de WireShark y de Microsoft Excel 2016 para probar el "truco" de sacar el nombre de un servidor MS SQL Server por medio del establecimiento de una conexión desde Excel.

Figura 4: Estableciendo una conexión a un motor SQL Server (sin credenciales válidas) desde Excel 2016

En las capturas de WireShark apareció un paquete distinto al esperado GSS-API, y sin esperarlo me topé con un paquete de TDS7 Pre-Login. La cosa se ponía más extraña aún, ya que los paquetes de Pre-login TDS7 son de la versión de SQL Server 7.0, que es el que utiliza Tabular Data Stream 7.

Figura 5: Mensaje capturado por WireShark en el establecimiento de la conexión a SQL Server desde Excel

Además de eso, como se puede ver en la captura, la configuración del servidor SQL Server no solo es con el puerto por defecto a Internet, sino que el cifrado de la conexión está deshabilitado por lo que se podrían hacer ataques de Network Packet Manipulation como ya vimos en MySQL Server.

Figura 6: Versiones de TDS asociadas a versiones de MS SQL Server

Ya tocaba hacer las últimas pruebas, así que manualmente probamos nmap con un fingerprinting contra el puerto, pero el servidor tiene filtrados los puertos contra los escaneos y no nos dio mucha información. 

Figura 7: Nmap detecta el puerto 1433 pero no la versión del servicio

Como última prueba, tocaba usar Exploit Next Generation SQL Fingerprint, una herramienta con tiempo pero que hace muchas pruebas para garantizar el fingerprinting de SQL Server, así que la buscamos, la localizamos y la probamos. El resultado es el que veis en la siguiente captura. Descubre el servidor SQL Server, pero no es capaz de dar la versión exacta, por lo que al final, el análisis manual con la conexión Excel y WireShark es lo que mejor ha funcionado.

Figura 8: Prueba de ESF contra la dirección del servidor SQL Server

¿Será un SQL Server 7 o un SQL Server 2012?

Llegados a este punto, había que documentarse a ver por qué Faast estaba reconociendo el SQL Server como 2012, así que fuimos a ver cómo hace nmap el filtro de detección de versión de SQL Server en detalle. La respuesta es curiosa. Microsoft SQL Server no hace disclosure de la minor version de TDS, así que hasta la versión Microsoft SQL Server 2014 se utiliza TDS 7 en el paquete de Prelogin. Lo que hace nmap y Faast es comprobar la firma del paquete. Para ello hay una pequeña base de datos que reconoce los paquetes de prelogin de todos los TDS7 y sabe si es un TDS 7.1, TDS 7.2, etcétera.

Figura 9: Volviendo a hacer la prueba con nmap tal y como la hace Faast obtenemos un SQL Server 2012

Al final, no ha sido más que responder una pregunta, y para ello ha habido que hacer pruebas, suposiciones y más verificaciones para descartar posibilidades, pero el resultado es una pequeña mejora en Faast que hará que el fingerprinting de los servidores SQL Server sea un poco más afinado aún. Por supuesto, un servidor SQL Server expuesto a Internet sin cifrado en la conexión no es lo más seguro que puede estar un motor de bases de datos. Me encanta este mundo en el que cada detalle cuenta y cada situación extraña genera un misterio a resolver.

Saludos Malignos!