Roaming Mantis: Nueva campaña de malware en iOS enfocada a la minería de criptomonedas

No es la primera vez que os hablamos de Phishing en Seguridad Apple, y esque este método de obtención de cuentas y credenciales es cada vez mas utilizado por ciberdelincuentes de todo el mundo debido a su gran potencial. En este caso nos encontramos frente a una nueva campaña de Phishing enfocada al uso de dispositivos infectados para la minería de criptomonedas. Hasta hace unos días esta campaña se centraba en dispositivos Android, sin embargo el malware utilizado ha sido modificado para que también pueda afectar a los dispositivos de la empresa de Cupertino y así gozar de un mayor alcance.

Esta nueva serie de ataques ha recibido el nombre de Roaming Mantis y se propagan a través del secuestro de DNS haciendo que los usuarios que se conecten a internet desde un router comprometido sean redirigidos a páginas maliciosas. En el caso de los dispositivos Android las páginas instan a las víctimas a descargarse archivos maliciosos con el nombre de Facebook.apk o Chrome.apk, mientras que en el caso de iOS muestran un mensaje en el que indican que es necesario recargar la página, al hacerlo nos lleva a una falsa página de Apple y solicita nuestros credenciales e información relativa a nuestra tarjeta de crédito (información que Apple nunca solicitaría).

Figura 1: Página fraudulenta proporcionada por Roaming Mantis.

Por si no fuera suficiente, aparte de obtener credenciales otra de las finalidades de este nuevo malware es la minería de criptomonedas. Minar criptomonedas desde nuestro dispositivo móvil puede afectar seriamente al rendimiento del mismo produciendo altos consumos de batería, un funcionamiento más lento o sobrecalentamiento del terminal. En un principio Roaming Mantis estaba orientado hacia los usuarios del continente asiático, sin embargo debido a que el malware utiliza diferentes idiomas (entre ellos el español) se ha convertido en una potencial amenaza para los usuarios de toda Europa.

Hoy en día es de vital importancia disponer de dobles factores de autenticación en nuestras cuentas con el fin de prevenir este y muchos otros tipos de ataques. También debemos recordar la importancia de extremar las precauciones a la hora de realizar cualquier cambio en nuestras cuentas, para ello es recomendable hacerlo siempre desde las páginas oficiales.

OSX/MaMi: Nuevo malware en macOS que modifica tus DNS

Recientemente ha surgido la noticia sobre un nuevo malware en macOS capaz de instalar un nuevo certificado raíz y secuestrar los servidores DNS, manipular el tráfico de Internet y redirigirlo a un servidor malicioso controlado por atacantes. De esta forma, un atacante puede robar datos confidenciales del dispositivo, incluidas las credenciales de inicio de sesión y las contraseñas. El malware denominado OSX/MaMi no es particularmente avanzado, pero modifica los sistemas infectados de forma persistente. 

El hecho de que instale un nuevo certificado raíz y secuestre los servidores DNS puede provocar acciones nefastas para el usuario. ¿Cómo OSX/MaMi afecta a macOS? Según el expero Patrick Wardle no está claro como el malware infecta un sistema macOS, aunque sí que cree que los atacantes están utilizando métodos como el correo electrónico o pop-ups en ciertas páginas, es decir, ataques de ingeniería social en la web.

Figura 1: OSX/MaMi y los certificados

¿Cómo puede un usuario de Mac verificar si su equipo está infectado? Es sencillo. Se puede verificar manualmente si está infectado con OSX/MaMi al acceder a la configuración DNS. Si el DNS está configurado en las direcciones IP 82.163.143.135 y 82.163.142.137, el dispositivo está infectado. Además, ninguno de los 59 antivirus de VirusTotal detectaba el malware, por lo que Wardle recomienda el uso de su software LuLu para detectar el tráfico de red de OSX/MaMi. Se recomienda a los usuarios de Mac a mantener su sistema acutalizado, evitar la descarga de aplicaciones y software innecesarios, no hacer clic en enlaces y archivos adjuntos de correos electrónicos desconocidos.

