5 acciones que pueden arruinarle el día a un pentester

5 acciones que pueden arruinarle el día a un pentester

Parecería absurdo que alguien contrate servicios para evaluar la seguridad y sabotee el análisis, pero sucede. Estas son las cosas que un pentester no aprecia.

Parecería absurdo que alguien contrate servicios para evaluar la seguridad y sabotee el análisis, pero sucede. Estas son las cosas que un pentester no aprecia.

En ocasiones, las auditorías de seguridad se ven truncadas por “errores” humanos que muchas veces son causados por los propios clientes. Parecería absurdo que alguien contrate servicios para evaluar la seguridad y luego se dedique a sabotear este análisis, pero sucede.

A lo largo de este artículo iremos destacando las acciones que podrían hacerle perder tiempo a un pentester y convertir un día normal en un gran dolor de cabeza para todas las partes comprometidas.

#1 Bloquear IPs o apagar un equipo

Naturalmente, previo a la evaluación de seguridad, se consensúa entre ambas partes la metodología. Además, se suelen definir horarios y desde qué dirección IP de origen se realizarán las pruebas de explotación. Una vez iniciado el testeo, es lógico que se generen alertas. Por supuesto, el bloquear la IP desde cual se realiza el estudio traerá aparejado que no se pueda obtener información sobre la plataforma estudiada.

Es curioso cómo muchos clientes olvidan bloquear sus IP (o deciden no hacerlo) en un día corriente, pero sí recuerdan hacerlo durante la auditoría. Si bien puede resultar tentador pensar que al tener un firewall bien configurado las plataformas no podrán ser atacadas, es solo una falsa sensación de seguridad, debido a que un atacante real podrá cambiar infinidad de veces la dirección desde donde llevará a cabo su ataque.

De manera análoga al caso anterior, apagar un equipo vulnerable detendrá sin duda que este pueda aparecer como desactualizado, marcando un punto en el informe. Sin embargo, este tipo de comportamiento, más allá de ser peligroso para la entidad afectada, generará que en el reporte no figure como un equipo auditado. Desde luego, es posible que se tenga que volver a realizar la auditoría.

#2 Desestimar una vulnerabilidad crítica

En varias oportunidades pueden encontrarse graves vulnerabilidades en servidores, aunque quizá no tan críticos para el core del negocio. Sin embargo, debe considerarse la cantidad de información disponible que podría quedar potencialmente en manos de un atacante, además de que le sería posible realizar un salto a otro dispositivo de la misma red de una forma bastante sencilla.

Estos son algunos de los motivos por los cuales no deberían desestimarse este tipo de vulnerabilidades en un informe. Recuerda que la seguridad es un proceso, no un producto.

#3 Rehacer el reporte

Una de las tareas más tediosas para los que realizan trabajos de campo o pentest es escribir el reporte. Tal vez si analizamos algunas de las causas veremos que los auditores suelen deleitarse mucho más con descubrir y explotar vulnerabilidades que con escribir sobre ellas, aunque por supuesto es una parte muy importante de su trabajo.

Es vital revisar cuidadosamente los resultados encontrados y eliminar cualquier falso positivo que pueda quedar en el informe, ya que un resultado incorrecto desacreditará en mayor o menor medida el resto de vulnerabilidades válidas del informe. La situación se complica cuando todas las vulnerabilidades encontradas no pueden aparecer en el reporte por diversos motivos, como por ejemplo la presencia de un equipo obsoleto que se encuentra sin uso, pero activo en la red.

Usualmente en este punto comenzará una negociación entre los auditores y los auditados, que muy probablemente terminará modificando (para bien o para mal) el reporte correctamente llamado preliminar. No es ninguna sorpresa que, si hay gran cantidad de modificaciones, esto no será nada grato para el auditor.

#4 Monitoreo excesivo

SysAdmins, encargados de seguridad y encargados de redes suelen cambiar sus rutinas diarias al enterarse que se harán auditorias de seguridad en los sistemas. Es decir, comienzan a monitorear exhaustivamente conexiones anómalas, por lo que en muchos casos podrán detectar e interceptar comunicaciones remotas de un auditor.

Por supuesto que si el pentester había logrado explotar una vulnerabilidad, probablemente se encuentre conectado y sea visible para un SysAdmin. Este podría fácilmente cortar la conexión, haciéndole perder el tiempo y la sesión al analista, aunque las vulnerabilidades sigan presentes.

#5 Borrado de archivos

Ligado al punto anterior, en muchas ocasiones las aplicaciones web pueden ser comprometidas. Una vez logrado el objetivo, uno de los modos más sencillos de explotación es la utilización de webshells para poder moverse entre directorios e ir ganando distintos accesos. Por supuesto que borrar este tipo de archivos no hará al servidor más seguro, ya que si fuera un ataque real probablemente no sería tan sencillo detectarlo.

Conclusión

Se dice que lo importante está en los detalles. Por eso mismo, de nada sirve ejecutar una revisión de seguridad superficial de una aplicación o sistema operativo y considerarla completa. Esto provocaría una falsa sensación de confianza que puede ser tan peligrosa como no haber hecho una revisión de seguridad.

Todos los modos que describimos de arruinarle el día al pentester también son métodos que generan mayor inseguridad en los sistemas o aplicaciones estudiados. Es por esto que resulta sumamente importante que auditores y auditados trabajen en conjunto, evitando generar dolores de cabeza y alineando ambos objetivos con el único fin de disfrutar de las tecnologías de forma segura.

Discusión