Forzar por fuerza bruta el nombre real de usuarios de macOS desde el navegador mediante mDNS

 (fingerprint.com)
3 puntos por GN⁺ 2023-07-14 | 1 comentarios | Compartir por WhatsApp
  • El nombre de host local predeterminado de macOS puede incluir el nombre del usuario, lo que permite a un sitio web reducir candidatos sin permisos mediante diferencias de tiempo en la resolución de nombres mDNS
  • Un atacante combina 50 nombres populares por país y género con candidatos de nombres de dispositivo; en pruebas, acertó el nombre de usuarios de macOS en un promedio del 65% de los casos
  • El JavaScript del navegador no puede abrir sockets UDP arbitrarios, pero puede comparar la latencia de respuesta de direcciones .local con solicitudes de fetch, iframe, Image y WebRTC
  • Información como zona horaria, idioma, ubicación de IP, navigator.language de Safari, resolución de pantalla y screen.isExtended puede usarse para reducir los candidatos de locale y modelo de dispositivo
  • Su utilidad práctica es baja y es fácil de detectar en la pestaña de red de las herramientas para desarrolladores, pero el mismo método de descubrimiento mDNS también podría usarse para detectar impresoras, smart TV, bocinas inteligentes y dispositivos IoT

Cómo se filtra el nombre desde el nombre de host local de macOS

  • El nombre real de un usuario de macOS puede inferirse desde el navegador sin solicitar permisos, y la clave está en el protocolo mDNS y en el formato predeterminado del nombre de host local
  • Incluso usando solo una lista de 50 nombres populares por género de un país específico, se detectó correctamente el nombre de usuarios de macOS en un promedio del 65% de los casos
  • Fingerprint no usa esta técnica en su producto ni ofrece un servicio de rastreo entre sitios
  • El objetivo de hacer pública esta discusión es ayudar a que los proveedores de navegadores corrijan rápido este tipo de técnica

Cómo funcionan mDNS y Apple Bonjour

  • multicast DNS es un protocolo para registrar, descubrir y difundir nombres de dispositivos dentro de una red local
  • Dispositivos como impresoras envían paquetes UDP de registro a la IP interna reservada 224.0.0.251, y pueden incluir nombres de host como HP_LaserJet_Printer.local
  • El dominio de nivel superior .local indica que ese nombre de host debe resolverse mediante mDNS
  • Los routers retransmiten automáticamente estos paquetes a otros dispositivos de la red local para que puedan almacenar en caché los nombres de host
  • Los dispositivos envían paquetes de consulta a la misma IP reservada para encontrar un dispositivo con un nombre específico que podría existir en la red
  • Algunos nombres de host de ejemplo son los siguientes
    • johns-mac-mini.local
    • david-ZenBook-UX431DA-UM431DA.local
    • james-iphone.local
    • canon-mf644c.local
    • bedroom-appletv.local
    • dlinkrouter.local
  • En dispositivos Apple, mDNS se usa ampliamente como parte de la función Apple Bonjour
  • El nombre de usuario puede quedar expuesto en el nombre de host local predeterminado y, en macOS, se puede revisar o cambiar en System Settings > Sharing

Método indirecto para comprobar nombres de host mDNS desde el navegador

  • mDNS se basa en paquetes UDP, por lo que no puede usarse directamente con sockets UDP arbitrarios dentro del entorno JavaScript del navegador
  • En su lugar, se aprovecha que el navegador intenta resolver el nombre de host de una URL para realizar un ataque de temporización
  • La prueba de concepto envía solicitudes fetch GET normales a device-1.local, que existe, y device-2.local, que no existe
  • Si la dirección se resuelve, el navegador envía un paquete TCP al puerto 80, que normalmente está cerrado
  • A nivel de red, aparecen errores distintos
    • device-1.local existente: ERR_CONNECTION_REFUSED
    • device-2.local inexistente: ERR_NAME_NOT_RESOLVED
  • En JavaScript, ambos errores se mapean al mismo error Failed to fetch, por lo que no se puede depender del tipo de error en sí
  • Como la red local es rápida, un nombre de host mDNS válido se resuelve mucho más rápido que el tiempo de espera predeterminado de la conexión
  • En el ejemplo, una dirección válida respondió en 4 ms y una inválida en 5 segundos
  • Este enfoque es lo bastante consistente para una prueba de concepto y se comporta de forma similar en los principales navegadores
  • En la práctica, además de fetch, también se pueden realizar ataques de temporización de resolución DNS con APIs de red de JavaScript como iframe, Image y WebRTC

