martes, 14 de diciembre de 2010


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:


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


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

Be safe ;)

viernes, 19 de noviembre de 2010

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

jueves, 7 de octubre de 2010

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

viernes, 10 de septiembre de 2010

:::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.


CVE-NUMBER: CVE-2010-1813
FIXED DATE: GOOGLE CHROME (2010-07-26) & APPLE SAFARI (2010-09-08)


"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


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======


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.


[ref-1] ->
[ref-2] ->
[ref-3] ->
[ref-4] ->


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.


Jose Antonio Vazquez Gonzalez,
Telecom. Engineer & Sec. Researcher.


That's all. Be safe ;)

viernes, 6 de agosto de 2010

:::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.



Some screenshots:

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

Fig.2: Code injected.

Be safe ;)

lunes, 5 de julio de 2010

:::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.

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

miércoles, 23 de junio de 2010

:::SPAS3C-WV-003:::Google IO XSS/HTML Injection Vulnerability

This post is about a bug discovered in Google IO (XSS/HTML Injection)

Risk: Medium

"Google I/O brings together thousands of developers for two days of deep technical content, focused on building the next generation of web, mobile, and enterprise applications with Google and open web technologies such as Android, Google Chrome, Google APIs, Google Web Toolkit, App Engine, and more."

Source: here

Get var "error" was vulnerable to XSS/HTML code injection but some tags and javascript events were filtered trying to do more difficult the explotation.
Also i noticed that viewing source code, error var triggered a SQL error, so I tried to make a SQL Injection but no worked.

Proof of concept:

Indirect. Needed user interaction (event JavaScript: onmouseout) ->

Fig.1: XSS (Indirect) and HTML Injection.

Direct. Not needed user interaction (event JavaScript: onerror) ->

Fig.2: XSS (Direct) and HTML Injection.

Be safe ;)

viernes, 11 de junio de 2010


I found this vulnerability one week ago, but I was waiting a fucking CVE number when somebody published a similar advisory without checking. This researcher made a public disclosure in an old release and he also said that it isn't fixed when this is fake (at least Source Code Disclosure/Download got fixed with lastest releases).

Copied from ChangeLog for 0.8.40/0.7.66 (Final releases in stable/development channel):


Changes with nginx 0.8.40 07 Jun 2010

*) Security: now nginx/Windows ignores default file stream name.
Thanks to Jose Antonio Vazquez Gonzalez.

*) Feature: the ngx_http_uwsgi_module.
Thanks to Roberto De Ioris.

*) Feature: a "fastcgi_param" directive with value starting with
"HTTP_" overrides a client request header line.

*) Bugfix: the "If-Modified-Since", "If-Range", etc. client request
header lines were passed to FastCGI-server while caching.

*) Bugfix: listen unix domain socket could not be changed during
Thanks to Maxim Dounin.


But vulnerabilities databases seem that they didn't confirm nothing.

This is my advisory:


"nginx [engine x] is a HTTP and reverse proxy server, as well as a mail proxy server written by Igor Sysoev. It has been running for more than five years on many heavily loaded Russian sites including Rambler ( According to Netcraft nginx served or proxied 4.70% busiest sites in April 2010. Here are some of success stories: FastMail.FM, The sources are licensed under 2-clause BSD-like license." copied from -> [ref-1]


Unix versions are not vulnerable (it only affects to NTFS file system)

Windows Stable versions:

nginx/0.7.66 --> Not vulnerable
nginx/0.7.65 --> Vulnerable
nginx/0.7.64 --> Vulnerable
nginx/0.7.63 --> Vulnerable
nginx/0.7.62 --> Vulnerable
nginx/0.7.61 --> Vulnerable
nginx/0.7.60 --> Vulnerable
nginx/0.7.59 --> Vulnerable
nginx/0.7.58 --> Vulnerable
nginx/0.7.56 --> Vulnerable

Windows Development versions:

