Linux Week y MS10_002

Hace unas semanas, me invitaron a dar una charla en la quinta edicion de Linux Week que se realizo en la semana del lunes 15 hasta el viernes 19 de marzo en las instalaciones de la PUCP. Desde aqui quiero felicitar a los organizadores y agradecerles por la invitacion y el buen trato.

El tema que toque en esa oportunidad fue ataques de lado cliente en donde basicamente hablamos sobre las tendencias de los atacantes, se expuso algunos de los "ataques" mas frecuentes que vienen ocurriendo para el robo de credenciales como lo son el Phishing y el Pharming. Lo ultimo, para que los asistentes tengan conciencia de las consecuencias si no se tiene algunos criterios minimos al momento de ingresar a una url no conocida o aceptar un archivo posiblemente malicioso.

Terminamos hablando un poco sobre los relativamente recientes ataques contra Google, la denonimada "Operacion Aurora". Fue en este ultimo punto donde realice una pequeña demo donde explote la vulnerabilidad antes mencionada, una vulnerabilidad de corrupcion de memoria que afecta a Internet Explorer
en sus versiones 6 y 7. Mediante esta, un atacante crea un HTML con un codigo javascript malicioso, que al ser interpretado por un navegador afectado, permitira tomar control total del equipo. Para probar el exploit, use Metasploit.

Una vez explotada la vulnerabilidad, el payload utilizado dependera de la vida del proceso asociado. Esto es debido a que una vez llamada la shellcode, la sesion meterpreter es cargada en el espacio de memoria asignado al proceso explotado, en este caso, iexplorer.exe. Si el navegador se cuelga por el ataque o si la victima simplemente deja de navegar y cierra el Internet Explorer, se libera la memoria, ergo, perdemos la sesion.

Para evitar este escenario, metasploit nos facilita la vida con la funcionalidad de migrar de proceso. Podemos automatizar esto escribiendo un script para que una vez conseguidos los privilegios, creemos un nuevo proceso y migremos a este. Tan solo seteamos el valor AutoRunScript.

Aqui les dejo el script utilizado



Ah, y la presentacion.

Client Side Attacks- LinuxWeek 2010

View more presentations from mvelazco.

Saludos!

MVelazco.

P.D: Tildes omitidas intencionalmente

GPEN versus GCIH : Una pequeña, pero, IMPORTANTE DIFERENCIA

En un medio con el nuestro (Perú) donde las certificaciones en tema de seguridad estan en la etapa 0 (apenas algunos se han certificado y no es exigencia para realizar labores relacionadas), resulta importante hacer siempre precisiones y dado el prestigio del entrenamiento de SANS y las certificaciones de GIAC, es importante comprender algunas diferencias y no dejar que nos den gato por liebre.

En diás pasados se aperturó una lista de correo para un grupo de personas con certificaciones de GIAC o alumnis de SANS respecto a ciertos cursos (relacionados los 3 a penetration testing) y luego se aperturó a los certificados y alumnis de manejo de incidentes.  Esto dió lugar a unas opiniones de los creadores, gestionadores e instructores de estos cursos de las cuales se puede extraer :

"504 is more geared to incident response than penetration testing." -Ed Skoudis
(504 es el código del curso que conduce a la certificación GCIH)

"Thanks for including 504.  I took 504 and then tried my new skills out by
attempting an internal pen test against my environment (with written
permission, of course!) and found I was lacking.  Although I had the tools
and some skills, the 560 class brought it all together for me as far as a
formal procedure of defining a scope and compiling a report.  I think 504
and 560 should be taught together in a two-week SANS Ultra Brain Dump Uber
Course.  They certainly complement each other. "
- Tony K. Reusser
(560 es el código del curso que conduce a la certificación GPEN).

4 Nuevos OSEH (Open-Sec Ethical Hacker)

