:::SPAS3C-SV-006:::OPERA BROWSER 10/11/12 (0-DAY) EXPLOIT

In this post, I do the release of an issue that I discovered 362 days ago and it was reported to Opera using the SSD program (SecuriTeam Secure Disclosure), but they have decided not to fix it.

Thanks to sinn3r of metasploit.com for his heap spray method for Opera Browser (tested on v11.51 and v11.50) that uses VirtualAlloc. You can try it, setting the target to 1. I will keep both methods to avoid heap spray holes, I mean, if you are trying the exploit with default target and it lands on a hole, change to target 1 and try it again.

But, next results were taken with default target.

By the way, Opera Next was updated two days ago (r1076 -> r1085). I have not had time to get results of this release, but I confirm that it's still vulnerable and even I've seen remote code execution.

Testing Method:

In this case, I was looking for success at first attempt, so I needed to find a method that did not use the crash-dialog, kept (by default) the config and did not use the last-visited feature (The next one maybe too paranoic):

0. In attacker: exploit ready.
1. In victim: Start Opera.exe and launch the exploit.
2. In victim: If success -> Close shellcode -> Turn off the computer.
3. In victim: If not success -> Do not restart + Do not send/Send -> Turn off the computer
4. In attacker: kill id_exploit and exploit (new random url)
5. In victim: Start the computer.
6. In victim: Go to step 1.


The results:

• Opera 12 pre-alpha -> RCE on 6/10 attempts
• Opera 11.51 -> RCE on 3/10 attempts
• Opera 11.50 -> RCE on 3/10 attempts
• Opera 11.11 -> RCE on 4/10 attempts
• Opera 11.10 -> RCE on 4/10 attempts
• Opera 11.01 -> RCE on 5/10 attempts
• Opera 11.00 -> RCE on 4/10 attempts
  

The exploit 0day here and here.


You can find more info:

• Metasploit (English)
  
• EnRed 2.0 (Spanish)
  

Update (2011/10/17): I want to explain that I do not have an exact date when Opera was reported. As I've explained in my report in spanish, probably it was 10 months ago. By the way, note that they fixed the known as "frameset exploit" in May. However, all the vulnerabilities were reported together.

Update (2011/10/19): Opera has patched the vulnerability with the new version released: 11.52.

Happy (0)day, folks!

:::SPAS3C-SV-004:::FINAL DISCLOSURE AND RELIABILITY TESTS (SSD-1010101 / PART-II)

I have taken a while and been trying to improve this one, unsuccess. But, I would like to thank to sinn3r and the rest of metasploit members who have tried to get a more reliable exploit. The poc is unstable and the crash is variable. Also I could not lead to more stable/reliable crashes. Anyway, I cannot discard the possibility of DEP bypass. Under some versions, it could be possible (controllable EAX to pivot) but unreliable/unstable. Give me a feedback if you get a poc that improves these issues :)

So far, the final result is not as nice as I wanted. Since I could not publish my ms10-090 exploit, you know, someone discovered before I could publish :) I am glad to get released this one and probably it does not come alone.

Here goes the reliability tests (click to see correctly):

Fig. 1: Reliability table.

It is important to notice that most of versions will not work at first attempt. Although it is possible and I have seen it: The crash-dialog helps here and the table above is based on it.

Crash-dialog options:

1. Restart-speech-dial -> close opera.exe -> open opera.exe -> go to url of exploit.
   
2. Restart and reopen all tabs.
3. Do not restart -> open opera.exe.

Tests features:

• Master Box: Windows 7 Ultimate with SP1 (English) (fully updated)
• VM engine: Virtual Box
• Virtual boxes: Windows XP Professional with SP3 (English) (fully updated) x 15
• Opera: Clean installations with configuration by default
• Browser cache: It's not cleaned
• Number of attempts: 100
• Number of OS restarts: 5
  
• Number of url-exploit changes: 10

Notes:

• I have noticed that the reliability changes when the box is restart. So it is very possible that you will get another results.
  
