Como podría el navegador Safari salvar tus navidades

Desde hace unos años los anuncios web son un “mal necesario” para mantener algunos sitios web, en cualquier otra época del año aunque sean molestos pueden resultar inofensivos, sin embargo si estás pensando en realizar tus compras de navidad por internet pueden jugarte una mala pasada. Muchas empresas anunciantes utilizan el fingerprinting para ofrecer una publicidad personalizada, solo tienes que buscar algún producto por internet para que las próximas veces que navegues por la red todos los anuncios estén relacionados con el producto que buscaste, algo que puede acabar con el factor sorpresa a la hora de hacer regalos navideños.

Para poder evitar situaciones como esta Apple ha provisto a su navegador con algunas herramientas que deberían ayudarte a acabar con estos anuncios, a continuación os explicaremos cuales son y cómo funcionan.

Machine Learning: Con esta funcionalidad Safari aprende a detectar cuales son los cookies necesarios y cuáles no, esto bloquea su uso a terceros al superar el día de antigüedad.

Posibilidad de acabar con el Site Tracking: Apple ha desarrollado dos herramientas (Una para Mac y otra para iOS) capaces de reducir el seguimiento realizado por las empresas anunciantes cuando navegamos.

Modo privado: El mejor método para que nadie sepa que has podido comprar es realizar tus compras a través de navegación privada.

Figura 1: Bloqueador de anuncios.

Bloqueadores de anuncios: La opción más eficaz para prevenir los anuncios personalizados es a través de un bloqueador de anuncios, podrás encontrarlos como aplicaciones o extensiones de tu navegador.

Uso del modo lectura: Desde hace un tiempo Apple te permite acceder a algunos sitios web en modo lector, evitando así parte de la publicidad.

Desactivar los cookies: Con este método puedes acabar con los anuncios pero también te resultara más difícil navegar por algunas de tus páginas web habituales.

Bloqueo de ventanas emergentes: Bloquear las ventanas emergentes es muy sencillo, solo tendrás que acceder a los ajustes de safari y buscar la opción de bloqueo de Pop-ups en el apartado de seguridad.

Estas son algunas de nuestras sugerencias para que podáis guardar el secreto de vuestras sorpresas navideñas tan solo realizando algún pequeño cambio en la configuración de vuestro navegador.

Grave vulnerabilidad en iOS demostrada en Pwn2Own

Apple advierte sobre los ataques WiFi y como pueden hacer que los dispositivos acaben infectados con malware. El equipo de seguridad de Apple ha tenido unas semanas complejas, principalmente debido a los problemas y vulnerabilidades WiFi que se han destapado como, por ejemplo, el temido KRACK.

Ahora los investigadores de Keen Lab de Tencent han mostrado un truco que aprovecha 4 errores para ejecutar código en un iPhone 7, ejecutando el sistema operativo iOS 11.1. El "truco" radica en el uso de una conexión WiFi. Esta vulnerabilidad fue una de los ganadores del famoso concurso Pwn2Own celebrado en Tokio.  Los investigadores recibieron 110.000 dólares por su ejemplo y su "truco". No hay mucha información sobre las vulnerabilidades específicas expuestas por Keen Lab, pero lo que si han demostrado es que el teléfono se conecta a una red WiFi y en el dispositivo se termina instalando una aplicación maliciosa, pudiendo extraer información confidencial del dispositivo. Apple ha sido advertida de los efectos y de este "truco" que parece una vulnerabilidad y bastante importante. Representantes de Apple, Google y Huawei se encontraban en el evento. Tienen 90 días para corregir las vulnerabilidades u ofrecer una razón válida para no abordarlas. Pasado ese tiempo Trend publicará los detalles.

Otras vulnerabilidades interesantes fueron descubiertas y demostradas durante el Pwn2Own como, por ejemplo, el investigador Richard Zhu hackeó un iPhone 7 con otras vulnerabilidades sobre Safari y se ganó 25.000 dólares. Otros 70.000 dólares fueron entregados a un investigador de seguridad conocido como mj0011, de la firma china Qihoo 360, por un ataque al Galaxy S8 de Samsung.

Pwn2Own Tokio 2014: Terminales móviles hackeados

Ya se celebró el evento anual Pwn2Own en Tokio durante los días 11 y 12 de Noviembre. El propósito de este evento para los investigadores de seguridad, desarrolladores y hackers fue el de explotar varios dispositivos a través de algún bug previamente desconocido, para luego informar al fabricante de este dispositivo respecto a dicha vulnerabilidad. Este evento es muy conocido, ytodos los años hablamos de él por aquí. Por ejemplo, el año pasado Mobile Safari en iOS 7.1.3 e iOS 6.1.4 fue hackeado. En 2012, iOS 6 fue pwneado en Amsterdam por Daan Keuper y Joost Pol.