Cómo forzar por fuerza bruta el nombre de un usuario de macOS

  • El nombre de host local predeterminado de macOS incluye el nombre del usuario y el nombre del dispositivo, y su formato cambia según el locale del idioma del sistema
    • Inglés: <name>s-macbook-pro.local
    • Francés: macbook-air-de-<name>.local
    • Ruso: mac-mini-<name>.local
  • Con un enfoque simple, combinar los 1,000 nombres más comunes, los 10 locales principales y 5 nombres típicos de dispositivos macOS obligaría a probar 50,000 nombres de host
  • En ese caso, la comprobación completa puede tardar más de una hora
  • Una estrategia más eficiente es limitar la búsqueda a un solo locale, un solo dispositivo y 50 nombres comunes de ese locale
  • Reducir el alcance baja la precisión, pero también reduce el tiempo del ataque y lo vuelve un escenario más realista
  • Para elegir el locale se pueden usar la zona horaria, el idioma y la ubicación de la dirección IP del navegador
  • Safari expone el locale del sistema mediante la propiedad navigator.language, y este valor normalmente coincide con el locale del nombre de host objetivo
  • Otra técnica indirecta para encontrar el país de origen del usuario es el método de detección de región de Apple ID tratado anteriormente
  • Los candidatos de dispositivo pueden acotarse con la resolución de pantalla
    • Por ejemplo, una resolución de 1728x1117 probablemente corresponde a una MacBook Pro de 16 pulgadas
    • Una pantalla extendida puede detectarse con la propiedad screen.isExtended
    • Si se detecta una pantalla extendida, los candidatos de dispositivo pueden volver a reducirse a los 3 o 5 dispositivos Apple con macOS más comunes

Límites y otras aplicaciones posibles

  • Este ataque no es práctico debido a debilidades inherentes y varias limitaciones
  • A menos que un sitio web quiera desanonimizar intencionalmente a sus visitantes, es fácil detectarlo en la pestaña de red de las herramientas para desarrolladores del navegador
  • Si este método se combina con detección de aplicaciones instaladas, podría crearse un sitio dañino que muestre el nombre real del usuario y su puesto con base en la lista de aplicaciones profesionales que usa, todo sin permisos
  • Aunque el ejemplo principal son dispositivos Apple con macOS, la técnica de descubrimiento mDNS puede ampliarse de varias maneras
  • También puede usarse para detectar impresoras, smart TV, bocinas inteligentes y otros dispositivos IoT del hogar mediante escaneo de red local
  • También puede aplicarse a iPhone y iPad, siempre que esté activada la sincronización por Wi‑Fi o la función de depuración remota de Safari

Lecturas relacionadas

