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

17 septiembre 2010

Análisis de la gestión de contraseñas en la UPM

En este artículo voy a exponer cómo se podría realizar un ataque contra los sistemas de recuperación de contraseñas de la UPM pudiendo modificar la contraseña del alumno y obteniendo acceso a todos los servicios que hagan uso de los mismos.

Antes de empezar quiero hacer referencia a otro artículo que trata del mismo tema, siendo éste Análisis de la gestión de contraseñas de la UCM, publicado en SecurityByDefault. Con respecto al mismo, decir que si intentamos acceder a los servicios “comprometidos” veremos que están cerrados, lo cual es una medida muy recomendable mientras se está tratando de solucionar.

Este artículo es un resumen, por lo que si queréis leer la versión completa tendréis que acudir al siguiente PDF. Además, aprovecho para adjuntar el enlace a una carpeta pública que he creado en Google Docs donde iré colgando todos los artículos en formato PDF. La carpeta en cuestión es Seguridad.

¡Comencemos!
Disclaimer:

No me hago responsable del mal uso que pueda darse a esta información. En ningún momento la intención del artículo es el incitar a que se produzcan ataques sobre las cuentas de los alumnos de la UPM, más bien su finalidad es la de concienciar al alumno/universidad de lo fácilmente explotables que son estos sistemas si no se toman todas las medidas de seguridad por ambas partes.

1. Introducción

El sistema que vamos a atacar es el de recuperación de contraseñas. A través de este sistema, podremos resetear la contraseña del alumno objetivo y acceder a todos los servicios que utilicen dichos credenciales (correo, campus virtual, etc).

Como ya comenté en el artículo sobre el sistema de la UCM, el ataque no es transparente al usuario por lo que nuestro intervalo de acción sobre la cuenta está limitado.

Con respecto a los credenciales, mediante este ataque podremos modificar la contraseña del alumno pero, ¿sabemos su nombre de usuario? En nuestro caso éste es la dirección de correo. Si no la sabemos, podemos aprovecharnos de un servicio-soplón el cual nos facilita la dirección de correo asociada a un alumno (a través de su DNI).

En este artículo voy a dar por sentado que ya hemos obtenido el DNI del alumno objetivo. En el caso de que no se tuviera, podéis acudir al artículo de la UCM en el que se explica brevemente algunas ideas de cómo podemos obtenerlo.

2. El sistema.

El sistema de recuperación de contraseñas de la UPM consta de una única etapa en la que hay que introducir el DNI del alumno y el código PIN (es el de la tarjeta universitaria, utilizado para la función monedero, consulta de expedientes, etc).

El sistema en sí no tiene ningún tipo de protección, por lo que podemos realizar el número de intentos que sean necesarios y, en un primer momento, no estaba monitorizado por lo que era muy difícil levantar sospechas. Además, en el artículo completo se explica cómo podemos reducir el ataque a un solo intento (olvidándonos de la fuerza bruta, de ahora en adelante FB, y de los posibles bloqueos que puedan implementar) o realizar el ataque sobre otro servicio vulnerable no monitorizado.

Sigo sin entender como, en servicios tan fácilmente explotables como éste, no se implantan medidas de seguridad. ¿Tanto cuesta introducir un CAPTCHA y/o un sistema de bloqueo preventivo?

3. Obteniendo el PIN.

En primer lugar, decir que el código PIN consta de cuatro caracteres numéricos. Con respecto a su generación para adjuntarlo en la petición, en principio no es necesario que contenga los cuatro dígitos, por lo que es igual de correcto introducir 10 que 0010.

Para obtener el PIN no tenemos más que hacer un ataque FB sobre el formulario de Olvido de contraseña. El ataque consistiría en hacer peticiones con el DNI y un PIN de la siguiente forma:
https://www.upm.es/gsr/correo_alumnos/olvido.upm?op=olvido
accion=validar&dni=DNI&contrasena=PIN

En el caso de que el PIN fuera incorrecto, nos devolverá un mensaje de error y en el caso de que acertemos, obtendremos el formulario para modificar la contraseña. Por lo tanto bastará con estar monitorizando la respuesta del servidor y, en el momento en el que no nos devuelva el error, podremos realizar la petición de cambio de contraseña. Esta petición ha de ser de la siguiente forma:
https://www.upm.es/gsr/correo_alumnos/olvido.upm?op=olvido
accion=final&contrasena=PASSWD&contrasena2=PASSWD
(ha de adjuntarse la cookie PHPSESSID validada)

Una vez modificada la contraseña habrá que esperar un par de minutos para que podamos acceder a todos los servicios sin problemas (véase el correo, el campus virtual, etc).
Como se ha dicho en la introducción, podríamos reducir el ataque a un solo intento. Podéis encontrar su explicación en el artículo completo.

