H&D HACKING & DEFENSE: 2011

Hola amig@s,

Aprovechando que me encuentro con unos momentos de libertad y tranquilidad de mis quehaceres cotidianos, academicos, familiares y de trabajo, los voy a aprovechar antes de que comience el ajetreo de las fiestas navideñas con mi adorada familia para contarles una historia de vida empresarial en donde vamos a enfatizar en que

"ACTUALIZAR NO ES ASEGURAR" Hardening ≠ Update / Upgrade.

Y esto comienza Asi:

Generalmente cuando terminamos un proyecto de Analisis de Seguridad a una Plataforma Informatica o un Objetivo especificado (target), posteriormente pasados unos meses se realiza el proceso de revision del Aseguramiento, es decir entramos a realizar una Auditoria al Proyecto de Aseguramiento, Hardening o Aplicacion de remediaciones, con base en las recomendaciones establecidas en los Informes del Pen Test.

Desafortunadamente en algunas ocasiones encontramos que las recomendaciones no se les da la importancia necesaria, o se confunden en el tedioso mapa de procesos, o en lo que en reingenieria llamariamos la pega burocratica, o no son tenidas en cuenta como deben ser para su aplicacion e implementacion, o se convierten en un cumulo de documentos para respaldar un proceso :\

Bueno de esto se trara la historia de Hoy.......

Realizando la auditoria de seguridad mensual, me entregan como ultimo objetivo el Portal Web para su respectiva revision. Encontrandome con la desagradable, nefasta o inconcebible situacion que al realizar los procesos de enumeracion del sitio me encuentro que la Aplicacion de administracion del Servidor Web Tomcat / Manager habia sido actualizado a su ultima version y nuevamente se cometia la Negligencia de dejar contraseñas facilmente descifrables o por Default ya que no cumplian con la Politica de cambio de contraseñas y custodio de claves. :\ (ESTO YA HABIA SIDO REPORTADO !!! e igual otras situaciones de riesgo encontradas ¬¬ )

Razon que me dio para centrar el Objetivo de mi informe en demostrar la importancia de la falla de seguridad humana (establecer contraseñas no robustas / default) y la gravedad de su explotacion.

Visualizandolo!!! Al aprovechar un atacante hasta donde podria llegar ampliando su superficie de ataque y afectando de manera integral toda la plataforma tecnologica de la Organizacion.

Resultados de la intervención.

Se procedió a realizar la revisión del sitio Web http://www.XXXXXXXXXXXX.com.co

A continuación, se presentan las evidencias encontradas de acuerdo a los objetivos de revisión establecidos anteriormente:

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.

Identificando estructura tecnológica del sitio Web.

Usando FOCA para identificar la estructura tecnologica del Portal Web

Realizamos una enumeración de nombres de usuario / password, encontrando como credenciales “admin / tomcat” como se muestra en la siguiente imagen.

Enumeracion de Sitio Web Con MetaSploit (Apache / Tomcat)

Brindándole al atacante la posibilidad de gestión del Apache Tomcat, como se Muestra en la siguiente figura habiéndose realizado el acceso al Tomcat Web Application Manager ( de hecho esto no deberia ser accesible a cualquier usuario, hasta el mismo favicon te da indicio de lo q atacas :\ )

Panel del Administrador Web Apache / Tomcat

Registrándose con las credenciales “admin / tomcat” en el Apache Tomcat/7.0.16


Entrando al Tomcat Manager Application

Logrando el acceso al Tomcat Web Application Manager, el atacante tiene la posibilidad de subir una Shell Remota o código malicioso para manipular no solo el sitio o los sitios Web que se estén administrando, si no tomar el poder del sistema operativo del servidor Web

Ya estamos en Tomcat Web Application Manager

Descripción del Sistema Operativo, Arquitectura y la versión del Servidor Web.

Como partida inicial posiblemente el atacante rapidamente haga uso de busqueda de Bugs en sitios especializados para diseñar su estrategia de ataque.

bugs "2.6.32.12-07-default amd64"

Con información precisa el atacante delineara su estrategia de ataque, para tal fin se prepara una Shell remote haciendo uso de Metasploit u otro mecanismo de acceso .

Debido a que algunas Shell presentan error y cierran la Sesión se busca la Shell adecuada para el Target (Objetivo Militar)

Preparando Shell

De esta forma visualizamos las Shell que se probaron para tener acceso no solo al sitio Web y su administración, si no al servidor que lo alberga. Se prueba con la Shell 4FrIEgk

Shell .WAR a Utilizar

Shell remote .WAR (4FrIEgk) generada y subida al administrador del sitio Web con sesión login iniciada. El inconveniente que se me presento al subir la Shell, era que mi equipo como atacante no se mostraba en internet como una Ip valida, teniendo que hacer uso de algún mecanismo interponiendo un router para abrir un servidor virtual, realizar una DMZ o exponer un equipo con direccionamiento de puertos y servicios para ser visto en internet como una Ip valida con comunicación directa al servidor afectado.

Shell subida a Tomcat / Apache

