TypoDetect: Una herramienta para detectar dominios de tus enemigos

Sin duda una de las técnicas más usadas en ataques de Phishing y Smishing, es el Typosquatting, el cual se aprovecha de la capacidad del cerebro humano en hacer correcciones inmediatas de palabras mal escritas, o de palabras faltantes en un texto. Esta es una habilidad muy útil para la lectura rápida y para minimizar el consumo de energía por el cuerpo en el momento de leer, razón por la que la lectura es tan relajante. Sin embargo, esta capacidad puede también ser utilizada por los malos en nuestra contra.

Figura 1: TypoDetect. Una herramienta para detectar dominios de tus enemigos

Existen muchos tipos de modificaciones que se pueden hacer a una palabra para que pueda ser usada en un engaño, por lo que para detectarlos hemos creado TypoDectec, - que puedes usar en tu Kali Linux - una herramienta en la que se se codificaron todos los tipos conocidos para así poder generar la mayor cantidad de posibilidades. Para entender los métodos que ejecuta la herramienta hemos hecho esta tabla con el dominio elladodelmal.com

Figura 2: Mutaciones de dominios creadas para elladodelmal.com

Una de las mutaciones que otras herramientas no toman muy en cuenta es el cambio de TLD (Top Levels Domains) o TLD Swap, pero esta mutación es muy importante si se tiene en cuenta que tomando solo los TLD de países son más de 500 y que con las nuevas normas de la IANA, cualquier palabra puede ser un TLD válido y no como al inicio de Internet que solo existían 6 TLD’s aprobados. 

Figura 3: Lista de TLDs actualizada. (imagen de ayer)

Con los cambios en la política de las IANA, casi diariamente aumenta el numero de TLD permitidos, así que la herramienta tienen esto en consideración para acceder a la publicación de la lista y actualizar las posibles mutaciones que se generen. Es así como del dominio elladodelmal.com se generan 689.921 mutaciones, las cuales como se ve de la imagen siguiente, se generan de los tipos de mutaciones antes mencionadas.

Figura 4: Ejecutando TypoDetect para crear mutaciones

Una vez, el sistema tiene la lista de mutaciones inicia las pruebas de si el dominio esta o no activo, para lo cual usa DNS over HTTPS (DoH), esto debido a que además de darnos los valores tipo A y tipo MX del dominio, nos brinda la posibilidad de tener una valoración del nivel de seguridad del dominio según su calificación de filtrado. Así, usando el servidor de DoH de ElevenPaths, obtenemos la respuesta y según el contenido se crea un JSON con todos los datos de DNS y la valoración de seguridad, con esta estructura.

Figura 5: JSON con resultado de dominios encontrados

Y para complementar la búsqueda se realizan las pruebas de que existen los dominios en la nueva red de DNS, denominada Blockchain-DNS, la cual se creo con la promesa de no poder rastrear los dominios que se usan al navegar, pero que desafortunadamente también a permitido el uso para actos maliciosos.

Figura 6: Demo de utilización de TypoDetect

Cuando el proceso de validación termina, lo cual se puede tardar unas horas, la herramienta pone en pantalla los dominios detectados como maliciosos y los detectados en Blockchain-DNS, pero crea un archivo JSON o TXT, con las respuestas de todos los dominios detectados como activos.

Figura 7: Typodetect en GitHub

Es así como esta herramienta Open Source, que está disponible en el GitHub de Telefonica en el  repositorio de TypoDetect,  le brinda una capacidad más de detección a los equipos de defensa y Threat Hunting en sus labores diarias, que pueden integrar en sus procesos.

Saludos,

Autor: Diego Samuel Espitia Montenegro, CSA de ElevenPaths, Colombia

Figura 8: Contactar don Diego Espitia

(DFaaS) DeepFakes as a Service en la DeepWeb: DeepFakes como Ciberataque y cómo detectar estos APT