• This exploit was coded when the stable release was v10.61 At that time, my best results was got with v10.62 and v10.61 (not clean installation: v10.6-> v10.61)
  

Finally, the msf module here and here

:::SPAS3C-SV-005:::IE8/9 USE-AFTER-FREE VULNERABILITY POC (ZDI-11-194/MS11-050/CVE-2011-1260)

Just the poc for my (and not only my finding) last IE (use-after-free) vulnerability:

<STYLE>
object{
float: left;
}
</STYLE>
<acronym>
hggssssssssssssssssssssssssddddddddddddddddddddddddddddddddddddddddddddddaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaadddddddddddddddddddddddddddddddddddddddddddddddddddddddd
</acronym>
<object>
head
</object>
<col>
ccc
</col>
<div style = 'layout-grid-char: 35735636357357354ex;'>
aaaaaa
</div>

You will find an awesome work, exploit, even new targets (IE6/IE7) in d0c_s4vage's blog.

More references:

• Microsoft advisory

• ZDI advisory

:::SPAS3C-SV-004:::OPERA BROWSER < 11.11 FRAMESET MEMORY CORRUPTION VULNERABILITY (SSD-1010101 / PART-I)

Voy a escribir este post en español porque llevo mucho tiempo sin hacerlo y de todas formas en inglés tampoco me explico demasiado bien.

En primer lugar, algunas aclaraciones sobre la vulnerabilidad/exploit:

• Esta vulnerabilidad la encontré hace ya tiempo, si mal no recuerdo a finales de Septiembre de 2010 y fue mi segundo exploit, por lo que no era muy elaborado, un heap spray y cruzar los dedos para que se cayera en esta zona. Lo bueno de la versión en la que lo encontré, es que a pesar del carácter aleatorio de la vulnerabilidad se podía sacar buen provecho de una forma reliable (ver advisory para más detalles). En concreto la versión de Opera por aquél entonces era la v10.61, posteriormente, este exploit ha ido perdiendo fiabilidad conforme han ido pasando las versiones hasta convertirse en un DoS, aún explotable pero realmente poco reliable. El caso es que he estado varios días dándole vueltas al poc, buscando en primer lugar un forma controlada de disparar la vuln y al mismo tiempo, reliable.

• Dejar claro que parece que tanto Opera, como el resto de fuentes que se han hecho eco de la vulnerabilidad, en algunos casos no están en disposición de testear la vuln (por un lado) y en otros casos (como Opera) no parecen hacerlo: La vulnerabilidad afecta a Opera v10.xx y Opera v11.xx (<11.11).
  

• Y es más (esto explica porque no voy a dar detalles de PoCs y exploits, más allá de un vídeo y un pequeño informe): La vulnerabilidad se dispara con éxito en Opera Mobile v11.x y Opera Mobile v10.x. Ahora bien, no sé si hasta el punto de conseguir explotabilidad o no, lo que sí puedo asegurar (tras hacer algo de debugging usando un Nokia N8, Symbian^3 y con carbide.c++ / IDA) es que quizás pueda ser explotable, me explico, mis conocimientos en debugging ARM y explotabilidad no van más allá de éste, como primer caso. Dicho esto, tras disparar varias veces la vuln en Opera Mobile, he visto que el PC (Program Counter) se carga con valores bajos (0x00000134, 0x00000130, etc) , lo cual es comúnmente poco explotable, pero a veces, he visto crashes en (0x006xxxxx, 0x005xxxxx), lo cual corresponde a zonas del heap y stack, es por ello, que no descarto la posibilidad de explotación en esta arquitectura. Es más, en su momento y aunque no tenía la posilidad de testear el poc, porque no tenía ningún smartphone, sólo pude hacer algunas pruebas usando el emulador de Windows Mobile y también resultó vulnerable. Lo que sí conseguí es tener un exploit en Opera Mobile Emulator for Windows. Sin embargo, y ante la posilibilidad de analizarlo en un entorno real, la explotación móvil quedó (y parece ser que aún queda) en el olvido. De todas formas, no es más que una posibilidad que trataré de comprobar.
  

