Mejorando los resultados de nmap – La bbdd de payloads.
Seguro que más de una vez, habéis observado la diferencia de tiempo necesario entre un escaneo de tipo UDP y un escaneo de tipo TCP, siendo el primero mucho más lento que el segundo.
Esto se debe a que UDP es un protocolo de transporte no orientado a conexión, al contrario que TCP. Ello quiere decir que en TCP, antes de mandar cualquier información a otro equipo a través de la red (en redes que usen TCP o UDP como protocolos de transporte), se establece un canal previo con el otro extremo, es lo que se conoce como fase de “three-way handshake”:
En cambio, cuando se usa UDP como protocolo de transporte, la información se manda sin realizar ningún tipo de establecimiento de canal previo, ni llevar ningún tipo de control de la información que se pueda estar perdiendo por el camino. Se gana velocidad pero se pierde confiabilidad (en caso de que sea necesario hacerlo, será una capa superior del modelo de red, la encargada de ello).
Cuando hacemos un escaneo con nmap, por defecto se incluyen únicamente las cabeceras de los paquetes sin ningún tipo de carga de “aplicación”, esto es así para enviar menos tráfico y hacer el proceso lo más rápido posible. La desventaja que tiene este método de funcionamiento es, que ciertos dispositivos de seguridad, como un IPS o firewall, pueden descartar el paquete TCP si ven que no tiene carga útil, para ello nmap cuenta con la opción “–data-length” para indicar el número de bytes aleatorios que se incluirán en los paquetes.
Si bien, esto nos puede resultar útil para escaneos de tipo TCP, en escaneos UDP es totalmente inútil, además, la mayoría de los servicios UDP no responderán a un datagrama que no contenga carga útil. Para ello, nmap incorpora ciertos “payloads” para servicios UDP conocidos que se establecen en el fichero “nmap-payloads” (http://nmap.org/svn/nmap-payloads).
Ahora pongamos un caso útil, necesitamos detectar servidores DNS en un rango de red, para ello podríamos hacer algo parecido a lo siguiente:
Como vemos en la imagen, únicamente el primer servidor ha respondido con un datagrama, el resto aparecen como “abiertos|filtrados” ya que no se ha podido determinar.
En esta prueba, el payload utilizado es el que viene por defecto “\x00\x00\x00\x30\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00”.
Ahora, probamos a capturar otro payload mediante Wireshark, para ello capturamos la petición y en la parte de “Domain Name System (query)” seleccionamos “Copy, bytes, hex-stream” y obtendremos algo así “babd010000010000000000000377777706676f6f676c6503636f6d0000010001”, esto lo pasamos a notación hexadecimal y lo insertamos en la base de datos “nmap-payload”:
udp 53 “\x8d\x78\x01\x00\x00\[…]\x63\x6f\x6d\x00\x00\x01\x00\x01″ (Se ha recortado por motivos de espacio, descuadraba demasiado)
Y volvemos a lanzar el mismo escaneo:
Como podemos observar ahora, tanto el primer servidor como el segundo, han respondido con un datagrama, habiendo obtenido un puerto abierto más.
Todo es cuestión de probar distintas cargas y quedarnos con la que mejor resultados nos dé, espero que os resulte interesante y de utilidad.
Esto se debe a que UDP es un protocolo de transporte no orientado a conexión, al contrario que TCP. Ello quiere decir que en TCP, antes de mandar cualquier información a otro equipo a través de la red (en redes que usen TCP o UDP como protocolos de transporte), se establece un canal previo con el otro extremo, es lo que se conoce como fase de “three-way handshake”:
En cambio, cuando se usa UDP como protocolo de transporte, la información se manda sin realizar ningún tipo de establecimiento de canal previo, ni llevar ningún tipo de control de la información que se pueda estar perdiendo por el camino. Se gana velocidad pero se pierde confiabilidad (en caso de que sea necesario hacerlo, será una capa superior del modelo de red, la encargada de ello).
Cuando hacemos un escaneo con nmap, por defecto se incluyen únicamente las cabeceras de los paquetes sin ningún tipo de carga de “aplicación”, esto es así para enviar menos tráfico y hacer el proceso lo más rápido posible. La desventaja que tiene este método de funcionamiento es, que ciertos dispositivos de seguridad, como un IPS o firewall, pueden descartar el paquete TCP si ven que no tiene carga útil, para ello nmap cuenta con la opción “–data-length” para indicar el número de bytes aleatorios que se incluirán en los paquetes.
Si bien, esto nos puede resultar útil para escaneos de tipo TCP, en escaneos UDP es totalmente inútil, además, la mayoría de los servicios UDP no responderán a un datagrama que no contenga carga útil. Para ello, nmap incorpora ciertos “payloads” para servicios UDP conocidos que se establecen en el fichero “nmap-payloads” (http://nmap.org/svn/nmap-payloads).
Ahora pongamos un caso útil, necesitamos detectar servidores DNS en un rango de red, para ello podríamos hacer algo parecido a lo siguiente:
Como vemos en la imagen, únicamente el primer servidor ha respondido con un datagrama, el resto aparecen como “abiertos|filtrados” ya que no se ha podido determinar.
En esta prueba, el payload utilizado es el que viene por defecto “\x00\x00\x00\x30\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00”.
Ahora, probamos a capturar otro payload mediante Wireshark, para ello capturamos la petición y en la parte de “Domain Name System (query)” seleccionamos “Copy, bytes, hex-stream” y obtendremos algo así “babd010000010000000000000377777706676f6f676c6503636f6d0000010001”, esto lo pasamos a notación hexadecimal y lo insertamos en la base de datos “nmap-payload”:
udp 53 “\x8d\x78\x01\x00\x00\[…]\x63\x6f\x6d\x00\x00\x01\x00\x01″ (Se ha recortado por motivos de espacio, descuadraba demasiado)
Y volvemos a lanzar el mismo escaneo:
Como podemos observar ahora, tanto el primer servidor como el segundo, han respondido con un datagrama, habiendo obtenido un puerto abierto más.
Todo es cuestión de probar distintas cargas y quedarnos con la que mejor resultados nos dé, espero que os resulte interesante y de utilidad.