Eleven Paths Talks: La red bajo ataque

El próximo Jueves 9 de Marzo, nuestros compañeros Claudio Caracciolo y Arsene Laurent hablarán sobre un tema de actualidad como son los ataques de denegación de servicio, una amenaza que siempre se encuentra ahí y que en cualquier momento puede golpear fuertemente. Claudio y Arsene contarán con la presencia de un invitado especial para tratar este tema.

Se hará hincapié en el uso de protocolos como NTP y DNS para llevar a cabo ataques de amplificación, los cuales pueden provocar que grandes cantidades de bits golpeen servidores, teniendo un factor de amplificación enorme. A finales de 2016, uno de estos ataques a través del uso de dispositivos IoT que habían sido secuestrados, hizo reflexionar a la sociedad sobre la facilidad de ejecutar ataques a nivel de red y la fragilidad con la que nos encontramos en las infraestructuras desplegadas. Si consideramos que, incluso, en muchos de los nuevos despliegues con nuevos protocolos sobre nuevas arquitecturas ya se conocen vulnerabilidades que podrían afectar a los servicios brindados. En este webinar se hablará de diferentes tipos de ataques de red, cómo las botnets afectan a estos esquemas y, sobre todo, cuáles son las soluciones más comunes de protección para estos casos.

Figura 1: Eleven Paths Talks Temporada 3

La sesión comenzará a las 15.30, hora española. Los talks durarán unos 50 minutos, divididos entre 10 minutos de comentarios sobre noticias interesantes relacionadas con las diferentes temáticas, 30 minutos de debate entre dos de nuestros CSA y un invitado especial y 10 minutos sobre consejos y herramientas. Recordar que las sesiones se llevarán a cabo a través de la plataforma GoToWebinar. Posteriormente, y como siempre, se publicarán en nuestro canal de Youtube. No pierdas la ocasión y registrate para el webcast. Si te perdiste algún capítulo de la primera temporada o de la segunda temporada puedes revisarlos en el canal de Youtube de Eleven Paths. Además, no pierdas la ocasión de exponer tus ideas y hablar con otros usuarios en la Community de Eleven Paths ¡Te esperamos!

Vulnerabilidades en mDNSResponder afectan a Bonjour de Apple

La semana pasada se publicó que vulnerabilidades en mDNSResponder afectaban a sistemas de Apple. Existían múltiples vulnerabilidades en el software open source de mDNSResponder, el cual está implementado por Bonjour en Apple. Las vulnerabilidades descubiertas podrían permitir a un atacante ejecutar código arbitrario en las máquinas dónde se encontrase instalada la aplicación. El protocolo mDNS se puede leer bajo el RFC 6762 y está implementado por Apple Bonjour y servicios del sistema operativo Linux nss-mdns.

Las vulnerabilidades que afectan al producto no son del año 2016, si no del año 2015. La comprobación errónea del tamaño de un buffer, CVE-2015-7987, en las funciones GetValueForIPv4Addr(), GetValueForMACAddr(), rfc3110_import() y CopyNSEC3ResourceRecord(). Otra vulnerabilidad del año pasado y que se encuentra en este software es la CVE-2015-7988, la cual es una referencia a null pointer. Ambas podrían permitir a un potencial atacante ejecutar código arbitrario o provocar una denegación de servicio provocando el crasheo en memoria. Ambos problemas afectan a las versiones de mDNSResponder 379.27 y superiores, aunque inferiores a la versión 625.41.2.

Figura 1: Security Update for mDNSResponder

Apple decidió anunciar y publicar un aviso de seguridad para indicar estos problemas. Tal y como se puede ver en su anuncio, las versiones actuales de productos Apple utilizan una versión de Bonjour sin estos problemas, pero versiones anteriores sí estaban afectadas. Las versiones afectadas de OS X son:

• Versiones anteriores a OS X El Capitan 10.11.1.
• Versiones anteriores a OS X Yosemite 10.10.5.
• Versiones anteriores a OS X Mavericks 10.9.5.

