Este nuevo ataque phishing permite bypassear 2FA

Desde hace unos años los dobles factores de autenticación nos han ayudado a proteger nuestra identidad digital de una forma rápida y sencilla. A pesar de la dura capa de seguridad que resultan ser los 2FA unos expertos han demostrado que no son completamente infalibles y es posible engañar a una víctima para que revele sus credenciales e incluso facilite su código OTP. Este ataque se demostró por primera vez en la conferencia Hack in the Box que tuvo lugar en pasado mes en Ámsterdam. El video de la demostración fue publicado en YouTube y busca resaltar el hecho de los ciberdelincuentes son cada vez mejores rompiendo las capas extra de seguridad a pesar de que usemos herramientas como 2FA.

El hack empleado en la demo para romper 2FA utiliza una combinación de dos potentes herramientas llamadas Muraena y NecroBrowser, las cuales trabajan en tándem para automatizar el ataque. La combinación de estas dos herramientas trabaja a la perfección ya que una realiza el ataque y la otra realiza un seguimiento de la sesión de la víctima. Muraena es la herramienta encargada de capturar el tráfico entre la víctima y el sitio web actuando como un proxy. Una vez que Muraena lleva a la víctima hasta una página falsa (de aspecto similar a la auténtica) solicitará a los usuarios sus credenciales y el código OTP, al igual que lo haría la página original. En cuanto Muraena ha autenticado la cookie de la sesión comienza el trabajo de NecroBrowser, una herramienta capaz de crear ventanas para mantener el seguimiento de miles de cuentas.

Figura 1: Demostración del ataque en la conferencia Hack in the Box

Su autor también ha publicado en GitHub una demostración del ataque para que otros desarrolladores puedan analizar cómo funciona detalladamente. Varios expertos en el ámbito de la ciberseguridad han asegurado que estas herramientas facilitan mucho el trabajo a los atacantes “amateur”. También han querido resaltar que no hay razones para perder la confianza en los dobles factores de autenticación o en la biometría ya que dificultan mucho el trabajo de los atacantes y son una mejor alternativa que utilizar únicamente un usuario y una contraseña. Independientemente del método que escojas para proteger tus cuentas desde Seguridad Apple queremos recordarte la importancia de una rápida actuación si sospechas que alguna de tus cuentas puede haberse visto comprometida.

Un fallo de privacidad permite a algunas aplicaciones de iOS utilizar tu cámara sin tu permiso

Recientemente Félix Krause, fundador de Fastlane y reconocido desarrollador e investigador de seguridad ha descubierto una vulnerabilidad que afecta gravemente a la privacidad de los usuarios de dispositivos iOS. El método utilizado por Apple para manejar el acceso a su cámara y grabaciones está dejando a muchos de sus fans vulnerables a ser espiados a través de aplicaciones que acceden a su cámara sin proporcionar ninguna clase de aviso o notificación. Esto se debe a que Apple solo solicita el permiso para acceder a la cámara una vez y si se acepta esto le da completa libertad a algunas aplicaciones para activar y desactivar la cámara en cualquier momento.

“Los usuarios de iOS normalmente autorizan a las aplicaciones a acceder a la cámara tan pronto como las descargan. Estas aplicaciones, ya sean de mensajería u de otro tipo pueden reconocer con facilidad la cara del usuario, hacer fotos o utilizar tanto la cámara delantera o trasera para hacer streaming sin el consentimiento del usuario”

El peor escenario que podría darse según Krause, es el de una app que al instalarla nos solicita acceso a la cámara para tomar una foto de perfil y luego sigue tomando fotos del usuario constantemente de forma encubierta. Krause se dió cuenta de que con la última versión de iOS una aplicación puede hacer cosas como detectar la presencia de una segunda persona y emitir videos y fotos en directo con cualquiera de las cámaras del dispositivo, incluso podría acceder los sensores de reconocimiento facial. Hasta ahora, el único modo de prevenir que una aplicación de iOS pueda grabarte sin tu consentimiento es cubrir las cámaras físicamente para inhabilitar sus sensores. También es recomendable revocar el acceso a la cámara de todas las aplicaciones y tomar las fotos desde la cámara y luego importarlas.

Figura 1: Solicitud de acceso a la cámara de iPhone.

Para evitar este tipo de comportamientos Krause sugirió el uso de OTP para acceder a la cámara y la instalación de leds que se enciendan cuando la cámara este grabando. Esta no es la primera vez que Krause destapa un fallo de privacidad de estas magnitudes en iOS, recientemente ha mostrado como los metadatos almacenados por las fotografías de tu galería pueden servir para realizar un mapeo de los lugares que has visitado.