4. El servicio soplón

El servicio-soplón no es ni más ni menos que el servicio a través del cual nos podemos crear una cuenta de correo de la UPM (del tipo @alumnos.upm.es).

Para crearnos una cuenta bastaría con realizar una petición a dicho servicio enviando el DNI del alumno y su PIN (claramente sólo es posible si el DNI corresponde a un alumno matriculado):

https://www.upm.es/gsr/correo_alumnos/solicitud.upm
accion=validar&dni=DNI&contrasena=PIN

¿Qué ocurre si el alumno ya tiene una cuenta asociada? Pues que el sistema nos devuelve una alerta mostrándonos su cuenta de correo y la fecha de creación.

Por lo tanto, en el caso de que tras obtener el PIN y modificar la contraseña, no supiéramos el usuario, bastaría con acudir a éste servicio para obtener el dato que nos faltaba.
¡Hasta aquí todo! Ya para terminar...

Aprovecho, ya que tienen relación entre sí, para enlazar el breve artículo PasswordFail de la UPM, en el que se demuestra que se guardan las contraseñas de los alumnos en texto plano, con el peligro que ello conlleva.

Como he dicho antes de empezar, no me hago responsable del uso que se haga de esta información.

La intención del artículo es concienciar a los usuarios y obligar a las universidades a prestar verdadera atención a todos los servicios que ofrecen y que éstos han de estar bien implementados pues los datos que manejan no son ninguna tontería.

Artículo cortesía de: Luis Delgado J.
Leer más...

16 septiembre 2010

Editores hexadecimales

De un hilo sobre editores hexadecimales de la lista más profunda y oscura de Internet he hecho una recopilación con los que se han ido mencionando para ver sus características más importantes y resumirlas en esta entrada.

Pese a que todos son usados para lo mismo, las diferencias entre muchas de ellas son importantes y dependiendo de la situación y los requisitos es posible que se use más de una.

Como siempre, lo mejor es descargar una demo de todas e ir probando sus funcionalidades. Al final cada persona aprecia aspectos distintos.
  • SweetScape 010 Editor - Su principal característica es el uso de plantillas o "Binary  Templates", que permiten automatizar tareas con un lenguaje similar a C/C++. Además soporta la comparación entre archivos, uso de histogramas y etiquetar posiciones con marcadores. El precio es de 129.95$ para la licencia comercial y de  49.95$ si es de uso académico o personal.

  • Zynamics Hexer - Hexer de la compañía especialista en ingeniería inversa Zynamics. Está programada en Java, lo que la hace multiplataforma. Además también soporta plantillas y es gratuita.


  • McAfee FileInsight -Esta herramienta está enfocada al reversing en malware tanto de archivos como de páginas web, dispone de plugins basados en python y múltiples decodificadores. La aplicación la distribuye McAfee de forma gratuita


  • IDM UltraEdit - Es posiblemente la más popular. Es además utilizada como editor para varios lenguajes de programación. Soporta la apertura de múltiples ficheros, coloreado según el lenguaje, conexión remota mediante FTP, remplazado de texto avanzado. No está enfocada al reversing pero es muy versatil. El precio de la licencia es de $59.95.

  • Radare - Radare no es únicamente un editor hexadecimal, se compone de un conjunto de herramientas para la ingeniería inversa en sistemas tipo Unix y multiplataforma. Pese a que es compleja (funciona bajo línea de comandos) para este entornos es sin duda la más potente.


  • BreakPoint Hex WorkShop - Este editor es altamente configurable y permite estructurar un archivo en secciones. También permite comparar archivos binarios. Su precio es de $89.95.


  • Hiew - Hiew es una aplicación de consola que permite el desensamblado y edición de ejecutables  NE, LE, LX, PE/PE32+ little-endian o ELF/ELF64. Soporta macros y búsqueda y remplazo avanzado. La licencia tiene un precio de 64$.

Leer más...

15 septiembre 2010

Premios Bitacoras 2010

Como cada año se van a celebrar los 'Premios Bitacoras.com edición 2010' en los que este año como novedad traen una categoría exclusiva de Seguridad (el año pasado estaba mezclada con Sofware).

Aprovechamos este post para presentar nuestra candidatura para esa categoría. Si opinas que nuestro trabajo aquí te gusta, te aporta cosas y crees que merecemos tu voto, puedes hacerlo de forma muy muy sencilla. En la edición anterior era necesario crearse una cuenta en el sistema, ahora han añadido la posibilidad de votar usando tu cuenta Facebook o Twitter. (Y ejem ejem, solucionado 'cierto problemilla')

