Blogs.update(“Unlearning Security”)

Estándar

Hola a tod@s!

Llevaba este post (y unos cuantos más) medio escrito en los borradores que tengo. Y hoy he dicho… Cojones! De hoy no pasa!

Comenzar algo casi siempre es bonito. Muchas veces lo hacemos con miedo, otras con ilusión, otras porque no quedan más cojones, y otras… Pues porque sí.

A todo el que me conoce un poco, y me pregunta por el blog, siempre le comento lo mismo. Que utilicé el blog para no tener que acordarme de ciertas cosas que me parecían y parecen interesantes. La cosa llegó a más y hoy, años después, todavía estamos aquí. Me gusta almacenar cosas! Soy muy 1.0!!

Hoy día lanzo la vista atrás, y la de gente que he tenido el honor de conocer gracias a este blog ha sido inmensa. Si no hubiese tenido ese pensamiento 1.0, donde andaría!

Es por ello, que cuando alguien “se atreve” a exponer al mundo sus ideas y conocimientos, hay que aplaudirlo. Y más aún cuando lo que publicas es bueno. Y ese es el caso de mi compañero y amigo Daniel Romero.

Lo conocí en la guarida de I64, y desde aquel día, no he parado de aprender de él. Un tío que se atreve con todo en materia de seguridad, pero en especial por las auditorías Web. Gracias a él, he llevado con éxito alguna auditoría que otra, y siempre que le he pedido ayuda, tanto en lo profesional como en lo personal, ha estado ahí para echarme un cable.

Aunque a simple vista no os suene de mucho, él fue el desarrollador de la primera versión de Marmita, por ejemplo. Testigo que han cogido los Monstruos (y no de feos) Francisco Oca y Manu Fernández, creadores de la FOCA, entre otras herramientas públicas y privadas.

Pues bien, Dani abrió un blog no hace mucho, y como no podía ser de otra forma, no ha parado de crecer, gracias a su contenido, y su continente. Artículos perfectamente redactados (no como los míos jaja) y bajo un contexto de formación, dan salida a verdaderas “joyas en materia de seguridad”, como los artículos dedicados a la explotación de vulnerabilidades, o los artículos dedicados a la ingeniería inversa en arquitecturas basadas en X86. Estos artículos, han dado pie a que se publiquen en packetstormsecurity. Como diríamos en mi tierra…. FITE!!!

Así que nada, actualizar los RSS, y aplaudamos a otro “grande”.

Gracias por compartir tus conocimientos Dani!

Saludos a tod@s!!

A la caza del mutante, parte IV

Estándar

Parte I

Parte II

Parte III

Parte V

Hola a tod@s!

En esta penúltima parte, vamos a realizar la búsqueda de MUTANT (MUTEX), a través de la herramienta volatility, y realizando para ello un análisis forense offline.

Para poder realizar esta búsqueda con éxito, el gran Andreas Schuster implementa un módulo para volatility, a través del cual,  y resumido en pocas palabras, realiza una búsqueda de la cadena Mut? En memoria paginada y no paginada.

Imagen 1.- Búsqueda de cadena Mut?

 El resultado es increíble, extrayendo no sólo la dirección de memoria y el nombre del Mutant, si no también información interesantísima, como por ejemplo el identificador de proceso (Client ID) que lo tiene referenciado.

Imagen 2.- Aplicación del módulo MutantScan en Volatility

En la próxima y última entrega, analizaremos la memoria offline, e intentaremos buscar evidencias, partiendo de los mismos principios que el estudio de Andreas Schuster. Lo único que vamos a cambiar esta vez, será la herramienta. En vez de utilizar Volatility Framework, se utilizará la herramienta WinDBG (Debugging Tools for Windows), y realizando las consultas de forma manual.

Saludetes!!

Referencias

Searching for Mutants

_KMUTANT Structure

Poolfind (MDSN)

Algunas notas sobre el exploit MS12-020

Estándar

Hola a tod@s!

