Yuzi download

Con el Jet Lag de mi viaje a Miami me levante pronto para aprovechar el tiempo y trabajar antes de comenzar las actividades planificadas para el día. De hecho, madrugué tanto que me dio tiempo hasta escribir este artículo durante el desayuno y dejarlo listo antes de comenzar el día, que todo es planificarse. La historia comenzó cuando me quité el grueso de los correos electrónicos y las acciones más importantes. Como siempre, decidí echarle un ojo a mi pasión, la seguridad informática. Esto es algo que realizo sistemáticamente todos los días. Leo, pruebo o compruebo algo que tiene que ver con Seguridad Informática, Hacking, y desde hace unos meses Big Data antes de comenzar o terminar el día. Obligatorio.

En este caso me puse a revisar un correo de mi amigo rootkit (que sigue aceptando la invitación que os hice en Mayo a todos para publicar vuestros artículos en el lado del mal) que me hablaba de un buzón temporal de esos que se usan para registrarse en sitios en los que no deseas dejar ningún rastro. Normalmente se utilizan en procesos de descarga que solicitan una dirección de contacto o para darse de alta en servicios que no quieres que sepan quién eres realmente. En este caso se trata del buzón de YOPMail.

La gracia de estos buzones es que normalmente se crea un alias, y durante un tiempo concreto se mantiene vivo. Una vez que se acaba el tiempo, generalmente asociado a una sesión, el buzón se elimina y con él todos los mensajes de correo electrónico que se hayan podido recibir hasta ese momento. Sin embargo, si se recrea ese buzón con el mismo alias, o si realmente el buzón no se elimina, entonces cualquiera podría investigar y saber qué está pasando por ahí y, tal vez en tiempo real, conseguir sacar alguna información jugosa. Esto es algo que Alejandro Ramos (@aramosf), en una de sus múltiples investigaciones que le llevarían más tarde a escribir con esas ideas el libro Hacker Épico, realizó hace mucho tiempo y publicó en un artículo titulado: "En lo qué pierdo el tiempo: Mailinator".

El caso del buzón de YOPMail es de esos que no solo reutilizan los buzones, sino que los alias son totalmente públicos y cualquiera puede conectarse a lo que está recibiendo ese buzón en todo momento, así que hay que tener mucho cuidado con lo que conectas allí. Quiero decir, cualquier alias de YOPMail es de todos. En mi caso, en una primera aproximación, me conecté a un buzón para ver qué llegaba.

Una cuenta de Steam asociada a un alias de YOPMail

Como podéis ver, lo que suele llegar casi siempre es SPAM, newsletters, etcétera, uno de los motivos por los que proliferaron este tipo de servicios. Pero, entre la lista de esos mensajes, encontré uno que me llamó la atención. Era un mensaje de Steam para recuperar la contraseña de una cuenta. 

No tiene mucho sentido que alguien ponga una cuenta de un servicio como Steam asociado a un mensaje de correo electrónico de un servicio como YOPMail, a menos que no conozca como funciona este servicio o que la cuenta que se esté asociando haya sido robada previamente, y el atacante no quiere dejar ningún rastro de ella. 

Lo cierto es que quería saber si esto era cierto o se trataba de un ataque de Phishing a uno de los usuarios de Steam, así que tras revisar el mensaje y ver que no parecía tener trampa ni cartón, me conecté y solicité la recuperación de contraseña para esa cuenta y me llegó, de nuevo al buzón de YOPMail, el One-Time Password para recuperar la cuenta.

Una vez introducido el sistema Steam te deja ver todos los usuarios y cuentas conectadas a esa dirección de correo electrónico para que se pueda cambiar, una a una, la contraseña de todas ellas. Como podéis ver, la lista es bastante grande.

No cambié la contraseña de ninguna de las cuentas, e hice un reporte a Steam porque quizá era una cuenta robada, o una cuenta que funciona con tarjetas de crédito robadas, o similar. Si no, si es de un usuario legítimo, usar YOPMail para recuperar la cuenta no parece lo más inteligente, así que Steam podrá decidir qué debe hacerse en cada caso.