nginx/0.8.40 --> Not vulnerable
nginx/0.8.39 --> Vulnerable
nginx/0.8.38 --> Vulnerable
nginx/0.8.37 --> Vulnerable
nginx/0.8.36 --> Vulnerable
nginx/0.8.35 --> Vulnerable
nginx/0.8.34 --> Vulnerable
nginx/0.8.33 --> Vulnerable
nginx/0.8.32 --> Vulnerable
nginx/0.8.31 --> Vulnerable
nginx/0.8.30 --> Vulnerable


This application was vulnerable to source code disclosure/download vulnerability when it was running in Windows OS (NTFS file system).
App parser couldn't handle ADS (Alternate Data Streams) and it treated a data stream as an usual file. An Attacker could read/download source code of webapps files using default data stream (unnamed): "filename::$data".

This issue is like an old security issue in Microsoft Windows IIS [ref-2].

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



1.- Start the server.

2.- Go to$data

3.- Browser requests to download...yes...go to file and open it.


[ref-1] ->
[ref-2] ->


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

[2010-06-04] => Inicial contact with vendor and sent advisory.
[2010-06-04] => Vendor response and believe that vulnerability got fixed with previous release.
[2010-06-04] => I confirm that nginx is vulnerable in Windows 7 OS.
[2010-06-04] => Vendor will try to see the issue.
[2010-06-04] => Vendor confirms the issue and he will get fixed on Monday.
[2010-06-07] => New releases out.
[2010-06-07] => I sent complete advisory and propose as disclosure date on Wednesday.
[2010-06-10] => Second chance to confirm public disclosure.
[2010-06-10] => Vendor agree.
[2010-06-11] => Forced to public disclosure.


Jose Antonio Vazquez Gonzalez,
Telecom. Engineer & Sec. Researcher.

Thanks to Ruben Santamarta (@reversemode) and Jose Maria Alonso (@maligno) for their support in other issues.


This is a visual Proof Of Concept:


Watch on youtube ->

Be good (responsible disclosure) has disadvantages...bye bye my first software advisory :(

Update: Thanks to exploits-db and security-focus because they (will) have updated their databases and (will) have published my advisory.

Be safe ;)

miércoles, 9 de junio de 2010

:::SPAS3C-WV-002:::Google App (Ventures) BSQLi Vulnerability

One month ago, I found serveral vulnerabilities in Google's sites.

These issues got fixed all and I want to say that Google Security Team did a good job and they fixed it soon.

All issues was discovered between 4 May and 9 May (year 2010, of course).

This issue is the most important in my opinion: Blind SQL Injection in

Risk: High

Google Ventures is Google’s venture capital arm.

We do primarily three things:
  1. Seek out the most innovative and interesting entrepreneurs and companies we can find
  2. Perform in-depth due diligence and invest in those we are most excited about
  3. Do everything we can to help those companies succeed
We invest for financial return, across all sectors and in all stages of a company’s growth. We are particularly interested in areas where access to our team, facilities, technology or other resources can help a company become more successful, but we do not limit our investments to those of strategic interest to Google – we look for companies and people that have the best opportunity to create significant, disruptive and innovative ventures.

Source: here

Site was made using PHP+MySQL (some parts) and GET var "jobid" vulnerable to injection of SQL code.

Proofs Of Concept (Searching MySQL version)

Return: 1=1 (True), so MySQL version is 5

Link PoC ->,1,1)=5,1,0)=1--

Fig. 1: BSQLi. True result.

Return 1=0 (False), so MySQL version isn't 4.

Link PoC ->,1,1)=4,1,0)=1--

Fig. 2: BSQLi. False result.

Also I tried to get a SQL Injection, with "Union Select" Statement but It didn't work.

Fig. 3: Trying SQL Injection "Union Select". MySQL error.

I didn't want to do a further research because I considered that it was enough.

Be safe ;)

martes, 18 de mayo de 2010

Mini-estudio de Strings (SingleQuote vs DoubleQuote) en PHP

Leyendo el blog de Skylined, su última entrada me ha inspirado para realizar un análisis similar, en español y algo más estadístico.

Cuando programamos en PHP, podemos escribir Strings o cadenas de la siguiente forma:

$string="Esto es un simple string con comillas dobles";
o bien,
$string='Esto es un simple string con comillas simples';

