Cómo falsificar un JPEG

• El autor opera Spigot, un generador de jerarquías de páginas web falsas, y expone páginas generadas aleatoriamente frente a rastreadores web agresivos
• Recientemente descubrió que los rastreadores de imágenes estaban explorando el sitio de forma intensiva para encontrar imágenes jpg
• Para manejar la generación de imágenes en tiempo real con un uso mínimo de CPU, propone usar como plantilla solo las partes estructuradas de archivos JPEG reales e insertar datos aleatorios en la parte comprimida
• Los resultados del experimento muestran que los JPEG creados de esta manera, aunque tienen errores, pueden mostrarse en la mayoría de los visores de imágenes y también parecen suficientemente plausibles para los rastreadores
• Este método consume pocos recursos del servidor, pero impone carga a los rastreadores, y se aplica en alrededor del 60% de las páginas de Spigot

---

Antecedentes de Spigot y la falsificación de JPEG

• Spigot genera en tiempo real una jerarquía de páginas web falsas basada en Markov Chain para entregar datos sin sentido a rastreadores web agresivos
• Algunos rastreadores usan firmas de navegador aleatorias e IPs para ocultar su identidad, y se detectó la posibilidad de abuso ilícito de dispositivos mediante botnets
• A través del análisis de tráfico, se confirmó que un nuevo rastreador llamado "ImageSiftBot" solicitaba intensivamente páginas de Spigot para recopilar imágenes
• El objetivo principal de Spigot es minimizar el uso de CPU del servidor y mantener una operación eficiente

Cómo generar imágenes baratas

• Generar imágenes dinámicamente consume mucha CPU debido a la compresión, por lo que se necesitaba un método eficiente
• Se aprovechó el hecho de que un archivo JPEG está compuesto por la estructura del archivo (tamaño, color, etc.) y una zona de datos de píxeles comprimidos
• Se ideó un método para extraer solo la información estructurada del encabezado de varios JPEG y rellenar el área de datos de píxeles con datos aleatorios
• Así es posible generar imágenes al vuelo sin comprimir una cada vez, minimizando la carga del servidor

Estructura del archivo JPEG e implementación real

• Un archivo JPEG está formado por múltiples chunks (con marcadores y longitud)
• Se conservan el encabezado y los metadatos, se registra solo la longitud de los datos de píxeles comprimidos, y se insertan datos aleatorios únicamente en esa zona
• Al usar 514 muestras JPEG, el tamaño total de toda la información de encabezados y de los datos estructurados necesarios es de apenas unos 500KB, por lo que la carga de memoria es mínima
• Ejemplo de código: la imagen se genera rellenando con números aleatorios el chunk de datos de píxeles de cada plantilla

Resultados en uso real y publicación como código abierto

• Los visores de imágenes reales pueden mostrar una imagen hasta cierto punto incluso si la zona de píxeles contiene datos completamente aleatorios
• A los rastreadores les cuesta identificar el error, y el costo de recopilar datos aumenta
• Con JPEG de 1280x960 y tamaño entre 200 y 300KB, se generan unas 900 imágenes por segundo, por lo que el procesamiento en tiempo real no representa problema
• Este método se aplica al 60% de todas las páginas de Spigot, y usa una semilla aleatoria basada en la URL para devolver la misma imagen en solicitudes repetidas
• Se observó un alto volumen de solicitudes de ImageSiftBot, Meta, AmazonBot, GPTBot y otros
• El objetivo central es cargar a los rastreadores usando pocos recursos del servidor

Códigos Huffman y optimización adicional

• Los datos de píxeles de JPEG usan codificación Huffman, por lo que insertar datos completamente aleatorios puede provocar errores en algunos visores
• Se añadió una técnica simple de enmascaramiento de bits (0x6D) para evitar que aparezcan 3 o más bits en 1 de forma consecutiva, reduciendo la probabilidad de códigos Huffman inválidos de 90% a menos de 4%
• También sería posible crear un flujo Huffman completamente válido, pero la ventaja es mínima frente al costo en recursos del servidor y tiempo de desarrollo

Conclusión

• El método de JPEG falsos de Spigot ahorra recursos del servidor con una eficiencia abrumadora y al mismo tiempo genera confusión y desperdicio de recursos para los rastreadores
• El código relacionado tiene menos de 100 líneas y fue publicado en GitHub
• Es una técnica simple pero creativa de defensa y dispersión del tráfico web

[GN⁺]

Opiniones en Hacker News