Saludos Malignos!

Hace 11 años, exactamente en el año 2005 nació el popular RAT (Remote Administration Tool) Poison Ivy. Las herramientas RAT son un tipo de malware creado especialmente para controlar totalmente un equipo desde una consola centralizada. Su evolución natural les llevaría a convertirse en las populares Botnets de equipos Zombie, donde desde un Command & Control Panel se llegan a gestionar millones de equipos infectados. En el año 2005, cuando aparece la primera versión de Poison Ivy, se empiezan a extender las técnicas de Reverse Shell, o lo que es lo mismo, que el llamado "Server" que se instala en la máquina infectada, es quien realiza la conexión al panel de control para recibir las órdenes y no al revés, como se hacía en malware clásico anteriormente.

Poison Ivy fue muy popular durante los años en los que  estuvo en plena evolución, hasta llegar al año 2008 donde apareció su última release, la versión 2.3.2. Después vendrían muchos más que copiarían la mayoría de sus funciones. Entre las muchas que traía la herramienta Poison Ivy estaba un módulo de vigilancia que permitía al atacante activar tu Webcam y grabarte en tu intimidad - y este no fue el primero que lo hizo -. Aquí tenéis una captura hecha por la webcam de una persona infectada con Poison Ivy 2.3.2, del año 2008.

El primer día que yo descubrí que con herramientas como Poison Ivy era tan fácil para un atacante activar tu Webcam la tapé. Desde hace más de una década llevo la Webcam de todos mis equipos tapados, lo que me generó que mucha gente me preguntara desde ese momento por qué lo hacía. Las nuevas herramientas RAT que fueron siguiendo la estela de Poison Ivy fueron añadiendo todas la misma función, y ver ya esa opción entre la lista de posibilidades no sorprende a nadie de este mundo. En la imagen IndSocket y en este otro artículo tienes Incognito RAT que también funciona con equipos Mac OS X infectados e incluso se controlaba desde un iPhone.

En el año 2011, ya con mi blog abierto, descubrí la existencia de un foro en el que la gente se dedicaba a infectar personas con RATs, capturarles con la Webcam y compartir el material con todos. Las fotos eran brutales, e incluso había vídeos subidos a Youtube - hoy retirados - que mostraban el proceso completo. Si te aburres, abre Youtube y busca vídeos y tutoriales de RAT. Te sorprenderá ver la gran cantidad de esta familia de malware que existe con la capacidad de grabarte en tu casa y hemos visto que hasta vecinos lo usaban para espiar a sus víctimas.

A partir de ahí, sistemáticamente he ido explicando en multitud de ocasiones el riesgo de no taparse la Webcam, además de explicar que el número de fallos que aparecen y que pueden permitir a un atacante infectarte para activar la Webcam es alto. En el año 2011 un bug en Adobe permitía hacer lo mismo.

En muchas demostraciones, como en el evento de Creo en Internet en el año 2011 o en el Security Innovation Day 2014, he hecho demos con malware que infecta el equipo y activa la Webcam usando Metasploit, que tiene módulos para eso desde hace infinidad de tiempo, e incluso algún ciberespía ruso ha salido retratado en un proceso de doxing con el que le han activado hasta la webcam de su casa - con sus cortinas último nivel de moda -.

Algunos creen que las Webcam con las luces son más que suficientes, porque si se enciende la luz lo ves, pero incluso hay muchos casos que han demostrado cómo es posible llegar a encender la Webcam sin encender la luz. Al final si hay software de por medio hay posibilidad de que haya un bug para saltarse el proceso.

Otros creen que por tener Linux ya no es necesario tapar la Webcam como si el software fuera diferente en ellos. Lo curioso es que hace años, pudimos ver ya documentos de la NSA que recomendaban a todos los miembros del gobierno que taparan la webcam y el micrófono para evitar este tipo de espionaje.