Esta entrada trata de realizar un estudio o comparación entre ambos métodos.

En primer lugar hay que aclarar que la forma en que PHP destina un entrecomillado de otro es diferente. Las comillas dobles se evalúan, esto significa que se pueden emplear de la siguiente forma:

$string="Esto es un string con $stringconcat";

En este ejemplo, las comillas dobles tienen primero que evaluar la variable $stringconcat y sustituir su contenido, con lo cual, realiza una evaluación, si hay más variables realizará X evaluaciones.
Sin embargo no se puede emplear (esto está mal):

$string='Esto es un string con $stringconcat';

Componiendo un sencillo Script PHP que realice un determinado número de ejecuciones con diferentes tipos de Strings y almacene los resultados temporales en un fichero, tal como este:

//DB sin String...
$time = microtime();
$$i = "Un String sin un numero";
//DB sin String...
$time = microtime();
$$i = 'Un String sin un numero';
//DB con String...
$time = microtime();
$$i = "Un String $i con un numero";
//DQ concatenado
$$i = "Un String ".$i." concatenado con numero";
//SQ concatenado
$time = microtime();
$$i = 'Un String '.$i.' concatenado con numero';
echo "Terminado! Ahora importe los datos a una tabla de excel...";

Donde realizamos 50 ejecuciones, separamos entre 5 tipos de strings: Dobles Comillas (solas), Comillas simples (solas), Dobles comillas con numero, Dobles comillas con 1 concatenación y Comillas simples con 1 concatenación. Almacenamos los resultados temporales en un fichero resultado.txt. Posteriormente estos datos se importan en excel y he elaborado unas gráficas que arrojan algunos resultados interesantes.

Fig.1: Tiempos de 50 ejecuciones.

Fig.2: Promedio de 50 ejecuciones.

En estas gráficas se aprecia como las dobles comillas con una concatenación son las que mayor retardo de ejecución producen, seguido por las comillas dobles con el número. A continuación las comillas simples con una concatenación y finalmente las dobles comillas y las comillas simples.

De todo esto se deduce que las comillas simples son la mejor opción de cara al rendimiento y que en general el empleo de comillas dobles no es acertado (debido a los retardos de las evaluaciones). Sin duda, esto va a cambiar mi forma de trabajar con Strings en PHP.

Be safe ;)

viernes, 14 de mayo de 2010

Más y más WebSites desde el gobierno (ZP 2.0)

Al hilo de lo sucedido hace algún tiempo en el estreno de la eu2010 y puesto que a día de hoy el señor Zapatero y su gobierno no despiertan muchos entusiasmos, con sus recortes, "tijeretazos", etc. He decidido escribir esta entrada como crítica para la infinidad de nuevos WebSites fomentados por el gobierno.

Sinceramente, lo que más me ha llamado la atención, al margen de los ejemplos que voy a mostrar, son los casos de mayor riesgo, que evidentemente no voy a divulgar, pero que me hacen llegar a una conclusión: La seguridad de los WebSites no importa al gobierno. Lo que realmente parece importar es la idea: Crear portales a discreción.

Estos casos, en su mayoría inyecciones de código en la DB e inclusiones de archivo local (LFI), se encuentran en bases de datos Oracle, MS Server, MySQL, etc. Empleando lenguajes de servidor PHP, ASP, ASPX, etc.

En ciertos casos (al inicio de la legislatura), se emplea la tecnología más recomendada o más cara, pero sin embargo, la seguridad es cero. Otros (ya en crisis), denotan las prisas por lograr un portal finalizado lo antes posible y al menor precio, dando igual emplear una DB totalmente anticuada y un servidor compartido, donde todas (y no es broma, pocas se salvan), incluida esta misma, son vulnerables (seguridad cero de nuevo).

La cuestión final que quiero aclarar es que este gobierno, el gobierno del Sr. Rodriguez Zapatero, se ha dedicado a crear WebSites para casi todo lo que se le ha ido ocurriendo, no importándole en absoluto la seguridad de los portales, siendo esta seguridad como una cuestión de tecnología robusta y al mismo tiempo, derrochando todo el dinero posible.