Los DeepFakes siguen estando en boca de todos gracias a las redes sociales, como el vídeo viral de Tom Cruise o el challenge de Putin en un gimnasio, ambos compartidos por TikTok. Estos videos nos hacen reír y nos muestran qué cosas puede hacer la tecnología en un futuro. Pero el tema se complicó cuando The Guardian publicó una noticia donde distintos miembros del Parlamento Europeo fueron víctimas de un ciberataque realizado con DeepFakes tal como hicieron el ataque del CDO que explicaron Pablo González y Enrique Blanco sobre Chema Alonso. Ya no es una posibilidad, sino una realidad.

Figura 1: (DFaaS) DeepFakes as a Service en la DeepWeb:

DeepFakes como Ciberataque y cómo detectar estos APT

En esta noticia se menciona que distintas figuras de las altas esferas del parlamento europeo, incluido Rihard Kols (encargado de asuntos externos de Letonia) o Tom Tugendhat (encargado de asuntos externos de Reino Unido) fueron conducidos hacia videollamadas falsas con miembros del gabinete de Alexei Navalny. El propio Tugendhat culpó en su Twitter al mismo gabinete de Putin de los ataques recibidos.

Figura 2: Tweet de Tom Tugendhat sobre los ataques con DeepFakes

Dejando de lado cuestiones políticas en las que, como podéis imaginar, no quiero entrar, este tema me sigue produciendo malestar dado que diversos medios ya consideran los DeepFakes como una de las tendencias de ciberataque. Me recuerda al cuento de Pedro y el Lobo: en Ideas Locas hemos ido avisando de que esto llegará desde que en el año 2018 vimos que el FaceSwapping ya tenía una potencia brutal y se podría alcanzar el real time en breve, como vimos en 2019 en una PoC del ataque… y ha llegado.

Algunos recordaréis la estafa del CDO con DeepFakes que publicamos hace más de dos años. Mis compañeros del equipo de Ideas Locas, Enrique Blanco y Pablo González presentaron en la RootedCON 2019 como con una GAN y un Neural Text-2-Speech Microsoft, éramos capaces de suplantar a Chema Alonso en un vídeo, diciendo que nos hiciera una transferencia. Y aunque esa transferencia nunca llegó, sirvió para mostrar al mundo de la ciberseguridad que lo que sí que iba a llegar, era el Lobo.

Figura 3: Pruebas para el ataque del CDO a Chema Alonso

Voy a refrescar un par de cosas de los DeepFakes, y a mostrar algunos avances, para que veáis que esto sigue y seguirá siendo un problema. Pero primero, hablemos de datos. Distintas organizaciones de investigación han querido abordar el problema, primero creando datasets que se puedan tratar y comparar resultados, como los Databases Imagenet o YOLO para tareas como Image Classification o Object Detection. Los datasets de imágenes falsas más conocidos son FaceForensics++, DFD, DFDC y Celeb-DF. Estos intentan proporcionar una gran cantidad de DeepFakes generados con distintos métodos para una representación completa de los DeepFakes in the wild. Os dejo por aquí una comparativa de los distintos datasets más utilizados:

Figura 4: Comparación Datasets de DeepFakes

Por ejemplo, DFDC (Facebook) cogió 4326 sujetos para generar 25TB de raw data, y utilizaron software off-the-shelf como DeepFaceLab con distintos modelos de GANs y Autoencoders. Para que veáis lo sencillo que es generar un DeepFake realista, aquí tenéis un vídeo tutorial para utilizar el software anterior, sin ánimo de que lo utilicéis para fines criminales.

Figura 5: Tutorial de DeepFaceLab

Para la detección de estos vídeos se suelen considerar dos formas analizando los distintos frames y audio de un video: análisis forense de las imágenes y extracción de datos biológicos a partir de imágenes.

Figura 6: Paper de DFDC

En Ideas Locas desarrollamos un plug-in de Chrome para que un usuario pudiera seleccionar un vídeo por Internet y ejecutar distintos algoritmos de detección de DeepFakes, basados en el análisis forense de imágenes. Este plug-in implementaba cutaro investigaciones científicas:

• FaceForensics++: Que nos permitirá comprobar DeepFakes en base a un modelo entrenado sobre su propia base de datos, y aumentarla a medida que vayamos procesando nuevos vídeos.