Hay un primoroso how-to usar la cuenta de facebook para votar de nuestros compañeros de Weblog Magazine.

Gracias a todos y mucha suerte a todos los participantes !! Iremos informando de las evoluciones.
Leer más...

14 septiembre 2010

Folklorica 1.0 (El retorno de los Titiriteros)

Hace tiempo hablamos de un tipo de troyanos que denominamos 'Titiriteros' porque tenían la habilidad de emplear otros programas como 'Títeres' y de esa forma camuflar conexiones.

En concreto proponíamos el uso de la interface OLE/COM de Internet Explorer para lanzar conexiones al exterior mediante InternetExplorer.Application.1 que permite lanzar peticiones GET / POST y procesar las respuestas.

Esto supone varias ventajas frente a la típica 'shell inversa' orientada a conexión remota:
  • Muchos Firewalls personales validan las conexiones en función de los programas que las generan, si lanzas troyano.exe, y este programa se intenta conectar al exterior, probablemente 'saldrá en la foto', por contra si usas como títere Explorer, la probabilidad de que ese programa esté aceptado como 'valido' es muy muy grande.
  • En muchos escenarios (típicamente corporativos) no existe conexión directa hacia el exterior, se emplean proxys, normalmente con autenticación usuario/contraseña. Si empleamos Explorer para salir al exterior también podremos hacer un bypass a esta protección.
En el anterior post publicamos una pequeña prueba de concepto sobre el tema, en este caso le damos una vuelta mas al asunto y presentamos una herramienta para que te construyas tu propia 'Operación Aurora', su nombre: Folklorica, que haciendo uso de objetos OLé (perdón OLE), exporta al exterior un cmd.exe.

Folklorica funciona con arquitectura Cliente / Servidor:
  • Cliente: Se debe ejecutar en un entorno Windows, ejecuta un Explorer en modo oculto (no aparece la ventana) y envía peticiones al Servidor. Cuando el Servidor le indica que ejecute un comando, lo ejecuta, captura la salida y lo envía en otra petición http
  • Servidor: Se ejecuta en la maquina 'del atacante', simula ser un servidor HTTP para comunicarse con el cliente. Permite ejecutar comandos en el cliente.
Adicionalmente, toda la comunicación entre cliente / servidor está protegida con una capa de cifrado RC4 para que tanto los comandos enviados como las respuestas, no puedan ser interceptadas por sniffers o logs de proxys.


Y descargar la herramienta desde aquí
Leer más...

13 septiembre 2010

Destripando OAuth en Twitter

Avisados estábamos de que a partir del 1 de Septiembre en Twitter se dejaba de permitir la autenticación básica en sus aplicaciones. A partir de ese momento, a todos aquellos que éramos amiguitos de desarrollar scripts en perl o python por ejemplo para comunicarse con Twitter, nos surgió una traba nueva, o como se ha denominado en Internet: el OAuthcalipsis. Así pues, la versión anterior de Tweetme.pl, herramienta de la que os hablamos hace tiempo, también dejó de funcionar!

Anteriormente, con proveer un par usuario/contraseña de una cuenta válida de Twitter, en el desarrollo y la ejecución, todo era maravilloso de sencillo, aunque más inseguro, puesto que los ingredientes de la receta de la autenticación viajaban en claro (cuántas y cuántas veces habremos dejado de utilizar twitter en eventos con redes compartidas/peligrosas) a través de la red.

OAuth llega a solucionarle a Twitter este problema… y a generarnos otros tantos a los desarrolladores "amateur". Me explicaré un poco mejor. Para la autenticación mediante OAuth, es necesario proveer 4 elementos a Twitter:
  • Consumer Key -> El desarrollador ha de registrar, a nombre de una cuenta twitter, la aplicación que desee. Así se generará este identificador único de aplicación.
  • Consumer Secret -> Para evitar suplantar diferentes identificadores de aplicación (mediante un ataque de fuerza bruta, pero que muy muy bruta, 21 caracteres alfanuméricos con mayúsculas y minúsuculas), se complementa el par con una clave denominada Consumer Secret.
  • Access Token Key -> Para cada usuario, será necesario asociar un identificativo de token que permita suplantar para esa aplicación, a ese usuario mediante ese token para operar en Twitter (de hecho es posible definir la aplicación como de "sólo lectura" o "lectura/escritura" según las necesidades)
  • Access Secret -> Como par asociado al Token Key se establece un Token secret.
De esta manera, cuando un usuario requiera la utilización de una aplicación/script que use Twitter, será necesario proveer los cuatro elementos descritos.

Si somos los desarrolladores de la aplicación/script y sólo lo vamos a utilizar nosotros, no hay problema en obtener esos cuatro datos directamente y "hardcodearlo" en el código. El problema viene en el momento en el que se comparte/distribuye esa aplicación a terceros, ya sea como software libre o como software comercial.

