Ataques de timing usando WebSockets: cómo los sistemas antifraude escanean tus puertos locales

¿Te gustaría probar Octo Browser con descuento?
Usa el código promocional OCTOSCRAPER para obtener un 30% de descuento en cualquier suscripción. Esta oferta solo es válida para nuevos usuarios.

Cómo WebSocket se convierte en un escáner local

Para empezar, un poco de contexto: WebSocket es un protocolo de comunicación sobre TCP diseñado para intercambiar mensajes entre cliente y servidor en tiempo real.

En un principio fue creado para poder jugar en el navegador sin lag o ver cuándo la otra persona está escribiendo en un chat. Pero los desarrolladores de sistemas de protección rápidamente se dieron cuenta de algo: si un navegador puede abrir un socket hacia un servidor remoto, en la mayoría de los casos nada le impide iniciar también una conexión hacia una dirección local del usuario.

¿Cómo ocurre esto? Justo después de cargar la página objetivo, o en el momento de iniciar sesión, un script antifraude oculto empieza a generar de forma asíncrona intentos de conexión. Pero no escanea todo al azar. El script usa la dirección 127.0.0.1 y recorre un pool de puertos predefinido (9222 para CDP, puertos de clientes VPN locales populares o de bases de datos). Y, por lo general, eso funciona.

Por qué el navegador lo permite

Los navegadores y sistemas operativos actuales tienen dos particularidades de arquitectura:

1. Evita el CORS estricto. Si el sistema antifraude intentara escanear puertos con una petición HTTP normal (fetch o XMLHttpRequest), el navegador bloquearía la lectura de la respuesta por la política de seguridad y las reglas contra contenido mixto. Sin embargo, el estándar WebSocket no usa el modelo clásico de CORS para restringir la lectura de respuestas, sino que envía una cabecera Origin que el servidor puede verificar. El simple hecho de que la conexión se establezca o falle ya aporta datos para el análisis.

2. El punto ciego del firewall. La interfaz de red loopback (tu dirección local 127.0.0.1) goza de un nivel de confianza enorme por parte del sistema operativo. El tráfico que va del navegador a un puerto local físicamente no sale hacia la tarjeta de red. La mayoría de los firewalls por defecto de Windows o macOS ni siquiera filtran este tipo de conexiones internas, porque las consideran seguras.

De este modo, el antifraude obtiene un túnel legítimo y sin bloqueos para husmear en tu entorno de trabajo. Pero, ¿cómo sabe exactamente si un puerto está abierto o cerrado, si no puede leer las respuestas directas del sistema?

La mecánica del ataque de timing

El entorno aislado del navegador (“sandbox”) limita mucho a los scripts. Por las políticas de seguridad (SOP/CORS), un script no puede simplemente leer la respuesta de un servicio local ni obtener el código exacto del error de conexión. Pero en un ataque de timing eso no hace falta. La mecánica es la siguiente:

1. El script arranca un temporizador interno (casi siempre con performance.now()).

2. Se inicia un intento de conexión WebSocket: new WebSocket('ws://127.0.0.1:9222').

3. El script espera a que se dispare el manejador de errores (onerror).

4. El temporizador se detiene al saltar el error y se calcula la diferencia de tiempo.

La clave está en cómo el stack de red del sistema operativo maneja las conexiones TCP:

• Puerto cerrado: el sistema operativo rechaza el paquete SYN entrante enviando un TCP RST. El navegador cierra el socket y dispara onerror. El tiempo de respuesta en red local es mínimo, normalmente entre 1 y 5 milisegundos.

• Puerto abierto: ocurre un handshake TCP completo (de tres pasos). Luego el navegador envía una petición HTTP de "Upgrade" al protocolo WebSocket. Aunque en ese puerto no haya un servidor WS (por ejemplo, sea una base de datos o SSH), la conexión no se corta de inmediato, sino por protocolo incorrecto. El tiempo del handshake y el intercambio de datos hace que la diferencia sea claramente mayor: de 10 a 50 milisegundos.

