Phishing en dispositivos móviles: ¿es más fácil?

El phishing es ya una de las "viejas" estafas en Internet. Aunque el concepto en los noventa, no fue hasta principios de esta década que se popularizó, justo cuando se popularizó la banca online. Desde entonces, se han intentado utilizar diferentes técnicas para mejorar la estafa, pero en esencia sigue funcionando de manera muy similar a sus comienzos. ¿Qué han aportado los smartphones y las tables a las técnicas de phishing?

El phishing tradicional intentó disimularse a sí mismo con diferentes técnicas más o menos elaboradas. Durante un tiempo intentaron utilizar siempre dominios muy parecidos a los que intentaban suplantar. Luego aprovechaban JavaScript para ocultar la barra del navegador (Internet Explorer 6) con la URL real del banco, superponiendo una imagen emergente en el punto exacto para que se confundiera con el propio navegador (algo parecido se hizo en iOS en 2010). Experimentaron con diferentes vulnerabilidades en el navegador para que el "ancla" en HTML simulara la URL real, pero realmente te llevara a otra web al hacer click sobre un enlace. Otras técnicas que se observaron durante un tiempo fueron los phishings bajo SSL. Finalmente, el phishing de hoy no se diferencia en exceso del de hace 10 años. Pero han aparecido nuevas plataformas que se utilizan para consultar webs. El navegador tradicional en el sistema de escritorio ya no es el único objetivo. ¿Qué oportunidades ofrecen estos dispositivos a los atacantes?

Las dimensiones de la pantalla

Barra de direcciones oculta

El primer factor que marca la diferencia y puede ser relevante con respecto al phishing son las dimensiones en sí de los dispositivos. Cuando el usuario entra a un sitio web con su teléfono o tablet, el dispositivo móvil intenta ofrecer la mayor visibilidad posible en la pantalla. Esto hace que, por ejemplo, en Safari la barra de direcciones desaparezca rápidamente. No saber en qué página se está, aumenta el peligro y facilita la labor de los atacantes.

Para añadir credibilidad a su ataque, algunos atacantes han implementado una barra que simula la original.

Aunque no todos los navegadores ocultan la barra por defecto, otros sí lo hacen cuando se realiza un desplazamiento hacia abajo en la web. Algunos atacantes realizan el desplazamiento automáticamente (añadiendo un ancla a la dirección, por ejemplo) y así el navegador oculta la barra de direcciones automáticamente, puesto que entiende que el usuario "ya ha tenido tiempo de verla".

Las vistas incrustadas en las apps

Algunas aplicaciones de redes sociales como Facebook, Tuenti, Twitter (una app que iOS tuvo que arreglar específicamente no hace mucho), o los gestores de correo, utilizan vistas web embebidas con el fin de proporcionar comodidad al usuario y estética. "Incrustar" una web en una app se hace a través de los componentes UIWeb usados por plataformas como Android o iOS. Cargan la dirección URL enlazada desde la app, y por defecto no muestran la dirección URL en ningún lugar de la app.

Esto podría ser utilizado por un atacante para hacer llegar un correo y, tras conseguir que acceda a la URL, presentar un sitio web falso. Desde la UIWeb, no podrá ser identificado en ningún punto. La app ofrecerá una falsa sensación de confianza en el contenido del sitio.

A continuación se muestra un ejemplo, donde un atacante envía un email a una víctima haciéndose pasar por un banco. El usuario, tras visitar el enlace accede a través de la app a la vista web embebida y se puede visualizar el sitio web. La app no identifica en ningún momento la URL real visitada.

Al visitar la URL aparece una vista incrustada en la aplicación de correo, sin barra de direcciones

El ejemplo se ha realizado con la app de gmail para iOS. El atacante podría usar un acortador de direcciones (shortner) con el objetivo de que el usuario no conozca el destino real del enlace. El usuario podría no verse amenazado por acortadores, ya familiares por su uso en redes como Twitter.

Los subdominios

Otro problema de espacio que presentan las barras de direcciones en los navegadores móviles de los dispositivos es que suele desplazar la vista de forma que se muestran normalmente los subdominios más a la izquierda. Este detalle permite al phisher diseñar en su sitio web un subdominio con, por ejemplo, un formato como el siguiente www.mibanco.es.dominiomalicioso.com. En este caso, si se accede desde Android al sitio web se vería lo siguiente:

Aunque no se observe, el dominio no es el real

La URL se desplaza a la izquierda, por lo que el usuario no ve, en principio, el dominio real al que se está conectando. El usuario podrá pulsar sobre la barra de direcciones y visualizar la URL al completo. Esta técnica ya la usan los atacantes en navegadores "tradicionales", usando una gran cantidad de subdominios, pero en el móvil se acentúa el problema por la facilidad para ocultar el dominio final y real.

Solo cuando se intenta editar la barra de direcciones, se aprecia el dominio en su totalidad

Y qué ocurre con el SSL

Se supone que el SSL, al igual que en el escritorio, debería ser la mejor defensa contra el phishing. ¿Lo ponen fácil en las versiones más ligeras del navegador? En general, si la conexión no está cifrada, la barra de direcciones ni siquiera muestra el protocolo por el que se navega. Si lo está, existen diferentes formas de visualizar la conexión que dependen de la plataforma:

Sorprendentemente, no se puede ver información sobre el
certificado en Safari para iPhone

En Safari, en conexiones cifradas se muestra un candado de color azul, con el que se indica al usuario que navega mediante una conexión cifrada. No se muestra el protocolo en la barra de direcciones. Si se pulsa sobre el candado, no apacerá más información sobre el dominio o el certificado.

En Safari también, un candado de color verde junto al título de la web indica al usuario que el certificado de la conexión es de validación extendida. El protocolo sigue sin mostrarse en ningún momento, tampoco más información cuando se pulsa sobre el candado. Esto facilitaría a los atacantes la creación de phishing puesto que con cualquier conexión SSL apacería el candado en la página falsa, que ofrecería confianza a la potencial víctima, sin posibilidad de comprobar realmente de dónde viene esa conexión supuestamente segura. Aquí, la vieja técnica de ofrecer seguridad a través del candado del navegador, tendría un efecto mayor.
En Android (tanto en Chrome como en su navegador por defecto), las conexiones cifradas "normal" y las de validación extendida, se muestran de la misma forma. Sí que muestra el protocolo (a costa de que la URL apenas se vea), pero no hace distinción entre la calidad de los certificados (si son "normales" o de validación extendida). Android sí que muestra más información tanto de la URL como del certificado cuando se pulsa sobre él.