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

:::SPAS3C-SV-002:::WEBKIT (APPLE SAFARI < 4.1.2/5.0.2 & CHROME < 5.0.375.125) MEMORY CORRUPTION VULNERABILITY (CVE-2010-1813)

This time, I'm going to post a new remote software advisory, which was fixed about one month ago, but i couldn't post because i was waiting an advisory and fix from Safari. Now fix is out, so i can post my own advisory.

-------------------------START-ADVISORY-------------------------------


TITLE: WEBKIT (APPLE SAFARI < 4.1.2/5.0.2 & GOOGLE CHROME < 5.0.375.125) MEMORY CORRUPTION VULNERABILITY
TESTED OS: WINDOWS XP SP3
SEVERITY: HIGH
CVE-NUMBER: CVE-2010-1813
DISCOVERED DATE: 2010-06-29
FIXED DATE: GOOGLE CHROME (2010-07-26) & APPLE SAFARI (2010-09-08)
FIXED VERSIONS: GOOGLE CHROME 5.0.375.125 & APPLE SAFARI 4.1.2/5.0.2
DISCOVERED BY: JOSE A. VAZQUEZ


======ABOUT APPLICATION======

"WebKit is an open source web browser engine. WebKit is also the name of the Mac OS X system framework version of the engine that's used by Safari, Dashboard, Mail, and many other OS X applications. WebKit's HTML and JavaScript code began as a branch of the KHTML and KJS libraries from KDE..." copied from http://webkit.org/

======DESCRIPTION======

A memory corruption vulnerability was confirmed by Chromium Security Team. Original stacktrace showed a null ptr dereference, but some pointers were also corrupted.

Stacktrace (using Chrome symbols):

WebCore::RenderObject::containingBlock() Line 597
WebCore::RenderBlock::paintContinuationOutlines() Line 2344
WebCore::RenderBlock::paintObject() Line 2232
WebCore::RenderBlock::paint() Line 1980
WebCore::RenderLayer::paintLayer() Line 2447
WebCore::RenderLayer::paintList() Line 2499
WebCore::RenderLayer::paintLayer() Line 2468
WebCore::RenderLayer::paint() Line 2252
WebCore::FrameView::paintContents() Line 1943
WebCore::ScrollView::paint() Line 797
WebCore::RenderWidget::paint() Line 281
WebCore::InlineBox::paint() Line 180
WebCore::InlineFlowBox::paint() Line 682
WebCore::RootInlineBox::paint() Line 167
WebCore::RenderLineBoxList::paint() Line 219
WebCore::RenderBlock::paintContents() Line 2090
WebCore::RenderBlock::paintObject() Line 2199
WebCore::RenderBlock::paint() Line 1980
WebCore::RenderBlock::paintChildren() Line 2127
WebCore::RenderBlock::paintContents() Line 2092
WebCore::RenderBlock::paintObject() Line 2199
WebCore::RenderBlock::paint() Line 1980
WebCore::RenderLayer::paintLayer() Line 2445
WebCore::RenderLayer::paintList() Line 2499
WebCore::RenderLayer::paintLayer() Line 2468
WebCore::RenderLayer::paint() Line 2252
WebCore::FrameView::paintContents() Line 1943
WebCore::ScrollView::paint() Line 797
WebKit::WebFrameImpl::paintWithContext() Line 1795
WebKit::WebFrameImpl::paint() Line 1818
WebKit::WebViewImpl::paint() Line 979
RenderWidget::PaintRect() Line 390
RenderWidget::DoDeferredUpdate() Line 501
RenderWidget::CallDoDeferredUpdate() Line 428


======PROOF OF CONCEPT======

http://pastebin.com/v7T0QK5g


======STEPS TO REPRODUCE======

1.- Upload 1.html and 2.html to your server.
2.- Open file 1.html with vulnerable app.

-Google Chrome:

3.- Wait for a while, then, crash is got (sad-tab).

-Apple Safari:

3.- Wait for a while, if crash is not got, use Ctrl+T to trigger it.


======REFERENCES======

[ref-1] -> https://bugs.webkit.org/show_bug.cgi?id=41373
[ref-2] -> http://googlechromereleases.blogspot.com/2010/07/stable-channel-update_26.html
[ref-3] -> http://support.apple.com/kb/HT4334
[ref-4] -> http://spa-s3c.blogspot.com/2010/09/full-responsible-disclosurewebkit-apple.html


======DISCLOSURE TIMELINE======

Standard Time Zone: GMT/UTC + 01:00 hour (Spain/Madrid)

[2010-06-29] => Posted new issue in Chromium Project (with pocs).
[2010-06-29] => Chromium confirmed memory corruption and opened new webkit bug.
[2010-07-26] => Chromium released new fix (Google Chrome 5.0.375.125).
[2010-09-08] => Apple released new fix (Apple Safari 4.1.2/5.0.2).
[2010-09-10] => Public disclosure.


======CREDITS=======

Jose Antonio Vazquez Gonzalez,
Telecom. Engineer & Sec. Researcher.
http://spa-s3c.blogspot.com/


-------------------------END-ADVISORY-------------------------------


That's all. Be safe ;)

:::SPAS3C-WV-005:::Vulnerability in Joomla! Core (Back-end) <= 1.5.19

About two months ago, i found several vulnerabilities in Joomla! v<= 1.5.19 and these are my advisories. This one was published on Joomla! Security Center: here

• Project: Joomla!
• Severity: Medium
• Versions: 1.5.19 and all previous 1.5 releases
• Exploit type: XSS Injection
• Reported Date: 2010-June-8

Back-end was vulnerable to XSS/HTML Code Injection. Get var "menutype" used in "com_menus" (core component) allowed the injection.

Proof-of-Concept:

http://[HOST]/[JOOMLA-PATH]/administrator/index.php?option=com_menus&task=view&menutype=mainmenu%22%20onmouseover=%22alert%28%27Discovered%20by%20Jose%20A.%20Vazquez%27%29;

Some screenshots:

Fig.1: XSS triggered in Joomla! Back-end

Fig.2: Code injected.

Be safe ;)

:::SPAS3C-WV-004:::Session Hijacking in Steam WebSite

About two months ago, my little girl gave me a great present for my birthday and i got Call of Duty Modern WarFare 2 (I <3 C0D).

Lots of minutes of game later, I decided to check security in Steam Website and i got very interesting results.

WebSite was vulnerable to XSS/HTML Injection and it could be exploited to steal cookies of users. I made a PoC showing how to launch the vulnerabilities using any browser (where xss was allowed) or "steam" schema uri (steam://openurl/) due to steam used its own internal browser.

The "steam browser" had/has some limitations:

• This browser didn't/doesn't allow to change the url -> Solution was schema uri.

• This browser had/has an url length restriction -> Solution was to use an evil JS file hosted anywhere.

• So, these would be simple PoCs.Get var "os" was vulnerable: http://store.steampowered.com/search/?os=mac%22%3E%3Cscript%3Ealert%28document.cookie%29;%3C/script%3E%3C!--&category1=998&category2=9

• Get var "category1" was vulnerable: http://store.steampowered.com/search/?os=mac&category1=998%22%3E%3Cscript%3Ealert%28document.cookie%29%3C/script%3E%3C!--&category2=9
  

Fig.1: Triggering one simple PoC.

Fig. 2: Session Hijacking PoC.

I also recorded a video showing how the issue could be exploited.

Watch in youtube: here

I made my game more secure but they (steam-website security team) didn't give me a present like a new nice game.

Be safe ;)