Esta vez se disponía de una bolsa de premios por valor de 425.000 dólares para cualquier persona  - en el concurso de móviles - capaz de hackear las entrañas del teléfono a través de una vulnerabilidad 0day. Muchos dispositivos fueron explotados con éxito, como por ejemplo iPhone 5S, Blackberry Z30, Google Nexus 7, Samsung Galaxy 5 o LG Nexus 5.  Según parece cinco equipos explotaron vulnerabilidades que habían encontrado para controlar cinco dispositivos. Tres de las cuales se basaban en tecnología NFC, pudiendo extraer datos de los terminales. Las otras dos vulnerabilidades surgen a través del uso del navegador web integrado en el sistema operativo.

Figura 1: Pwn2Own Tokio 2014

iPhone 5S cayó víctima de un ataque con dos bugs en Mobile Safari que tumbaron su sandbox y les permitió llegar al core del corazón. Solo Windows Phone se salvo - en alguna medida - al no conseguir romperse la sandbox. Nico Joly fue quién consiguió explotar un Windows Phone instalado en un terminal Lumia 1520, con un exploit que se aprovechaba de un fallo en el navegador web por defecto, es decir Internet Explorer. Desde el concurso se comentó lo siguiente:

"Consiguió tomar acceso a la base de datos de cookies del navegador, sin embargo, la sandbox le bloqueó, por lo que no fue capaz de hacer con el control total del sistema.

En definitiva, una nueva edición de Pwn2Own en el que expertos de todo el mundo participan de manera sana, con el fin de ayudar a los fabricantes de dispositivos en la seguridad de éstos. De este modo, dichos terminales serán más robustos en un futuro.

Rompiendo la seguridad de los navegadores para iOS: Phishing, Universal Cross-Site Scripting y bugs en iPhone

Esta semana pasada se han publicado las diapositivas de las conferencias SyScan360. Entre la lista de charlas nos hemos parado a ver una que estaba centrada en la seguridad de los navegadores de Internet para iOS, titulada "Mobile Browser Security: iOS" y que se centra en analizar todos los fallos de seguridad de distintos productos y cómo explotarlos en diferentes esquemas de ataque, que van desde el Phishing y el Address Bar Spoofing hasta el Universal Cross-Site Scripting. Eso sí, no solo se centra en Mobile Safari, sino en los más de 70 navegadores que a día de hoy es posible descargarse desde AppStore. Sí, a nosotros también nos han parecido demasiados.

Al principio pensábamos que no daría para mucho, y que la gran mayoría de los trucos estarían ya tratados en el libro de Hacking iOS: iPhone & iPad, donde en su momento le dedicamos un capítulo entero a estos ataques. Lo cierto es que además de los que allí se cuentan y explican en detalle, han añadido alguno más a la lista que hay que tener presente. Aquí os dejamos algunos de ellos.

El truco del phishing por tiempo de error

Este truco, que afecta a Mobile Safari nos ha gustado especialmente. En él se habla de aprovechar que el tiempo que tarda el navegador Mobile Safari for iOS en generar un Time-Out en una página web va desde 1 minuto hasta 10 dependiendo de las diferentes versiones del navegador. La gracia está en que en el momento en que se invoca se cambia la barra de navegación con el nuevo sitio que se llama. Para ello, el truco es enviar a la víctima a una página de Phishing y ejecutar un código como el que se ve a continuación.

Figura 1: Un Phishing abusando del time-out de carga en Mobile Safari

En la parte del Document.Write se debe pintar la página de Phishing, y al invocar la web que se quiere suplantar por un puerto que no está disponible, se comenzará a intentar cargar, cambiando la barra de dirección, pero sin modificar el contenido de la página hasta que se produzca el Time-out.

Figura 2: Efecto de phishing que se produce aprovechándose de este truco

Mientras tanto la víctima verá la página con el Phishing, y la barra de dirección con el dominio real. Eso sí, saldrá la barra azul de carga intentando explicar que el sitio está intentando cargar algo, pero durante ese tiempo, la víctima puede caer en el engaño.

El title como barra de dirección

Un truco simple que funciona en muchos navegadores que ocultan la barra de dirección es tan sencillo como poner en el title la URL del sitio al que se quiere hacer Phishing, obteniendo un efecto visual muy resultón en todo el proceso.

Figura 3: Efecto de poner en el title una URL de phishing