1 comentarios

 
GN⁺ 2023-07-14
Comentarios de Hacker News

  • Uso Little Snitch en macOS y tiene una interfaz bastante buena que puede configurarse para preguntarle explícitamente al usuario local antes de permitir solicitudes de red
    https://www.obdev.at/products/littlesnitch/index.html
    A veces me bloquea mientras inicio sesión de forma remota, normalmente cuando mi sesión SSH intenta descargar algo nuevo, como cuando NPM obtiene componentes de NodeJS. La descarga por SSH en la terminal de texto se queda congelada y, cuando me doy cuenta de que la causa es Little Snitch, tengo que bajar hasta el escritorio de abajo, mover el mouse para despertar el monitor, quitar el protector de pantalla y hacer clic en “Allow” en el cuadro de diálogo de Little Snitch
    Supongo que está funcionando como se diseñó. Dicho eso, este tipo de herramientas a menudo viene configurado para permitir silenciosamente las solicitudes a la red local por defecto, así que no sé si la travesura del post original funcionaría también en mi entorno

    • En mi caso, me cuesta imaginar configurar LittleSnitch para permitir solo ciertos nombres de host desde el navegador. Tengo una regla de “permitir todo el tráfico a 53/80/443”, porque si no, la mayoría de los sitios web harían que LittleSnitch mostrara cientos de ventanas emergentes
    • Uso NetFence en un iPhone con jailbreak
      Sorprende ver qué conexiones de socket abren las apps a escondidas, incluidas las apps bancarias
      https://havoc.app/package/netfence
    • Pero Little Snitch filtra la IP incluso cuando bloquea :(
      https://news.ycombinator.com/item?id=35363343
    • He usado OpenSnitch, un software similar en Linux. No detectó nada raro, pero sí resultó bastante molesto para las tareas básicas en general
    • Como referencia, la resolución DNS ocurre antes del popup de permitir/denegar conexión. Por ejemplo, www.example.com se resuelve a 1.1.1.1, pero la conexión real a 1.1.1.1 no se establece hasta que presionas Confirm
      Si agregas Pi-hole a tu red, no te vas a arrepentir del tiempo/dinero/inversión

  • ¿Hay alguna forma de impedir que sitios web del internet más amplio hagan solicitudes de red a mi red local? Me cuesta imaginar por qué esto debería estar permitido por defecto
    No estoy sugiriendo revivir los permisos de la Local Intranet Zone de IE

    • En general no pueden por CORS. La única razón por la que este “hack” funciona es por la diferencia en el tiempo de rechazo entre solicitudes a dominios que no se resuelven y solicitudes que sí se resolvieron pero son rechazadas
      Aun así, aunque tengas algo corriendo en https://192.168.2.1, una app web que se ejecute desde https://my-own-domain.com no puede acceder a eso a menos que el servicio en 192.168.2.1 permita my-own-domain.com como Origin
    • Brave agregó recientemente una función que requiere permiso para acceder a la red local
      https://brave.com/privacy-updates/27-localhost-permission/
      Post de HN: https://news.ycombinator.com/item?id=36574775
    • Una app que suele abusar de esto es la app de escritorio de Discord, que deja un puerto local abierto y escuchando
      Cuando el navegador va a una página de invitación a un canal de Discord, envía una solicitud a localhost a través de ese puerto y le pasa el ID del canal al cliente. Entonces la app puede mostrar la experiencia nativa de “Join Channel”
      Me di cuenta porque esto seguía funcionando incluso en modo incógnito y con el navegador desconectado de Discord. No está bien. Hace falta mejorar mucho el sandboxing de todas las aplicaciones en el mundo de escritorio
    • Se puede bloquear con un filtro estático de uBlock Origin:
      ||local^$all
      Esto bloquea todas las solicitudes hacia .local, incluidas las solicitudes originadas desde .local mismo. Si quieres permitir que foo.local se comunique consigo mismo, por ejemplo porque estás ejecutando un servidor web, necesitas una excepción adicional por dominio:
      @@||foo.local^$domain=foo.local,all
      O, si confías en .local completo y quieres permitir que cualquier foo.local se comunique con cualquier bar.local, puedes agregar una sola excepción para todo .local:
      @@||local^$domain=local,all
    • Para evitar confusiones, el problema no es que un servidor de internet esté enviando solicitudes a la red local, sino que el navegador web local está enviando esas solicitudes. Claro, el JavaScript que se ejecuta en el navegador puede haberse cargado desde un servidor en internet

  • Con el paso del tiempo, cada vez me da más tranquilidad usar internet principalmente desde una caja de Qubes, con una VM desechable de Whonix/Tor y JavaScript desactivado
    Esto es realmente asqueroso. No sorprende, pero el simple hecho de que sea posible es horrible en varios sentidos
    Si no conoces fingerprint.com, ellos hacen “perfilado profundo de usuarios”. Piensa en ello como mantener el mismo ID de usuario incluso si cambias de computadora, navegador o sistema operativo. Hay una demo en la página principal y da un poco de escalofríos lo bien que acierta

    • Te identifica completamente como el mismo dispositivo incluso con IP distintas de VPN. De verdad da escalofríos
    • Esto es asqueroso. Impresiona que lo logre en el modo incógnito de un iPhone estándar incluso cambiando dos IP, aunque claramente debería verse igual que otros iPhone
      Filtro de uBlock Origin para romper la demo:
      ||fpjscdn.net

  • Con un tipo similar de ataque de temporización, se puede hacer escaneo de puertos a la máquina local y a otros dispositivos de la red local desde el navegador
    https://github.com/Flu1dTeam/PortScanner
    Hace tiempo atraparon a eBay haciendo esto
    https://blog.nem.ec/2020/05/24/ebay-port-scanning/

    • ¿Qué? Esto da muchísimo miedo, ¿cómo es que nunca había oído hablar de esto?

  • Menos mal que siempre cambio el nombre de mis dispositivos
    El esquema de nombres por defecto de Apple es un error de privacidad. Una vez tuve una primera cita con una persona de las fuerzas del orden; era una mujer que había ido sola y claramente se preocupaba por protegerse, así que me dijo que había investigado mis antecedentes y que también había avisado a varias personas de su comunidad dónde estábamos
    En cambio, yo ni siquiera sabía su apellido, y lo tomé como broma. Después de cenar, cuando nos subimos al coche, en la pantalla del tablero apareció que su iPhone se había emparejado automáticamente, y el nombre del iPhone estaba configurado con su nombre y apellido, lo cual me pareció interesante. No se lo señalé y, hasta el final del trayecto, le pedí que adivinara cómo sabía su nombre

    • De verdad pasa muy seguido que en autos rentados queden guardados una docena o más de perfiles de teléfonos emparejados anteriormente, con libreta de contactos, ubicaciones guardadas en mapas e incluso historial. Claro, no sirve de mucho, pero es información que se filtra sin pensarlo
      Lo más difícil es acordarme de borrar mi perfil antes de devolver el coche

  • En el ejemplo de arriba, una dirección válida tarda 4 milisegundos, y una inválida tarda 5 segundos
    Esto me sorprendió. Habría esperado que un fallo en la consulta DNS fuera mucho más rápido que el timeout de conexión por defecto que viene después de una consulta DNS exitosa
    Aun así, siempre me pareció que s-mac-xxxx era una elección algo rara. Más todavía considerando que es una empresa que vende mucho la privacidad como punto fuerte. Uno esperaría que no usaran nombres reales, o quizá aquí priorizaron la “facilidad de uso”. Desde la perspectiva de privacidad, los nombres de host aleatorios que genera Windows son mejores

    • El DNS normal le pregunta a un solo servidor en una sola IP una respuesta de sí o no, pero mDNS es multicast, así que no hay un único servidor que pueda decir con autoridad “no”†. Solo cuando la consulta expira porque ningún servidor responde se puede detectar que no existe el registro
      † En rigor, no es del todo cierto. Si algún dispositivo sabe que ese nombre le pertenece, puede responder que no
    • La razón por la que el nombre real del usuario termina en el nombre de host probablemente sea AirDrop. Parece que el sistema usa el nombre de host para funciones como Personal Hotspot o AirDrop, y otro tipo de nombre podría generar mucha confusión al compartir archivos
    • Además del punto sobre el timeout de conexión por defecto, aquí también se da el caso de connection refused, o sea, se recibió un RST y no un timeout de conexión

  • El texto está bien escrito y es interesante. Me gusta especialmente el tono sin exageraciones, con frases como “considerando las debilidades inherentes y las muchas limitaciones, este ataque no es práctico”

    • En otro universo, esto se habría llamado “FINGERBleed” y habría venido con sitio web elegante y logo incluido
    • No estoy tan seguro
      Este método permite probar si existe un nombre de host específico en una red
      Si es un único nombre de host poco común, quizá no sea gran cosa, pero ¿qué pasa con los nombres de host fijos o por defecto, tan comunes en el mundo IoT?
      Un sitio web podría adivinar a escondidas si el usuario tiene cierto dispositivo. Usado para ataques dirigidos sería peor. Si ya conoces algunos dispositivos de la red, podrías inferir si el usuario que se conectó está dentro de la red objetivo

  • Ojalá desactivar JavaScript no significara desactivar también la experiencia final del usuario

    • Esta es la única razón por la que no puedo desactivar JavaScript globalmente
      Aun así, parece que de ahora en adelante no quedará otra que dejarlo desactivado por defecto por motivos de privacidad
    • ¿No hay alguna manera de limitar fuertemente lo que puede hacer un motor de JavaScript?

  • Por suerte, el nombre de mis dispositivos suele ser algo como “xxxs's MacBook Pro (34)”. No es un bug, es una función

    • Pongan el nombre de usuario de la laptop como user y el nombre de host como hostname. Cuanta más gente haga esto, mejor

  • Interesante, bien escrito y con una prueba de concepto decente. Bien hecho
    Como contramedida divertida, podrías cambiar el nombre de host del dispositivo a algo como atemptingurl.local para tentar al atacante a visitar ese sitio web. Esa página podría estar cuidadosamente diseñada para ejecutar la misma técnica contra el atacante y devolver un mensaje como este:
    “Hola, [nombre del dispositivo del hacker]. La información de tu máquina, tu dirección IP, tu ubicación geográfica y otros datos de fingerprint ya fueron recopilados y reportados a [insertar nombre de agencia cibernética aterradora].” Incluso si no es un veterano experto sino un script kiddie, al menos podría sacarle una risa
    A la gente le hacen falta más razones para reír :-)

    • Para eso tendrías que ejecutar un servidor HTTP con CORS totalmente abierto. Eso también te expone a todos los bugs del servidor HTTP que elijas, así que reduces tu propia seguridad