Llevo unos 3 días informándome sobre la vulnerabilidad que afecta a todos los servicios de Terminal Server, y he aquí la información que puedo aportar al respecto de leer y releer scripts e información adicional.

Después de leer en mi RSS post similares con información relativa a exploits públicos, los cuales revelaban que habían conseguido ejecutar código remoto , me puse a buscar dichos exploits.

El único que he encontrado, a simple vista parece que lanza una shellcode escuchando en el puerto 4444 de la posible “víctima”. Nada más lejos de la realidad.

Estuve como 45 minutos de mi triste vida intentando buscar algún port de RDP en python sin éxito. Así que estuve leyendo cosas relacionadas con el proyecto FreeRDP, para al final, confirmarse la sospecha de que el script que se encuentra publicado en Pastebin es un puto fake como una catedral, y que me costó cerca de una hora de mi vida.

Imagen 1.- FAKE como una catedral

El siguiente script que probé,  es el ya archiconocido exploit chino, el cual lleva código robado de un partner de Microsoft. En un principio se habló de una filtración en ZDI, pero Microsoft ha acabado confirmando que se ha tratado de una filtración a través de uno de sus partners.

Este exploit funciona a la perfección, pero sólo en Windows 7. He probado en un Windows XP SP3 en Spanish, y no causa ningún efecto en el sistema, salvo que éste consume todos los recursos a nivel de CPU, permaneciendo al 100% en la ejecución del exploit.

Imagen 2.- 100 % CPU exploit ms12-020

Como he comentado antes, en Windows 7 y Windows Server 2008 funciona a la perfección, pero es posible mitigar en parte este ataque, configurando el equipo para que sólo permita la autenticación basada en NLA (Network Level Authentication). Cuando configuramos esta opción, a la hora de negociar una conexión RDP contra un Server 2K8 o un Wiindows Vista/7, se obliga a autenticarse primero al cliente, antes de que el equipo que hace las veces de servidor establezca una sesión completa RDP. Esta configuración, mitigaría cualquier ataque de denegación de servicio de forma automatizada, debido a la no disponibilidad de usuario y password. En el caso de que se conozca un usuario y password de RDP, se podría seguir explotando el fallo, y automatizándolo con scripts.

Sin duda alguna, el que me ha funcionado a la perfección tanto en Windows XP como en Windows 7, ha sido el paquete de demostración que ha publicado el descubridor del fallo Luigi Auriemma. El paquete de demostración lo tiene publicado en el advisory ampliamente comentado en otros blogs y foros de internet, y funciona perfectamente.

En el propio Advisory, Luigi explica que en algunas ocasiones, se hace necesario realizar varias veces el envío del paquete malicioso para que Windows suelte un bonito BSOD, así que dicho y hecho! Como hay publicados ya muchos exploits en Python, Ruby, C y demás lenguajes, yo para probar mis sistemas he decidido realizar un cutre script en BATCH (Con dos cojones ;-)) haciendo llamadas a netcat para que realice un envío del paquete malicioso.

Probando en Windows XP y Windows 7 con el paquete mágico, con sólo el envío de 4 paquetes los dos sistemas pintan un bonito BSOD. El cutre código (Of course) aquí:

 @echo off
 echo .
 echo ##################################################################################
 echo # MS12-020 cutre script BSOD Exploit
 echo # Juan Garrido http://windowstips.wordpress.com
 echo # Tested on XPSP3 And Windows 7 32 bits
 echo # Windows 7 With NLA (NetWork Level Authentication) not Working
 echo # See more http://technet.microsoft.com/en-us/security/bulletin/ms12-020
 echo ##################################################################################
 if "%1"=="" GOTO msg
 set _IP=%1
 set _Netcat=nc.exe %_IP% 3389 ^< termdd_1.dat
 :RUN
 FOR /L %%i IN (1,1,5) DO %_Netcat%
 GOTO end
 :msg
 echo ERROR: Specify a hostname or IP address.
 echo i.e. %0 HOSTNAME
 goto end
 :end
 pause
 

Salu2 a tod@s!

 

Referencias

