Todos los que trabajamos en seguridad utilizamos herramientas como Nmap para nuestras tareas diarias, y tomamos muchas decisiones de acuerdo a la información que obtenemos de ellas. ¿ Pero qué hacemos cuando estas herramientas no nos dicen toda la verdad ?
Un gran problema que tienen muchas herramientas, es que interpretan en lugar de decodificar.
Por ejemplo, cuando Nmap no recibe un RST o un SYN/ACK de un host, interpreta que "el puerto se encuentra filtrado". Cuando si solamente decodificara, debería decir "no he recibido ninguna respuesta del host". El trabajo de interpretar es del analista, y no del autor de la herramienta.
En el siguiente ejemplo, podemos ver que al escanear el puerto 80 de un host con Nmap, obtenemos que el puerto esta filtrado:
Un gran problema que tienen muchas herramientas, es que interpretan en lugar de decodificar.
Por ejemplo, cuando Nmap no recibe un RST o un SYN/ACK de un host, interpreta que "el puerto se encuentra filtrado". Cuando si solamente decodificara, debería decir "no he recibido ninguna respuesta del host". El trabajo de interpretar es del analista, y no del autor de la herramienta.
En el siguiente ejemplo, podemos ver que al escanear el puerto 80 de un host con Nmap, obtenemos que el puerto esta filtrado:
Ahora si mientras hacemos nuestro escaneo con Nmap, sniffearamos el tráfico con Wireshark, podríamos ver lo siguiente:
Como pueden apreciar, obtuvimos un paquete de error ICMP Host Unreachable. Esto significa que el firewall nos daba permiso para acceder al puerto 80, pero del otro lado no había ningún servidor que conteste a nuestro pedido.
En este ejemplo que hemos visto, Nmap claramente interpreto "el puerto se encuentra filtrado", cuando en realidad debería haber dicho "el puerto esta abierto pero del otro lado no hay nadie que conteste el pedido".
Esto para un consultor de seguridad es algo muy grave, ya que durante un PenTest podríamos pensar que nuestro cliente esta protegido, cuando en realidad tiene un puerto abierto que podría ser usado por un atacante para poner un backdoor.
Otro ejemplo muy claro, puede ser la vulnerabilidad que se descubrió hace poco en Snort, que permitía evadir la detección de un ataque. Si solamente confiáramos en Snort para detectar un ataque, nos estaríamos perdiendo de muchas cosas.
Por todo esto, nunca confíes en tus herramientas.
En este ejemplo que hemos visto, Nmap claramente interpreto "el puerto se encuentra filtrado", cuando en realidad debería haber dicho "el puerto esta abierto pero del otro lado no hay nadie que conteste el pedido".
Esto para un consultor de seguridad es algo muy grave, ya que durante un PenTest podríamos pensar que nuestro cliente esta protegido, cuando en realidad tiene un puerto abierto que podría ser usado por un atacante para poner un backdoor.
Otro ejemplo muy claro, puede ser la vulnerabilidad que se descubrió hace poco en Snort, que permitía evadir la detección de un ataque. Si solamente confiáramos en Snort para detectar un ataque, nos estaríamos perdiendo de muchas cosas.
Por todo esto, nunca confíes en tus herramientas.
4 comentarios:
Yo juego al Quake(r) III jeje
Salu2
Es por eso que el trabajo lo hace una persona y no una herramienta.
Estas solo nos facilitan las tareas, no la realizan.
Es el criterio del tecnico determinar que es un falso positivo y que no lo es.
Ahora en el caso del snort, siempre sucede que el problema no es el bug del mismo, sino la falsa seguridad que nos genera.
Keep on blogging
abrazo
Leonardo, perdón el atrevimiento, pero emho no se utiliza en nmap el flag --reason justamente para esa tarea de ver el porque no lo toma como abierto o cerrado y sí como filtrado?
Por otro lado, --packet-trace también creo que podría ayudar.
saludos y felicitaciones por tu excelente
blog.
Maunic, gracias por tu comentario, sin dudas esos flags son de gran ayuda.
Lo importante es que sepamos que el trabajo de interpretación debe ser hecho por el analista y no la herramienta.
Saludos!
Leo
Publicar un comentario