• La explotación bajo sistemas con hw DEP y ASLR (> Windows Vista SP0) es poco probable debido fundamentalmente al carácter aleatorio de la vulnerabilidad y la dificultad de construir un ROP exploit. Por el mismo motivo, la explotación en cada versión de Opera es más o menos reliable.

• Otras plataformas donde se ha testeado con éxito la vulnerabilidad son: MacOS X Snow Leopard y Ubuntu (GNU/Linux). Además de las versiones de Windows: XP, Vista y 7.
  

Reformando el exploit...

En mi lab, preparé una máquina virtual con Windows XP SP3 (full updated) y con /nx=alwayson (DEP soft on). Tomé la última versión vulnerable, en concreto, v11.10 y a empezar... Como dije anteriormente, este exploit era bastante reliable en v10.62 pero en v11.10 era muy poco explotable. En primer lugar, encontré la forma de disparar la vulnerabilidad de forma controlada y finalmente ajuste el spray para conseguir la máxima fiabilidad. Así pues el exploit consta de dos etapas, una primera donde se hace el heap spray y en otra, se dispara la vulnerabilidad.

Este exploit no he llegado a testearlo en más versiones, pero el exploit anterior, lo testeé en numerosos entornos desde v10.00 hasta v11.10 y todos consiguieron RCE al menos una vez (alguno más reliable que otro). Por tanto, con un poco de trabajo podría convertirse en un exploit con una cobertura bastante amplia.

Así pues, y cómo más vale prevenir que curar, de momento no haré publica más información que ésta:

• Un video donde se puede ver la explotación con éxito y reliable (80-90%) en v11.10.

• El advisory (en inglés), con algunas modificaciones desde su envío a SSD (sobretodo correcciones de idioma). Probablemente, haya dejado demasiada información a la vista pero obtener el poc es más complejo que fuzzear el tag frameset, al menos eso parece xD
  

Actualización: SecuriTeam reconoce haber notificado el tema móvil a los desarrolladores de Opera que descartan tener un update cercano, sin embargo no descartan parchear algún que otro asunto más ;)

Referencias:

• Advisory de Opera

• SecuriTeam Secure Disclosure program

:::SPAS3C-WV-006:::Multiple Vulnerabilities in Mozilla Sites

This is old stuff, which i should have posted before, discovered in Mozilla websites several weeks ago:

• bugzilla.mozilla.org: CSRF (saved searches).
  
• creative.mozilla.org: CSRF (user profile).
  
• developer.mozilla.org: Plain text password disclosure.

I will provide some details about them.

1. CSRF (saved searches) in bugzilla.mozilla.org

PoC: http://pastebin.com/63H2YtMd

Sec-Severity: Low/Medium

CVE: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-0046

Description: Saved searches for bugzilla user's panel are not protected against CSRF attacks and it could be used to add bullshit.

This vulnerability affects to Bugzilla (bug tracking system of mozilla foundation) <= 3.2.9, 3.4.9, 3.6.3, and 4.0rc1
Reference: http://www.bugzilla.org/security/3.2.9/

Screenshot:

Fig.1: Launching the CSRF exploit

Fig.2: Exploit executed succesfully

2. CSRF (user profile) in creative.mozilla.org

PoC: http://pastebin.com/0r1MyvVv

Sec-Severity: Critical

CVE: N/A

Description: User profile could be changed using a CSRF attack.

Screenshot:

Fig.3: CSRF (user profile) in create.mozilla.org

3. Plain text password disclosure in developer.mozilla.org

PoC: Register to developer.mozilla.org and then, come back to check your mail. This site sent your password in plain text.

Sec-Severity: High

CVE: N/A

Description: MDC sent your password in plain text.

Screenshot:

Fig.4: Plain text password disclosure

And yep, my MDC password contains an "e".

On the other hand, Mozilla security team solves these issues quickly.
That's all. Be safe ;)