• Era de esperarse que el archivo robots.txt bloqueara el acceso de robots al árbol /spigot/, pero descubrieron que si simplemente quitaban /spigot/ de la URL, igual podían seguir accediendo a Spigot; como el espacio de nombres /~auj no está bloqueado por robots.txt, incluso un crawler bien intencionado podría entrar por accidente a esa ruta y caer en un bucle infinito de páginas, lo cual no es nada agradable referencia a robots.txt

  • Antes hubo un comentario del autor diciendo que no había configurado aparte un robots.txt; sobre haber tomado una medida tan extrema, dijo que no le gusta la idea de que el operador de un sitio web tenga que configurar algo a propósito para evitar un DOS causado por crawlers; su postura es que un crawler legítimo no debería estar raspando de forma sostenida un sitio más de 15 veces por segundo

  • Sobre el hecho de que incluso los crawlers bien intencionados puedan caer en un bucle infinito de páginas, se muestra escéptico respecto a cuál sería exactamente la obligación de un operador web de “ser amable” con quienes raspan su sitio; no está claro que realmente tenga que ser así

• Si se puede identificar que un crawler está ignorando robots.txt, parece más eficiente mantener ocupada la conexión de red y dejarla ahí que devolverle información “basura”; no queda muy claro por qué haría falta servir basura sin límite desde el endpoint

• Se le ocurrió la idea de confundir a los scrapers para entradas de IA poniendo captions falsos en cada imagen; por ejemplo, a una imagen con una mancha verde ponerle "un gato jugando con una pelota de catnip", y a una imagen azul algo distinto como "un petirrojo haciendo su nido"

  • Un scraper bien hecho podría analizar la imagen misma con el modelo CLIP u otro modelo de captioning para volver a verificar si la descripción textual realmente coincide con la imagen

• El caso más grave es facebookexternalhit, el bot operado por Meta (Facebook); incluso está documentado oficialmente que este bot ignora robots.txt; Facebook lo justifica como detección de enlaces maliciosos, pero en la práctica, si un usuario malintencionado envía repetidamente a Facebook la URL de un endpoint costoso, el efecto es que Facebook termina lanzando el bombardeo de tráfico por él; por eso, varios días al mes el sitio recibe oleadas de tráfico de más de 10 r/s durante un día entero

  • Aun así, hay duda de si 10 r/s realmente califica como un “bombardeo de tráfico”; incluso contra un solo servidor apenas sería perceptible

• Al leer sobre Spigot, alguien recordó Project Honeypot; hace 20 años le emocionaba bastante recibir correos diciendo que los scripts del proyecto y el registro MX que había donado habían ayudado a atrapar recolectores de correo en su sitio; por ejemplo, le avisaban que gracias a su MX habían detectado a un remitente de spam no verificado (IP: 172.180.164.102)

  • El script honeypot está padre, pero hoy en día se siente bastante anticuado; el script en Python (que además no se puede modificar por los TOS) solo soporta CGI y Zope de forma predeterminada, así que quien haga una app WSGI probablemente tendría que rodearlo con un wrapper

• Falsificar un JPEG cuesta mucho menos CPU que generarlo correctamente; además, este proceso en sí mismo también puede funcionar como una especie de fuzzing, haciendo que el malware del otro lado se caiga (crash) si su decodificación de JPEG es deficiente

• Que el tráfico reciente venga de miles de IP residenciales no significa necesariamente que sea una botnet típica; también podría ser una estructura de proxyware, donde mucha gente se inscribe en “VPN gratis” o herramientas de “ingresos pasivos”, y su dispositivo termina funcionando como nodo de salida para el tráfico de otros usuarios; en ese caso podrían estar sirviendo, sin saberlo, como conducto del tráfico de crawlers de IA material relacionado

  • Al final, este tipo de proxyware también es una variante de botnet a la que los usuarios se unieron voluntariamente; como es poco probable que esas personas descubran en sitios como HN que su IP es el problema, parece razonable que alguien redirija esas IP a una página de advertencia diciendo “eres parte de una botnet”; en la práctica, de todos modos, lo más cómodo es simplemente bloquearlas sin más

  • Opinan que esto también entra perfectamente dentro de la categoría de botnet

• Resulta llamativa la forma en que se habla de cómo satisfacer al bot; fue un artículo divertido y el proyecto también parece interesante

• La actitud de “me dio lástima el bot luchando por cumplir su misión y pensé en cómo alegrarle el día” se siente muy fresca y divertida; contrasta bastante con los hilos que normalmente están llenos de enojo y quejas

  • Esa actitud positiva también es posible gracias a la tranquilidad de poder hacer sufrir a los crawlers malos y darles basura

• Me gusta el resultado (la imagen) de este enlace ver imagen, se siente como una especie de pieza artística con mensaje

  • Si quieres la verdadera experiencia Spigot, en Firefox puedes ir a F12 > Network > cambiar No Throttling a GPRS, y en Chromium a F12 > Network > crear un Custom profile de 20kbps para limitar la velocidad y sentirlo de forma más realista

  • Me pregunto si aquí también hay contenido relacionado con Shakespeare