Mensajes

Parece ser que nos tiraron el video que sale en ADSLZone: Así que aquí teneis una versión mejor:

[youtube=640,360]http://www.youtube.com/watch?v=_YK1WFZF790[/youtube]

Otros juegos como Disgaea 3: Absence of Justice
http://3mf.ru/d/scr/video2.png
http://3mf.ru/d/scr/videotest.png

También desde hace un tiempo el emulador carga varios homebrews como ScoggerHD:
http://www.youtube.com/watch?v=Ow7VnwffzBI

Sé que no deja de ser un juego cutre en 2D de PSN, pero hasta hace pocos meses solo teníamos un triangulo de colores estatico. El salto ha sido enorme y además recientemente se han unido bastantes desarrolladores al proyecto: https://github.com/DHrpcs3/rpcs3
Estamos preparando una serie de tests automatizados para acelerar el desarrollo de RPCS3 (y otros emuladores de PS3, y probablemente también Xbox360 dado que comparten arquitectura en parte).

Pero vamos, aun queda bastante trabajo para que funcionen juegos AAA de la talla de FFXIII o GTA5. Este juego y otros varios que hemos encontrado esta semana nos han pillado por sorpresa, y van bastante más rápido de lo esperado pese a estar siendo emulador con un intérprete sin optimizar.

Pronto sacaremos un recompilador de la PPU (bueno, sacará [DH] el autor original, yo no tengo huevos a meterme a eso hasta que no haya un prototipo hecho) que acelerará la emulación lo suficiente como para trabajar con demos más complicadas e implementar más comandos para la tarjeta gráfica de la PS3.

[VirtualDJ Pro/Home v7.4]

Aunque corrigieron la vulnerabilidad que dije, resulta que acabo de encontrar otra más en la última versión del programa (VirtualDJ Pro/Home v7.4). Vuelve a ser un buffer overflow por culpa de los tags ID3. Se produce cuando el programa intenta buscar automáticamente una caráctula en Google Imágenes para un archivo MP3 malintencionado. El buffer que contiene la request a Google ("http://images.google.com/images?q=[Tag_ID3_'Título]") puede resultar "pequeño" y dado que el programa no comprueba si el título que se va a meter después de "?q=" es demasiado grande, pues pasa lo que pasa.


Si quereis más info podeis entrar aquí:
http://functionmixer.blogspot.de/2013/04/virtualdj-prohome-74-buffer-overflow.html

Y la demo la teneis aquí:
[youtube=560,315]http://www.youtube.com/watch?v=Yini294AR2Q[/youtube]


PD: He puesto el mensaje en este hilo porque en la demo vuelvo a enseñar como bypassear los filtros de caracteres que es al fin y al cabo de lo que iba el hilo al principio.

Saludos!!

EL TEMA DE LOS DICCIONARIOS PARA CRACKEADORES NUNCA ME PARECIERON EFECTIVOS..... PARA MI UN PROGRAMITA o DETECTA LA SEÑAL Y LE DETECTA LA CONTRASEÑA o TRATAMOS CON PROGRAMITAS PARA LA JILADA DEL MONTON QUE NO TENDRA RESULTADOS POSITIVOS 

¿Has leido lo que he escrito antes? Esto no es un diccionario genérico A-Z, 0-9 caracteres... Hay algunos routers de estas empresas en los que reaver no funciona y la única manera es ataca la key WPA2. Hasta hace un mes la mejor manera para romper las claves del EasySetupAssistant tardaba 6000 años, con este programa tardará 24 horas en el peor de los casos con una CPU mala de cojones. En un caso medio tarda 2 horas.. Y si sabes información como el "día" en que fue instalado el router 4 segundos. La única forma de mejorar el ataque sería romper directamente  WPA y WPA2 cosa que es casi imposible...
Leete la información antes de soltar gilipolleces y si tienes intención de responder, asegúrate de pulsar la tecla "Bloq Mayus" otra vez.