Y es que resulta que Twitter no ve con buenos ojos el distribuir el consumer key y consumer secret de una aplicación determinada, de forma masiva. Twitter comunicó que, una vez que un par consumer key/secret son de dominio público, las revocarían (en su propia Revocation List) y la aplicación queda inutilizada.

Por otra parte, el par Access Token Key/secret es único para cada usuario que quiera hacer uso de esa aplicación. En el caso que N usuarios quieran utilizar una aplicación twitter con OAuth, deberán permitir a su usuario twitter que la aplicación identificada por $consumer_key y $consumer_secret lea/escriba en twitter con su identidad.

Para ello es necesario generar un par de Token key/secret distintos para cada cuenta, manteniéndose fijo el par Consumer key/secret que identifican a la aplicación. Para generar los access token key/secret es necesario haber hecho login vía web en Twitter con la cuenta que queramos y, al ejecutar la aplicación, ésta nos deberá proveer de una URL a la que acceder, que nos indicará que la aplicación X requiere nuestra aprobación para ser usada con nuestra cuenta. Después de aceptar, aparecerá un PIN que habrá que introducir en la aplicación para poder obtener el par token key/secret también necesarios para la aplicación.

Algunos lectores diréis: "No me cuadra esto que dicen en SbD porque yo no he actualizado mi cliente Twitter (como Tweetdeck por ejemplo) y todo me sigue funcionando igual y sin problemas. Además no he tenido que hacer cosas raras con los tokens y los consumer keys ni nada de esto". Pues efectivamente, tenéis razón. Y es que es posible, para algunas aplicaciones, utilizar xAuth, otra forma de autenticación que requiere que Twitter manualmente verifique y apruebe ese tipo de autenticación para dicha aplicación en concreto. Me recuerda un poco al procedimiento para añadir una aplicación en la appstore de Apple. Para ello hay que proporcionar, entre otras cosas el "consumer key" de la aplicación, pero que en el fondo son peticiones con POST vía HTTPS a Twitter.

En aplicaciones no "reconocidas" por Twitter o FOSS, aún no se ha solucionado el problema de la distribución del consumer key/secret en formato texto. Debido al concepto Open Source y al tener que poner a disposición de cualquiera el código fuente completo de la aplicación, y que si Twitter descubre un par consumer key/secret éstas serán deshabilitadas, me gustaría proponer un par de opciones, que por supuesto no son la panacea, puesto que son fácilmente bypasseables, pero al menos Twitter no podrá invalidar el par consumer key/secret porque no van en la propia aplicación en modo texto:

  • Ofuscar tanto el valor como el nombre del parámetro a la autenticación con OAuth mediante un ROT13 o cualquier otro mecanismo de cifrado. (Método propuesto por Marc Mims, mantenedor del módulo Net::Twitter para Perl)
De esta manera:

Net::Twitter->new(
   traits => [qw/API::REST OAuth RetryOnError/],
   decode_entities => 1,
   (   
    grep tr/a-zA-Z/n-za-mN-ZA-M/, map $_,
    pbafhzre_xrl => 'ZlPbafhzreXrl',
    pbahfzre_frperg => 'ZlFrperg',
   ),
);


En tiempo de ejecución se sustituye por:

Net::Twitter->new(
    traits => [qw/API::REST OAuth RetryOnError/],
    decode_entities => 1,
    consumer_key => 'MyConsumerKey',
    consumer_secret => 'MySecret',
);

Lo cual no es publicarlos en claro en el código.

  • Otra opción sería forzar que los valores de ambas variables estén en una ubicación remota. Puesto que para acceder a Twitter, es necesario que haya conectividad con Internet, antes de acceder a la autenticación, es obtener consumer_key y consumer_secret previamente y utilizarlos en la autenticación. Si Twitter bloquea dicho par, con generar uno nuevo, no es necesario bajar una nueva versión de la aplicación y "hardcodearlos" (que puede generar retrasos de semanas si nos referimos a una aplicación que esté en la AppStore de Apple por ejemplo) sino hacer un cambio en el servidor únicamente.

Para Tweetme.pl he implementado una mezcla de ambas, que no incumpla las exigencias de Twitter, pero que permita no tener que entregar un programa compilado y ofuscado (que finalmente sería comprometido igualmente por gente con capacidades de reversing), ni que utilice xAuth, por el papeleo y trámite que ello permite con Twitter (siempre y cuando aprueben xAuth en una aplicación Open Source, claro está). Además, en esta nueva versión se provee de un script para que sea sencillo obtener los tokens y personalizarlo para cada usuario.

Leer más...