Las versiones anteriores a iOS 9.1, watchOS 2.1 y AirPort Base Station Framework anteriores a 7.7.7 y 7.6.7. Se recomienda que los usuarios actualicen sus sistemas operativos, tanto OS X como iOS, watchOS y AirPort con el objetivo de no ser vulnerable a estas vulnerabilidades de mDNSResponder.

Apple libera una *Critical Update* para su gama AirPort

Apple ha liberado una nueva revisión de seguridad con cáracter de urgencia para su gama de routers inalámbricos. La gama es la conocida como AirPort. La actualización es ligeramente misteriosa, ya que corrige una vulnerabilidad reportada por primera vez hace más de 9 meses. Apple ha tardado demasiado tiempo en dar detalles. Esto puede ser debido a que los dispositivos afectados no eran productos estrella de la marca, lo cual no justifica tardar tanto en proporcionar actualizaciones. De esto ya hemos debatido en otras ocasiones, y es que hay veces que los fabricantes tardan demasiado tiempo en arreglar ciertas vulnerabilidades.

El fallo más antiguo que se ha parcheado es el CVE-2015-7029, del que aún no se conocen detalles en la base de datos del Mitre, simplemente se dice que el CVE ha sido reservado. El misterio continúa cuando se dice que uno de los fallos solventados es uno que provocaba la ejecución de código remoto el cual tiene una descripción pobre y poco detallada oficialmente. Un problema de corrupción de memoria existía en el análisis de datos DNS. Este problema ha sido resuelto comprobando o validando los límites de los parámetros.

Figura 1: Actualización del firmware de AirPort

Se puede obtener mayor detalle desde el propio sitio de Apple, dónde se indica en qué afectan las vulnerabilidades y las medidas que sus usuarios deben tomar para solventarlas. En este caso es fácil, hay que actualizar el firmware de los dispositivos para lograr un estado de seguridad aceptable y no ser vulnerable a vulnerabilidades conocidas. No pongas en riesgo la red de tu empresa o de tu casa, actualiza de forma inmediata tus dispositivos AirPort.

El ataque a los DNS de Apple que te dejó sin conexión

Durante el día de ayer muchos usuarios tuvieron problemas para conectarse con los servicios de Apple, incluso, como apuntaron algunos, hasta para conectarse a la web que dice cuál es el estado de los servicios de Apple, lo que generaba una ironía en el servicio.

Figura 1: Página de estado de servicios de Apple caida

Según parece, esta desconexión se debió a problemas de conexión con los servidores apuntados en los registros DNS de Apple.com que estaban almacenados en varios proveedores de DNS, incluido Google, que contenían entradas erróneas, según apunta Apple Insider. Estos errores parece que fueron introducidos por un ataque a los proveedores de DNS que hicieron esos cambios en los registros, aunque no ha habido contestación oficial por parte de Apple.

Figura 2: Problemas con las respuestas del DNS de Apple

Lo que sí vuelve a dejar claro es que, años después, seguimos con un Internet soportado por un servicio de DNS que aún no ha avanzado hacia un sistema seguro y todavía los servicios de DNSSec no se han extendido masivamente, lo que puede provocar caos similares a estos en el futuro. ¿Os imagináis Smart Cities, Connected Cars, Connected Humans, etc... soportados por un sistema como el DNS en el que aún no se ha tomada conciencia en serio de la seguridad?

Flashback Botnet aún tiene 22.000 Mac OS X infectados

La botnet Flashback para equipos Mac OS X llenó todas las portadas de los medidos de comunicación centrados en seguridad informática y/o centrados en las tecnologías Apple. Como no podía ser menos, nosotros estuvimos cubriendo en detalle todas las noticias que iban surgiendo a su alrededor, desde su aparición inicial, hasta el descubrimiento de su creador, pasando por todas las mutaciones que fue sufriendo o los puntos más álgidos en los que se hablaba de más de 600.000 equipos infectados y de que podía considerarse ya una pandemia para la compañía.