• Exposing DeepFake Videos by Detecting Face Warping Artifacts: Dado que los algoritmos de DeepFakes actuales solo pueden generar imágenes de resoluciones limitadas, dejan artefactos distintivos en los vídeos DeepFake. Esta herramienta es capaz de detectarlos con un modelo de CNN.

• Exposing Deep Fakes Using Inconsistent Head Poses: Los DeepFakes se realizan con un swap entre una cara original y una cara sintetizada, por lo que esto introduce errores en la detección de la pose de la cabeza en 3D. Con estas incoherencias, y gracias al modelo HopeNet, se hace un estudio estadístico entre los distintos vectores calculados. Aquí podéis ver un ejemplo en el que se ve que esta animación de Chema Alonso hace "cosas raras".

Figura 7: DeepFake de movimiento de una foto.

• CNN-generated images are surprisingly easy to spot...for now: Dadas las características especiales de las imágenes creadas por 11 modelos distintos de generadores basados en CNNs, un clasificador de imágenes estándar puede generalizar bien a otras arquitecturas. De esta manera se confirmó que las imágenes actuales generadas por CNN comparten defectos sistemáticos, evitando que logren una síntesis realista.

Como se puede ver en el funcionamiento, el plugin buscaba vídeos en la página actual y, después de consultar si este vídeo ya se encontraba en nuestra base de datos, se realizaba el análisis con los cuatro módulos descritos anteriormente. Aunque esta herramienta se basaba en la detección de imágenes falsas por Internet, sería interesante que los distintos servicios de videollamada lo implementaran también como servicio de ciberseguridad. La arquitectura de los distintos módulos era la siguiente:

Figura 8: Arquitectura API DeepFakes Detection de Ideas Locas

En el caso de Tugendhat, por ejemplo, y utilizando la librería cv2, se procesaría el stream del vídeo y se comprobaría si ese vídeo puede ser fake en el momento en que empieza la transmisión, como si de un factor de autenticación se tratara. También se podrían utilizar herramientas como el face-recognition de pypi, para comprobar inconsistencias en el reconocimiento facial de las personas que aparecen en el vídeo, común en DeepFakes a tiempo real. De las técnicas para detectar vídeos fake basadas en datos biológicos, mis compañeros os hablaron ya, por ejemplo, de la detección de DeepFakes basados en el parpadeo de los vídeos.

Figura 9: Detección de DeepFakes basado en el blink de los ojos

Pero en este artículo me voy a centrar en el análisis de las pulsaciones de los individuos que aparecen en el vídeo. Exactamente, monitorizando las constantes vitales del investigado como si se tratara de una película de James Bond. Las dos técnicas más utilizadas para la detección del palpito del corazón son la fotopletismografía en remoto (rPPG) y el balistocardiograma (BCGs). Como no quiero bombardearos con información, me centraré únicamente en la primera. La Plestimografía es una técnica del cálculo del latido del corazón de un individuo a través de los distintos cambios de presión que sufre su piel, y es muchas veces utilizada para monitorizar a un individuo en cuestión.

Figura 10: Detecting Pulse form Head Motion in Video

La Fotoplestimografía en remoto es una técnica de Computer Vision que intenta emular esa técnica utilizando un vídeo del sujeto y, por tanto, calcular los cambios de presión a partir de diferencias de intensidad de píxel en los canales RGB de éste el movimiento de la cabeza y la respiración. Esta técnica tiene muchas desventajas debido a que su precisión está altamente influenciada por parámetros externos, como la luz ambiental, la calidad de la cámara, el color de piel del individuo o la distancia entre la cámara y el sujeto.

En el siguiente vídeo me podréis ver utilizando el siguiente código en C++ que, con una sencilla compilación, permite que calcules tu Beat Rate Per Minute en tiempo real utilizando tu webcam. También podéis encontrar otras implementaciones interesantes, como Pulse, que permite la monitorización con un servicio levantado en uno de los puertos de tu ordenador y con una visualización sencilla de los datos. ¿Os imagináis un detector de mentiras con una ampliación de estos códigos?

Figura 11: Probando el código de rPPG