[http://functionmixer.blogspot.com.es/2013/03/vulnerabilidad-virtualdj-prohome-73.html]

Hola! No he entendido muy bien eso XD..
Pero he escrito un post en mi blog sobre la vulnerabilidad y como explotarla:
http://functionmixer.blogspot.com.es/2013/03/vulnerabilidad-virtualdj-prohome-73.html

Me refiero es que hay dos buffers que toman el valor del título del MP3:

• El primero almacena todos los caracteres ASCII imprimibles del título (si no lo son, mete un RETN delante "por si acaso"). Este primer buffer no es vulnerable
• El segundo, de longitud 4100, almacena caracters ASCII de la A a la Z que contenga el título y es en este donde esta el problema.

...el resto lo explico en el artículo de antes y mi mensaje anterior. 
Incluyo el código también así que puedes explotarlo y con algun depurador ver lo que sucede.

Todo solucionado.
Aprovechando que EDI apuntaba a un buffer que contenía todos los bytes (y no solo las mayúsculas), me bastó con buscar una dirección de la memoria representable con letras mayúsculas que contuviese un CALL EDI.

Al final lo encontré en 0x44465346 ("FSFD"), que correspondía en este programa a "urlmon.dll". Luego me encontré con que el cabrón del programa metía un 0xC3 (RETN) delante de cada byte no imprimible en ASCII, así que tuve que hacer algunas cosa más, pero bueno fue fácil.

El resultado es éste (podeis considerarlo el PoC de un 0day si quereis):

[youtube=560,315]http://www.youtube.com/watch?v=PJeaWqMJRm0[/youtube]

[bytes de la 'A' a la 'Z' en el EIP]

Muy buenas! Acabo de encontrar en un programa un buffer overflow algo gracioso:

Se leen todos los bytes de un archivo y se guardan en un buffer en la dirección 0x088399C8. Hasta ahí todo bien. Luego se comprueban cuáles de todos esos bytes están en el rango 'A'-'Z' y si es así, se meten en un segundo buffer de caracteres en el stack. Si rellenamos el archivo con muchos bytes 'A'-'Z', este segundo buffer peta y acabamos con varios registros modificados, incluido el EIP.

El problema es cómo desviar la ejecución a la dirección que me interesa si solo soy capaz de meter bytes de la 'A' a la 'Z' en el EIP, es decir, solo puedo lograr cosas como 0x41414141, 0x41424344, 0x534E4F50, ... En el EAX o ECX creo que aún podría hacer un apaño para que cogiese un valor arbitrario.
¿Alguna idea de por donde seguir? ¿Es esto una limitación imposible de saltar al diseñar un exploit?

Tan solo bastaría lograr de alguna manera un salto a 0x088399C8 para lograr la queridísima "ejecución de código arbitrario", por desgracia 0x08, 0x83, 0x99 y 0xC8 no son "letras mayúsculas".

Que pena no tener uno de estos routers para poder probar esta aplicacion.

Puedes probar también con routers D-Link o Linksys con el programa que postee en el otro hilo. Ambos funcionan de forma muy parecida.


Por si no queda claro como usar el programa que he posteado al comienzo del hilo, he hecho un tutorial.
[youtube=640,360]http://www.youtube.com/watch?v=sJDuDWIhdGc[/youtube]

Por si no queda claro como usar el programa que he posteado al comienzo del hilo, he hecho un tutorial.
[youtube=640,360]http://www.youtube.com/watch?v=sJDuDWIhdGc[/youtube]

[Linksys]

Al igual que hice con los routers de TP-Link, aquí tenéis el programa final para generar los diccionarios para estos routers (Linksys y D-Link). Ejecutad Pure-GenKeysFinal y seguid las instrucciones. Introducid la BSSID del router o la fecha de lanzamiento al mercado del router si la sabéis como argumento para obtener un diccionario reducido específico para el modelo del router que estáis atacando, eso puede reducir el tiempo de crackeo a unos pocos minutos. Si no sabéis ninguno de estos datos, no metáis argumentos y listo.  

Descarga: http://www.mediafire.com/download.php?i2055rwj1pt8zn7
Si quereis más velocidad aún, no protestéis y enviadme la BSSID y fecha de fabricación de los routers que he puesto abajo.  




Post original:
En lo que recopilamos la lista de modelos, BSSID y fecha de fabricacion de los routers TP-Link, he estado desensamblando asistentes de otros routers solo por curiosidad. Y traigo muy buenas noticias: Algunos routers de Linksys y D-Link usan un sistema casi idéntico para generar las claves. Realmente podría copiar y pegar el 90% de lo que escribí acerca del fallo en los routers TP-Link, así que pondré sólo lo más relevante y si queréis más información podeis leer el hilo original. El Linksys EasyLink Advisor y el D-Link Quick Setup Wizard sufren el mismo fallo al estar basados en Network Magic, un software creado por Pure Networks (que pertenece a Cisco/Linksys). Bueno, no sé, me ha parecido un dato curioso, porque si vendieron ese software a D-Link, pudieron también haberlo vendido a otros fabricantes y podría haber otros routers afectados... Pero bueno, vamos a lo que nos importa:  


La función que genera las seeds es idéntica a la de los routers TP-Link, la podeis encontrar aquí.
La función que genera las claves a partir de las seeds es muy parecida (comparadla con la de TP-Link, si quereis):

Código [Seleccionar] Expandir

windows = "1I2Z0O5SUV"
macosx  = "B8DO0I1S5UVZ2"  #Solo para los Linksys instalados en Mac OS X
def genKey(seed):
   key = ""
   for i in range(10):
       while True:
           seed = ((seed)*0x343FD + 0x269EC3) % (2**32)
           edx = ((seed >> 0x10) & 0x7FFF) % 0x24
           if edx >= 0xa:
               edx += 0x37
           else:
               edx += 0x30
           if chr(edx) not in windows:
               key += chr(edx)
               break
   return key
Como veis, esta vez no se usa una lista de caracteres válidos, sino que se generan caracteres 0-9; A-Z y se descartan los aquellos contenidos en la lista de caracteres prohibidos (que podrían llevar a confusión como '0' y 'O') hasta lograr tener 10 caracteres. Como vimos en el hilo de TP-Link, podemos aprovechar esto para romper la clave en minutos con GPU o unas pocas horas con CPU. Fin de la historia.  


Routers afectados de Linksys:

WAP610N (En Windows los caracteres prohibidos son: "1I2Z0O5SUVB8")
WRT110
WRT120N
WRT160N    (V1, V2, V3)
WRT160N-HP (V1*)
WRT160NL
WRT310N    (V1, V2)
WRT320N
WRT400N
WRT54G2
WRT610N    (V1*, V2)

Vienen a ser principalmente todos los routers con esta forma plana, rectangular y redondeada: FOTO
En todos estos routers me he encontrado con una curiosidad / problemilla: Como veis en el código de arriba, los caracteres prohibidos varían entre el asistente de instalación de Windows y el de Mac OS X, pero creo que el algoritmo no.  Además, otro dato interesante, el router WAP610N usa una lista de caracteres prohibidos algo distinta bajo Windows (nada que no tenga solución XD).


Routers afectados de D-Link:

DGL-4100
DGL-4300
DIR-615 (not all revisions)
DIR-625
DIR-635
WBR-1310
WBR-1310 rev.B
WBR-2310

Al no existir un asistente para Mac OS X, no tenemos el problemilla de los Linksys. Algo curioso, es que el modelo EBR-2310, aún sin tener WiFi, tenía en su asistente de configuración llamadas a la función esa. A decir verdad, me surgieron algunos problemas al analizar al asistente de D-Link. Solo puedo confirmar que en su interior "existe" una función que genera nuestras queridas claves WPA2 inseguras. Pero no se nada más, así que mejor ir confirmarlo primero. Como dije, todos los modelos afectados son los que tienen el famoso D-Link Quick Setup Wizard de Pure Networks. Por ejemplo: CAPTURA1, CAPTURA2 (fijaos en el logo abajo a la izquierda que pone "Network Magic").


Aquí teneis los programas para trastear con el fallo este... Funcionan igual que los de TP-Link, para más info mirad el mensaje original.
Linksys-CheckKeys: Comprobar si una clave es vulnerable. http://www.mediafire.com/download.php?pmqt9aykwxhwkto
Linksys-GenSeeds: Generar seeds de un intervalo de tiempo. http://www.mediafire.com/download.php?kpe7844kqd9bk4j
Linksys-GenKeys: Generar un diccionario de keys a partir de las seeds. http://www.mediafire.com/download.php?2h9y0pkay9id1rt
*Se llaman Linksys-..., pero también valen para los D-Link.

Lo más importante ahora, creo que es asegurarse de que el ataque es posible en la práctica (a diferencia del otro post, yo no tengo ninguno de estos routers). El ataque contra un Linksys WRT160N pude verificarlo con este video (minuto 4:20). Pero como he dicho en los D-Link y en el resto de los Linksys esto es pura teoría. Para confirmar la vulnerabilidad, pasarme la contraseña por PM; o usad  directamente el Linksys-CheckKeys. Por lo demás, necesitamos lo de siempre:

• Una listas de BSSID, asociados al modelo y la fecha de fabricación.
• Feedback sobre los programas.

Sé que todo esto es tan tan parecido con lo de TP-Link que hasta podría haberlo posteado en ese mismo hilo (si los moderadores lo creeis oportuno, no dudéis en unir este mensaje al otro hilo).

Saludos!

[@maffiuss]

@maffiuss
Lo primero, muchas gracias!  
Además has dicho lo mismo que estaba pensando yo también.. suerte que por otros sitios ha habido más apoyo en conseguir algo más de información para explotar este fallo. Por otra parte entiendo que a mucha gente solo les interesa lo que voy a postear aquí abajo independientemente de los detalles técnicos. Pero en fin, todo lo digo con cariño y sin acritud.



Aquí tenéis el programa final para generar los diccionarios para estos routers. Ejecutad TPLink-GenKeysFinal y seguid las instrucciones. Introducid la BSSID del router o la fecha de lanzamiento al mercado del router si la sabeis como argumento para obtener un diccionario reducido específico para el modelo del router que estáis atacando, eso puede reducir el tiempo de crackeo a unos pocos minutos. Si no sabeis ninguno de estos datos, no metais argumentos y listo.  

Descarga: http://www.mediafire.com/download.php?vtu146u849ogueq

Si quereis más velocidad aún, no protestéis y ayudad a completar la tabla de abajo aportando la información de estos routers.
(También he colocado este mensaje en el primer post del hilo).


En otro orden de cosas, creo que hay aún más routers de TP-Link afectados. Supongo que son modelos algo más antiguos y no aparecen en la página de TP-Link, pero el asistente aún es posible descargarlo de otros sitios. Por ejemplo:
http://www.softpedia.com/dyn-search.php?search_term=Easy+Setup+Assistant&x=-529&y=-45

TD-W340G
TD-W300KIT
TD-W8101G
TD-W8960N
TL-WR2543ND