Durante un tiempo se ha supuesto que la botnet estaba erradicada, pero desde Intego han decidido comprobarlo, y la realidad es que la botnet aún está muy viva. Para comprobarlo se ha decidido comparar uno de los dominios del sinkhole descubierto de la botnet que se activaría el 2 de Enero de este año 2014. Para los que no estén muy acostumbrados a esta tecnología, hay que aclarar que los bots llevan un algoritmo dinámico que hace que cada día busquen el panel de control de la botnet en un dominio distinto. Estos dominios se calculan en el bot con un algoritmo que depende de la fecha del sistema del equipo, lo que hace que solo si conoces el algoritmo sabrás donde irán los bots a buscar los comandos.

Figura 1: Evolución de equipos infectados por FlashBack Botnet según estimaba Symantec

Los ingenieros de seguridad haciendo reversing al código dieron con el algoritmo de búsqueda de paneles de control tiempo ha, y en Intego han comprado el dominio que se activaba el 2 de Enero de 2014 para ver cuántos equipos estaban aún infectados y buscaban conectarse. La respuesta es que al log del servidor Apache llegaron más de 22.000 equipos únicos infectados durante 5 días de monitorización.

Figura 2: Log del servidor de Apache en el dominio buscado por los bots de FlashBack

Esto hace que muchos equipos estén aún infectados aunque la botnet esté descabezada, pero están aún a la espera de que aparezca un nuevo comando que ejecutar en esas máquinas infectadas. Además, se han detectado 5 versiones distintas de los bots desplegados por esta botnet que tanto daño hizo a los usuarios de Mac OS X por las mafias del Fraude Online.

DNS de WhatsApp secuestrado pero los mensajes intactos

Ayer fue un día intenso para los responsables de seguridad de WhatsApp ya que además de tener que lidiar con una nueva Prueba de Concepto que muestra cómo es posible descifrar las conversaciones de WhatsApp por una red WiFi - lo que abre una gran puerta a que se genere una nueva herramienta que dé completamente la vuelta a las técnicas de cómo espiar WhatsApp - el sitios web de la compañía sufrió lo que parecía ser un defacement en toda regla.

La intrusión, que en definitiva fue "solo" un DNS Hijacking al más puro estilo Hacker Épico, fue a cargo de un grupo Pro-Palestino que logró apuntar el nombre de dominio de www.whatsapp.com a un servidor web controlado dónde se había puesto una página cambiada, pero nunca tuvieron acceso a los datos de las conversaciones almacenadas en los servidores de WhatsApp.

Figura 1: Sitio web de WhatsApp secuestrado y defaceado

Tras el susto, todo volvió a la normalidad, y a pesar de la prueba de concepto sobre el descifrado de las conversaciones, aún no hay una herramienta pública capaz de hacerlo, aunque parece que la habrá, por lo que cualquier conversación de WhatsApp que se haya grabado o que se grabe durante este periodo de tiempo, tal vez pueda ser descifrada en el futuro. No obstante, cuidado con lo que envías por WhatsApp, que ya sabes que podrá ser descifrado en breve y que aunque borres los mensajes pueden ser recuperados con Recover Messages.

Malware por Pornografía: OSX/RSPlug a.k.a. Mac Cinema

Continuando con la revisión de malware histórico de sistemas Mac OS X, llegamos a OSX/RSPlug, también conocido como Mac Cinema, un troyano descubierto en el año 2007 y que fue evolucionado durante un par de años. Este software malicioso utilizaba técnicas de ingeniería social para conseguir ser descargado e instalado en el equipo de la víctima, de ahí que sea denominado como “caballo de Troya” o simplemente “troyano” ¿Cómo lo hacía Mac Cinema?

Método de infiltración