Entre los hackers esto es muy común desde hace años y en esta foto tomada al equipo de Moxie Marlinspike cuando era responsable de seguridad de Twitter se podía ver que él hacía lo mismo con  la Webcam de su Mac OS X.

Ahora la gente ha visto que Mark Zuckerberg también tapa la webcam y el micrófono de su MacBook y ha vuelto la gente a preguntarse si será excesivo o no hacer esto con su equipo, tablet y dispositivo móvil, que el malware para Android también puede hacer estas cosas.

Yo llevo mucho tiempo con la mía tapada, e incluso regalamos para los eventos el popular iPatch con Latch para los asistentes, pero tú eres libre de hacer lo que quieras. Eso sí, "Si no tapas tu Webcam, ponte sexy para salir en Internet".

Saludos Malignos!

Una de las partes que se revisa en detalle cuando se hace un pentesting a una compañía es el servidor DNS. Los registros que allí se encuentran pueden dar mucha información. Desde conocer la infraestructura del Active Directory - buscando los registros que genera este servicio - o la infraestructura de la red - buscando los registros PTR, SRV, WPAD o el Primary Name Server -, hasta llegar a conocer información sobre la versión del DNS, el software sobre el que está construido el servicio, dónde navegan sus usuarios, el software de los clientes - inluidos los antivirus -,  etcétera. Y entre otras, las opciones de seguridad en los servicios de correo electrónico.

Es en este último servicio de correo electrónico, donde más información se puede obtener sobre la seguridad del mismo. Desde información de la infraestructura con los servicios MX y SPF, hasta las políticas antispoofing y antispam con la información de las políticas en las configuraciones DKIM, SPF o SenderID o DMARC (y en el futuro con los registros de SMTP STS). Todos ellos permiten saber a un atacante si va a poder realizar con facilidad o dificultad un ataque de Spear Phishing a la organización.

A todos ellos, hay que añadir un par de registros DNS que pueden ayudar a un atacante a reconcoer que la empresa está utilizando Microsoft Office365 o Windows Live Mail. Los registros son de tipo TXT y son necesarios para validar el dominio de la organización.

Esta validación es obligada por Microsoft cuando contratas un dominio nuevo personalizado para Office365, para evitar que nadie suplante el dominio y basta con hacer una búsqueda de registros TXT en el dominio objetivo para ver si están allí. Son los que comienzan por "MS=XXXXXXXX"

Esta es la forma en la que Microsoft valida el dominio. En el caso de que sea un dominio del antiguo Windows Live Mail, el registro tiene un aspecto como "v=msv1 t=XXXXXXXXX", pero también indica la existencia del backend de Microsoft. 

Para detectar Gmail, basta con mirar el DNS y fijarse en dos registros TXT. El primero el de "Google-Site-Verification", que indica que se ha validado el dominio con Google - pero no es concluyente porque se puede validar el domino sin tene el correo en Gmail - y el registro SPF, donde debe aparecer incluido el valor _spf.google.com como uno de los enviadores de correo autorizados, ya que ese registro de Google es el que incluye las direcciones IP utilizadas por Gmail para enviar los mensajes de e-mail.

Por supuesto, que estén los registros DNS ahí puede no significar nada si el administrador del servidor DNS los dejó allí olvidados después de validar los dominios o configurar el servicio, pero es un indicio más que útil en la mayoría de los casos. ¿Conoces algún otro registro DNS de validación que obligue a crear algún sistema en los DNS de las organizaciones?

Conocer que una organización tiene como plataforma Office365 o Gmail es útil para aquellos ataques de Spear Apps que se quieran realizar contra una organización, como ya os contamos en la serie de artículos de SAPPO: Spear Apps to stealth OAuths Tokens. Es necesario, ya que dependiendo de cuál sea el ID Provider, la app maliciosa y la API que habrá que utilizar será distinta y, con solo mirar estos registros se puede saber qué utiliza la organización.

Saludos Malignos!