Latch: Un servicio para proteger tus identidades digitales

Ayer mismo hablábamos por aquí del problema que surge cuando se exponen identidades digitales en Internet debido a que se haya hackeado algún gran servicio en la red. Si esto sucede en identidades en las que se ha reutilizado una contraseña o se ha utilizado algún método de generación de contraseñas que pueda ser descubierto por un atacante, el riesgo crece exponencialmente. Proteger una identidad con una contraseña no es una buena idea, como ya decía el periodista de la revista Wired Mat Honan que fuer "duramente hackeado" cuando le robaron su contraseña de Apple ID con un truco de ingeniería social. Para proteger correctamente las identidades se deben usar soluciones de segundo factor, y Latch proporciona una app para ponder una protección de segundo factor a cada una de las identidades de Internet con la menor de las complejidades.

Su nombre, "pestillo" en inglés, es una buena metáfora de su funcionamiento. La idea es que un usuario que sea dueño de una identidad pueda, desde su usuario de Latch, poner una identidad a ON u a OFF a su antojo desde una app en el terminal móvil. Con esta protección, aunque un atacante haya podido robar una identidad en Internet, si el Latch está OFF, aunque tenga el usuario y la contraseña no conseguirá acceso a la identidad. Aún más, el mero hecho de hacer uso de la identidad robada generaría una alerta que le llegaría al terminal móvil del dueño, alertándole de que su identidad está expuesta, lo que ayudaría a reducir el fraude y detectar el robo de identidad de forma temprana.

Figura 1: Arquitectura General de Latch

Aún no se ha publicado la lista de sitios en los que está integrada la tecnología, pero actualmente están disponibles los plugins para frameworks como PrestaShop, Joomla!, DotNetNuke, RedMine y WordPress, con lo que si entras en el area de Developer de Latch y te sacas una cuenta gratuita podrás instalarlo en cualquiera de esos entornos. Además, también están disponibles los SDKs para los principales lenguajes de servidor, como Python, Java, PHP, C# o C, y está documentada y explicada en detalle el API necesaria para integrar Latch en cualquier solución a medida que tengas en tu entorno.

Figura 2: App de Latch para iOS

Si quieres probarla como un usuario más, se ha creado un falso banco online llamado Nevele donde puedes sacarte una cuenta, y ponerle un Latch desde alguna de las apps de iPhone o Android que ya están disponibles. Para ello, una vez instalada la app tienes que sacarte una cuenta de usuario de Latch y seguir las indicaciones que se explican en la web. Tienes un ejemplo del proceso en El lado del mal. También está integrado el plugin de PrestaShop en la tienda online de 0xWord, así que si quieres probarlo más, puedes sacarte una cuenta allí, y en las opciones de "Mi Cuenta" encontrarás la opción de "Proteger la cuenta con Latch". Ya puedes comenzar a "Latchear" unas cuentas para comenzar el día.

Entrevista a Steve Dispensa de PhoneFactor

Recientemente el mundo entero se hizo eco de la aparición de PhoneFactor para iPhone, una solucion de autenticación fuerte de doble factor basada en terminales móviles. PhoneFactor es la compañía lider en soluciones de autenticación fuerte para la empresa implementando doble factor de autenticación basado en teléfonos móviles. A nivel mundial proporciona estos servicios a gobiernos, instituciones médicas, bancos, empresas y cualquier aplicación web que lo requiera. El objetivo de esta empresa es convertir el dispositivo que todo el mundo tiene, el teléfono, en una herramienta que ayude a securizar de forma efectiva y a un buen coste los sitemas de autenticación de las organizaciones.

Uno de los co-fundadores de PhoneFactor y CTO de la compañía es Steve Dispensa, es un speaker y escritor habitual sobre la seguriad de los sistemas de autenticación, y fue el co-autor del RFC 5746, que solucionó al debilidad de TLS-renegotiation que descubrió junto con su compañero Marsh Ray, y que les llevó a las primera página de las noticias por encontrar un fallo de seguriad explotable en las conexiones TLS. Además, Steve Dispensa tiene la curiosidad de haber sido premiado cinco veces por Microsoft como MVP (Most Valuable Professional) en el area de desarrollo de drivers para el kernel.

Steve Dispensa

A parte de todo esto es un tipo simpático y cercano, con el que nuestro compañero Chema Alonso tuvo el gusto de hacer amistad en la conferencia Troopers de alemania, donde fueron speakers los dos últimos años. Así que, aprovechándose de este nexo de amistad, le pedimos que le hiciera una entrevista a Steve Dispensa sobre la solución y aquí están las preguntas y las respuestas en Español e Inglés.