Otra cuestión es el hecho de desmentir el mencionado caso de la eu2010, como un caso de no hack, puesto que para ellos todo lo que no afecte al WebServer no será considerado como hack. Con esta mentalidad, de darle igual la seguridad de un usuario final (caso de un XSS o HTML injection) y preocuparse exclusivamente por la seguridad de su servidor, es la mayor de las similitudes (mundo seguridad vs. mundo real) que sufrimos actualmente.

Dicho todo esto, dejo algunas "simpáticas" capturas de nuestro máximo representante político, en algunas de sus famosas WebSites actuales y no actuales. Se dirá que son "pintadas", que no son hacks o...para qué tanto si hubiera sido más fácil hacer "DesignMode=ON" y comenzar a retocar. Pero la realidad es que son vulnerabilidades Web, que son cuestiones de seguridad y que deben ser revisadas.

Metodo: POST
Tipo Vuln: HTML Injection

Fig.1: Zp en

Metodo: POST
Tipo Vuln: HTML Injection

Fig.2: Zp en

Metodo: POST
Tipo Vuln: HTML Injection

Fig.3: Zp en

Fig.4: Zp en

Sin lugar a dudas este último es mi preferido, pues se envía por GET y con la simple URL podemos lanzar la inyección. Comprobar aqui

Como nota final quiero aclarar que esto es una simple muestra en un corto periodo de testeo, las pruebas se realizaron exclusivamente en los buscadores de ciertos sites, nada de testeos profundos de otras variables, otros formularios, etc. Por otra parte me gustaría decir, que todo esto fue reportado hace más de 6 meses, pero que los administradores de los sites: a) les ha dado igual. b) los filtros anti-spam se han comido mis advisories.

Be safe ;)

miércoles, 12 de mayo de 2010

Probando 0-day en Safari para Windows (memory corruption) (EDB-ID: 12573 )

Hace pocas horas ha sido publicado un 0-day en Safari para Windows, afectando a versiones inferiores a la 4.0.5. En este caso, yo he realizado un test del exploit con la versión 4.0.4.

Fig. 1: Mi versión de Safari para Windows (4.0.4).

El contenido del exploit hace referencia a explotación local y remota y esto es debido a que el bloqueador de Pop-Ups está deshabilitado por defecto para archivos locales, sin embargo, cuando navegamos por la red este bloqueador permance activo (de ahí que si tenemos el exploit en un Web Server, necesitemos deshabilitar este bloqueador).

Echando un rápido vistazo al exploit, básicamente se trata de un error en el manejo de la ventana padre, lo cual puede realizar una llamada a una función empleando un puntero inválido. El exploit lanza su shellcode, en este caso, calc.exe empleando la técnica Heap Spraying de SkyLined. En resumen, esta técnica (ya relativamente antigua) transforma un gran bloque de memoria inválida , en memoria válida, mediante la inserción de bloques de menor tamaño de nop+shellcode. En el supuesto de que la aplicación vulnerable caiga en esta sección inválida. Quizás éste sea el primer exploit de Skylined sobre el tema: aquí. Aunque al parecer ya se estaban empleando técnicas basadas en heap spray desde 2001.

Realmente realizando una búsqueda por la Web, encontramos referencias a este exploit desde el día 7 de Mayo.

Fuentes: aquí y aquí

Aquí dejo unas capturas del exploit en acción...

Fig. 2: Paso 1 en el exploit (prompt del alert)

Fig. 3: Paso 2 (Prompt con un buffer de 20000 A's)

Fig. 4: Paso 3 (Exploit ejecutado).

Por otra parte, revisando la información de crash, tenemos una vista de los registros según Dr. Watson for Windows:

eax=0d0d0d0d ebx=7e398a01 ecx=3cde8792 edx=1016f729 esi=7fdabea0 edi=7e398bf6
eip=47330003 esp=0012e898 ebp=7e3991c5 iopl=0 nv up ei pl nz na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000206

Aquí dejo unos links al 0-day: exploit-db y securityfocus

En definitiva, un bonito exploit, que precisa de cierta interacción del usuario como la deshabilitación del bloqueador de pop-ups y el cierre de las ventanas empleando Alt+F4 (teniendo en cuenta que otros usuarios directamente hagan un asesinato del proceso de safari.exe y el exploit se rompa xD).

Los créditos de este exploit van para: Krystian Kloskowski

Solución actual: No hay parches por el momento.

Solución temporal: Deshabilitar JavaScript en Safari.

Be safe ;)

