Search for in Google by Dino

Google Custom Search

martes, 3 de enero de 2012

P A R T II - "Actualizar no es Asegurar" HARDENING ≠ UPDATE / UPGRADE

Saludos,



Vamos a darle continuidad a nuestro articulo de "Actualizar no es Asegurar" HARDENING ≠ UPDATE / UPGRADE (°L°))? con la finalidad de terminar de contarles esta historia.

Para ambientarles un poco citare el objetivo de la intervencion:

En el proceso que se efectuó de análisis del sitio Web (Pen Test), se encontró que hacían uso de contraseñas débiles o por default y se especificaban las recomendaciones para mitigar la vulnerabilidad.

Desafortunadamente la medida que tomaron en el aseguramiento fue nuevo servidor y actualizar la versión del Apache / Tomcat pero con la misma falla de seguridad. Se pretende demostrar algunas acciones que llevaría a cabo el atacante para ampliar su superficie de ataque afectando no solo el sitio Web, si no la Red Interna y lo que se encuentre a su alcance

Y continuaremos mostrando las evidencias correspondientes :

Una excelente fuente de informacion es la configuracion de los crontab, puesto q le permitira al atacante determinar informacion sensible critica e importante para la Organizacion, determinando la frecuencia,   y generacion de backup de datos.


Archivo /etc/crontab (tareas programadas)


Script de realización backup diario programado en el crontab del sistema, esta referencia le permite conocer la criticidad de los datos sensibles y su ubicación.

En el mismo se encuentra el volcado de la base de datos MySql con credenciales quemadas, e igual para la Base de Datos del OpenLdap en un archivo backup_LDAP-dif y los buzones de correo de los usuarios.





RECORD HOST - PostgreSQL
Archivo de configuración del Cake.php

Permite al atacante medir el expertis del Sysadmin, al determinar opciones de booteo, seguridad, estados de recuperacion o boot de kernel con versiones anteriores (recuperacion de kernel), arquitecturas del sistema y discos de almacenamiento.


Consulta de los archivos de booteo del sistema Linux (grub/menú.lst)
Otra fuente de informacion valiosa son los historicos de comandos.








Consulta del archivo /root/.mysql_history


Configuracion del .htaccess


Realizando volcado de los archivo de usuarios y claves del sistema /etc/passwd, /etc/shadow.
Se muestra usuario samba creado por el atacante para lograr acceso al sistema vía ssh.

Archivo /etc/passwd

Archivo /etc/shadow
Con base en esta información el atacante lanzara procedimientos de desciframiento de claves, para esta ocasión hacemos uso de JhonTheRipper.




Se procede a consultar el tipo y método de autenticación, determinando el uso de PAM y saslauthd


De igual forma se procede a explorar e investigar otros archivos de configuración que permiten aumentar el espacio de ataque a otros servidores o equipos con enrutamiento al servidor Web. Consultando archivo de configuración del servicio DNS.

Nos permite determinar a que otros equipos o servidores podemos llegar, mas aun si existen relaciones de confianza entre servidores. Comprometiendo otra Compañía (Empresa).


Consulta del archivo /etc/hosts



Realizamos consulta del servidor virtual


Consulta de archivos con información importante permitiéndole al atacante lograr otros objetivos de ataque.

Archivo conexionDB.properties

Determinando la configuración de Red del servidor Web. El atacante puede determinar si la configuracion de red es dinamica, estatica, si existen otras NIC con IP asignadas o virtuales o si existen sistemas de redundancia o sistemas de Clustering.


Determinando el sistema de autenticación en el sistema


Revisando el archivo de perfil general de los usuarios /etc/profile.


Revisando archivo de configuración correo interno protocolo POP3


Revisando archivo de configuración Tunning del Kernel del sistema Operativo.

Revisando la configuración del servidor de correo Dovecot



Revisando la configuración del archivo ldap.conf (OpenLDAP)
archivo ldap.conf (OpenLDAP)
Revisando la configuración de los hosts de confianza del servidor aplicado por el servicio ssh. Nuevamente, vemos como se comprometen la información de empresas de terceros. El atacante tendria la posibilidad de crear relacion de confianza con  el servidor añadiendo las key o haciendo uso de las validas.



Revisando archivo de configuración con la agenda de Kronolith



Se encuentran otras advertencias establecidas y reportadas en el Informe del Pen Test Inicial.  

Pero no las vamos a mostrar aqui, puesto que el objetivo de este articulo era demostrar el alcance que puede tener un atacante mas estructurado, logrando no solamente compromenter el sitio Web, si no el Servidor Web con todas las paginas que se encuentran en el permitiendo como ya lo habiamos mencionado facilmente una Mass Defacement. Con un poco de curiosidad y exploracion nos damos cuenta que el atacante ha logrado no solo comprometer el servidor si no todo aquel Host o Server que tenga algun enrutamiento o relacion de confianza afectando los diferentes servicios q esta prestando. 

En resumen se comprometio La Web, El servidor Web, Todos los servicios que el servidor esta prestando, se tiene alcance a la LAN, WAN u otros servidores de la Organizacion y de otras Empresas.

Los cuales no fueron explotados puesto que el "Contrato de Servicios", "Acuerdo de Confidencialidad" y la "Carta de Autorizacion" no nos permitia llegar a ellos, no estaban dentro del alcance del Proyecto, pero para una atacante real no seria impedimento alguno si no el "COFRE DEL TESORO".

De esta forma terminamos esta historia y con la ferviente conviccion que hemos dejado un mensaje de (IN) Seguridad y continuo aprendizaje.


Si te gusto o tienes alguna observacion o critica constructiva, es Bienvenida......

Bytes


Dino

PD: Un especial agradecimiento a mi gran amigo  @crodallega / Roguer  por su colaboracion  :P
PD2: Todas las vulnerabilidades encontradas y reportadas han sido corregidas.