El malware se distribuía a través de portales de contenido pornográfico con enlaces a videos que, al intentar ser reproducidos, mostraban un mensaje indicando que Apple QuickTime no podía mostrar el video por la falta de un códec, y a modo de “buena acción” se ofrecía su descarga al usuario. Con la descarga del susodicho codec, se preguntaba por la contraseña de administrador para completar el proceso de instalación, con lo cual OSX.RSPlug ya tenía libertad para actuar a sus anchas. El malware fue evolucionando y cambiando un poco su forma de distribución, pero con los mismos patrones. El truco no era nuevo y es el mismo que utilizaría más adelante el malware OSX/FKCodec.A.

Daños causados

Una vez instalado en el equipo, se centraba en realizar ataques de Pharming. Es decir, alteraba la configuración de los servidores DNS del sistema por unos maliciosos. La tarea de los servidores DNS es la de mapear un nombre de dominio en una dirección IP y los configurados por este troyano dirigían al usuario a páginas pornográficas para hacer ataques de clic fraud a y portales donde se practicaban estafas. Mismo negocio que el que usaron los creadores de DNS Changer - ahora camino de la cárcel -.

Para ello creaba un script en la siguiente ruta /Library/Internet Plug-Ins/plugins.settings. La finalidad de este script es la de volver a restaurar sus direcciones de DNS en el caso de que el usuario las cambiase, haciendo que los efectos del troyano no fuesen tan sencillos de revertir. Además se encargaba de recoger información de la víctima y enviarla a los servidores del panel de control de este malware.

Identificación y eliminación del troyano

Para saber si el equipo está infectado, basta con comprobar la existencia del archivo plugins.settings en la carpeta /Library/Internet Plug-Ins. El primer paso es eliminar este archivo y vaciar la papelera de reciclaje. El siguiente paso era eliminar el proceso que impide cambiar las direcciones de DNS. Para ello había que eliminar las tareas del demonio cron para root con crontab –r desde la cuenta de root.

Figura 1: RSPlug aún en XProtect

A día de hoy, XProtect sigue bloqueando la descarga de este malware en sistemas Mac OS X. Basta con ir al fichero de configuración de XProtect en /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.plist y ver como la primera firma es la de RSPlug.A, lo que significa que aún deben quedar muestras en activo.

Condenas y multas para creadores de DNS Changer y Path

En el post de hoy os recogemos dos noticias que tienen que ver con sentencias de los tribunales que han salido a la luz pública en los últimos días. La primera de ellas a una banda de ciber-criminales que infectó millones de computadoras para ganar dinero con una multimillonaria estafa. La segunda, una condena a una red social por no actuar acorde a la ley para proteger la privacidad de sus usuarios.

El caso DNS Changer

El malware DNS Changer afectó a millones de usuarios en una estafa de pharming que alcanzó los 14.000.000 USD y que se extendió por los sistemas operativos Windows, Mac OS X y Linux. En Julio de 2012 el FBI tiró definitivamente los servidores de DNS falsos que utilizaba la red criminal y ahora los 7 implicados, seis de ellos originarios de Estonia y el otro de Rusia, se enfrentan a los tribunales en USA en los que el primero de ellos Valeri Aleksejev, de 32 años, declarado culpable, se enfrenta a 25 años de prisión, la deportación y una multa de 7 Millones de USD.

El caso Path

La red social Path fue protagonista de un escándalo de privacidad a nivel mundial cuando se descubrió que estaba robando los contactos de los terminales móviles de sus usuario sin pedir consentimiento alguno de ello a los usuarios, lo que llevó a que incluso tuviera que pedir disculpas públicamente. De poco han servido esas disculpas, pues la FTC Americana acaba de sancionar a la compañía con una multa de 800.000 USD, lo que sin duda no ha debido sentarles nada bien.

Figura 1: Envió de contactos robados a servidores de Path

En cualquier caso, esperamos que estas medidas sirvan un poco como elemento de disuasión a ciber-criminales y empresas que invadan la intimidad de los usuarios de sus tecnologías, y que nuestra vida sea un poco más tranquila.

OSX.Flashback: aún hay cerca de 100.000 infectados. Comprueba si hay un equipo infectado en tu red.