El fin de semana último realizamos otro curso de ethical hacking donde enseñamos las técnicas de ataque que aplicamos en los servicios que realizamos.
Es interesante como los participantes poco a poco van engarzando las diferentes etapas de una penetración de forma casi natural.
Tuvimos especial énfasis en temas de hacking de aplicaciones web, incluso, Camilo Galdos (Dr. White) participó dando una charla al respecto.  Obviamente, los participantes quedaron sorprendidos por su juventud y capacidad.
También, tuvimos otra vez un laboratorio en particular sobre hacking de redes wifi.
Así mismo, los participantes pudieron analizar los hechos del "defacement" que sufrimos, aprender a diferencia un verdadero defacemente de un "defacemente", conocer sobre los autores y complices, los "motivadores", analizar "evidencias" públicas y comprender como no siempre las cosas son lo que parecen.
Al final, se llevó a cabo la evaluación con el examen de OSEH que nos permite contar con 4 personas más que han certificado el contar con un nivel elemental en temas de ethical hacking (ya llevamos 30 certificados).
A continuación, algunas imágenes :

Metagoofil enhanced

Como verán, estamos siendo más productivos con el blog (será porque se acerca el 2012 y queremos ser famosos ? jejeje...).

Siempre hemos dicho en presentaciones, en conversaciones con los clientes y en los entrenamientos que para nosotros usar herramientas Open Source es vital porque podemos modificarlas según necesitemos sin esperar que el proyecto que las origina lo haga y seria peor si se tratáse de herramientas comerciales o simplemente gratuitas (pero, a cuyo código fuente no tenemos acceso).