• Puerto filtrado por un firewall: el paquete SYN se descarta directamente. El navegador no recibe respuesta del SO y espera el timeout del sistema. Aquí la diferencia de tiempo es mucho mayor y se mide en segundos.

Los navegadores modernos redondean los valores de los temporizadores a entre 0,1 y 1 ms. Pero para este tipo de ataque de red esa precisión ya sobra. La diferencia entre un TCP RST instantáneo y la espera en un puerto abierto se mide en decenas de milisegundos, y eso basta para una detección fiable.

Los sistemas antifraude más avanzados tienen en cuenta que el tiempo de respuesta se ve afectado por la carga de CPU, el trabajo del recolector de basura de JavaScript y las particularidades de cada sistema operativo. Por eso no usan umbrales fijos.

Antes de escanear los puertos objetivo, el script se calibra: primero toca un puerto cerrado, aleatorio y alto (ws://127.0.0.1:54321) para medir tu respuesta base personal de un puerto cerrado en ese momento. Y es sobre ese valor de referencia que se calculan las anomalías en los puertos relevantes.

Para qué quiere el antifraude tu localhost

El objetivo de los sistemas antifraude es desanonimizar el perfil y detectar rastros de multicuentas.

La mayoría de las soluciones antidetect se concentran en el spoofing de las huellas digitales (Canvas, WebGL, fuentes) y dejan el stack de red sin la atención que merece. Para los sistemas de protección los puertos abiertos específicos funcionan como un marcador confiable de que se está suplantando una identidad digital o usando herramientas de automatización.

Los algoritmos de scoring buscan:

Las estadísticas de timing, recopiladas en fracciones de segundo, se envían al servidor del sistema de scoring. Ahí se analiza la matriz de puertos y, según el resultado, se suman puntos negativos al scoring del perfil (o no).

Si tienes abierto el puerto 9222, es una señal de que el perfil no lo maneja una persona real, sino un script (Puppeteer, Playwright, Selenium) vía protocolo CDP. Ninguna simulación de movimientos de mouse o de tipeo humano va a ayudar en ese caso: la sesión corre el riesgo de recibir el riesgo-score máximo, y en el mejor de los casos aparecerá un captcha, y en el peor (si el antifraude es estricto), la sesión será baneada.

Si tienes abiertos los puertos 22 (SSH), 3306 (MySQL) u otros puertos específicos de clientes proxy locales, tampoco vas a poder pasar por un usuario común. El antifraude entiende que probablemente está frente a una máquina virtual, un servidor alquilado o una estación dedicada a multi-accounting. El nivel de confianza de la cuenta cae.

Cross-linking y vinculación de farms de cuentas

Esto es lo más problemático para el multicuentas. Supongamos que en una sola máquina tienes 50 perfiles: a cada perfil se le genera un fingerprint único y se le asigna una IP única. Desde afuera, parecen 50 personas distintas.

Pero el sistema operativo base (o el servidor) es el mismo. Y, por lo tanto, el conjunto de programas en segundo plano que corren en él (con sus propios puertos abiertos) también es el mismo. Ese patrón de puertos puede actuar como una especie de "superfingerprint". El antifraude puede detectar que 50 usuarios aparentemente distintos comparten una configuración idéntica y atípica de servicios locales, vincularlos en una sola red (farm) y mandar toda la cadena a un shadow ban.

Así es como, escaneando el localhost, los sistemas antibot pueden mirar detrás de la cortina de tu antidetect y ver la infraestructura real que lo sostiene.

Cómo protegerse: aislamiento y firewall

Para trabajar con sistemas antifraude serios tu protección debería basarse en estos principios:

• Aislamiento del stack de red: usar máquinas virtuales o contenedores con redes estrictamente restringidas. Si el navegador corre en un entorno completamente aislado, los ataques de timing van a devolver valores típicos de puertos cerrados, porque los servicios de la máquina host simplemente no estarán a su alcance.

• Configuración correcta del firewall: el firewall debe estar configurado no solo para bloquear, sino para rechazar de inmediato los intentos de conexión. Hay que usar la regla REJECT (que devuelve un TCP RST al instante) en lugar de DROP (que deja el paquete colgado hasta el timeout). Es precisamente REJECT lo que imita a un puerto cerrado de forma natural, sin levantar sospechas ante un analizador de timing.

• Bloqueo global: el método más radical, pero efectivo, es prohibirle por completo al navegador acceder a localhost. Esto neutraliza al instante los scripts antifraude que intentan sondear tu sistema.

Aun así, el bloqueo global tiene su contraparte. Algunos servicios (aplicaciones para trabajar con llaves de hardware o firmas digitales) usan agentes locales. La falta de comunicación con ellos puede convertirse, en sí misma, en una anomalía para el scoring.

Por eso, en esta situación hay dos soluciones óptimas:

• Filtrado puntual: permitir el acceso, a nivel de firewall o de extensiones, solo a recursos locales de confianza, y cortar de raíz (con REJECT) cualquier intento de conexión WebSocket hacia puertos desconocidos en segundo plano.

• Usar herramientas especializadas que hacen esto a nivel de kernel (navegadores antidetect).

El navegador antidetección Octo Browser, por ejemplo, cuenta con protección contra el escaneo de puertos. Con esta función, Octo se hace cargo de este tipo de conexiones e intercepta, a nivel de la API del navegador (incluida la API de WebSockets), cualquier intento de un script de acceder a direcciones dentro del rango 127.0.0.0/8 o a localhost.

Comprobando la protección con tus propias manos

Se puede comprobar cómo funciona esto con una prueba sencilla.

Para empezar, lanza en tu computadora un servidor local común, con un puerto abierto.

Así se ve un puerto abierto.

Después abre cualquier sitio en tu navegador e intenta acceder al puerto abierto.

En un Chrome normal, la respuesta va a llegar con una pequeña demora. Esa demora es justamente la confirmación de que el puerto está abierto.

Si haces lo mismo en Octo Browser, vas a ver que el puerto aparece cerrado.

Octo Browser controla el acceso a tus puertos para evitar filtraciones.

¿Funciona Private Network Access (PNA)?

Private Network Access es una función de seguridad de los navegadores modernos (sobre todo de Chrome) que evita que sitios web públicos envíen peticiones a dispositivos o servidores dentro de la red local del usuario.

Es cierto que los navegadores modernos intentan cerrar esta brecha:

• Limitan o bloquean directamente el acceso a localhost desde contextos públicos no seguros.

• Exigen un Secure Context (HTTPS) estricto para iniciar este tipo de conexiones.

• Envían peticiones previas (CORS Preflight) antes de permitir el acceso a la red local.

Pero los desarrolladores de sistemas de protección también se adaptan a eso. Usan dominios públicos que resuelven a 127.0.0.1 (por ejemplo, yourapp.localhost.com) y trabajan con certificados HTTPS válidos, evitando así parte de estas restricciones básicas.

Y lo más importante: PNA no protege contra los ataques de timing a nivel de TCP. Aunque PNA termine bloqueando la petición al puerto local por falta de las cabeceras correctas, el navegador primero necesita establecer la conexión TCP para poder intentar leer esas cabeceras. Si el puerto está cerrado, el sistema operativo sigue rechazando la petición al instante (TCP RST en un lapso muy corto). Si el puerto está abierto, el handshake TCP se completa con éxito, el navegador intenta iniciar el intercambio de datos, se topa con las restricciones de PNA y recién ahí corta la conexión y devuelve un error. Todo eso consume esas mismas decenas de milisegundos que le bastan al algoritmo antifraude. PNA impide leer los datos, pero no puede ocultar el tiempo que la conexión efectivamente tardó.

Conclusión

Hoy en día, hay que abordar el spoofing de forma integral. Puedes armar un perfil perfecto parecido a un usuario común, pero un puerto de depuración 9222 olvidado o el puerto por defecto de una base de datos pueden delatar tu spoofing aparentemente impecable. Protege tu stack de red: aísla tus entornos de trabajo, configura reglas de firewall estrictas, o delega este trabajo en soluciones que previenen este tipo de filtraciones a nivel de kernel.