En la presentación se analizan un montón de CVEs en los diferentes navegadores, y algunos de ellos de tipo Universal Cross-Site Scripting, es decir, que afectan al software del cliente y permiten acceder a datos de todos los dominios que estén cargados.

Figura 4: Ejemplos de Universal Cross-Site Scripting que se detallan en la presentación

Los creadores de esta conferencia mantienen un blog en el que publican periódicamente fallos de seguridad en los diferentes navegadores de dispositivos móviles que merece la pena que tengas en tu RSS, se llama Browser Shredders.

iOS 8: Apps podrán usar passwords guardadas en Safari

Poco a poco vamos conociendo más novedades de iOS 8. En este caso otra peculiaridad con la seguridad de las apps que nos ha llamado la atención. En este caso se trata de una característica que le permitirá a una app usar una contraseña guardada en Apple Mobile Safari para una determinada URL. Dicho así, seguro que a muchos de vosotros os habrán saltado todas las alarmas, y no es para menos, pero esperemos que esté bien diseñada y no tengamos ningún problema en el futuro con apps maliciosas que quieran robar las passwords cacheadas en el navegador del terminal.

La idea es que si un usuario accede habitualmente vía Mobile Safari a una web, y un día después en el futuro decide descargarse el app para iOS8 asociada a esa URL, el programador de la app podrá consultar cuáles son las contraseñas cacheadas para esa URL en Mobile Safari y ofrecerle al usuario la posibilidad de usarlas en la app.

Figura 1: App en iOS 8 accediendo a una credencial cacheada en Apple Mobile Safari

Se supone que el usuario será informado de este hecho por una alerta, tal y como muestran en MacRumors, pero estas cosas de mezclar tanta usabilidad con la parte de seguridad del sistema siempre acaban por darnos cierto respeto. ¿Podrán las apps solicitar las cuentas de Facebook en lugar de solicitar una autorización OAuth? Veremos.

Apple Safari en iOS 8 escaneará tus tarjetas de crédito

Es más que evidente que Apple ha definido un claro objetivo para la nueva versión de su sistema operativo móvil iOS 8 metiéndose en el mundo de las compras online a través de la usabilidad. Hoy vamos a analizar una funcionalidad que, sin ser tan impactante como HealthKit, HomeKit, Swift y las demás novedades en seguridad que trae consigo iOS 8, resulta realmente interesante. Nos referimos a la posibilidad que ofrece Safari en iOS para escanear tarjetas de crédito.

Muchas veces, cuando queremos realizar un pago en Internet, nos vemos en la necesidad de introducir el número de tarjeta de crédito, tarea susceptible a errores y que puede hacerse bastante tediosa. Apple ha puesto fin a este inconveniente. Ahora, cuando se muestre un formulario de datos bancarios en pantalla, aparecerá la opción Scan Credit Card. Si el usuario la selecciona, se le pedirá que proporcione permisos para utilizar la cámara trasera del iPhone, así como para acceder a la lista de contactos. Una vez superado el trámite, la cámara del dispositivo se activará, lista para escanear la tarjeta y rellenar automáticamente los campos, de una manera muy similar a como se introducen los códigos de las tarjetas regalo en iTunes.

Figura 1: Scan Credit Card en Apple Safari para iOS 8

Su uso es muy sencillo. Basta con encuadrar la tarjeta en el marco que muestra la pantalla del dispositivo, y el software de reconocimiento de caracteres de Apple hará el resto. Además, la aplicación intenta asociar los números de tarjeta con las personas de la lista de contactos del usuario. Obviamente Apple es consciente de las posibles amenazas de seguridad de este sistema, por lo que no se automatiza todo el proceso de compra. Como medida de precaución, es necesario introducir manualmente el CVV (los tres dígitos de seguridad de la parte posterior de la tarjeta) para validar cualquier operación.

No cabe duda de que Apple está buscando llevar al extremo la facilidad en los pagos. Es posible que esta nueva tecnología pretenda allanar el camino para iWallet, que como ya vimos hace un tiempo, promete cambiar la forma de realizar transacciones en las tiendas. Eso sí, no parece que vaya a usar por ahora NFC... mala noticia.

Hacking de iPhone & iPad con SSLStrip sobre iOS (II de II)

En la primera parte de este artículo se enseñó cómo se mostraba una conexión segura en el navegador Safari para iOS además de explicar y qué es y cómo funciona la técnica de hacking SSLStrip. Hoy vamos a ver cómo llevar a cabo el ataque SSLStrip sobre un terminal iPhone o iPad y cómo se comporta Safari para iOS ante este tipo de ataques.

Paso 1: Realizar un ataque man in the middel con ARP Spoofing

