Facilitando las auditorias con Google Hacking + AAD

Cuando necesitamos auditar una web y queremos tirar de los resultados de google hacking uno de los trucos que suelo tener en cuenta es tirar del operador -inurl: para descartar aplicaciones, variables de aplicaciones incluso dominios que ya he comprobado.

Un ejemplo sería el siguiente. www.tussam.es identifico la tecnología que voy a auditar en este caso php.

Imagen 1: Búsqueda con Dork sin exclusión

Entro en el primer resultado compruebo que no haya nada interesante y vuelvo a realizar la búsqueda descartando la variable id ya que he comprobado que no es vulnerable

Imagen 2: Búsqueda con Dork con exclusión

El problema de esta consulta es que pueden existir otras aplicaciones o directorios en la web que no contengan precisamente en la variable la cadena id, con lo cual estaríamos descartándola, pero sin embargo seriamos capaces de añadir más cantidad de operadores excluyentes si solo nos fijamos en las variables

Fijémonos entre la cantidad de exclusiones sin pasarnos del límite de palabras en la consulta, entre “dominio+aplicación+variable” (Primeros 2 bloques) y solo “variable” (último bloque).

Google
8 operadores sobrepasa el límite

site:www.tussam.es inurl:php
-inurl:www.tussam.es/index.php?id=
-inurl:www.tussam.es/index.php?id=
-inurl:www.tussam.es/index.php?id=
-inurl:www.tussam.es/index.php?id=
-inurl:www.tussam.es/index.php?id=
-inurl:www.tussam.es/index.php?id=

"www" (y las palabras que le siguen) se ignoró porque limitamos las consultas a 32 palabras.

Google
Búsqueda Exacta (la ideal)
Sin pasarme del límite 7 operadores

site:www.tussam.es inurl:php
-inurl:www.tussam.es/index.php?id=
-inurl:www.tussam.es/index.php?id=
-inurl:www.tussam.es/index.php?id=
-inurl:www.tussam.es/index.php?id=
-inurl:www.tussam.es/index.php?id=

Bing
Búsqueda Exacta (la ideal)
13 operadores sin pasarme del limite

site:www.tussam.es -instreamset:(url):”php”
-instreamset:(url):”www.tussam.es/index.php?id=”
-instreamset:(url):”www.tussam.es/index.php?id=”
-instreamset:(url):”www.tussam.es/index.php?id=”
-instreamset:(url):”www.tussam.es/index.php?id=”
-instreamset:(url):”www.tussam.es/index.php?id=”
-instreamset:(url):”www.tussam.es/index.php?id=”
-instreamset:(url):”www.tussam.es/index.php?id=”
-instreamset:(url):”www.tussam.es/index.php?id=”
-instreamset:(url):”www.tussam.es/index.php?id=”
-instreamset:(url):”www.tussam.es/index.php?id=”
-instreamset:(url):”www.tussam.es/index.php?id=”

Google
Búsqueda en base a las variables GET
Sin pasarme del límite. 30 operadores con variables

Bing
Sin pasarme del límite. 20 operadores con variables

¿Vale la pena correr el riesgo basándonos solo en las variables? por supuesto que sí, tenemos más cantidad de exclusiones.

Filtrando correctamente con Google el límite ronda los 7 operadores mientras con Bing llegamos a 13 operadores sin pasarnos.

En cambio filtrando en base a las variables, Google con 30 frente a los 20 permitidos por Bing, queda claro con cual nos quedaríamos por ello hay que decir que Google la tiene más larga con 30 contra 20 de Bing y es que aquí el tamaño sí importa jeje.

Bueno pues hice una herramienta para automatizar este proceso, que trabaja con google y con su querido captcha problema que no tenemos con Bing

La herramienta tiene el siguiente aspecto.

Imagen 3: AAD Interfaz

Simplemente es necesario que en la primera entrada de datos se le envié el dork intentando filtrar lo más posible los resultados, por ello que filtro también por la tecnología para evitar html, jpg, png, etc, de este modo acortar los resultados.

En el segundo filtro se puede especificar con una expresión regular por ejemplo [?] de este modo aparecerían todas las urls parametrizadas, y es que a quien no le gustaría que a google se le pudiesen pasar expresiones regulares eh? El que no le guste que tire la primera piedra… ¬¬ vale sigamos.

Y la última opción que sirva para ver los operadores de exclusión con las variables GET encontradas en la web.

Imagen 4: ADD en acción y abajo misma ultima búsqueda de ADD pero en el buscador

Y hasta aquí este post espero que os haya gustado y es que últimamente no posteo tan seguido por que ando liado con la FaasT y cuando llego a la casa estoy sExo polvo :p.

Salu2!; 

Se puede descargar de aqui:  https://sourceforge.net/projects/aadgoogle/

Jornada Gratuita de seguridad HighSecCON II

 

Quiero anunciaros la jornada gratuita de seguridad HighSecCON II que organizamos desde HighSec el día 15 de Noviembre de 17:00 a 20:00. El objetivo de la HighSecCON es crear un punto de encuentro de gente interesada en el hacking ético y la ciberseguridad.

