Cuestionamiento a los procesos de pentesting

Por fin consigues que la empresa pague una evaluación práctica de seguridad  de la infraestructura, o lo que en el mundo de la seguridad se conoce como un pentest. Seleccionas los objetivos a ser atacados, elaboras los detalles del contrato y el gran día de inicio preparas café para todos.

Los pentesters inician sus labores. Son semanas arduas de coordinación y vigilar que aunque estén haciendo su trabajo, no vayan a afectar tus sistemas y redes. Por fin acaban y tras una semana más de elaborar el reporte, te llaman para darte los detalles y revisarlos para entender qué es lo que encontraron. Lo primero que te dicen es que hay 19 hallazgos críticos, 4 medios y 21 bajos.

Empiezas a estar intranquilo por esos 19 críticos. Pides empezar a revisarlos cuanto antes. De inmediato emergen los detalles de cada uno de esos hallazgos y sus vulnerabilidades informáticas asociadas. Al terminar de revisarlas te quedas con una gran duda. “¿Pudieron explotarlas?”

Los pentesters se voltean a ver unos a otros. “Bueno, propiamente no. En algunos casos no encontramos el código de explotación que abusa de la debilidad. En otros casos sí los encontramos pero al querer usarlos con las versiones existentes en la infraestructura no sirvieron. Un tercer caso fueron las vulnerabilidades con exploits que casi servían pero no del todo porque lo único que logramos fue hacer una denegación de servicio a pesar de que la documentación decía que se podía controlar un sistema.”

Te rascas la cabeza. “¿Pero entonces, no lograron entrar a ningún sistema? ¿No pudieron extraer información de algún servidor o dispositivo de red? ¿Algo que hayan comprometido?” Los pentesters piensan un poco la respuesta y el líder de proyecto responde: “No, no nos fue posible”.

De pronto te sientes aliviado. ¡No hubo acceso ni robo de información! Pero inmediatamente viene la pregunta de rigor: “¿Entonces, por qué clasificaron a esos hallazgos como de criticidad alta?”

Hay un silencio de un par de segundos. De nueva cuenta el líder del equipo de pentesters toma la palabra. “El fabricante mismo y un CERT los clasifican como de criticidad alta. Puedes revisarlo por ti mismo, aquí están todas las ligas de referencia.”

Analizas un par ahí mismo. Los pentesters tienen razón. Las debilidades tienen clasificación alta. Y a continuación dices: “Entiendo que la criticidad es alta, pero eso lo establece un tercero. Aquí dentro de la infraestructura ustedes no pudieron hacer gran cosa con ellos. Es decir, no entraron a un sistema para escalar privilegios, no tomaron el control de un equipo ni pudieron interceptar información. De hecho, y tal vez de lo más relevante, es que en todos esos 19 hallazgos críticos, tuvimos que apagar al menos un control de seguridad para que ustedes pudieran hacer lo suyo. Ya sea el antivirus, la prevención de intrusos o una regla en el PIX. ¿Todo eso no se debe de tomar en cuenta para establecer la criticidad?”.

Ellos respiran profundo. “Mira, la criticidad es alta porque si hubiéramos podido hacer un exploit o hubiéramos logrado que un código de explotación existente funcionara con la versión que tienes en los sistemas, podríamos haber entrado a los sistemas y tomar control de ellos.”

Tú intervienes. “Estoy de acuerdo con ustedes, pero el punto es que no lo lograron. En un pentest el hubiera no existe. En una consultoría de seguridad basada en Word y PowerPoint con unos trajeados, ahí sí se valen los ‘hubiera’ y ‘podría’ pero no en un pentest. Básicamente lo que hicieron es escanear la infraestructura, encontrar debilidades y clasificarlas. Pero no pudieron explotarlas realmente. Y no es que exija que se exploten, pero mi punto es que la criticidad no debe de ser alta. Tendría que ser media o baja porque al final de cuentas no pudieron hacer una afectación real y práctica con ellas.”

Los pentesters se ponen a la defensiva ante tus comentarios tan directos y sin tacto. Responden elevando ligeramente la voz que “una cosa es que nosotros no hayamos podido hacerlo y otra cosa es que otro grupo de pentesters con más tiempo y recursos no pueda hacerlo. Es cuestión de que un código de explotación sirva para que alguien entre al sistema y tome su control.”

Piensas que es muy acertado lo que han dicho y que tienen un punto válido. Pero prosigues. “¿Y por qué ustedes no pudieron, les falta tiempo o capacidad? ¿Es a eso a lo que se refieren con que les faltaron recursos? Los contratamos para que comprueben lo que encontraron.”

“Nos faltó tiempo”, responden secamente. “Alguien más lo podría hacer. Y repito, la criticidad no está establecida por nosotros, sino por un tercero.”

Yo no estoy de acuerdo. Un hallazgo no es sinónimo de una vulnerabilidad. Un hallazgo toma en cuenta tanto la debilidad, como la amenaza, los controles de seguridad actualmente existentes y la explotación. De otro modo persiste la duda sobre la posibilidad real de abusar de la debilidad. Cuando no hay un pentest de por medio, efectivamente recurrimos a escenarios de ataques donde elaboramos hipótesis de la criticidad de una debilidad. Sin embargo un pentest es práctico. No hay teoría. No hay escenarios. Hay una realidad donde hay que probar la explotación de la vulnerabilidad para decir que es crítica. Y cuando hay una consecuencia como acceso al sistema o extracción de información, ya no hay duda sobre el hallazgo de alta severidad.

Llegan, no te piden apagar ningún control de seguridad ni que les digas el tipo de sistema operativo y versión usada. No te piden nada. Después de unos días simplemente se aparecen una tarde en tu oficina y te dicen que el Directorio Activo es suyo, que tienen el control de los servidores y estaciones de trabajo. Son los administradores de la infraestructura. Los señores feudales de tu castillo tan celosamente protegido. ¿Y sabes? No necesitan decirte en un reporte que encontraron un par de hallazgos críticos. Eso, mi estimado, ya lo sabes.