En primer lugar hay que realizar un ataque de man in the middle, en este caso con la técnica ARP Spoofing, que permita capturar todo el tráfico entre el dispositivo móvil y, por ejemplo, el router. Para ello se debe activar la opción de ip_forward para realizar reenvíos de tráfico desde nuestra máquina, y después utilizar la herramienta arpspoof, la cual se puede utilizar en OS X a través de los ports. En este caso, y por simplicidad se utilizará una distribución Kali Linux para realizar el envenenamiento de la caché ARP.

Dicho esto, vamos a ejecutar la instrucción echo 1 > /proc/sys/net/ipv4/ip_forward, con permisos de administrador, para hacer que nuestra máquina reenvíe el tráfico. Después, lanzaremos la herramienta arspspoof, tal y como se puede visualizar en la imagen. La sintaxis es sencilla arpspoof -i "interfaz de red" -t "direccion IP iphone" "dirección IP router". Esta instrucción tenemos que ejecutarla en ambos sentidos, es decir envenenando a la víctima y después también al router.

Figura 1: ARP Spoofing sobre un dispositivo iPhone

PoC - Paso 2: Jugando con iptables y SSL Strip

El siguiente paso es configurar nuestra máquina para redirigir lo que pase por nosotros con destino puerto 80 se envíe al puerto 10000 de nuestra máquina, dónde tendremos a SSL Strip esperando. A continuación se muestra cuál es la sintaxis de iptables para lograr esto:

   iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-ports 10000.

Una vez ejecutado esto como administrador, debemos arrancar el script de sslstrip, simplemente ejecutando sslstrip -w.

Figura 2: SSL Strip a la escucha

PoC - Paso3: ¿Cómo se comporta Safari?

Lo primero que hace Safari para iOS es mostrarnos el sitio web de Gmail, sin ningún tipo de alerta, porque como se mencionó en el artículo anterior, no hay SSL por ningún lado, todo va sobre HTTP puro. Como se ve en la siguiente imagen la página es la misma, porque es la original, pero el candado ha desaparecido.

Figura 3: Gmail sin SSL en la conexión

Como se puede ver, por diseño, Safari para iOS oculta el protocolo, que no es mostrado ni estando bajo SSL, ni sin estar bajo SSL. por lo que perdemos una referencia visual sobre qué tipo de conexión estamos teniendo y el icono del candado es lo único que nos puede ayudar. Pero, como hemos dicho en la parte anterior, al instante de cargar el sitio web, Safari para iOS sube hacia arriba la barra de direcciones por lo que si el candado no está, tampoco lo echaremos en falta en una navegación normal. En la imagen superior se puede visualizar la falta del protocolo, y en la imagen siguiente como realmente estamos navegando por HTTP.

Figura 4: Navegando por HTTP

Por último, una vez que la víctima confía en el sitio web e introduce sus credenciales, podemos ver como éstas son recogidas por el atacante en un fichero, ya que como la comunicación es HTTP no hay problema alguno de cifrado.

Figura 5: Recogida de credenciales de gmail

Esta técnica es una de las más comunes en los ataques de hacking a iPhone & iPad, y por eso muchas apps usan conexiones con Certificate Pinning para evitarlos. Poned los ojos bien abiertos cuanto utilicéis los navegadores móviles, ya que trucos como éstos, o como los que hemos visto en el artículo sobre phishing en dispositivos móviles están a la orden del día.

Pwn2Own: Mobile Safari en iOS 7.0.3 e iOS 6.1.4 hacked

Hace poco que  hemos hablado de las actualizaciones iOS 7.0.4 y de iOS 6.1.5 y alguno puede pensar que estas arreglan los dos bugs que han sido explotados con éxito en la competición de Pwn2Own que está teniendo lugar en la PacSec de Tokio, pero no es así. Los equipos de seguridad de Google y Apple están avisados y se espera que estén resueltos en la próxima versión de iOS.

El equipo que consiguió los bugs fue el Keen Team, formado por 8 investigadores de seguridad chinos que encontraron los bugs en Mobile Safari. Con ellos fueron capaces de robar la cookie autenticada de una sesión en Facebook en iOS 7.0.4 y robar una fotografía del carrete de fotos del terminal en un iOS 6.1.4, aunque no fueron capaces de romper la sandbox, por lo que se llevaron solo el 50% del dinero de los 27.500 USD de premio.

Figura 1: Miembros del Keen Team mostrando la foto robada de iOS 6.1.4

En ambos casos los exploits fueron de tipo client-side y explotados vía la pulsación de un enlace, por lo que se necesita algo de ingeniería social para entrar en la web del atacante, o se hace necesario atacar a un sitio web que vaya a ser visitado para preparar un watering hole attack.