https://github.com/FreeRDP/FreeRDP

http://pastebin.com/fFWkezQH (FAKE como una catedral)

http://blogs.technet.com/b/msrc/archive/2012/03/16/proof-of-concept-code-available-for-ms12-020.aspx

http://pastebin.com/jzQxvnpj (Exploit funcional Windows 7)

http://technet.microsoft.com/en-us/library/cc732713.aspx (Network Level Authentication)

http://aluigi.org/adv/termdd_1-adv.txt (Advisory explicando la vulnerabilidad MS12-020)

Mentiras, y gordas…

Estándar

Hola a tod@s!

Estaba leyendo el periódico, la gaceta, el 20 minutos y demás publicaciones, como cada día hago en la oficina, de 9:00 a 13:00 eso sí, y como buen “security researcher”, cuando leo la siguiente noticia…

González Sinde gastó 56.404 euros del Ministerio de Cultura en un proyector para la Familia Real

Y digo… Coño, vaya pastizal que se han gastao en el proyector de los cojones! Las porno se tendrán que ver de puta madre no?

En fin, después de meditar durante un buen rato sobre cómo sería ver una porno en un aparato de tales dimensiones y capacidad técnica, estuve footprinteando un poco a ver si podía buscar más info. Y me encuentro con lo siguiente:

Coño que es verdad!

Que se han gastao la pasta en un proyector para los príncipes y mi hermano en paro!

Acto seguido, empecé a pensar sobre el país en que vivimos y en qué clase política nos “dirige”… A lo único que llegó mi perturbada mente es a pensar en improperios varios que ni yo mismo conocía….. Cuando pienso…. CUANTO COSTARÁ EL BICHO ESTE EN EBAY??

Imagen 1.- El bicho…. NUEVO

Link al bicho

Estoooo…. Recapitulemos…..

42.000 pavos de diferencia???? WFT??

Así que se me ocurren varias opciones…..

Opción 1.- Que cinematografía pereira son unos caros de TRES PARES DE COJONES

Opción 2.- Que traer un BICHO de estas características cueste en aranceles e impuestos varios 42.000 pavos menos el beneficio que tendrá que sacar la pobre Cinematografía Pereira

Opción 3.- Que la señora ministra SINDE, a la cual le doy un afectuoso saludo desde aquí, utilice esa diferencia para arreglar los posibles fallos que pueda tener la Web de los premios GOYI.

Opción 4.- Que se hayan equivocado, lo cual dudo mucho, ya que la película Mentiras y Gordas, ideada y guionizada por nuestra querida EX-Ministra Sinde, se otorgase ella misma (cuñao!!), una adjudicación en “ayudas”, por valor de 1 kilotón de euretes….

Cualquier día me compro una guitarra, y me voy a conocer mundo….

Pero qué coño….. Ya tengo una guitarra!!

Salu2!!

A la caza del mutante, parte III

Estándar

Parte I

Parte II

Parte IV

Parte V

Esta vez, vamos a utilizar las herramientas Process Explorer y Handle, de Sysinternals, para la correcta búsqueda de Mutants (MUTEX) en el sistema.

Siempre que un objeto se crea o se abre, una referencia hacia éste, es creada. Esta referencia, llamada HANDLE, estará asociada con un proceso, a través de una tabla llamada HANDLE TABLE.

Process Explorer, permite, entre otras características, el poder visualilzar estas entradas a través de su interfaz gráfica. Para ello, tendremos que activar el panel inferior, y que sólo nos muestre la referencia.

Imagen 1.- Mostrar handle en Process Explorer

Una vez que el panel inferior se encuentra activo, es fácil encontrar las referencias a los MUTANT (MUTEX), tal y como se muestra en la siguiente figura:

Imagen 2.- Mutant visualizado con Process Explorer

Si se necesita automatizar el proceso en forma de línea de comandos, la herramienta Handle, de Sysinternals, permitirá extraer todas las referencias, incluyendo las del directorio \BaseNamedObjcts. Para ello, habrá que pasarle el parámetro –a, para que incluya todos los handle. Si se desea que pregunte por el Security Descriptor, incluiremos también el parámetro –u.