Aún y las posibles complicaciones en cuanto a precisión de éste tipo de algoritmos, la Universidad Politécnica de Madrid desarrolló una investigación científica con sorprendentes resultados: por encima del 98% de AUC (Area Under the Curve) en dos datasets, DFDC y Celebrity-DF. Se utilizan la consistencia temporal y la coherencia espacial como mecanismos para detectar las frecuencias cardiacas en vídeos faciales, aplicándolo así, en la detección de DeepFakes. 

Figura 12: Arquitectura DeepFakesON-Phys

En la imagen anterior aparece la arquitectura del modelo utilizado en DeepFakesON-Phys, que se basa en dos modelos de redes neuronales: Motion Model para la detección de movimiento de la cabeza, y Appearance Model, para la detección de cambios en la densidad de píxel.

Reflexión final

Los DeepFakes, queramos o no, ya son un problema para la sociedad. Ya hemos visto que las técnicas de Inteligencia Artificial y Machine Learning se pueden aplicar a la ciberseguridad, y diversos grupos criminales los están utilizando para intentar desestabilizar relaciones internacionales con ciberataques. Aún y habiendo muchísimas investigaciones publicadas, y otras en curso, no hay un consenso global de que los DeepFakes puedan llegarse a detectar con un grado alto de precisión, y estos métodos de generación no paran de mejorarse con los años. 

Figura 13: Libro en 0xWord de Machine Learning aplicado a Ciberseguridad de
Carmen Torrano, Fran Ramírez, Paloma Recuero, José Torres y Santiago Hernández

En la DeepWeb ya se empiezan a ver servicios DeepFake as a Service, por lo que dudo que las consecuencias sociológicas de esta tecnología tarden mucho en verse reflejadas. Pedir un DeepFake a un cibercriminal para chantajear a una persona cercana está al alcance de un par de clics. Pero con los DeepFakes a tiempo real, como el caso mencionado que abría el artículo, esto ya no es una conversación filosófica, esto empieza a ser real, "Black Mirror Style". Si no nos podemos fiar de lo que vemos, ¿qué nos queda?.

Saludos,

Autor: Bruno Ibañez (@brunoaibanez)

Figura 14: Contactar con Bruno Ibáñez López en MyPublicInbox

Gremlin Botnets: El club de los poetas muertos [Parte 2 de 6]

Tras acabar la primera parte, quedaba claro que el mundo del cibercrimen estaba poniendo mucha atención al mundo de las apps para Android por medio de controlar Gremlin Apps que se conviertan en Gremlin Botnets desplegadas vía Google Play, lo que podría abrir un nuevo escenario. El de utilizar toda esa red de apps como si fuera una mega-botnet y hacer algo similar a lo que describía yo en la primera parte con la FOCA Botnet.

Figura 1: Gremlin Botnets: El club de los poetas muertos [Parte 2 de 6]

Es decir, si un cibercriminal es capaz de controlar una amplia red de apps instaladas en un amplio volumen de dispositivos móviles, puede hacer cosas maliciosas a capricho en dispositivos que pertenecen a personas que trabajan en empresas y organizaciones que pueden ser interesantes para un APT (Advanced Persitent Threat). Es decir, para realizar ataques mucho más sutiles que los descritos en la parte anterior de esta serie.

3.- Una Botnet para APTs: APTs as a Service

Supongamos que una banda criminal controla 100 apps que están instaladas en 10 Millones de dispositivos. Todas estas apps son totalmente benignas, pero como muchas apps benignas se llevan datos del dispositivo que permiten a la banda criminal identificar qué persona está utilizando ese terminal móvil. Es decir, la app busca sacar información de quién usa ese dispositivo averiguando cosas tan sencillas como:

- Qué número de teléfono se usa en ese dispositivo. 

- Qué cuentas de servicios de Internet como Twitter, Facebook, Linkedin, etcétera están dadas de alta en el dispositivo. 

- Qué direcciones de correo electrónico están en ese dispositivo.

