A lo largo de los años he tenido la suerte de obtener las aptitudes de un buen pentester, gracias a tener responsables que me han ido aconsejando sobre cómo mejorar mi forma de trabajar, de cómo ser más eficaz, y de entregar un trabajo de calidad que realmente le sea útil al cliente. En esta área de la informática que es la seguridad ofensiva, es imprescindible que unas buenas aptitudes técnicas vayan acompañadas de otras aptitudes que veremos a continuación, que según mi opinión son recomendables adquirirlas y practicarlas.
«SIEMPRE APRENDIENDO, SIEMPRE MEJORANDO»
Esta profesión tiene la “maldición” de estar permanentemente actualizado, si realmente quieres entregar un trabajo decente.
- Conoce las últimas vulnerabilidades: Es necesario estar al día de qué nuevas vulnerabilidades se publican para cada producto, si a la hora de realizar una auditoria nos encontramos con ese sistema, seamos capaces de identificar y explotar dicha vulnerabilidad.
- Conoce las últimas herramientas: Relacionado con el punto anterior, frecuentemente se publican nuevas herramientas que mejoran el desempeño de tu arsenal actual, por lo que es necesario estar al día. Si le preguntáis a un pentester con varios años de experiencia sobre su arsenal de herramientas imprescindibles actuales y de hace 3 años, probablemente habrá cambiado sustancialmente. También recomendable no limitarse únicamente a saber utilizar la herramienta, si no conocer cómo funciona internamente.
En muchas ocasiones nuestro entorno de pruebas será muy limitado, o cierta herramienta no funcionará por algún motivo, que probablemente nunca lo descubramos salvo que conozcamos internamente el problema.
- Mejorar conocimientos en áreas transversales: no solo de seguridad pura y dura se alimenta un pentester. Se deben tener conocimientos generales en prácticamente cualquier área IT. Por enumerar algunas: administración de sistemas, redes, programación y desarrollo seguro, exploiting, malware, incident response, threat Hunt, forense, etc.
¿Cómo aprender?
- Cacharrear y cacharrear. Trastea con herramientas, practica con CTFs y máquinas virtuales vulnerables. Monta un laboratorio casero, cuanto más complejo, más aprenderás.
- Asiste a congresos de seguridad. En ellas se suelen hablar de las últimas novedades del mundo del infosec.
- Leer, leer y leer. Tener una lista de gente en twitter que suele compartir contenido interesante. Lo mismo para listado de blogs. Y por supuesto, libros técnicos.
- Escribir y exponer. Una forma muy útil de afianzar conocimientos es explicarle a alguien lo que has aprendido. Por ejemplo, cacharrear con una máquina virtual vulnerable se aprender, pero escribir un write-up con los pasos realizados para comprometerla, se aprende muchísimo más. Además, ese conocimiento ya lo tienes por escrito para consultarlo cuando quieras.
Ser riguroso
Conozco gente que son unos auténticos fuera de serie técnicamente, pero luego son unos verdaderos desastres documentando su trabajo, o explicando al cliente sus descubrimientos. Es una pena haber descubierto una vulnerabilidad compleja de explotar si luego no has evidenciado cada paso correctamente. Por eso es necesario tener siempre presente que cada prueba que lances, vulnerabilidad que encuentres, lo haces como parte de un proyecto a un cliente. Ahí van algunos puntos para mejorar estos aspectos:
- Rigurosidad con las evidencias: cada vulnerabilidad que se encuentre debe ir acompañada de evidencias que demuestren de forma impepinable, y sin lugar a discusión la veracidad de dicha vulnerabilidad. En muchos casos, los informes de resultados suelen redirigirse a otros departamentos, y en ocasiones éstos suelen ser reacios a creer la veracidad de las deficiencias encontradas. Por eso es necesario que la evidencia demuestre eficazmente la veracidad de la vulnerabilidad. También es recomendable evidenciar una vulnerabilidad con una herramienta estándar, que se encuentre disponible en cualquier distribución Linux, como nmap, openssl, o curl, por ejemplo. De esta manera, mostrando el comando lanzado con los parámetros utilizados, permites al cliente por un lado comprobar por ellos mismos la veracidad de la vulnerabilidad, y por otro lado, darles la manera de verificar si la vulnerabilidad ha sido remediada, una vez la hayan solventado.
- Rigurosidad con las pruebas: cada prueba lanzada debe ser:
- Trazable: Imprescindible tener un log de toda herramienta que se lanza. En el transcurso de una auditoría suele ocurrir que algún activo se cae, y por regla general a los primeros que se les suele apuntar con el dedo es a los auditores. Por eso estos logs son útiles para demostrar si hemos sido (o no) los causantes de la pérdida del servicio.
- Repetible: Es deseable que cada prueba lanzada pueda repetirse, principalmente de cara a evidenciar, o verificar por parte del cliente. Si no somos capaz de reproducir de nuevo la explotación de una vulnerabilidad, probablemente algo no se habrá hecho correctamente, o peor, algo habremos roto.
- Explicable: Ya mencionado en puntos anteriores. Debemos ser capaces de explicar cómo se ha identificado una vulnerabilidad.
- Solucionable: El punto más importante bajo mi punto de vista. Para el cliente, más que entender la vulnerabilidad, es más importante saber cómo pueden mitigar el riesgo asociado. Debemos, por tanto, aportarle diferentes soluciones para remediar o mitigar de forma alternativa el riesgo. En algunas ocasiones, la opción más efectiva no suele ser posible aplicarla, o no a corto plazo, por lo que debemos aportarle al cliente soluciones alternativas o compensatorias que de alguna forma mitiguen el riesgo.
Ser metódico
Por último, es muy importante que el trabajo de un auditor sea muy metódico, para poder entregar un trabajo de calidad, sin que se nos haya escapado algún aspecto sin probar.
- Centrarse en el alcance del proyecto: si el alcance son 3 aplicaciones web, no salirse de esos activos. Si es una auditoria de vulnerabilidades y no un test de intrusión, lanza las pruebas necesarias para verificar la vulnerabilidad, pero no la explotes. Es muy tentador explotar una vulnerabilidad de ejecución de código remoto, o instalar una webshell en una web vulnerable a RFI, pero cosas malas pueden ocurrir en el camino.
- Seguir una metodología estándar: OWASP, OSSTMM, seguir una metodología y cumplir todos los pasos nos permite verificar que estamos auditando todos los posibles puntos a revisar. Conforme vas adquiriendo experiencia, acabas por elaborar tu propio checklist con cada herramienta de tu arsenal, con sus parámetros.
- Documentar y evidenciar sobre la marcha. Tal vez algo que hayas descubierto mañana ya no esté disponible. Evidencia y documenta, no esperes al último día o corres el riesgo de perder u olvidar alguna evidencia importante.