sábado, 8 de mayo de 2010

:::SPAS3C-WV-001::: Multiple Vulnerabilities in ILIAS 4.0.3


Ilias is a LMS (Learning Management System) created by a german
university. It's used by universities, schools and high schools around the world.
This document is the advisory sent to Ilias Security Team, therefore it is written in present time.
Personally, I've worked previously with this team and vulnerabilities was patched in short time, but this release takes almost two months. Anyway, I think that it is a punctual fact.

Examples are tested against my old university. I had already finished XD.

I know that my english is :( but it was enough to help.

Credits given: 4.0.5 Release Notes



The information in this advisory and any of its demonstrations is provided "as is" without any warranty of any kind.

I am not liable for any direct or indirect damages caused as a result of using the information or demonstrations provided in any part of this advisory.


Risk: Low

Using tag GET var, we could stop comments, but here XSS or HTML INJECTIONS is not possible, this would be a simple BUG.

-> Issue in [BUG]

Fig. 1: Simple bug.

This will be the HTML source code returned:

... --> &#" id="block_pdcontent_0_blimg" /> -->

We use End Comment Tag (-->).

Anyway, html tags are restricted so this isn't exploitable with a HTML or XSS Injection.


Risk: Medium

Changing Personal Information, setting for Street, City and Country:

XSS by J. A. Vazquez " onmouseover="alert('J.A. Vazquez');//

Save this changes.

When you move mouse in input tag, with value: "XSS by J. A. Vazquez", XSS is triggered.

Fig. 2: XSS triggered.

Note: This XSS is persistent, in control event, but this only affects my account. Therefore It's medium Risk.


Risk: High

Changing departament parameter for:

");alert('XSS by J.A. Vazquez');//

Saving changes, we bypass protection in CDATA...

Now we go to Public Profile and set "Departament" as visible.

Then, go to location and set "show in personal profile".

Now if a user visit our profile, he could be owned with xss attack.

Fig. 3: Direct and Persistent XSS

Note: This XSS could be reproduced using other vars (any of location, for example, city, street or view) (No tested but it's probably). This XSS is persistent and it doesn't need a javascript event for triggering. It's triggered in page load.


Risk: Medium

Go to bookmark section and create a folder, then set a new bookmark in this folder with:

Title: Nice XSS by J.A. Vazquez
Description: Nice XSS by J.A. Vazquez
URL: aa" onmouseover="alert('Creado por J.A. Vazquez!');

Fig. 4.1: XSS in bookmark. Location 1.

Fig. 4.2: XSS in bookmark. Location 2.

Note: This XSS only affects to own user. It's loaded in a javascript event and it could be reproduced in two different location.


Risk: Medium

Plugin Tiny MCE has some vulnerabilities.


You display a MDB2 (MYSQL) ERROR.

Fig. 5.1: SQL Error.

But if we put any value in session_id, this value is stored. I've tried a SQL Injection Attack, but it's not reachable.

Fig. 5.2: Session_id corrupted in DB.


Risk: High

Plugin Tiny MCE is vulnerable to Directory Traversal.

Go to -> http://[HOST]/Services/RTE/tiny_mce/plugins/ibrowser/imagemanager.php?obj_id=6&session_id=%&client_id=test_403/../../../&obj_type=frm

Fig. 6: Denial Of Service using DT.

Note: Tested only in localhost because server could be DoSed (Denial Of service). Depends on Script time execution.
Btw, Local File Inclusion (LFI) or Remote File Inclusion (RFI) is not possible) (In this case, "client_id" var is used to load image titles, etc).


Author of this advisory is Independient Security researcher José A. Vázquez Gonzalez. Copyright © 2010 José Antonio Vázquez González.

That's all. Be safe ;)