1.- First of all, Steve, I would like to make clear what are the advantages of using the phone as second authentication factor instead of a RSA Tokens of Secure ID.

RSA tokens (SecurID), and similar products like OATH tokens, soft token apps, etc., are quite common, and they all work approximately the same way: the token generates a one-time passcode (OTP), which is usually a six-digit number, every minute or so. The user enters the number into the application when prompted, proving that the user is in control of the token.

The most common password-stealing attacks these days involve malware (sometimes called “man-in-the-browser” attacks). The problem with OTPs is that they are re-entered into the same computer that is infected with the malware, so the malware simply steals the OTP and forwards it onto an attacker somewhere else in the world who’s ready and waiting. The attacker then logs in using the stolen OTP.

This isn’t theoretical, either – banks all around the world have been attacked in this way, resulting in real losses to banking customers.

  

1.- Lo priemro de todo, Steve, me gustaría que quedaran claras cuáles son las ventajas de utilizar un teléfono como segundo factor de autenticación, en lugar de utilizar un Token RSA de SecureID.

Tokens RSA (SecureID), y productos similares como los tokens OATH, applicaciones de soft token, etc... son bastante comunes, y todos ellos funcionan aproximadamente de la misma forma: El token genera un código de paso de un solo uso (OTP), normalmente un número de 6 cifras, más o menos cada minuto.

El ataque más común hoy en día para robar las contraseñas incluye el uso de malware, los llamados “ataques de man in the browser”. El problema con los OTP es que estos deben ser re-ingresados en la misma máquina que está infectada con el malware, por lo que el software malicioso símplemente roba también el código OTP y lo envía a un atacante en algún lugar del mundo que está listo y esperando. El atacante se conecta en ese instante utilizando el OTP robado.

Este no es un ataque teórico, bancos por todo el mundo han sido atacados hoy en día de esta froma, generando pérdidas reales para los clientes del banco.

2.- Lot of companies are using SMS as a second authentication mechanism. What are the security risks related to SMS as a second factor?

SMS is certainly better than nothing, but the usual way SMS is implemented involves sending an OTP that is typed back into the user’s computer. So, the same considerations apply – if the user’s computer is infected with malware, that malware has direct access to the OTP, and can steal it on behalf of an attacker.

Not all SMS is vulnerable to this attack, though. PhoneFactor’s own SMS solution is two-way out-of-band, meaning that users reply directly to received messages with another SMS. This system isn’t vulnerable to those attacks.

2.- Michas empresas están utilizando los SMS como un segundo mecanismo de autenticación. ¿Cuáles son los riesgos de seguridad relativos al uso de SMS como segundo factor de autenticación?

Usar SMS es ciertamente mejor que nada, pero la forma habitual en la que los códigos SMS son implementados es para enviar un OTP que se vuelve a introducir en la computadora del suairo. Así que la misma consideración anterior se aplica: si la computadora del usuario está infectada con malware, ese mismo malware tiene acceso directo al OTP, y puede robarlo en nombre del atacante.

Aunque no todos los mensajes SMS son vulnerables a este ataque. PhoneFactor tiene su propia solución de envío de SMS de doble sentido y por un canal alternativo (out-of-band), lo que significa que el usuario responde directamente a los mensajes SMS recibidos con otro mensaje SMS. Este sistema no es vulnerable a ese tipo de ataques.

3.- What are the security protections in PhoneFactor?. Do you have any extra protection against man in the mobile attacks?

Good question. If the user is using a computer to access the protected app and a phone to handle the authentication, the job of an attacker is twice as hard, because he has to compromise both devices in a simultaneous and coordinated fashion in order to gain control of both of the factors (password / phone). If the user is running an app from the same phone that handles the authentication, the attacker still has to compromise both the affected application and the PhoneFactor app. This is an improvement on soft-token systems that have you type an OTP back into the (potentially infected) phone browser, which can be compromised by a single piece of malware.

Platforms like iOS make this separation a little easier, which is one of the reasons we’ve launched the iOS app first. But in any case, this kind of architecture is always going to be safer than simple passwords or OTP tokens/soft tokens.

3.- ¿Cuáles son las medidas de seguridad en PhoneFator? ¿Tenéis alguna protección extra contra ataques de man in the mobile?

Buena pregunta. Si el usuario esta utilizando una computadora para acceder a una aplicación protegida y un teléfono para manejar la autenticación, el trabajo del atacante es dos veces más duro, porque tiene que comprometer ambos dispositivos de manera coordinada y simultanea para conseguir obtener el control de ambos factores (contraseña / teléfono). Si el usuario está ejecutando una aplicación del mismo teléfono que gestiona la autenticación, el atacante aún tendría que comprometer la aplicación y la palicación de PhoneFactor. Esta es una mejora respecto a los sistemas de token por software en los que se debe introducir el OTP de nuevo en un navegador del teléfono (potencialmente infectado), que puede ser comprometido de nuevo, por una única pieza de malware.