El evento es completamente gratuito y tendrá como ponentes a:

• Pablo Gonzalez (@pablogonzalezpe) con “A la caza del pedófilo, Flu-AD y su integración con Metasploit & Any Shellcode!“

Flu-AD es un troyano creado para los cuerpos policiales de distintos países. Hoy en día los países debaten si sus cuerpos policiales podrán utilizar este tipo de herramientas en la lucha contra la pedofilia en Internet. La inyección de funcionalidades en ejecución mediante shellcodes proporciona una vía para llegar a un engranaje optimizado en pocos KB de herramienta. Por ejemplo, integración entre Flu-AD y Metasploit Framework.

• Marc Rivero (@seifreed) con “Mama estoy infectado por un malware“

El objetivo principal de la charla pretende es exponer de manera histórica el cambio de tácticas (no solamente a nivel de código malicioso, sino de recursos, técnicas e infraestructuras) que han sido desarrolladas tanto por medios de pago por internet, como por los cibercriminales. Se hará especial hincapíe a las medidas de seguridad adoptadas durante los últimos años en el sector de la banca electrónica y las técnicas empleadas por los delincuentes para conseguir saltárselas (con ayuda de los usuarios legítimos). Desde la autenticación simple basada en usuario y contraseña, las tarjetas de coordenadas, los teclados virtuales, hasta los sistemas que autentican al usuario mediante el uso de smart­‐cards. Del mismo modo, se expondrá la capacidad del código malicioso actual para conseguir, ya no solamente la información de cuentas bancarias, sino del contexto en el que se ejecutan (sandbox laboratorios de malware con el fin de recopilar información que pueda ser convertida en inteligencia que servirá para

optimizar las tácticas empleadas)

• Ricardo Martín (@ricardo090489) con “Como aprovechar el autofill de Chrome para obtener información sensible“

En esta charla se hablará de cómo aprovechar el autofill de Chrome para obtener información sensible como pueden ser números de cuenta bancaria y otros datos privados, ayudándonos de capas y propiedades que no han tenido en cuenta los de Chrome para ocultar los campos que se auto rellenarán con esta información tan valiosa para un atacante, consiguiendo de esta forma auto rellenarlos sin que la víctima se dé cuenta de ello.

• Roberto García (@1GbDeInfo) con “Iniciación al XSS“

Los ataques XSS siguen en auge hoy en día. Si piensas que tu web está segura, vuelve a repasarlo porque quizá sea vulnerable a los ataques XSS. Cross Site Scripting se basa en inyectar código malicioso en un sitio vulnerable y permitir ejecutar ese código. Si te llama la atención, estate atento a la chala porque veremos un acercamiento a un tema de moda como son los ataques XSS.

El evento se repite cada 2 meses y está apoyado por el ICFS (Instituto de Ciencias Forenses y de la Seguridad) de la UAM además de tener la colaboración de Thiber y Flu-Project.

Para reservar una entrada gratuita manda un correo a  info@highsec.es. La localización del evento será en la Escuela Politécnica Superior de la Universidad Autónoma de Madrid.

Más información en

• http://www.highsec.es/highseccon-ii/
•     info@highsec.es
•     @highsec0

Artículo cortesía de @highsec0

Obtener el captcha, mostrarlo y enviarlo desde tu aplicación