Imagen 3.- Mutant descubierto a través de Handle

En el próximo post, realizaremos esta tarea, utilizando para ello volatility framework, en un análisis offline.

Saludetes!

 

A la caza del Mutante. Parte II

Estándar

Parte I

Parte III

Parte IV

Parte V

La forma más sencilla de buscar mutantes (MUTEX) en nuestro sistema y en tiempo real, es utilizando las herramientas de SysInternals. Para ello, la primera herramienta que utilizaremos será WinOBJ, la cual nos permitirá visualizar, de forma jerárquica, el manejador de objetos (Object Manager) de Windows. Cada recurso de Windows, se encontrará catalogado en un espacio de nombres. Un recurso puede ser la memoria RAM, una entrada de registro o un directorio, por ejemplo.

Cada objeto administrado por el Object Manager tendrá una estructura determinada. Bajo esta estructura, se encontrará un nombre que identifique al objeto en sí (Object Name) y un Security Descriptor, el cual aportará información sobre los derechos de acceso del objeto.

Los MUTANT (MUTEX),  entre otros objetos, se encuentran catalogados en el directorio (Object Directory) \BaseNamedObjects. Dentro de este directorio, podremos realizar consultas gráficas para encontrar fácilmente Mutex maliciosos.

Imagen 1.- Acceso a objetos MUTANT a través de WinObj

A través de esta utilidad, se pueden realizar consultas al Security Descriptor, para conocer qué derechos de acceso y dueño, tiene este objeto.

Imagen 2.- Permisos de Objeto MUTANT

En la próxima entrega nos centraremos en la búsqueda de estos objetos a través de otras herramientas de Sysinternals como Process Explorer o bajo línea de comandos con Handle.

Referencias

Object Manager (PDF)

Object Manager (PPT)

Object Manager (Wikipedia)

A la caza del Mutante. Parte I

Estándar

Parte II

Parte III

Parte IV

Parte V

Un mutante, es como Windows llama de forma común a un Mutex. Un mutex ayuda a la hora de acceder a los recursos del sistema, o como mecanismo que ayude a que sólo una instancia de la aplicación se encuentre corriendo en el sistema.

Las aplicaciones pueden crear mutantes con un nombre específico o con un nombre en particular. Si una segunda instancia de la aplicación es ejecutada en el sistema, ésta intentará crear un mutex sin éxito, lo cual obligaría a la aplicación a terminar.

A menudo este tipo de técnicas son utilizadas por malware de diverso tipo para prevenir múltiples infecciones de una misma cepa. Y a menudo también nos podemos encontrar con aplicaciones que crean Mutex con la finalidad de proteger al sistema operativo. Entre los diferentes mecanismos de protección que puedan ofrecer, uno de ellos es la creación de Mutex a priori utilizados por Malware. Con esto intentan prevenir que algún tipo de virus pueda ejecutarse bajo esta técnica.

Utilizar la búsqueda de Mutex maliciosos como única técnica de detección de Malware es algo muy pobre, debido a que es muy fácil modificar este parámetro. Una prueba de ello lo tenemos en el configurador del archiconocido Poison Ivy.

Imagen 1.- Nombre de Mutex generado automáticamente por Poison Ivy

Es por ello que, unido a mi morbosa curiosidad, y dado el incremento de este tipo de técnicas en la programación de Malware, que dedicaremos 5 entradas sobre las técnicas y herramientas existentes para buscar con éxito mutantes (MUTEX) creados por aplicaciones.  Para ello, iremos realizando las operaciones desde lo más fácil, a lo más difícil, siempre desde mi punto de vista. La búsqueda de Mutex las realizaremos desde el punto de vista de:

  • Herramientas de Sysinternals (Análisis en Vivo)
  • Volatility Framework (Análisis Offline)
  • WinDBG (Debugging Tools de Windows) (Análisis Offline)

Nos vemos en la segunda parte!!