Si algo hay común en el 99.99% de los test de intrusión que se realizan es el uso de escaners de puertos en la fase de Escaneo del objetivo.
Existen múltiples escaners de puertos en la actualidad; algunos ampliamente conocidos y utilizados como nmap o más recientemente masscan y otros menos conocidos como SuperScan, Advanced Port Scanner, Angry IP Scanner, etc...
El objetivo de estas herramientas es la de encontrar servicios provistos por equipos de del dominio objetivo con la esperanza de encontrar alguno con una versión obsoleta con vulnerabilidades de las que tomar ventaja.
Dependiendo de cómo se haga, un escaneo de puertos puede llegar a ser muy ruidoso y fácil de detectar para los administradores de los sistemas auditados, incluyendo la posibilidad de que algún que otro servidor se quede tostado con el escaneo.
En algunos casos, desenfundar el nmap a la primera de cambio y comendar a disparar SYNs a todo lo que se menea no tiene por que ser la única aproximación a la identificación de servicios.
Para poder retrasar esta fase de disparo a lo loco un poco más, acuden a nuestro rescate los registros SRV de los DNS (RFC2782). Estos registros ayudan a identificar servicios provistos a través de consultas al DNS con el siguiente formato de RR (Resource Record):
_Service._Proto.Name TTL Class SRV Priority Weight Port Target
Este RR facilita una forma de explorar el DNS en busca de servicios de cualquier tipo sin necesitar crear RR específicos para el servicio buscado, como por ejemplo ocurre con los RR de tipo MX o NS. Es decir, el RFC2782 se creó con el objetivo de generalizar la localización de servicios para un dominio. Por ejemplo, se podría preguntar al DNS por el servidor que da servicio CalDAV (una extensión de WebDAV para calendarios) con la siguiente query utilizando la herramienta dig:
$ dig @8.8.8.8 _caldav._tcp.google.com srv +short
5 0 80 calendar.google.com.
Como se puede observar, el DNS responde con la información de dónde está el servidor CalDAV del dominio google.com (calendar.google.com) incluyendo el número de puerto por el que está dando este servicio (el 80).
Buceando en www.ietf.org he buscado aquellos RFCs que definían un SRV record para el protocolo, dando finalmente con un listado de aproximadamente 52 registros SRV que podrían encontrarse si el servidor DNS está configurado para ello.
Para automatizar esta tarea de descubrimiento de servicios he creado DNSProspect, que recibe como entrada un fichero con un listado de dominios o un nombre de dominio único y el nombre de un fichero CSV donde guardar los resultados encontrados. El script preguntará a un listado de open resolvers por estos 52 registros SRV del(de los) dominio(s) objetivo (el DNS preguntado es elegido aleatoriamente en cada query).
Este script nos permitirá encontrar puertos abiertos en servidores del dominio objetivo sin llegar siquiera a que el objetivo detecte ningún tipo de comunicación hacia ninguno de sus servidores por tu parte (aunque los DNS a los que se se esté preguntando puedan llegar a redirigir la query al DNS autoritativo del objetivo).
Para que os hagáis una idea, del listado de Top 1000 dominios de Alexa he encontrado unos 485 puertos TCP y UDP dando servicio sin llegar siquiera a lanzar un SYN hacia ninguno de sus servidores, de los cuales, los más frecuentes han sido servicios XMPP, SIP e incluso servicios de Directorio Activo y Kerberos.
En resumen: el uso de los registros SRV puede ser muy útil para encontrar servicios abiertos y conseguir pasar más desapercibido frente al objetivo, ya que no se llega a realizar comunicación directa por nuestra parte.
Si utilizais la herramienta o conocéis posibles registros SRV que pueda añadir al listado a testear no dudéis en comentádmelo o hacer un pull request en github.
¡Hasta la próxima!
Justo hace un año, en diciembre de 2014, los
investigadores de seguridad Indrajeet Bhuyan y Saurav Kar descubrieron una
vulnerabilidad en WhatsApp que permitía bloquear remotamente el smartphone del
receptor de un mensaje simplemente enviando 2000 palabras con caracteres
especiales que alcanzasen los 2kb de información. Al recibir uno de
estos mensajes la aplicación se bloqueaba y entraba en bucle hasta que el
receptor borraba la conversación entera e iniciaba un nuevo chat.
