He recibido un correo en el que se me sondeaba sobre la posibilidad de colaborar profesionalmente con un peticionario, al que obviamente he pedido permiso para poder hablar de ésto, vaya que se sintiera ofendido. Tal y como me ha pedido, no revelaré su identidad ni hablaré tampoco de la empresa para la que trabaja, que todo sea dicho, es conocida en el mundillo.

El caso es que este correo me hace reabrir un discurso que llevo años pronunciando. Hoy quiero haceros a todos partícipes de este pequeño debate, y en caso de que haya alguien que se sienta identificado, nos cuente lo que opina al respecto.

Este señor me pedía información para realizar una auditoría. Yo he declinado, por muchas razones, la principal es que en caso de aceptación existiría un conflicto de interés con mi empleador, al que le debo lealtad y respeto, así como cumplimiento de la legislación vigente :) Aún así, es posible que existan vías de colaboración para otros menesteres en los que no exista tal conflicto, algo de lo que yo particularmente me alegro.

Este señor me solicitada información sobre lo que podría costar una auditoría de un TRU64. Lo que ocurre es que lo que este señor quería contratar, leyendo sus peticiones, no era una auditoría, era un test de intrusión. Para él la auditoría equivalía a un test de penetración, confusión frecuente sobre todo en personas que están en departamentos que orbitan alrededor de TI, y en los que no se puede presuponer que se conozcan este tipo de distinciones.

El auditor no es mas guay ni es mejor que el pen-tester. Tampoco sucede en el otro sentido. Son perfiles distintos, que hacen trabajos distintos, y no por ello uno es más valioso que el otro. Por eso mismo aclaremos que una auditoría NO es un un test de penetración, aunque obivamente, son conceptos que tienen relación.

El test de penetración es una prueba técnica que se ejecuta en un contexto delimitado (una IP pública, un equipo de la red local, lo que sea), en el que se intenta lograr la intrusión explotando vulnerabilidades, problemas técnicos y deficiencias de la configuración, con la finalidad de evaluar si un sistema es o no es seguro ante un ataque externo. Muchas veces se habla de hacking ético, queriendo significar esto que se trata de ponernos en la piel de un atacante externo que, explotando problemas, desea acceder a nuestros recursos protegidos. El adjetivo ético hace referencia a que lo hacemos bajo demanda del peticionario, y sin oscuras intenciones. Por eso mismo creo que sería más prudente llamarlo cracking ético, porque según la filosofía underground, el hacker entra sin causar daños ni pretenderlos. Una larga disquisición cracker vs hacker, que tampoco es menester desarrollar ahora :)

La mejor manera de entender qué es un pen-test (penetration test, test de penetración) es resumiendo esquemáticamente las fases habituales de un análisis de este tipo:

  1. Definimos nuestro objetivo. En este caso, el ejemplo de análisis es la IP a la que nos lleva OpenBSD.org. Ni qué decir que esto que os cuento es un mero ejemplo, y que obviamente, un test completo acarrea bastante más trabajo. No quiero que ningún pen-tester se sienta ofendido ante la imagen de simplicidad de este ejemplo :)
  2. Listado de servicios en exposición (habitualmente, un escaneo de puertos). Entre otros, resulta que "Interesting ports on openbsd.sunsite.ualberta.ca (129.128.5.191): 80/tcp open http". Descubrimos que en OpenBSD.org tienen el puerto 80 abierto (menudo descubrimiento :P)
  3. Identificación completa de servicios y versiones. Identificamos qué servidor Web y que versión están a la escucha de ese puerto 80. Nmap nos vale también, aplicando la opción de TCP/IP fingerprinting. Ejecutamos un nmap -T4 -A www.openbsd.org -p 80 y descubrimos que "80/tcp open http Apache httpd 1.3.34 ((Unix) PHP/4.4.2 mod_perl/1.27) Running: Sun Solaris 2.X|7|8. OS details: Sun Solaris 2.6 - 8 (SPARC)". Información suficiente para progresar.
  4. Análisis automatizado de vulnerabilidades y deficiencias. Antes de proceder al análisis manual, aprovechemos las herramientas que separan trigo y paja. Ya recogeremos el grano después. Pasamos un escáner de vulnerabilidades para ver si ese Apache descubierto es vulnerable o no. El escáner automático dice que no hay nada anormal. Vía muerta de investigación.
  5. Análisis manual de vulnerabilidades y deficiencias. Repasamos el histórico de vulnerabilidades y tratamos de explotar las deficiencias manualmente. Queremos ver si ese Apache 1.3.34 está actualizado en lo que parches de seguridad concierne (no lo está, pero los fallos entre la 34 y la 37, última disponible, no son explotables). Tampoco hay deficiencias de configuración reseñables. Vía muerta.
  6. Ejecución de la intrusión, si es posible (si por el Apache no podemos, tratamos por el sistema Solaris, o vía módulos de Apache detectados, como PHP/4.4.2 mod_perl/1.27. Cualquier puerta de entrada es válida. Por desgracia, no la encontramos. No esperaba menos de OpenBSD :)
  7. Recolección de evidencias (capturas de pantalla, logs, etc) en el caso de que encontremos vías de acceso. Hay que guardar todas las pruebas para demostrar después los logros del trabajo. Eso sí, hay que ser profesional obteniendo y conservando pruebas.
  8. Informe del test, documentado todo lo que hemos hecho y qué hemos logrado, y lo más importante: consignamos las recomendaciones para subsanar el problema con la mejor optimización. Un trabajo técnico que no proporciona soluciones óptimas no sirve DE NADA.

Eso es un test de intrusión en esencia, resumido esquemáticamente. Una auditoría es un concepto mucho más general, en el que no necesariamente evaluamos la seguridad de un ítem. Podemos evaluar la eficacia, la eficiencia, el rendimiento, la escalabilidad, la compatibilidad, los tiempos de recuperación ... La auditoría es un trabajo en el que se evalúan habitualmente una o varias características de un sistema determinado así como su interrelación. Estas características ni tan siquiera tienen por que ser técnicas. Es posible auditar aspectos financieros u operacionales.

Bajo mi punto de vista, una auditoría, salvo que el alcance no lo requiera, puede perfectamente incorporar un test de penetración como una prueba más. El auditor puede conducir la prueba si tiene habilidades para ello, si bien es deseable, por plazos, por objetividad y porque cuatro ojos ven más que dos, que esta prueba, mucho más económica que una auditoría de sistemas, la haga un tercero, interno o externo a la compañía, y que el auditor evalúe los resultados de dicha prueba. Es el escenario de la auditoría de seguridad más usual, en el que además de los test de intrusión, se evalúan otros aspectos como la calidad de la criptografía, la explotación del sistema, las comunicaciones, la seguridad física, la seguridad lógica, el retorno de la inversión, ... todo lo que queramos definir en nuestro alcance.

Insisto: son trabajos distintos. No podemos confundirlos. Llamemos a cada cosa por su nombre, por favor :)

¿Has llegado al final del artículo? ¿Lo leíste entero? Te mereces un premio, no me cabe duda. Aquí os dejo dos enlaces para seguir investigando:

Saludos :)

Technorati:

Tags: ,



Relacionados:
Enumeración de vulnerabilidades para ejecutar tests de penetración
Reglas mod_rewrite incorrectas
Test de intrusión