Conseguir estos datos en los sistemas operativos Android no ha sido muy complicado en el pasado y, a pesar de que Google ha puesto foco en mejorar la seguridad de sus dispositivos, aún queda un parqué sustancialmente relevante sin actualizar que permite a los desarrolladores de las apps acceder a las cuentas almacenadas en el terminal o al número de teléfono.

Figura 14: Sencillo código que encontrarás en muchos repos de GitHub
para llevarse todas las cuentas de un sistema operativo Andorid.

Una vez que se ha conseguido extraer información de las cuentas en el dispositivo, es decir, e-mail, número de teléfono o usuarios de servicios de Internet, el trabajo que debería hacerse en backend es utilizar técnicas OSINT (Open Source Intelligence) para localizar quién es quién. Es decir, en qué empresa trabaja, qué cuentas tiene en redes sociales, su operador de telecomunicaciones, si esos e-mails ha sufrido leaks de contraseñas o en qué parte del mundo vive esa persona.

Figura 15: Manual OSINT para analistas de ciberinteligencia

Aunque parece algo muy difícil, lo cierto es que no lo es tanto. El Manual de OSINT para analistas de ciberinteligencia de Yaiza Rubio y de Felix Brezo explica muchos de esos mecanismos, y nosotros, en el equipo de Ideas Locas, creamos nuestra propia plataforma tiempo atrás, llamada Dirty Business Card, en la que basta con dar una dirección de e-mail o un número de teléfono y se hace un rastreo de esa persona por una infinidad de sitios de la red, sacando todo tipo de detalles.

Figura 16: Demo de funcionamiento de Dirty Business Card

La última parte del negocio es, una vez que se sabe quién está detrás de cada dispositivo, desde el panel de control de nuestra Gremlin Botnet se podría hacer malicisosa una, y sola una, app de todas ellas. Es decir, utilizando un canal basado en esteganografía se enviaría una orden a la app instalada solo en el dispositivo de la víctima para hacer la recolección de información o la ejecución del comando que se desee.

Esto hace que el comportamiento del resto de las apps siga siendo benigno, pero el de una sola sea malicioso. De esta forma solo hemos activado una Gremlin App de todo el parque de instalaciones de nuestra Gremlin Botnet que están controladas, generando el menor ruido posible ante posibles análisis o controles de seguridad. La exposición es mucho menor cuando se activa solo una app.

Y para conseguir hacer aún menos ruido y generar menos sospechas, hacemos uso de permisos y acciones oportunistamente en el sistema operativo. O lo que es lo mismo. Si queremos acceder al carrete de la fotos para llevarnos la fotografías de ese móvil, solo tenemos que esperar que el usuario utilice una función de la app que necesite acceder al carrete para aprovechar ese momento y robar las fotografías.  De esta forma, las sospechas son infinitamente menores, al poder justificar el acceso a las fotos por el uso de una función que el usuario ha, conscientemente, utilizado.

Pero vamos a ver todos estos puntos en más detalle para entender mejor cómo está hecha nuestra Gremlin Botnet de apps que vamos a ver en funcionamiento en una demostración un poco más adelante.

3.1.- Los permisos en Android

A partir de la versión 7.0 de Android, conocida como Nougat, Google comenzó a restringir y eliminar el uso de algunos permisos que habían demostrado que dejar la seguridad en manos de que un usuario, muchas veces sin entender bien el significado y las consecuencias de ello, no había sido una buena idea.

Pero hasta esa versión, y con un abanico de posibilidades varias, saber quién utilizaba, o lo que es lo mismo, en qué teléfono estaba corriendo una app no era demasiado complicado. Nosotros hicimos una demo llamada GetMyNumber de cómo se puede saber el número de teléfono en el que está corriendo una app usando diferentes trucos, algo que a partir de Android 7.0 no es posible, pero que antes se podía hacer de varias formas.

Figura 17: Demo de GetMyNumber hecha en 2015

La primera de ellas, haciendo uso de los permisos READ_PHONE_STATE o READ_PHONE_NUMERS, se puede sacar información de las versiones antiguas, llegando hasta poder saber el IMEI del teléfono. Por supuesto, hoy esto está capado, pero no en las versiones antiguas, y cuándo revisamos con Tacyt - nuestra plataforma Big Data de ciberinteligencia en el mundo de las apps móviles - cuantas apps pedían este permiso en el año 2015 el resultado fue de alrededor de 1.5 Millones de apps.