En Symantec han hecho un cálculo y una estimación de decrecimiento de la botnet creada por FlashBack Trojan, y estima que aún ronda los 100.000 equipos infectados, tal y como se puede ver en este gráfico de seguimiento.

Figura 1: Decrecimiento y estimación del mismo de la botnet FlashBack

Todo ello, pese a los esfuerzos de Apple sacando una actualización de Java con herramienta de limpieza incluida, lo que demuestra que para luchar contra el mundo del fraude online son necesarios esfuerzos coordinados.

Por otro lado se han publicado los nombres de los dominios a los que va a intentar conectarse las máquinas troyanizadas con OSX/FlashBack.K buscando el panel de control, por lo que si quieres saber si un equipo de tu red tiene easte troyano puedes hacer un sencillo truco con el DNS de tu organización.

Figura 2: Generación dinámica de nombres de dominio para el C&C

Basta con que crees estos dominios apuntando a un servidor fake donde registres las conexiones. De esa forma, mirando los logs podrás descubrir qué direcciones IP de tu red están infectadas con esta versión del troyano. Si tienes muchos Mac OS X en tu organización, merece la pena el intento.

DNS Changer: Cuando el pharming llegó a Mac OS X

DNS Changer es malware para Mac OS X tan sencillo que cualquier usuario podría programarlo. DNS Changer se encarga de cambiar la configuración del fichero que contiene los servidores DNS del equipo, el cual en máquinas basados en UNIX es /etc/resolv.conf. Este malware para Mac OS X fue descubierto el 30 de Noviembre de 2007 y realmente no era más que un script en bash cuya función, como se ha comentado anteriormente, cambia las direcciones IP de los servidores DNS configurados en la máquina atacada. 

A este tipo de ataque en el que se cambian las resoluciones de los servidores DNS, mediante cambios en el fichero de resolución local hosts, o mediante la suplantación directa de lo servidores DNS que va a utilizar la víctima se le conoce como Pharming.

¿Qué se busca con este malware?

El malware por sí no realiza ninguna acción dañina al equipo, simplemente sustituye los valores de las direcciones IP contenidas en el fichero de resolución DNS. Con ello se busca que la víctima resuelva los nombres de dominio en servidores DNS controlados por el atacante, por lo que sería muy sencillo realizar  un ataque de Phishing sobre la víctima, que suele ser el objetivo final de este tipo de acciones.

Si la víctima configurase unos nuevos servidores, o cambiase la configuración al uso de un servicio DHCP, los servidores controlados por DNS Changer se perderían. El atacante también pensó en ello, y para evitarlo DNS Changer también realiza es una copia de sí mismo que se almacena en %System Root%/Library/Internet Plug-Ins/plugins.settings y añadía al Cron una entrada para ejecutar dicho archivo periódicamente.

¿Dónde se encuentra este tipo de malware?

Este tipo de archivos se encontraba, principalmente, en imágenes de disco DMG, en la descarga de generadores de claves (keygen), cracks de aplicaciones, juegos, etcétera. Una vez que el usuario instalaba la aplicación, la cual estaría modificada para lanzar el script y las acciones correspondientes, o una vez que el usuario ejecutara la aplicación con las credenciales de administrador, el malware podría actuar con todo el potencial.

Según la página oficial de control www.dnschanger.com también ha sido encontrado malware con comportamiento similar en archivos o paquetes de codecs de vídeo que se obtenían de páginas web pornográficas. Incluso, ha sido encontrado en otro malware similar como OSX.RSPlug.A, OSX/Puper, OSX/Jahlav-C. Para Mac OS X hay una utilidad gratuita para eliminarlo, en caso de estar infectado: DNS Changer Removal Tool.

Detectar Mac OS X y LogMeIn con DNS Cache Snooping

La técnica de DNS Cache Snooping consiste en consultar las resoluciones de nombres de dominio que se encuentran cacheados en el servidor DNS de una empresa para así conocer a qué servidores se están conectando los equipos internos de una red. Veamos un ejemplo para entenderlo.