Hace tiempo que publiqué el artículo que explicaba que cuando usas Google Authenticator, si no haces ningún intento de resolver el valor del TOTP, Google no te deja ningún rastro. Esto es una mala idea de seguridad porque entonces nunca serías consciente de que alguien te ha robado la contraseña y está solo a un paso - robarte el segundo factor con alguno de los trucos que contaba ayer - de quitarte tu cuenta. Hoy quise revisar cómo gestiona Microsoft esta situación en Hotmail, a.k.a Windows Live Mail, a.k.a. Outlook.com, para ver si lo hacía bien o lo hacía mal. Y lo hace mejor que Google.

Si has visto el título, ya te podrás imaginar que en este caso, el log de tu cuenta de Microsoft sí que refleja correctamente la situación que yo que describo. Para comprobarlo, tenemos que ir a la página de Actividad Reciente de tu cuenta, donde que da información de todos los accesos que se hacen a ella y veremos el último acceso correcto a la cuenta - he borrado toda la información anterior, así que solo me muestra el último acceso -.

Ahora vamos a abrir otra sesión desde otro navegador en Modo Incógnito y ponemos correctamente la contraseña, pero nos quedamos en la parte donde se nos solita la verificación del segundo factor de autenticación - que en este caso es un OTP vía SMS o vía e-mail asociado -. Y no respondemos nunca a esta pregunta porque somos un atacante y aún no hemos resuelto el problema de robar el 2nd Factor Authentication.

Si refrescamos el listado al que podemos acceder vía Actividad Reciente en nuestra cuenta de Microsoft, veremos que ahora aparece una entrada con el identificador de "Security Challenge", lo que refleja justo esta situación.

Si nos vamos a la ayuda de Microsoft veremos que el log al que podemos acceder es de lo más florido y refleja cualquier situación de seguridad que haya tenido que ver con nuestra cuenta. Desde el acceso correcto o el Security Challenge hasta cualquier cambio que suceda en alguna de las propiedades de seguridad de la cuenta. La lista completa la tienes haciendo clic en la imagen.

En definitiva, que me gusta más este log que el que tiene Google, aunque por desgracia la mayoría de los usuarios no revisan estos detalles de su cuenta periódicamente. Aquí os dejé unas acciones extras para saber si te estaban espiando tu cuenta de Hotmail/Live/Outlook o Gmail ahora mismo.

Saludos Malignos!

A la hora de impartir una charla o conferencia, con demostraciones prácticas utilizando un smartphone, es muy aconsejable que todo el auditorio pueda ver la pantalla del smartphone para comprender mejor todas las prácticas que realices con él terminal. Para los usuarios de iPhone, iPad, lo más habitual suele ser utilizar algún software tipo Reflector junto con AirPlay en sus dispositivos. o directamente usar QuickTime con iPhone como webcam. Como alternativa, los usuarios de Android pueden utilizar algún programa similar a Mobizen para hacer lo que se conoce como el "Screen Mirroring" y así poder compartir la pantalla de su smartphone con el resto del auditorio.

Figura 1: Comparte sólo la pantalla de tu Android, no tus passwords

Compartir la pantalla del tu dispositivo Android utilizando Mobizen es muy sencillo y puede utilizarse también para grabar los mensajes de SnapChat o Telegram con autodestrucción, por eso es muy popular. Basta ir a la página del fabricante, instalar la aplicación en el ordenador portátil que se comunicará con el dispositivo Android e instalar la app de Mobizen en el dispositivo móvil.

A partir de aquí, hay que configurar la aplicación instalada en el ordenador portátil. Durante el proceso de instalación, si se lee el contrato de licencia, uno de sus artículos dice que la compañía será la encargada de proteger los datos de carácter personal de sus usuarios. Entiendo que entre esos datos personales, están la cuenta de correo y contraseña utilizada por el usuario.

Figura 2: Término que indica al usuario final que la compañía protegerá sus datos de carácter personal

