En el artículo de hoy voy a intentar describir y aportar mi conocimiento y experiencia sobre la fase de análisis y explotación de vulnerabilidades, enmarcada dentro de la serie de artículos que estamos haciendo sobre las distintas aproximaciones a la hora de hacer un pentest y cómo descubrir o identificar los objetivos del mismo.

Como analistas, es el turno de pasar al ataque

Como analistas, ahora es el turno de pasar al ataque. Sabemos que hay peces en el rio y queremos pescar alguno. Sabemos que hay truchas, pero… ¿qué cebo uso? ¿Qué anzuelo? ¿A qué hora se pesca y en qué cauce del rio? Esta es la parte que debemos averiguar y aprovechar en esta fase del pentesting.

Vamos a imaginar que nuestra organización objetivo, que hará las veces de víctima durante la auditoría de seguridad, ofrece a sus clientes servicio web, correo y conexión remota para el departamento de informática o empresas de soporte. Un escenario de lo más habitual.

En la anterior fase averiguamos que el servidor es un Apache 2.2.12, que alberga una página web Wordpress 3.7. Al tratarse de sistemas conocidos, podemos optar por buscar fallos anteriormente documentados por otros profesionales. Para ello podemos usar el propio sistema de categorización de vulnerabilidades llamado Common Vulnerabilities and Exposures (CVE), en el que se reportan todos las fallos conocidos. Por ejemplo, para esa versión de Apache aparecen varios fallos de seguridad. Se puede apreciar que la mayoría son del tipo DoS (Denial of Service), que “tumban” al servidor saturándolo de peticiones; pero aparecen dos que llaman la atención: CVE-2010-0425 y CVE-2013-1862.

¡Estamos de suerte!

Con esta información sabemos que ese servidor web tiene dos fallos, dos vulnerabilidades conocidas que un atacante podría aprovechar. ¿Cómo lo haría? Podemos averiguarlo buscando en alguna de las webs especializadas en exploits (programas que se aprovechan de una vulnerabilidad para ejecutar una acción), como puede ser Exploitdb, para saber cuáles están publicados y listos para usarse en una determinada vulnerabilidad.

¡Qué fácil de comprometer es este sistema entonces! Aunque en la mayoría de casos suele pasar que:

  • Se identifica una vulnerabilidad pero no existe públicamente un exploit o manera “sencilla” de explotarla.
  • No se encuentra una vulnerabilidad para la versión que estamos auditando.
  • Se encuentra un exploit pero no funciona. Muchas veces están mal escritos para que la persona que los usa los modifique, minimizando su uso a manos de gente sin el conocimiento suficiente.
  • Este sistema está contra ti y no funciona nada…

Siguiendo el ejemplo que hemos puesto, pasamos a evaluar las vulnerabilidades del Wordpress realizando el mismo proceso. Puede que tengamos suerte, o puede que no. Puede que el sistema que auditamos esté completamente actualizado y no existan vulnerabilidades. ¿Desistimos?

Aquí es donde nos salimos de los manuales convencionales y pasamos a la pericia del auditor.

Podemos seguir la guía de top 10 de vulnerabilidades en aplicaciones web de la organización OWASP (Open Web Application Security Project).

Aunque esta guía se orienta mucho a la parte web, los ítems se pueden más o menos transpolar a distintos sistemas. Vamos a tomar también el top 10 de riesgos para aplicaciones móviles.

Algunas comunes, cuya aparición varía según el año en que se elabore el ranking, son:

  • Security Misconfiguration

Una mala implementación del responsable, como por ejemplo dejar la carpeta de instalación en el servidor, no borrar un usuario por defecto o no poner una contraseña a un servicio. La robustez de las contraseñas y las políticas de seguridad asociadas siempre es otra obligación en los procesos de explotación.

  • Poor Authorization and Authentication

Preparar un buen diccionario de contraseñas para realizar un ataque de fuerza bruta es básico en un pentest. Desde el punto de vista del auditor es importante usar por ejemplo un diccionario de 1.000 palabras, y en el intento 400 encontrar la clave del administrador, ya que estar 1 hora probando sin éxito ya es un fallo de seguridad. Pero también es importante, de cara al informe, documentar que se ha intentado un ataque de fuerza bruta con 1.000 palabras y que no se ha encontrado la clave, pero que el sistema no fue capaz de defenderse de este ataque, por lo que más tiempo o más velocidad podrían resultar en éxito.

  • Unintended Data Leakage

Pongamos el ejemplo del ataque de contraseña. Si el sistema nos responde con “usuario o contraseña inválido” lo hace bien, lo malo sería que dijera “contraseña inválida”: estaría revelando que el usuario está correcto.

  • Unvalidated redirects and forwards 

Esto es muy curioso. Imagina un correo malicioso de spam con una dirección para pinchar y robarte información o enviarte una pieza de malware. ¿Confiarías en “http://asdfasdasd.xasdfsdf.cvsdgfsdf.ru”? Seguramente no es una URL muy apetecible. Imagina esta: “http://www.burguerkinggggg.ar”. ¿Confiarías en sus ofertas? Pero ahora imagina o, mejor dicho, pincha en esta: http://www.google.com/amp/kinomakino.blogspot.com. ¿Confiarías en el dominio Google.com? Esto es una redirección, donde se usa un dominio para acceder a otro, pero la confianza del usuario es mayor que usando otro tipo de direcciones, como los ejemplos anteriores. En este caso la redirección es a mi web personal, algo no tan peligroso ;)

Como verás, la fase de enumeración de vulnerabilidades y explotación de las mismas es tan amplia y compleja como el número de sistemas que existen.

En el próximo capítulo seguiremos con estos consejos para aplicar en escenarios de explotación defensiva de vulnerabilidades, y apuntaremos al sistema más débil de todos: ¡el usuario!

Sigue leyendo: ¿En qué consiste un penetrarion test?