Aunque, la alternativa más apropiada que realice para no ser tan invasivo y mantener la Shell temporalmente decidí realizar la búsqueda y creación de una Shell remota .WAR (créditos de @crodallega creador de la Shell) realizar el deploy de la aplicación y tomar posesión del servidor Web, realizando la toma de evidencias necesarias de manera controlada y realizando el Undeploy de la misma para no dejar backdoor o puertas traseras disponibles que afectaran nuevamente el sitio Web.

De esta forma se realiza el Deploy de Shell.war

Realizando el Deploy de la Shell.war

Así se encontraría disponible para hacer uso de /Shell

Considero que hasta este punto en que hemos llegado podriamos definir el skill del atacante, debido a que un Defacer o Script-Kiddie se dedicara a realizar lo que mas le gusta como buen "Grafitero" a cambiar los index o paginas por default subiendo su imagen de 5up3r H4x0r 31173, o a su bien con un poco mas de curiosidad se dara cuenta que puede realizar un Mass Defacement y vanagloriarse de sus triunfos en sitios como Zone-H, contandole a sus amigos de sus maravillosos triunfos en la vida y crecimiento personal egolatra.

Ahora, si nos ubicamos en el rol de un atacante con un Skill mas estructurado, y haciendo uso de su expertis y conocimiento pensaria que puede realizar las siguientes acciones en el sistema en busca de su Objetivo.

1- El atacante explorara el sistema con la finalidad de ampliar su espectro de ataque, verificando que información es crítica y sensible para lograr su cometido.

Determinando el directorio actual

2- Identificando el Sistema Operativo y su versión.

3- Identificando el usuario que ejecuta el servicio web apache / tomcat con la finalidad de buscar metodos para escalar privilegios como todo el poderoso señor "root".

4- Determinando una grave y mala práctica de seguridad al ejecutarlo como root (administrador Linux / Unix), razon que le ha ahorrado una gran labor y ha logrado el "Santo Grial" de los hackers (xDDD viejos recuerdos :P )

5- Ahora, debe determinar como va atacar, quien esta en sesion, que procesos se estan ejecutando y servicios parar visualizar los sistemas de contenccion como, Firewall (Iptables), SELinux, AppArmor, sistemas de Integridad de Archivos (como TripWire, Xintegrity, AIDE, AFICK, YAFIC, Samhain, etc), Servidores de Logs (Syslog-ng), IDSs (Snort), etc.

Buscara ser lo mas anonimo y escondido posible (como se dice en mi tierra "Como Pedro por su casa").

6- Identificando usuarios conectados

Identificando servicios y procesos.

7- Determinando el Perfil del Servidor (con base en sus servicios y sof instalado)

8- Determinando las conexiones establecidas en el sistema (buscando conexion con otros servidores, o herramientas de contenccion)

Revisando puertos y conexiones activas.

9- Posteriormente revisamos la configuración de AppArmor (SuSE Linux no tiene SElinux por default)

10- Q y en q estado (nivel de ejecucion) esta arrancando en el sistema.

Identificando servicios al inicio y niveles del sistema.

11- Identificando demonios (daemons) instalados en el sistema

12- Identificando logs en el sistema (gran fuente de informacion para el atacante)

13- Listando estructura de directorios y archivos (explorando File Systems)

14- Revisando reglas de Iptables.

15- Buscando usuarios con privilegios SETUID y SETGID en ejecutables (determinando escalar privilegios o mecanismos de anonimato en el sistema haciendo uso de otros usuarios con permisos delegados)

16- Busqueda de archivos world-writable (modificables por cualquier usuario y semillas para incluir malware o scripts maliciosos, backdoor, rootkits, troyanos, etc)

17- Buscando archivos sin dueño y grupo (nouser -o –nogroup, esto tambien le permitira al atacante determinar si el sistema ha sido atacado o reflejar el nivel de conocimiento del administrador al permitir este tipo de usuarios)

18- Listando las variables configuradas del kernel (determinando el "Tunning" del sistema y midiendo el conocimiento del Sysadmin)

19- Revisando si el forward (reenvió) esta activado y enrutamiento (ampliando el espectro de ataque, y nuevos objetivos de ataque en redes nuevas).

20- Revisión del servicio de correo postfix (buscando fuentes de informacion valiosas para fuga de informacion critica sensible).

21- Revisión de configuración de autenticación del servicio POSTFIX con el servicio LDAP.

22- Revisión de los archivos de configuración del servicio OPEN LDAP

23- Archivo de Configuración phpLDPAdmin para administrar el OPENLDAP

24- Archivo de configuración Config.php

25- Revisión del archivo función databases.php de configuración de la Base de Datos (Postgres)

26- Se encuentran archivos de backup-ldap con credenciales quemadas en el comando ldapsearch con password Dxxxxxxxx11 (password enmascarado por confidencialidad de la informacion)

WOW!!!!!!!

No me habia dado cuenta de lo extenso de este articulo :\

Por lo tanto he decidido hacerlo en dos partes debido a que aun me qdan como cuarenta (40) evidencias que presentar :(

Asi, que si no te aburre......... o te parecio interesante........... espero continues con la segunda parte de esta historia de mis Tales From the Crypt