Una vez instalada la aplicación en el ordenador portátil, ésta solicita una cuenta de correo y una contraseña en el proceso de configuración. Cualquier persona no familiarizada con la tecnología o seguridad informática es muy probable que introdujera como contraseña la misma que utiliza en la cuenta de correo usada en Mobizen.

Figura 3: Solicitud de cuenta de correo y password

Según el artículo 7 de la Figura 2, aunque se introdujera durante el proceso de configuración la misma password que la de la cuenta de correo del usuario, no habría de qué preocuparte. Si se analiza el tráfico de red, tras introducir una cuenta de correo electrónico y contraseña, la aplicación envía por medio de una conexión HTTP al servidor un objeto JSON con el correo del usuario y la contraseña en texto claro.

Figura 4: Cuenta de correo y password enviados en texto plano vía HTTP

Tras la finalización de la instalación de la aplicación en el ordenador portátil, siempre que se quiera utilizar la aplicación para compartir la pantalla del dispositivo Android con el resto del auditorio, será necesario volver introducir la cuenta de correo con la contraseña, si hemos decidido que la aplicación no recuerde esta información.

Figura 5: Login con usuario/password, Google+ o Facebook

Como se ve en la figura anterior, si disponemos de una identidad digital en Google+ o Facebook, también podemos utilizarlas para configurar la aplicación, pero la securización de los datos de acceso a las identidades digitales anteriores corresponde a Google o Facebook, ya que es contra sus servidores con los que realiza la validación de esas cuentas.

Figura 6: Autenticación segura frente a Google

Es más, conociendo la dirección IP del servidor donde se mandan las cuentas de correo electrónico y las contraseñas, bajo HTTP, realizando fuzzing contra el servidor Apache podrían descubrirse recursos tan interesantes como los siguientes:

Figura 7: Recursos descubiertos en el servidor Apache de Mobizen

Conclusiones

Aunque en las condiciones del contrato de cualquier aplicación te garanticen que van a proteger tus datos de carácter personal, no te fíes, puede ser que tu información viaje en texto claro y cualquiera de la Wi-Fi en la que estás conectado pueda verlas o que al final, las medidas que hayan implantado en los servidores no sean tan eficientes.

Además, cuando impartas una conferencia y utilices alguna aplicación para que el auditorio vea la pantalla de tu dispositivo móvil, piensa que puede que al menos uno de los asistentes puede que esté conectado a la red Wi-Fi del auditorio intentando robar datos de los demás asistentes conectados a la misma red Wi-Fi, así que, si necesitar Internet para tus demostraciones prácticas, procura usar tu VPN y si es posible tu propia conexión con tu smartphone haciendo tethering.

Autor: Amador Aparicio
Twitter: @amadapa

La historia que os voy a contar es un ejemplo de cómo los detalles de seguridad en las tecnologías pueden acabar por tumbar muchas de las conclusiones que damos por ciertas usándolas. En el caso de hoy, voy a hablaros otra vez de algo que muchos ya saben que es inseguro, pero que sin embargo es parte fundamental de nuestras vidas hoy en día, las señales GPS que reciben nuestros dispositivos. De hoy va la historia en la que ha estado trabajando el investigador español JAEP Erratum y que os voy a explicar.

Las señales GPS las utilizamos en todos los servicios de navegación que llevan nuestros dispositivos, desde los servicios como Waze, Google Maps, Apple Maps o TomTom, hasta los detectores de radares de velocidad que se venden y van en cualquier lugar del coche para avisar al conductor de un posible control oculto en la carretera. Pero no solo eso, se utilizan en servicios de las redes sociales, en publicidad dirigida, en el mundo de los juegos, etc...

Esta señal GPS, como hemos visto muchas veces, se puede falsificar fácilmente en el terminal por el dueño del mismo, por lo que algunos servicios podrían ser abusados. Este fue el ejemplo del caso de Tinder, lo que permite a una persona localizar a otra en cualquier lugar del mundo, ligar con todo un país o perseguir a una víctima con una especie de drone de vigilancia. También, manipulando la señal en el terminal podría afectar a la validez legal de los de certificación digital de fotografías tomadas en una ubicación, como en el caso de Stamphoto, pero esto, como vamos a ver, también se puede hacer remotamente con un ataque de SDR-RTL.