Plataformas como iOS hacen esta separación mucho más fácil, que es una de las razones por las que hemos lanzado la aplicación para iOS antes. Pero, en cualquier caso, este tipo de arquitectura siempre va a ser más seguras que contraseñas simples o tokens OTP por hardware o por software.

Funcionamiento de PhoneFactor

4.- Why an app for Apple devices? Are you planing to release PhoneFactor in Android, BlackBerry or Windows Phone?

We started with iPhones for a few reasons. They have a lot of market share, of course, and particularly among our enterprise users. iOS also has a stronger security model than, e.g., Android, so we felt comfortable starting there. Additional phone OSes will be supported in the future, although release dates are not set yet.

4.- ¿Por qué una aplicaicón para dispositivos Apple? ¿Tenéis planes para lanzar PhoneFactro en Android, BlackBerry o Windows Phone?

Comenzamos con iPhones por unas pocas razones. Ellos tienen una gran cuota de mercado, por supuesto, y particularmente entre los usuarios de nuestras empresas. IOS además tiene un modelo de seguridad más fuerte que, por ejemplo, Androd, así que nos sentimos muy cómodos comenzando por aquí. Sistemas operativos de teléfonos serán soportados en el futuro, aunque las fechas de lanzamiento no están definidas aún.

5.- What is necessary to be accomplished for a company to deploy your solution?

PhoneFactor is generally straightforward to set up. It has out-of-the-box support for a variety of common enterprise environments, such as RADIUS, LDAP authentication, IIS-based websites including Outlook Web Access, Windows Terminal Services, and more. It also has built-in support for synchronization with Active Directory and other LDAP directories, user self-service, automated enrollment, and more. Deploying the iPhone app requires that users enable the user self-service portal, which runs on IIS as well. The total work depends mostly on how complex the existing environment is.

5. ¿Qué necesita cumplir una empresa para desplegar vuestra solución?

La configuración de PhoneFactor suele ser muy directa. Nada más ponerla en ejecución tiene soporte para una buena variedad de entornos empresariales, como RADIUS, autenticación LDAP, sitios web basados en IIS – includio Outlook Web Access, Windows Terminal Services, y más. Tiene tamibén soporte incorporado para sincronización con Active Directory y otros directorios LDA, autoservicio de usuarios, aprovisionamiento automatizacion, y alguna cosa más. El despliegue de la aplicaicón para iPhone requiere que los usuarios habiliten el portal de autoservicio para los usaurios, que también correo sobre IIS. El trabajo final depende mayormente de cómo de complejo es el entorno existente.

6.- In some cases, you don´t have Internet connection in the mobile, because you are in other country or without signal from your mobile company. Do you have any solution for storing codes in advance?

Currently, the phone app requires either a 3G connection or a Wi-Fi connection to work. We’ve found it’s unusual for users to have Internet access on their computer (to log into something) but not on their phones. But, this is something we are considering for a future release.

6.- En algunos casos te encuentras con que no hay conexión en el terminal móvil, porque estás en otro país o sin señal de la compañía telefónica. ¿Tenéis alguna solución para guardar códigos por anticipado?

Actualmente la aplicación requiere o una conexión 3G o una conexión WiFi para funcionar. Hemos encontrado inusual que los usuarios tengan Internet en la computadora para conectarse a la aplicación pero no en el teléfono. Pero esto es algo que estamos considerando para una futura versión.

7.- Let´s suppose one of our readers wanted to deploy your solution in Spain. What are the necessary steps to do it? Do they need special servers or technologies in their companies?

PhoneFactor integrates well in a variety of enterprise environments. The PhoneFactor software itself runs on Windows Servers. From there, integration with existing apps needs to be done. So, for example, to protect a PPTP VPN, you would use RADIUS integration, or to protect Citrix Web Interface, you’d use the IIS plug-in. Then you’d need to set up user synchronization with AD or LDAP (or manually enter users), and install the user self-service portal to enable users to activate their iPhones and iPads.

Enrollment is largely automatic: users are sent welcome e-mails by the PhoneFactor software as they are imported, and those e-mails link the user back to the self-service portal, where enrollment and training are completed. After that, the user is up and running.

7.- Supongamos que uno de nuestros lectores quisiera desplegar vuestra solución en España. ¿Cuáles son los pasos necesarios para hacerlo? ¿Necesitana servidores o tecnologías especiales en sus compañías?

