El
phishing es uno de los campos que más ha explotado con el tema de los dispositivos móviles y es que los navegadores no ayudan a combatir este mal que acecha al mundo de la seguridad. Aplicando las normas de la ingeniería social podemos llegar a hacer verdaderas obras de arte con un coste de tiempo bajo, gracias a herramientas como
SET, por ejemplo, pero cuando la combinación es
SET y los navegadores de los dispositivos móviles la mezcla es explosiva.
Al final la definición clásica de
phishing es la de estafa mediante el uso de la ingeniería social para obtener información de manera fraudulenta. A continuación exponemos algunos ejemplos de lo fácil que es a día de hoy caer en una emboscada hecha para lograr acceso mediante un
client-side attack, tal y como se cuenta en el capítulo del mismo nombre en el libro de
Hacking iOS: iPhone & iPad
Bar address: Ocultando verdades
El primer ejemplo que comentamos es el de la bar address. Sabemos que al entrar en un sitio web el dispositivo móvil intenta aportar el mayor campo de visibilidad al usuario haciendo que la barra de direcciones desaparezca rápidamente. Este hecho supone un foco donde el usuario no pondrá sus ojos, facilitando la suplantación de una web. En el título de la página se muestra, simplemente el título que se quiera mostrar, fácilmente copiable por el usuario malicioso.
Pero, podemos ir un paso más allá, e incluso aunque el navegador nos haga el favor de ocultar la barra, podríamos
implementar nuestra barra de direcciones, para que en todo momento el usuario confíe en el contenido,
tal y como se hacía ya en el año 2010.
 |
| Figura 1: Mostrando una barra falsa |
El componente UIWeb View
El
desarrollador de apps para iOS conocerá bien este componente, da riqueza a su aplicación permitiéndola utilizar controles de
Mobile Safari con el fin de navegar o consultar recursos web a través de su aplicación. ¿Qué ocurre con la
URL? ¿Es mostrada en algún lugar? Pues la respuesta es, que por defecto, no. En otras palabras, debe ser el desarrollador el que se esfuerce en añadir la
URL a la que se conecta la
app.
 |
| Figura 2: UI Web View sin URL en Gmail para iOS |
Como se puede visualizar es un tema delicado, ya que cualquiera podría realizar dicha acción utilizando el menú de SET y con alguno de los cientos de servidores de correo abiertos que hay por Internet.
La utilización del subdominio
Sabemos que las barras de direcciones no son muy grandes en pantallas de 3.5, 4, 5 pulgadas. Los phishers también lo saben y por ello utilizan una técnica denominada "muestro subdominio que corresponda con dominio real y te robo".
El ejemplo es el siguiente, la URL que se muestre aparece sin protocolo (para que sea más estético) y siempre con el valor del dominio más a la izquierda posible, por ello si utilizamos el siguiente subdominio www.mibanco.es.dominiomalicioso.com, con un poco de suerte y colocación podremos dejar solo visible en la barra de direcciones la parte de www.mibanco.es, por lo que a la vista parece que nos encontramos en dicha URL. El sitio web es una copia falsa en la cual nos mostrarán lo que quieran y nos solicitarán lo que deseen.
En iOS 7 esto no ha mejorado, sino que ha empeorado, ya que ahora en la barra de direcciones de Mobile Safari solo se pueden ver los certificados unos instantes, y la URL completa también, ya que luego solo queda el hostname del sitio. En definitiva, terreno abonado para phishers y ataques APT.
En este post continuamos con la segunda parte de la Guía de seguridad para tu Secure Summer! Recogemos el testigo del post anterior y procedemos a expandir nuestro diccionario de términos.