Figura 18: Casi 1.5 Millones de apps usando READ_PHONE_STATE

Entre la lista de formas que usamos en GetMyNumber, se encontraba el uso de los servicios de telefonía, es decir, ver si desde la información de la SIM es posible sacar el número. Esto se puede hacer con un comando similar a:

TelephonyManager tMgr       = (TelephonyManager)getSystemService(Context.TELEPHONY_SERVICE); 

String mPhoneNumber = tMgr.getLine1Number(); 

Pero no es el único truco. Por supuesto, pasa sacar las cuentas de servicios de Internet se puede hacer uso del permiso GET_ACCOUNTS  y buscar aquellas que están registradas. En aquellos tiempos, acceder a tu cuenta de Telegram o ChatON, basadas en números de teléfono y llevarte el número, era bastante trivial.

Figura 19: Accediendo con el permiso GET_ACCOUNTS

Con este permiso se puede acceder a todas las cuentas que estuvieran dadas de alta en el sistema operativo Android, ya sean Twitter, Facebook o Google, algo que ya no es posible en las últimas versiones.

Uno de los motivos por los que saltó la voz de alarma fue porque - y esto es posible aún en versiones antiguas - si la app solicitaba el permiso de RECEIVE_SMS, entonces no solo podía saber qué número de teléfono tenía, si no que podía pasar a un criminal el número para que este solicitara el inicio de sesión en WhatsApp o Telegram, y cuando el Token para el 2FA llegara vía SMS al teléfono, la app maliciosa pudiera leerlo y robar la cuenta.

Figura 20: Casi 35.000 apps (que serían cientos de miles de instalaciones)
tenían los permisos necesarios para robar Telegram o WhatsApp

Cuando revisamos con Tacyt el número de apps que tenían esta posibilidad. Es decir, que podrían volverse maliciosas y desde una Gremlim Botnet para APTs dar la orden para que cualquiera de ellas robara la cuenta de Telegram o WhatsApp a gusto, vimos que el número era de apps en Google Play era de cerca de 35.000.

Figura 21: Proceso para robo de WhatsApp o Telegram sabiendo
número de teléfono y teniendo permiso Receive_SMS

Es verdad que esto ha mejorado desde la versión de Android 7.0, pero por desgracia, más del 60 % de los dispositivos Android aún cuentan con versiones anteriores a esa, lo que hacer que muchos sigan teniendo toda su seguridad dependiendo de esos permisos. Por eso es tan importante actualizar el sistema operativo, y por eso muchas apps - como WhatsApp - dejan de dar soporte a versiones antiguas de los sistemas operativos Android.

Figura 22: Cuota de diferentes versiones de sistemas operativos Android a día de hoy

Aún así, aunque el sistema operativo se encuentre en una versión 7.0 o superior, las apps que pudieran utilizarse para este tipo de Gremlin Botnets pueden hacer usar otro tipo de trucos, como poner un sistema de login de la app basado en OAuth usando la cuenta de uno de los servicios de Internet.

Figura 23: Típica autenticación en mundo móvil usando un IdP OAuth

No hay nada más fácil, sea la versión de Android que sea, que pedir un login basado en Facebook, Google o una dirección de e-mail. En este caso estaríamos utilizando autenticación basada en OAuth, y ya os contamos en el año 2016 todos los datos y permisos que se pueden obtener por medio de este protocolo. Os dejo el enlace al artículo de SAPPO, por si queréis repasarlo.

Saludos Malignos!

*********************************************************************************
- Gremlin Botnets: El club de los poetas muertos [Parte 1 de 6]
- Gremlin Botnets: El club de los poetas muertos [Parte 2 de 6]
- Gremlin Botnets: El club de los poetas muertos [Parte 3 de 6]
- Gremlin Botnets: El club de los poetas muertos [Parte 4 de 6]
- Gremlin Botnets: El club de los poetas muertos [Parte 5 de 6]
- Gremlin Botnets: El club de los poetas muertos [Parte 6 de 6]
*********************************************************************************