PhoneFactor se integra en una variedad de entornos empresariales. El software de PhoneFactor corre en servidores Windows. A partir de ahí, es necesario integrarlo con las aplicaciones existentes. Así, por ejemplo, para proteger una conexión VPN PPTP, sería necesario hacer una integración con RADIUS, o para proteger un interefaz web de acceso a Citrix, se debería utilizar el plug-in para IIS. Luego sería necesario configurar la sincronización de usuarios con Active Directory o LDAP (o meter los usuarios manualmente), e instalar el portal de autoservicio para permitir a los usauiros activar sus terminales iPhone o iPad.

8.- Now, talking about your company. What other security solutions are you developing in your company? It´s possible to have something similar to this in a Mac OS X platform?

Beyond the iPhone app, PhoneFactor also supports making phone calls for authentications as well as sending two-way SMS messages. PhoneFactor also includes the Universal Web Gateway, which is a reverse proxy component that can add two-factor security to any web app on any platform, advanced event confirmation and transaction verification functionality, and more. Mac OSX clients are generally supported seamlessly, and server software that integrates through a standard mechanism (e.g., RADIUS, PAM, LDAP, …) is supported as well. The Universal Web Gateway can be used to protect websites hosted on OSX or on any other UNIX-like system. Integration with LDAP directory servers allows user synchronization as well.

8.- Ahora, centrandonos en vuestra empresa, ¿qué otras soluciones de seguridad estáis desarrollando? ¿Es posible tener algo similar a esto en una plataforma MAC OS X?

Más allá de la aplicación para iPhone, PhoneFactor también soporta la realizacion de llamadas de teléfono de autenticación así como el envío de mensajes SMS en dos direcciones. PhoneFactor tamién incluye el Universal Web Gateway, que es un componente de proxy reverso que puede añadir seguridad de doble factor a cualquier aplicación web en cualqueir plataforma, confirmación de eventos avanzadas y funcionalidades de verificación de transacciones, y más. Los clients Mac OS X son generalmente soportados sin ningún problema, y el software de los servidores también es sofportad y se integra a través de mecanimos estándar, por ejemplo, RADIUS, PAM, LDAP, etc.... El Universal Web Gateway puede ser utilizado para proteger sitios web hosteados en servidores OS X o en otros systemas UNIX-like. LA integración con directorios LDAP también permite la sincronización de usuarios.

9.- Now, in confidence, how an ex-Microsoft MVP end up publishing iOS Applications?

J I have always thought Windows had the best kernel and base OS (well, at least since around Win2k), but my current feeling is that Apple has the best mobile OS. But more importantly, iOS has good market share, a better security model than its peers, and it makes our app look good! I’m not a big fan of the walled garden approach, philosophically, but it makes good business sense. But, iOS isn’t the only platform we’re going to do a mobile app on…

9.- Y ahora, en confianza, ¿cómo un ex-Microsoft MVP termina publicando aplicaciones para iOS?

Siempre pensé que Windows tenía el mejor kernel y sistema operativo base (bueno, al menos desde Windows 2k), pero mi sentimiento actual es que Apple ha desarrollado el mejor sistema operativo de dispositivos móviles. Pero lo que es más importante, iOS tiene una buena cuota de mercado, un modelo de seguridad mejor que sus competidores iguales, ¡y eso haer que tu aplicación luzca bien! Filosóficamente, no soy un gran fan del modelo de Walled Garden - N.T: en el que Apple controla el sistema operativo, la distribución de aplicaicones y lo que se puede instalar en el dispositivo -, pero permite un modelo de negocio con sentido. Aún así, iOS no es la única plataforma para la que nosotros vamos a hacer una aplicación móvil...

10.- You and Marsh became famous due to the TLS-Renegotiation bug... Do your applications have extra security checks against this?

You can be sure we've tested for that case. :-) But actually we got a bit lucky when we designed our system, before we knew about the bug, and ended up with an architecture that didn't rely on TLS renegotiation. So it was easy to disable once we discovered the bug.

10.- Tú y Marsh os hicísteis famosos debido al fallo de TLS-Renegotiation... ¿Tienen vuestras aplicaciones alguna comprobación de seguridad extra contra esto?

Puedes estar seguro de que hemos testeado nuestras aplicaciones contra este caso :) Pero de hecho tuvimos un poco de suerte cuando diseñamos nuestro sistema antes de que supieramos nada acerca del bug y termino siendo una arquitectura que no se apoyaba en la renegociación TLS. Así que fue fácil deshabilitarlo una vez que descubrimos el bug.