Iniciación a un laboratorio de seguridad (III)

Una vez hemos realizado los ataques, vamos a acabar esta breve serie, analizando que han sido capaces de capturar el Snort empleando las reglas del VRT, y un OSSEC con la configuración por defecto.

Por parte del Snort, éste ha detectado 4 ataques. Como vemos en la captura, éste detecta el acceso por Terminal Server y el acceso al recurso compartido C por contraseña, o el uso del llsrpc pero no vemos rastro real de la ejecución del exploit o del meterpreter. Esto es debido a que las reglas por defecto que generan dichas alertas dan lugar a muchos falsos positivos y por defecto están deshabilitadas:

En la parte del OSSEC nos llama la atención que no salten alertas tales como la creación de nuevos usuarios en la máquina o de usuarios agregados al grupo de Administradores. Debemos recordar que la configuración es la de por defecto, sin habilitar logs extendidos ni otras variantes.

Únicamente se nos informa de fallos de seguridad en la configuración del servidor que se tiene habilitado la autenticación mediante LM, algo peligroso debido al cambio a solo mayúsculas, la división de la contraseña en dos bloques de 7 caracteres y el no empleo de la semilla. Adicionalmente se nos informa que aceptamos sesiones nulas, lo que puede permitir a un atacante listar los usuarios, grupos y dispositivos de la máquina. Pero nada relacionado con el ataque, como podemos ver a continuación:

# ./rootcheck_control -i 003 
Policy and auditing events for agent 'Victima (003) - 10.0.0.2': 
Resolved events: 
** No entries found. 
Outstanding events: 
2010 May 20 12:04:37 (first time detected: 2010 May 20 12:04:37) 
Windows Audit: LM authentication allowed (weak passwords). 
2010 May 20 12:04:37 (first time detected: 2010 May 20 12:04:37) 
Windows Audit: Null sessions allowed. 

# ./syscheck_control -r -i 003 
Integrity changes for 'Windows Registry' of agent 'Victima (003) - 10.0.0.2': 
** No entries found. 

# ./syscheck_control -i 003 
Integrity changes for agent 'Victima (003) - 10.0.0.2': 
** No entries found.

(No se registran alertas en los logs relacionados con el ataque)

Ante dicha situación, realizamos una prueba de calibración accediendo a un recurso no disponible y observamos que en efecto se registra dicho acceso :

10.0.0.2 - - [20/May/2010:13:55:33 +0200] "GET /s2/webficticia HTTP/1.1" 401 844 
    "-" "Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)"

Por tanto, tal como se ha visto en la PoC, emplear configuraciones y firmas por defecto prácticamente es como no emplear herramientas de seguridad, por lo que durante el despliegue de dichas herramientas de seguridad es muy importante configurarlas adecuadamente.

Como conclusión, podemos decir que es muy recomendable el empleo de un laboratorio como el que hemos visto, donde la máquina víctima sea una maqueta genérica sin parchear del cliente donde se desea realizar un proceso de Hardening o Bastionado. De esta forma podemos realizar varias pruebas y comprobar el nivel de detección real de nuestras herramientas.

Comments

  1. Muy buena saga. Hasta yo, que soy de sistemas, lo he entendido!

Trackbacks

  1. […] This post was mentioned on Twitter by Security Art Work, jose m Lechon. jose m Lechon said: Para terminar con la trilogía de articulos, aqui dejo el últmo de la saga del laboratorio de seguridad: http://bit.ly/aIRJCD […]

  2. […] Iniciación a un laboratorio de seguridad (III) Una vez hemos realizado los ataques, vamos a acabar esta breve serie, analizando que han sido capaces de capturar el Snort empleando las reglas del VRT, y un OSSEC con la configuración por defecto. […]