Tal vez al desarrollar una herramienta que tira de un servicio web este necesite que se le envíe un captcha por ello es necesario obtenerlo y presentarlo en tu herramienta para luego enviarlo junto con el recurso al servicio web, si ya saben cómo darle una solución a este “problema” tal vez sea mejor que no sigas leyendo, en cualquier caso te puede servir para refrescarte cómo lograrlo.
Bueno el concepto simplemente es ir directamente al enlace donde se genera la imagen dinámica y obtenerla junto con la cookie con la que está relacionada, en este caso esa cookie era PHPSESSID.
Para el ejemplo voy a utilizar un servicio web para decompilar online ciertos formatos de archivos (http://www.showmycode.com/), para ello la aplicación que realizo como ejemplo en C# le va a enviar una url de una aplicación que se encuentra subida en una página web (http://zoomquilt2.madmindworx.com/).

Imagen 1: Par de datos necesarios para la posterior petición.

Entonces he creado un código en C# que realiza una petición a http://www.showmycode.com/?c, parsea la cabecera y obtiene la cookie PHPSESSID (realmente se puede hacer esto de otras formas más elegantes pero bua me da igual) – Imagen 1.
Lo siguiente será interceptar la petición que se envía para decompilar la herramienta que está alojada en http://zoomquilt2.madmindworx.com/zoomquilt2.swf para este cometido he utilizado el addon de Firefox, live HTTP headers.

Imagen 2: Interceptada la petición cuando se envía el formulario.

He subrayado los datos que se van a modificar en la aplicación, primero la cookie, la url donde se aloja la aplicación a decompilar y el valor del captcha.

Imagen 3: código de la segunda petición.

Este es el código de la segunda petición, donde se va a enviar tanto la url de la aplicación a decompilar, el valor del captcha, el contenido de la petición por POST, la cookie y el mensaje en el Response que se espera si todo ha salido bien en el código fuente devuelto por la web "Your decoded code", Si se cumple la condición de encontrar esta cadena en el código fuente significará que todo ha salido bien y con ello que el envío del par captcha-cookie se ha realizado de forma satisfactoria, justo después se tendrá que parsear el HTML en busca del cuadro donde se encuentra el código de la aplicación decompilada y volcarlo en un fichero.htm junto con los estilos css para que quede tal que así.

Imagen 4: fichero generado por la aplicación con el volcado del SRC.

http://www.multiupload.nl/8CNGENNBG1

Algunos ejemplos y defensas contra el clickjacking

El clickjacking fue descubierto por Jeremiah Grossman y Robert Hansen en 2008. También se le conoce como UI redressing. El concepto es sencillo, y las técnicas para conseguirlo no son difíciles de implementar. Se podría decir que la técnica se basa en un fallo de diseño de HTML y por tanto toda web es "vulnerable" por defecto. Las soluciones hasta ahora son en realidad "parches" aplicados tanto al protocolo como a los navegadores, que han aparecido para intentar mitigar el problema.

El fin del clickjacking es conseguir que un usuario pulse en un enlace (y realice una acción) sin que lo sepa, o creyendo que lo hace en otro enlace con otro fin, con todas las consecuencias que eso puede acarrear. Puede ser un enlace de votación (que vote a alguien que no desea), seguir a alguien en Twitter, un "Me gusta" de Facebook... El atacante "disfraza" un enlace no deseado, volviéndolo atractivo para la víctima. Para conseguirlo, se basa en el juego de capas que se puede conseguir con HTML e "iframe". Iframe es una (anticuada en cierta forma) técnica para cargar una web dentro de otra. Clickjacking está basado normalmente en el iframe.
Para una explicación de cómo realizar este ataque, se debe entender el funcionamiento por capas intrínseco al HTML. Una web maliciosa (roja, en la figura) debe cargar una web legítima (gris) delante pero , de forma transparente (con opacidad cero). La web roja consistirá en un mensaje atractivo, en el que el usuario desee pinchar. La web legítima será la "víctima" en el sentido de que el usuario realmente pulsará sobre ella sin quererlo. Además, será víctima del ataque porque permite que se "abuse" de ella (veremos cómo evitarlo). Si se posiciona correctamente un enlace sobre otro, y se cuadran las capas, el efecto puede ser el del "secuestro" del clic del ratón.

Para preparar la página maliciosa, el atacante debe contar con dos componentes básicos:

• Un iframe a cualquier otra página, que en este caso será la "víctima", o en rigor, la página que será finalmente pulsada, sin que lo sepa el usuario.
• Este iframe debe servirse desde la página maliciosa aplicando un estilo concreto que permita que sea transparente y quede posicionada por delante, en el punto correcto. Por ejemplo

El "style" definirá el ataque.

• opacity:0. Vuelve transparente al elemento. Su valor va de 1 (totalmente opaco) a 0, transparente e invisible.
• position: El elemento se coloca en relación a su primera posición (no estática) elemento antecesor.
• top:0px;left:0px;width:99%;height:95%;margin:0px;padding:0px. Estos parámetros permiten tomar todo el ancho de una página y que se acople a sus márgenes para que la cubra totalmente
• z-index:1. Permite que se posicione por delante/encima de cualquier otro elemento. Si este número se incrementa (puede valer 100, por ejemplo), se posicionará delante de todo lo que tenga un z-index menor. Si el número es negativo, se posicionará por detrás.

El ataque completo, podría ser algo así:

Y cuando el usuario crea pulsar sobre un enlace muy atractivo o conveniente para él, en realidad puede que esté realizando una transferencia, por ejemplo.

Una ventaja de esta técnica que la diferencia del CRSF (cross site request forgery), es que con ella se sigue disponiendo del token válido en el caso de páginas que necesiten sesión, y si el usuario está presentado en la web "víctima", lo hará con el mismo token y como si realmente la acción se hubiera realizado desde la página original.

Pero se puede ir más allá. El problema inicial se definió en 2008 con este vídeo, en el que se presentaba un ejemplo en el que la víctima activaba inadvertidamente su cámara web al presionar botones en la propia página de Adobe.

 

Un ejemplo concreto

Imaginemos un sistema de votación muy sencillo, alojado en un dominio culaquiera, en la web vulnerable.php.

El atacante utiliza test.html, que carga mediante un iframe la página vulnerable.php de forma transparente con opacidad 0. La carga "por delante" de test.htm, pero al ser transparente, el usuario solo visualiza el contenido de test.html. En ella propone votar a otra web cualquiera, por ejemplo elladodelmal.com. Este es el reclamo. Pero el usuario que pulse sobre el botón, realmente estará votando a elevenpaths.com.

La última secuencia muestra una imagen de la aplicación test.htm con opacidad 1, lo que significa que se puede ver la aplicación vulnerable.php y test.php claramente una sobre la otra.

Evitar el ataque: en un sitio web

¿Qué puede hacer una página para que no sea utilizada como víctima del clickjacking? No puede hacer mucho más que evitar que se cargue ella misma dentro de un iframe. Así ningún atacante podrá ponerla "invisible" y sobre otra que el propio atacante ha creado. Una de las soluciones "antiguas" era la de evitar con JavaScript que una página no estuviera siempre en el "top".

Se debería incluir este código en cada página. Pero estas técnicas podían, a su vez, ser evitadas por el atacante.

Como solución más práctica, se ideó añadir al protocolo HTTP una cabecera llamada X-Frame-Options. Las páginas que envíen estas cabeceras al navegador, pretenden protegerse de aparecer en un iframe. Se propusieron varios métodos más o menos flexibles para intentar ayudar a las que legítimamente necesitaran incluirse dentro de un iframe. Sus valores son:

• DENY, el navegador evita que la página sea renderizada si está contenida dentro de un iframe
• SAMEORIGIN, la página solo puede ser mostrara en un frame que provenga del mismo origen que la propia página.
• ALLOW-FROM uri, el navegador bloqueará la renderización sólo si el origen de nivel superior está en un contexto de navegación que es diferente al valor uri proporcionado en la directiva

Los usuarios deben confiar en que las páginas las envíen, y que su navegador las interprete correctamente. Esto último hace tiempo que ya lo implementan la mayoría. Por ejemplo, Chrome desde su versión 4.1.249.1042, Firefox desde 3.6.9, Internet Explorer desde la 8, Opera desde la 10.5...

Evitar el ataque: desde el cliente

Pero aunque la mayoría de páginas  ya se aprovechan de estas cabeceras, ¿qué pasa con las que no? El usuario debe protegerse. Ciertos antivirus detectan en el navegador comportamientos "extraños" de este tipo, y les han asignado firmas. Por ejemplo Avira, lo detecta como  HTML/Infected.WebPage.Gen2.
Otro método para protegerse es utilizar la funcionalidad "clearclick" del conocido plugin NoScript, que ofrecerá protección al usuario para FireFox.

Ejemplos de alertas sobre ClickJacking.
Fuente: http://blogs.computerworld.com/sites/default/themes/cw_blogs/cache/files/u91/noscript_clickjack.jpg 

Fuente: http://hackademix.net/2008/10/08/hello-clearclick-goodbye-clickjacking/

Os adjunto un video en el que muestro como mediante esta técnica un hacker sería capaz de desviar cientos de votos engañando a los usuarios habituales de una web que ha sido comprometida, creyendo estos estar cliqueando ‘Me gusta’ a una persona cuando realmente se esta votando a otra.

Clickjacking example 2

Cómo aprovechar el autofill de Chrome para obtener información sensible

A finales de 2010, Google introdujo en Chrome autofill, una característica cómoda, pero que puede suponer un problema de seguridad para sus usuarios. Incluso después de que otros navegadores sufrieran problemas de seguridad relacionados con esta funcionalidad, y que la funcionalidad en sí haya sido cuestionada, sigue siendo posible robar la información almacenada del usuario que rellena un formulario sin que lo perciba.
En general, almacenar datos sensibles en el navegador no suele resultar una buena idea. Justo antes de que Chrome implementara el "Autofill", en verano de 2010, se descubrió cómo sacar todos los datos almacenados en Safari con fuerza bruta en JavaScript. El usuario rellenaba un campo pero el navegador se encargaba de rescatar todos los demás almacenados, probando todas las letras y dejando que el navegador hiciera el resto. La vulnerabilidad fue parcheada poco después. No hace tanto, en agosto de 2013, se criticó desde muchos frentes lo sencillo que era recuperar contraseñas almacenadas en Chrome, que podían observar en texto plano.
Con un sencillo método se puede conseguir que el usuario que escribe en un formulario, entregue esos datos a un tercero sin que sea consciente de ello.

¿Cómo funciona?

Autofill de Chrome permite almacenar la dirección postal (dividida en otros datos como nombre, apellidos, teléfono, código postal...) y la tarjeta de crédito (dividida en titular, número y fecha de caducidad). Los datos (excepto la tarjeta de crédito) se pueden sincronizar con la cuenta de Google. El menú de configuración y cómo acceder a él, se observa en la siguiente secuencia de imágenes.

Imagen 1: Configuración del autofilling.

Imagen 2: Configuración del autofilling (Direcciones).

Imagen 3: Configuración del autofilling (Tarjetas de crédito)

Diferentes pantallas de configuración de "autofill" en Chrome

Para que un formulario aproveche el autofill, los inputs deben ser debidamente identificados para que Chrome sepa qué valores corresponden.

Imagen 4: Atributos para el autofilling

Dispone de cierta heurística para intentar que casen los campos. Por ejemplo sabe que autocomplete="mail" debe ir autocompletado con el mismo contenido que cuando lleva de valor autocomplete="Work  email".

El "ataque"

Un atacante puede aprovechar esta característica del navegador para obtener información privada como puede ser los datos del domicilio o datos de la tarjeta bancaria. Planteamos un escenario en el que la víctima visite una página web por https especialmente modificada, introduzca los datos y el atacante se ayude del autofill que ofrece el navegador para obtener datos sensibles almacenados. Todo esto a pesar de las pequeñas trabas que introduce Chrome en su código para evitarlo.
Por ejemplo, como precaución, Chrome solo proporciona la tarjeta de crédito a páginas bajo https. Esto no es ningún problema para un atacante, pues es solo tiene que operar a través de una conexión SSL. Existen páginas fraudulentas que funcionan con certificados gratuitos.
El segundo paso es preparar el formulario y ocultar a los ojos de la víctima, los inputs que interesan al atacante. La primera aproximación pensaría en utilizar la etiqueta "hidden". Pero en el input el atributo type no puede llevar ese valor. Una segunda aproximación podría ser introducir el formulario dentro de un div con la propiedad visibility en "hidden"... pero Chrome evita que los inputs sean auto-rellenados cuando se cumplen estas condiciones. ¿Cómo conseguirlo entonces?
Una fórmula puede ser aprovechar la propiedad de scroll, subiendo la capa algunos píxeles para que no se observen el resto de inputs en los que se pretende recopilar la información. En este caso, el formulario "gancho" se vería:

Imagen 5: PoC Autofilling

Pero, usando este "div", conseguimos que en su interior se oculten todos estos inputs y no se visualicen en el navegador:

div style ="overflow:hidden;height:25px;"

Imagen 6: Campos ocultos en el formulario.

Chrome rellenará toda la información adicional sin que la vea el usuario. El atacante, recopilará la información y podrá disponer de muchos más datos de los que cree haber rellenado el usuario.

Imagen 7: Recolección de los datos robados.

En resumen, aunque resulte cómodo (para sistemas usados por una misma persona solamente), debe evitarse el uso de la funcionalidad autofill, puesto que se ha demostrado que es posible ofrecer a cualquier página bajo https datos tan sensibles como el número de la tarjeta de crédito y su fecha de caducidad, sin que la víctima sea consciente.
Para evitar este problema (o potenciales en el futuro), por ahora el mejor remedio es simplemente no utilizar esta funcionalidad.

Ricardo Martín Rodríguez

ricardo.martin@11paths.com

@ricardo090489

Inyecciones en inyecciones SQL

La entrada que traigo hoy, trata de como llevar un paso más haya las Union Based SQL Injection, por ejemplo si en algún caso nos vemos frente a una inyección SQL de este tipo, que no contiene datos aprovechables, como pueden ser subir una webshell u obtener las credenciales para acceder al login del gestor de la web que se esté auditando, etc. Se ha de tener en cuenta que un ataque como el Union Based SQL Injection se puede aprovechar de otras formas, y una de estas formas es la que hoy expondré.

Se trata ni más ni menos que aprovechar los campos imprimibles de la consulta SQL que por debajo está realizando la página web al cambiar los parámetros que se envían por la url. Aprovechándonos de dicha forma lograr inyectar además de la inyección SQL, código Javascript, HTML o por qué no realizar un SSI, de este modo podríamos desde ejecutar comandos en una Shell devuelta por el sistema que se muestra en la página (SSI), incluir un iframe para cargar un exploit (HTMLi), leer las cookies, suplantar un formulario como vimos en uno de los anteriores post de este blog Ataques XSS avanzados a aplicaciones webs: 3 Ejemplos; o cualquier otro que se nos ocurra, y es que de esta forma se lograría explotar otro tipo ataque que tal vez por estar bien protegida la web no se podría dar y con ello otra forma de ownear la web.

A continuación se puede ver un ejemplo de una inyección XSS sobre una inyección SQL ya que no se logró explotar de otra forma un XSS en lo demás de la web, siendo irrelevantes los datos obtenidos en la base de datos.

Imagen 1: XSS con SQLi en Google Chrome.

Otro punto a favor de realizar una inyección XSS de esta manera, es que se consigue Bypassear tanto los filtros Anti-XSS de navegadores como Google Chrome (Versión 29.0.1547.76 m) como los de IExplorer (10.0.9200.16660).

Imagen 2: XSS con SQLi en IExplorer.

Para realizar este ataque se debe primero preparar la inyección SQL de modo que quede así.
http://www.localhost.com/test.php?Op=2-1+union+select+1,2,3,4,5,6

Imagen 3: Búsqueda del campo imprimible.

Como se puede apreciar el campo imprimible es el que cae en el 5, entonces será cuestión de sustituirlo en este caso por la inyección XSS cifrada en Hexadecimal con cualquier conversor de Ascii a Hex.

Ascii: <script>alert("code-disaster.blogspot.com")</script>
Hex: 3c7363726970743e616c6572742822636f64652d64697361737465722e626c6f6773706f742e636f6d22293c2f7363726970743e

y por ultimo concatenar a la inyección SQL junto con dos paréntesis de apertura al principio, más 0x (que sirve para identificar el cifrado en el gestor de base de datos y que luego va a servir para devolverla impresa en la web en texto plano), más la cadena en Hex y dos cierre de paréntesis al final.

((0x3c7363726970743e616c6572742822636f64652d64697361737465722e626c6f6773706f742e636f6d22293c2f7363726970743e))

Quedando así.
http://www.local.com/test.php?Op=2-1+union+select+1,2,3,4,((0x3c7363726970743e616c6572742822636f64652d64697361737465722e626c6f6773706f742e636f6d22293c2f7363726970743e)),6

Profesionales de la seguridad informática I

Después de una semana de sequía sin escribir en el blog por las fechas de entrega de proyectos, ya que andamos un poco justos de tiempo he conseguido hacer un hueco para publicar una entrada que no acaba hoy ya que seguiré con el hilo de esta entrada cuando logre realizarme unas cuentas fotos con otros tantos profesionales de la seguridad informática y es que de ello va esta entrada.
Empezando con mi querido jefe (más me vale hablar bien de él … jejej) Pablo González, muy buen compañero del cual desde que lo conozco he de decir que es alguien que se ha preocupado por mí, por llevarme por el buen camino y guiarme y del que he aprendido y seguiré aprendido mucho de él, excelente persona y muy apreciado por todos en el entorno de este mundillo. Sin más hablar un poco de su experiencia y formación como profesional de la seguridad informática.

Pablo González
 
Es Project Manager en 11Paths, empresa perteneciente a Telefónica Digital. Ingeniero Técnico en Informática de Sistemas e Ingeniero en Informática por la Universidad Rey Juan Carlos. Certificado en  MCTS Windows 7, Configuring, MCITP Enterprise Desktop Administrator Windows 7, MCTS Windows 7 y Office 2010 deployment, MCP Designing Security for a Windows Server 2003 Network, MCTS Windows Server 2008 R2 Server Virtualization. Certificado en LPIC-1 y Small Bussiness CISCO. FTSAI. Anteriormente ha trabajado como Responsable de Seguridad en Informática 64. Premio Extraordinario Fin de Carrera por la Universidad Rey Juan Carlos en Ingeniería Técnica en Informática de Sistemas en 2009. Premio al mejor expediente de su promoción por la Escuela Técnica Superior de Ingeniería Informática de la Universidad Rey Juan Carlos en 2009. Es ponente habitual en diversos foros y congresos de seguridad a nivel nacional, entre los que se encuentran No cON Name y RootedCon.
Es autor de los siguientes libros:

• Metasploit para pentesters.
• Pentesting con Kali.
• Hacking dispositivos iOS: iPhone & iPad.
• PowerShell: La navaja suiza de los administradores de sistemas.
• Windows Server 2012 para IT Pros.
• Hardening de servidores GNU/Linux

Y lleva junto con Juan Antonio Calles el blog de http://www.flu-project.com/

Imagen 1: Yo y Pablo González

El siguiente del quien voy a hablar no es ni más ni menos que de Chema Alonso conocido por todo el que mínimamente se haya acercado al mundo de la seguridad informática, ponente en conferencias de todo el mundo y demás, pero ahora les hablaré sobre mi experiencia personal durante el tiempo que llevo trabajando con él, ya que luego haré un inciso para extender el recorrido que lleva este personaje tan conocido por todos a nivel nacional e internacional en el campo de la seguridad informática, sin más he de decir que a demás de simpático es una persona que llega a todos, no es el típico jefe que te podrías encontrar trabajando en cualquier otro sitio, es alguien más cercano y junto a Rodol han creado y llegado a construir los pilares de lo que es hoy en día 11paths, por ultimo decir que es alguien de quien no puedo decir que no haya sido amable conmigo y para demostrároslo y os muráis de envidia decir que me ha llevado hasta mi casa en el cochazo con el que aparezco en la Imagen 2.

Chema Alonso

Conocido como el Maligno, es quizá uno de los referentes de seguridad informática y hacking a nivel mundial. Ingeniero Informático de Sistemas por la Universidad Politécnica de Madrid - donde ha sido nombrado Embajador Honorífico por su excelente carrera profesional, e Ingeniero Informático y Master en Sistemas de Información por la Universidad Rey Juan Carlos ha sido premiado como Most Valuable Professional en Enterprise Security por Microsoft durante 8 años. En la URJC ha realizado su Doctorado en Informática dedicado a técnicas de auditoría de seguridad web. Miembro fundador de Informática 64, donde trabaja como consultor e investigador de Seguridad desde hace 14 años. De su trabajo en Informática 64, han salido herramientas populares de la seguridad informática como FOCA, MetaShield Protector o la reciente Forensic FOCA, y desde donde han salido las publicaciones de técnicas hacking como Time-Based Blind SQL Injection, (Blind) LDAP Injection o Connection String Parameter Pollution. Recorre el mundo participando en conferencias de seguridad de renombre internacional como Defcon, BlackHat, ShmooCON, HackCON, SEC-T, DeepSEC, RootedCON, NoConName, Ekoparty, Yahoo! Security Week, Digital Crime Consortium, FIRST, ToorCON, etc… donde ha dado más de 100 conferencias por todo el mundo. Ha sido invitado por Yahoo! para las jornadas de Seguridad en San Francisco. Famoso por su gorro a rayas, Chema Alonso ha publicado más de 50 artículos en congresos académicos y revistas técnicas, siempre sobre seguridad informática y es coautor de varios libros de Seguridad Informática. Escribe a diario su blog “Un informático en el lado del mal”, tocando temas de actualidad, hacking y seguridad desde hace 7 años. En el año 2012 fue elegido en los premios Bitácoras como el mejor blog de seguridad informática del año. Además es colaborador y mentor en Talentum Startups de Telefónica, director del Master de Seguridad de la Universidad Europea de Madrid y profesor del Master de Seguridad de la Universidad Oberta de Catalunya y de la Universidad Politécnica de Madrid. Actualmente puedes escucharle todos los martes en el programa La Mañana de la COPE a las 11:30 horas.

Imagen 2: Yo y Chema Alonso

Imagen 3: Yo y Chema Alonso otra vez..

Ahora hablaré de un amiguete a quien aprecio mucho, alguien que conozco hace bastante, bastante más de cuando lo vi por primera vez y es que esa misma mañana cuando entraba por primera vez a informatica64 vi a un chaval que salía a tomarse su pan con mantequilla y cola cao, tenía así como poco pelo cuando luego caí y me di cuenta que no era otro que Germán Sánchez, compañero durante aquellos tiempos de gran nivel en indetectables.net donde compartimos y aprendimos sobre malware y posteriormente sobre in-seguridad web, que decir de él. Desde el primer día que lo conoces ya eres su colega, es muy cercano y simpático, es con quien no puedes salir de fiesta por que luego … hay lo dejo jajaja.

Germán Sánchez

Autor del libro Pentesting Con Kali, Administrador del famoso blog de enelpc.com.

• Security Analyst
  Telefónica Digital Identity & Privacy (Eleven Paths)
  abril de 2013 – Actualidad (6 meses)Distrito C, Sede Central de Telefónica
  Consultor de Seguridad Informática en Informática 64
  abril de 2012 – abril de 2013 (1 año 1 mes)

Docente en cursos de hacking ético, pentesting, malware, forense en windows, ataques en redes de datos IPv4 e IPv6, VoIP, seguridad web, auditoría de código y temas relativos a la fortificación de sistemas.
Realizando auditorías web, test de intrusión y análisis de malware para evitar amenazas o fallos de seguridad en empresas externas, con el consiguiente informe técnico, donde reflejar las vulnerabilidades encontradas.
Auditoría de redes LAN en empresas externas, utilizando técnicas relativas al sniffing, pivoting y exploiting.

Imagen 4: Yo y Germán

Acceso a la cuenta de un usuario directamente a través de la url sin previo login

Esta es una práctica que al parecer se está utilizando cada vez más, ya son varias webs que me encuentro con esta forma de acceder a la cuenta de un usuario sin previa autenticación y que encima no caducan las urls pasado cierto tiempo.
A continuación voy a explicar algunas de las ventajas para un atacante e inconvenientes para los desarrolladores en cuanto al uso de este método.

Referer
El Referer sería un vector para obtener estas jugosas urls algo simple de lo que se podría sacar el acceso a la cuenta de la víctima es como si en el Referer se transmitiera las credenciales. Un ejemplo sería realizando una aplicación que recoja los Referer y pidiendo a la víctima que acceda a la web donde se encuentra esta aplicación donde se obtendrán estas urls que transmiten el key para entrar como usuario logead.

Ficheros del historial de los navegadores
Otro causa de por qué no utilizar este método y otro truco de como robar estas urls como todas las otras por las que el usuario navega es el fichero donde se guarda el historial  de navegación por ejemplo en Google Chrome con Windows 8 se haya en un fichero que se encuentra en C:\Users\RootedLab\AppData\Local\Google\Chrome\User Data\Default\History Index 2013-09

Imagen 1: Historial de Chrome

Google Dork
Un ejemplo es el caso de www.humblebundle.com se dieron cuenta un poco tarde sin poder evitar la indexación de sus urls ya que como se puede ver en la segunda imagen se encuentra configurado el robots.txt para deshabilitar que se indexe estas urls pero como se ve en la primera imagen se dieron cuenta algo tarde ya que hay indexadas bastantes de ellas con acceso a la cuenta aunque ya reclamadas, por ello esta sería otra truco a tener en cuenta

Imagen 2: Urls de acceso indexadas

Imagen 3: Robots.txt

Fuerza Bruta
Casos de webs como https://www.humblebundle.com/downloads?key=4vMtRuTHm53R que permiten el acceso a la cuenta a través de la url tienen una clave compuesta de 12 caracteres aleatorios alfanuméricos en minúscula (27), mayúscula(26) y numérica(10) por ello cabe un rango de posibles combinaciones de 63^12 algo inviable por tiempo y recursos además habría que contar con la posibilidad de realizar varias denegaciones de servicio, pero no por ello descartable para otras webs.

Imagen 4: Cuenta humble

Otros detalles de por que no usar este método
Antes se solía mandar al correo un email las webs donde uno se acababa de registrar con el usuario y contraseña una práctica que ya no se suele usar por el hecho de que una vez comprometido el correo un atacante podía ver esas credenciales y ahora con el método del acceso en la url existe otro vector por el que el atacante acceda a X web como usuario logeado teniendo de este modo la misma importancia que enviar las credenciales al correo, aunque no le será tan fácil al atacante que se haya colado en su correo filtrar los emails como se hacía antes con los que contenían credenciales filtrando por “password, contraseña, usuario, login”, ya que no hay un patrón que filtre las urls que tenga la clave en la variable… tal vez por key? Para el caso de www.humblebundle.com si hubiese servido, pero cada web tendrá su propio nombre de variable

Imagen 5: Bandeja de entrada gmail

Hay que tener en cuenta que cualquier usuario si guarda una url como esta es más susceptible a guardarla sin la seguridad y protección que podría emplear para guardar unas credenciales, por ello resulta más fácil robar una url con el acceso que una combinación de usuario y contraseña

Tips for develop "Path Traversal" Tool

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

iDStore lista ficheros y directorios ocultos de ficheros .DS_Store

Hoy traigo una herramienta que fue publicada en elladodelmal.com hace unos meses cuando aún estaba realizando las prácticas del ciclo superior de Desarrollo de Aplicaciones Web (DAW), quise algún día traerla y hoy ya toco.
Glosario
.DS_Store (Desktop Services Store) es un archivo oculto exclusivo del sistema operativo de Apple Inc. Mac OS X para almacenar los atributos personalizados de una carpeta, como puede ser la posición de los iconos o la imagen de fondo.
Estos ficheros suelen encontrarse en paginas webs al realizar la subida de un directorio junto con los ficheros .DS_Store ocultos de un Mac OS X  y por ello algunos se pueden encontrar indexados a los buscadores. Estos ficheros se puede encontrar dorkeando en Google con un dork tal que así, inurl:.ds_store intext:Bud1 o de esta otra forma ext:ds_store Bud1

Imagen 1: Busqueda con Dork

Estos ficheros como se puede apreciar en la siguiente imagen tiene un “Head” propio de propio de ellos que contiene la cadena Bud1 además de un cuerpo en el que se encuentra un patrón al final de los nombres de ficheros y directorios “Ilocblob” que los identifican

Imagen 2: Fichero .DS_Store

La herramienta que he desarrollado se encuentra compilada en C# y Java además de sus correspodientes SRC donde podréis ver e investigar como funciona, esta versión no esta lo depurada que me hubiese gustado pero realiza su objetivo listando de la URL donde se encuentra el fichero .DS_Store los nombres de ficheros y directorios escondidos en el.
Para un ejemplo se realizo la prueba contra esta web que además de contener dicho fichero tiene un directorio abierto, con lo cual se pueden contrastar los resultados extraídos por la herramienta y los que se listan en la propia web y es que esta herramienta es una gran alternativa a listar directorios que se encuentran protegidos y con ello no son listados.

Imagen 3: Directorio abierto

Una vez lanzada la aplicación se puede ver como quedo el resultado en la siguiente captura.

Imagen 4: Resultado de la iDStore

Se puede apreciar los ficheros que en un principio estuvieron, con errores 404 y que ahora no están y los que aún continúan estando
Source en C# y Java + compilados
http://sourceforge.net/projects/idstore/files/

Ya van 165 descargas :O

Ataques XSS avanzados a aplicaciones webs: 3 Ejemplos

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

Hacer webshell indetectables parte III de III

Siguiendo con el hilo del post anterior se les va a hablar de herramientas comunes para ofuscar código PHP y así lograr saltarse los antivirus. Como ejemplo se usará una herramienta llamada carbylamine escrita en PHP y desarrollada por Prakhar Prasad

Su uso es simple, es necesario pasarle 2 parámetros, fichero de entrada y fichero de salida

Imagen 1: Ejecución carbylamine

Al comparar el código de los dos ficheros se puede ver un gran cambio

Imagen 2: Comparación c99 Ofuscada y sin Ofuscar

Y al analizarlos no se detecta como código malicioso.

Imagen 3: Análisis de Avira

Así de sencillo se logra burlar al antivirus y es que no es Avira el único caso, es más desde mi punto de vista Avira es uno de los mejores antivirus que existe hoy en día y es que volviendo a criticar lo que se habló en el anterior post del método de detección por firmas que tan ineficaz es y aún más si estas empresas no invierten trabajo en añadir firmas a herramientas tan conocidas como puede ser la c99 ofuscada sin previas modificaciones con los típicos métodos de ofuscación.

Imagen 4: Análisis en Virustotal - detección 0/47

Y es que son muchos los que se inician en el mundo del defacement y sin más suben una web shell ofuscada que se han bajado de la primera página de los resultados de google.

Imagen 5: Búsqueda en google c99 webshell

Muchos webmasters se alertarían si su antivirus la hubiese detectado

Conclusión
Me gustaría proponerle una idea y que llegase a los oídos de estas empresas antivirus.
Porqué no advierten los antivirus cuando en un directorio web se encuentra un fichero que hace llamadas a determinadas funciones como gzinflate, base64_decode, etc y si esta al tanto, el administrador la añada como excepción. ¿Se les ocurre algún CMS que ofusque su código fuente como lo hace carbylamine?.

=================================================================
Indetectar web Shell parte I de III
Indetectar web Shell parte II de III
Indetectar web Shell parte III de III
=========================================================================