Autor: Chema Alonso (Contactar con Chema Alonso)

Apple responde a Google con un "Exagerao!" y "en el camino nos encontraremos".

La publicación de la investigación hecha por el equipo de Google Project Zero sobre los iOS Chain Exploits ha levantado ampollas. Muchos usuarios de iPhone se han sentido defraudados por lo que implica que haya pasado esto, y reclaman a Apple muchas más medidas de seguridad, así como explicaciones más detalladas de lo que ha pasado e información de si se han visto afectados.

Figura 1: Apple responde a Google con un "Exagerao!" y "en el camino nos encontraremos".

Y es que la publicación de Google ha hecho mucho daño a Apple. Primero porque los exploits utilizados en esta campaña desde 2016 "in the wild" son los más peligrosos, ya que desmontan el sistema completo de seguridad en iOS, desde el cifrado del almacenamiento, hasta la seguridad del CodeSigning frente a los ataques de Jailbreak, pasando por las recomendaciones de seguridad para las apps y el propio modelo de desarrollo de código seguro en Apple, ya que en el informe de Google se habla de que los bugs están en partes poco usadas y poco revisadas del código.

Figura 2: Hacking iOS: iPhone & iPad (2ª Edición)

Al final, crear estos Remote Jailbreak Exploits es algo conocido desde hace ya mucho tiempo, y siempre han sido como el "Santo Grial" que buscar en iPhone, tal y como explicamos en el libro de Hacking iOS: iPhone & iPad (2ª Edición) que escribimos tiempo atrás. Pero es que además, el que se estuvieran usando estos exploits "in the wild" pone en duda la capacidad de Apple para capturar los exploits que aparezcan en el mercado de los Security Researchers. 

Y como el revuelo ha sido tanto, Apple ha contestado con sus propios resultados tras la investigación, que ha sido publicado en este artículo titulado "A message about iOS Security". Los puntos principales del mensaje son:

Figura 3: A message about iOS Security de Apple

1) Ataque muy focalizado: No se encontraba en muchas webs, solo en una docena de ellas y centradas en páginas que atraían a miembros de la comunidad Uyghur, una minoría étnica dentro de China. No es la primera vez que esta comunidad es afectada por ataques de iOS y MacOS.

2) Hace 6 meses que está parcheado: El post de Google se publica seis meses después de que todo estuviera parcheado, y tal y como está redactado da la impresión de espionaje en masa. Y eso no ha pasado.

3) Durante 2 meses "in the wild": Según todas las evidencias que Apple tiene, la campaña solo estuvo activa durante un periodo de dos meses y no durante dos años, tal y como afirma Google. Cuando el equipo de GPZ se acercó, Apple dice que ya estaba arreglándolo.

4) La seguridad es un viaje interminable: O "arrieros somos y en el camino nos encontraremos"

Sea como fuera, los ataques fueron posibles, rompiendo la seguridad así que Apple tiene que tomar nota de que estos ataques de RJB no se le pueden escapar muchas veces. Por otro lado, cuando un exploit se utiliza masivamente, su tiempo de vida suele acortarse, ya que las probabilidades de que llame la atención y sea detectado "in the wild" es muy alta, así que es más que probable que el ataque haya durado mucho tiempo afectando a pocos o durado poco afectando a muchos.

Figura 4: Tu iPhone es tan (in)seguro como tu Windows

Así que el debate entre la visión de afecta a todos aunque solo unos lo hayan sufrido durante casi dos años, y la visión de ha afectado a pocos durante un par de meses, es el que marca el límite entre los dos informes. Lo cierto es que tanto en Android como en iPhone ya hemos visto que estos ataques son más que posibles y cuantas más soluciones de protección personal tomes como usuario, mejor. 

Figura 5: Cómo protegerse de los peligros en Internet

Para protegerse y entender mejor los riesgos de Internet, os recomiendo una lectura de este libro de "Cómo protegerse de los peligros en Internet" que escribió José Carlos Gallego. Tenéis el indice de contenidos en este enlace que os he dejado.

Saludos Malignos!