DNS Cache Snooping

Supongamos que un equipo de la red interna de una empresa quiere conectarse a este blog, es decir, a www.seguridadapple.com. Para ello, primeramente necesita conocer cuál es la dirección IP asociada a este nombre de dominio, así que consultará al servidor DNS que tiene configurado el equipo en las opciones TCP/IP de la conexión. Si este es un servidor de la empresa interno, inicialmente no conocerá la respuesta, así que comenzará un proceso de consultas recursivas entre servidores DNS para alcanzar un servidor que sí que conozca la dirección IP.

Cuando la dirección IP llega al servidor interno de la organización, éste almacenará durante un tiempo la información obtenida en la memoria Caché por si algún otro equipo realiza la misma consulta. Si durante el ese tiempo, algún otro equipo realiza la consulta, entonces contestará directamente sin necesidad de realizar el proceso recursivo de descubrimiento de la respuesta.

La técnica de DNS Caché Snooping se basa en eso, en conocer que información está en la memoria Caché de un servidor DNS de una organización. De esta forma se pueden conocer hábitos de navegación, software instalado y hasta reconocer perfiles de personas en una organización y saber si están o no activos en un momento dado.

Para obtener esa información, basta con configurar las consultas al DNS interno como consultas no recursivas, es decir, que si el servidor DNS no conoce la respuesta, que no lance ninguna otra pregunta a otro servidor. Así, si conoce la respuesta, es decir, está en caché, se obtendrá la dirección IP asociada a un nombre de dominio, y si no, se obtendrá una referencia al servidor DNS al que habría que preguntar.

Analizando las conexiones de LogMeIn

Esta semana pasada estuvimos hablando de LogMeIn, el servicio que permite conectarse remotamente a un Mac OS X por medio de una página web y, pensando en la arquitectura, nos dimos cuenta de que se podría detectar la existencia de Mac OS X en una red interna con ese servicio mediante la técnica de DNS Cache Snooping. 

Los equipos con LogMeIn instalado, realizan conexiones hacia los servidores de dicho servicio, y el usuario solo tiene que conectarse a esos servidores. Es por tanto necesario que el equipo con LogMeIn anuncie su existencia en Internet conectándose a ellos.

Para conocer cuál es el proceso, procedimos a capturar con Wireshark una sesión de comunicaciones entre un cliente Mac OS X con LogMeIn instalado y analizamos las peticiones DNS y obtuvimos lo siguiente.

Figura 1: Peticiones realizadas a LogMeIn analizadas con Wireshark

Como se puede ver, se realizan una serie de peticiones a servidores de LogMeIn como son:

- dc.logmein-gateway.com

- list.2.logmein-gateway.com

- control.app59.logmein.com

Tras analizar los registros que se consultan, uno de ellos, en concreto list.2.logmein-gateway.com, parece ser una lista con los servidores que puede utilizar el equipo para anunciarse.

Figura 2: Valores del registro list.2.logmein-gateway.com de tipo TXT en el servidor DNS

Tras realizar varias pruebas vimos que los equipos consultan, de forma aleatoria, uno de los siguientes cuatro registros:

- list.1.logmein-gateway.com

- list.2.logmein-gateway.com

- list.3.logmein-gateway.com

- list.4.logmein-gateway.com

Y  partir de ahí el servicio de LogMeIn se conecta a uno de los servidores descritos en esa lista.

¿Cómo detectar los Mac OS X con LogMeIn?

Pues basta con utilizar cualquier herramienta de DNS Cache Snooping y configurarla para buscar estos registros, si alguno está en la caché DNS, entonces se podrá inferir que hay algún Mac OS X con el servicio LogMeIn. La FOCA tiene un módulo de DNS Cache Snooping que puede usarse para detectar software vulnerable.

Si quieres obtener la FOCA Pro y aprender más sobre cómo sacarle partido, puedes apuntarte al training online del día 14 de Marzo.