Una de las primeras herramientas que modificamos para manejar adecuadamente algunos cambios en Google y algunas formas de búsqueda es metagoofil, herramienta desarrollada y mantenida por Edge-Security Research y la cual hemos modificado "ligeramente" (incluso, los remito al web de ellos para revisar la excelente documentación creada para esta t00l http://www.edge-security.com/metagoofil.php )

Por favor, como siempre les decimos a todos : descarguen esta versión, revisen el código, asegurense que no tiene un troyano o similar y luego de eso, usenla.

El programa esta comentado para un mejor entendimiento.

Descarga : Metagoofil.py

Hiding Tracks with .bash_profile

 Buscando maneras en las que un atacante puede minimizar sus huellas en un sistema *nix comprometido, encuentro, gracias a MUrizar, con una simple y eficaz forma de hacerlo.

Al añadir una línea al fichero .bash_profile (tambien funciona en .bashrc), podemos lograr que todo comando precedido de un espacio en blanco, no sea guardado en el historial de comandos del usuario (.bash_history).

export HISTCONTROL=ignorespace

Esto puede funcionar en un escenario donde se quiera evitar el uso de rootkits o zappers para borrar evidencias. Hay otras formas de hacerlo pero me gustó esta por su simplicidad. Lo importante es no olvidarse de añadir el espacio en blanco !

Desde luego, esto no servirá de nada para ocultar la presencia del atacante si el admin utiliza comandos como w, who, users, last y lastlog que mostrarán información sobre usuarios y sus logins. Una manera de evitar esto sería modificando los ficheros parseados por estos comandos para mostrar su output:

/var/run/utmp
/var/log/wtmp

Tal ves eso para otra ocasión,


MVelazco

Update 1

Conversando con WCuestas y buscando evitar añadir un espacio en blanco antes de todo comando ingresado, me sugiere una forma mucho más práctica de realizar la misma tarea sin tener que hacer cambios en ningún archivo.

Nos enfocamos en 2 variables de entorno de bash, $HISTSIZE y $HISTFILE. Cada una guarda el valor del número de líneas guardados en el historial y el fichero donde se guardará el historial, respectivamente.
Una imagen vale más:

Bien, entonces jugando con esas variables podemos conseguir que en una nueva sesión, no se guarde historial de comandos ejecutando lo siguiente:

HISTSIZE=0; export HISTSIZE
HISTFILE=/dev/null; export HISTFILE

Lo interesante es que en la próxima sesión, las variables serán cargadas según lo dictado en .bashrc, así que para el admin todo esto es transparente, aqui no paso nada!.

Enumeracion LDAP

Hola a todos. Lamentablemente el trabajo hace algo difícil el postear nuevo contenido en este blog, sin embargo, y después de un buen tiempo, me siento a escribir un nuevo post para las personas que de cuando en vez sintonizan este canal.

En esta oportunidad quiero enfocarme en un tema que no siempre aparece en un proyecto de Ethical Hacking, tal es el caso del password cracking. Voy a tocar algo de teoría (bibliografía: www.google.com), definir un probable escenario y dar algunos tips para obtener usuarios válidos dentro de un dominio o un servidor LDAP.

Primero vamos a definir el término "password cracking", según wikipedia:

El password cracking es un proceso informático que consiste en descifrar la contraseña de determinadas aplicaciones elegidas por el usuario. Se trata del rompimiento o desciframiento de claves (passwords).

Un concepto bastante conocido, sin embargo, muchos se preguntarán para qué sirve en un proyecto de Ethical Hacking. Pues para auditar la robustez (o la falta) de políticas de passwords utilizadas en una organización. Como toda etapa del EH, busca tomar evidencias para emitir una recomendación de mejora. En este caso, por ejemplo, si nos encontramos con el password "123456" en un servicio importante la recomendación es implementar una política de passwords que tenga en cuenta entre otras cosas la longitud, el tiempo de expiración, no utilizar palabras de diccionario, no usar cumpleaños, etc. Un buen recurso aquí: www.sans.org/security-resources/policies/Password_Policy.pdf
También pueden realizar una búsqueda con los términos: "password policy", "password policy standard" en nuestro amigo google, seguro dará buenos resultados.

Ahora el escenario. Estamos realizando un EH interno y llegamos a la etapa de password cracking. El cliente ya eligió a qué servicios se hará el test, tenemos un servidor de correos y un servicio de intranet. Tenemos a nuestra disposición varios diccionarios de passwords de varios temas y en distintos idiomas. El problema surge: Si queremos que el test tenga los resultados esperados, ¿qué diccionario de usuarios utilizar?.


Es aqui donde nos aprovechamos de un recurso muy utilizado en redes basadas en Windows, el Active Directory. El directorio activo es la implementación de Windows de LDAP (Lightweight Directory Access Protocol) que contiene un árbol jerarquizado de objetos categorizados. Permite a los administradores de red realizar tareas como establecer políticas , desplegar programas en muchos ordenadores y aplicar actualizaciones críticas a toda la organización. Para nuestros fines, nos centraremos en sólo un tipo de objeto contenido en el árbol: los usuarios.

En resumen, para crear el diccionario vamos a enumerar los usuarios del directorio activo o del servidor LDAP haciendo consultas al árbol y de esta forma armar una base de datos con los nombres de usuario registrados para lanzar el test de password cracking. Tenemos diferentes estrategias para lograr el objetivo de acuerdo al tipo de evaluación:

Black Box.

• En este caso intentamos una conexión anónima al servidor LDAP, para el caso de controladores de dominio en Microsoft Windows 2000 lo más probable es que podamos realizar esta enumeración anónima sin problemas.
• Otra estrategia es escuchar el tráfico en la red para poder obtener un usuario y contraseña válidos y con estas credenciales realizar la enumeración LDAP.
• Además es posible extraer credenciales válidas de diversas formas, como por ejemplo mediante las credenciales de un sistema transaccional a la base de datos, y otras más.

Gray Box y White Box.

• Podemos utilizar las credenciales de un usuario del dominio, o de una cuenta de correo.
• En el 90% de organizaciones en las que he participado en un EH interno la salida a internet es filtrada por medio de un proxy a manera de aumentar la velocidad (a traves de la cache) y restringir a los usuarios según sus privilegios (utilizando el directorio activo). Así que también se puede utilizar estas credenciales.

Pasos a Seguir.

Primero es necesario identificar al DA:

nmap -p389 --open 10.0.0.0/24

En el caso del controlador de dominio el servidor LDAP suele estar en el servidor que utilizamos como DNS.

Una vez identificado el servicio necesitamos hacerle las consultas, pero cómo?? En este caso utilizaremos la herramienta ldapsearch que viene con el paquete ldap-utils. Ok, aprendamos a usar ldapsearch:

man ldapsearch

Luego de leer la pagina del man, buscar ejemplos en google y preguntarle al colega :P, obtenemos el comando.

ldapsearch "objectclass=user" -h 10.0.0.43 -b "dc=organizacion,dc=com,dc=pe" -D "usuario@organizacion.com.pe" -w "passw0rd" > ldapdump.txt

"objectclass=user" Para determinar que solo queremos consultar a objetos del tipo "user"
-h La ip del Directorio Activo
-b La base del directorio LDAP
-D El usuario con el que nos conectamos al servidor
-w El password del usuario
> Dumpeamos todo en un fichero de nombre ldapdump.txt



Wow tenemos un archivo con 64903 lineas! Que buscamos??. En la imagen observamos la entrada de un usuario (alguna información fue cambiada y otra escondida por obvias razones). Ldapsearch nos retorna mucha información sobre el usuario como grupos a los cuales pertenece, la última vez que se logueó en el dominio, quota de la cuenta del correo, etc, etc. Pero a nosotros sólo nos interesa el nombre de usuario. Ese dato se encuentra en la variable "sAMAccountName". Ese es el usuario con el que se loguea a los servicios.

Aprovechamos el poder de nuestra shell bash para cortar el archivo y sólo sacar los usuarios del archivo de texto utilizando los comandos grep, cut y sort.

cat ldapdump.txt | grep 'sAMAccountName' | cut -d' ' -f2 | sort > usersDominio.txt

En la imagen se puede ver el resultado.



El resultado, un fichero de 888 lineas donde cada linea es un usuario.

Done, contamos con una base de datos de todos los usuarios registrados en el dominio. Ahora es momento de utilizar la herramientas de password cracking con la que se sientan más cómodos. Recomiendo Hydra.

Esto es todo, espero les haya gustado, y no duden en dar comentarios/dudas/críticas/quejas.

Gracias a CCuadra por la revisión,

saludos

MVelazco.

Plan de Continuidad del Negocio

Un Plan de Continuidad del Negocio, garantiza la no interrupción de procesos críticos dentro de un negocio. En tecnologías de información, se maneja el mismo concepto y es hacia dónde vamos a orientar el desarrollo del presente tema.

El desarrollo de un Plan de Continuidad del Negocio o BCP (por sus siglas en ingles, las cuales significan Business Continuity Plan), debería contemplar 5 aspectos básicos como parte de su ciclo de vida, estos son:

1. Análisis.
2. Diseño de la solución.
3. Implementación.
4. Pruebas y aceptación del Plan.
5. Mantenimiento.

• El análisis consiste en identificar los procesos críticos de TI que mantienen en correcto funcionamiento el desarrollo de las actividades de la corporación en general, entendiéndose que en la nueva teoría de administración de empresas, el Área de TI que antes era un departamento de apoyo a la toma de decisiones y soporte a las actividades empresariales, ha pasado a ser una de las áreas funcionales en todo negocio, así como lo es Recursos Humanos, Logística, Finanzas o Ventas.

• En lo referente a Diseño de la Solución vamos a detallar como proteger estos procesos que identificamos en la fase anterior, en la medida de lo posible se debe intentar mantener en un funcionamiento “aceptable” los procesos críticos del negocio que son apoyados en la infraestructura informática de la empresa. En esta etapa se elaboran los Planes de Recuperación ante Desastres o DRP (Disaster Recovery Plans) por sus siglas en ingles. Debe entenderse como desastre toda situación que hace compromete la seguridad de la infraestructura informática o incluso puede llegar a convertirla en no disponible. Los desastres se pueden clasificar principalmente en: Desastres naturales, que por su misma naturaleza, son casi imposibles de predecir y a la vez de afrontar. Por otro lado tenemos desastres a causa de un error humano, estos últimos en la mayoría de los casos son más fáciles de reparar.

• La Implementación es probablemente lo más difícil ya que el impacto que puede tener el implementar un BCMS (Business Continuity Management System) – Sistema de Administración de Continuidad del Negocio – es complicado ya que además de involucrar personal para invertir tiempo en el desarrollo del mismo, puede tener un impacto económico considerable dependiendo del alcance y es aquí en donde debemos de preguntarnos: ¿Cual es el impacto de la caída de algún servicio informático critico para la organización y hasta donde nos podría costar la no disponibilidad del mismo? Por ejemplo, una empresa de seguros que no tiene la base de datos de contratos de clientes y coberturas al momento que un cliente es víctima de algún siniestro se puede convertir en un problema bastante grande que incluso podría tener implicancias legales, mucho peor si se trata de un siniestro que pone en riesgo la vida de una persona como lo sería un seguro de salud. Si un cliente sufre una amenaza de infarto y alguien solicita ayuda, puede resultar en el fallecimiento del cliente. Probablemente sea un caso excesivo sin embargo no es una situación imposible de presentarse para el tipo de negocio que hemos puesto de ejemplo que es una empresa de seguros.

• En cuanto a las pruebas, estas deben ser rigurosas, asegurando que realmente la estrategia de BCP es medible bajo dos puntos de vista: Retribución de la inversión y Garantía de Continuidad. Es aquí en donde se muestra el valor real que tienen los DRP creados en la segunda fase. Por último hay un tema de aceptación que debe ser sostenido ante un directorio con los “Tomadores de Decisión” de la corporación.

• Finalmente, como cualquier sistema, este debe tener un proceso de mantenimiento continuo, que garantice el correcto funcionamiento del mismo además de que la estrategia inicial no haya cambiado y de ser este el caso, el mantenimiento hará que la estrategia sea actualizada. Conforme el Área de TI vaya cambiando, así mismo se deberá hacer ajustes en la estrategia inicial de tal manera que esta siga teniendo un valor real para la organización.

El tema de BCP en cuanto a TI se refiere va mas allá de tan solo redundancia en servicios, replicas de bases de datos o ejecución de copias de respaldo, ya que hablamos de copias de respaldo, es interesante ver como siempre nos estamos preocupando de hacer copias de respaldo de la información, sin embargo las guardamos en el mismo lugar en donde queda nuestra oficina. Si ocurriera un incendio en el edificio en donde se ubica esta oficina no nos serviría de nada, cierto? La información se quemaría así como los demás bienes de la empresa, dejándonos imposibilitados de poder restaurarla al adquirir nuevos equipos, es por esta razón que una de las buenas prácticas nos dice que las copias de respaldo no se deben almacenar en el mismo lugar físico en donde se encuentra la empresa ni cerca. En algunos países esta recomendación es llevada a cabo de una forma interesante y es que se hacen alianzas de protección de información, las cuales consisten por ejemplo en que la empresa A almacena las copias de respaldo de la empresa B, cabe resaltar que por mas relación de confianza que haya entre dichas empresas siempre hay consideraciones que se deben tener como por ejemplo intercambiar las medias encriptadas y en cajas que utilicen precintos de seguridad inclusive el uso de una caja fuerte no estaría de más.

Para terminar, enfoquemos el tema de un BCP no solo como una manera de mantenerse a flote sino como una estrategia que mantiene la buena reputación de nuestra organización o acaso nos gustaría que nuestros clientes se quejen de la falta de disponibilidad de nuestros servicios porque algún sistema de información falla o no está disponible en el momento requerido?