Las tecnologías de SDR (Software Defined Radio) permiten a un atacante emitir y escuchar señales en frecuencias del espectro utilizadas por diferentes tecnologías que dan soporte a comunicaciones de toda índole y son una pieza clave en el Hacking de Comunicaciones Móviles. Como ya vimos, un ejemplo sencillo es utilizar un sistema SDR-RTL para poder escuchar las conversaciones GSM y hasta poder capturar los mensajes SMS que se envían por la red. Esto, podría ser utilizado para robar cuentas de de servicios de Internet protegidas por mensajes SMS si el atacante está cerca de la antena por la que la víctima va a recibir la comunicación.

Ataques GPS Spoofing con SDR

También se pueden atacar otro tipo de señales, como las del mundo IoT - de las que podremos hablar largo y tendido en otros artículos, pero hoy, como os podéis imaginar por el cariz que lleva la historia, las señales de las que hay que hablar son las de GPS, que no están cifradas ni protegidas. Esto permite que cualquier atacante que esté cerca tuya pueda inyectarte una señal falsa GPS en el terminal, mandando tu dispositivo GPS a cualquier ubicación del mundo y, lo que es peor, a cualquier fecha.

Esto es porque la señal GPS también se utiliza en muchos terminales para configurar la fecha y la hora - como por ejemplo los dispositivos iOS -. En esta conferencia impartida en DefCON 23 podéis ver todos los ataques SDR contra GPS que se pueden realizar. 36 minutos de learn&fun.

Manipular la fecha y la hora vía GPS de un terminal iPhone puede hacer que todas las apps que tenga un sistema empiecen a fallar, dejen de funcionar, o comprometan a una persona a la que un atacante puede situar en un lugar y una fecha concreta ante los ojos de un analista forense que tire de herramientas para analizar los datos de un terminal.

Ataques GPS Spoofing con SDR a iPhone

En este vídeo hecho por JAEP Erratum se puede ver cómo remotamente, un atacante puede enviar señales falsas GPS a una víctima con su iPhone - utilizando la herramienta sdr-gps-sim y tenerla paseando por Barcelona, París o cualquier lugar del mundo.

Por supuesto, este ataque afectaría a cualquier servicio de certificación de ubicaciones GPS, o a los sistemas sociales - podrías tener a tu amigo adicto Tinder toda una noche buscando pareja con chicas del otro lado del mundo -, o en el caso de iOS 5 la señal GPS también se podía cambiar desde las señales 2G/Edge/GPRS, y esto producía un efecto muy curioso en iPad e iPhone, ya que se engañaba al sistema y te permitía acceder a las fotografías sin desbloquear la pantalla del terminal.

¿Te imaginas que alguien desde un puente de una autopista justo antes de una salida se pusiera a enviar señales GPS que situaran a los coches desplazados 300 metros? Podríamos estar hablando de la generación de un problema serio, ya que todos los conductores podrían sufrir una distracción de alto peligro. Pero es que se puede hacer que el terminal iPhone deje de funcionar con todas su apps. Por ejemplo, en este otro vídeo de JAEP Erratum se puede ver cómo enviar a cualquier iPhone al futuro. En concreto, al 16 de Agosto del año 2029, justo al lado del Santiago Bernabéu en la bella ciudad de Madrid - supongo que para ver algún partido del Real Madrid -.

Dicho esto, ya hay muchas iniciativas para cambiar los sistemas GPS por sistemas más robustos en los que los terminales clientes validen a los emisores de la señal GPS, y hay medidas de contención para detectar señales falsas en los sistemas operativos de los smartphones, pero la realidad es que como se puede ver, a día de hoy las cosas están como están.

Saludos Malignos!