El caso en que FSE se encontró con el FBI

• El operador de FSE, mientras rastreaba a usuarios ilegales que llegaban a una instancia del fediverso, organizó con logs y correos electrónicos la secuencia de scraping de BoardReader/SocialGist y la solicitud de información del FBI
• El punto de partida del problema habría sido que los resultados de búsqueda de BoardReader hacían que incluso publicaciones de servidores externos parecieran publicaciones de FSE, lo que provocó tanto la llegada de usuarios ilegales como atribuciones erróneas
• BoardReader ocultaba el User-Agent y usaba proxies residenciales, Tor y reproducción de sesiones de navegador para raspar /api/v1/timelines/public?local=false; incluso después de ser bloqueado siguió repitiendo solicitudes, aumentando la carga y los costos del servidor
• El FBI envió el 14 de marzo de 2023 una Emergency Disclosure Request relacionada con WitchKingOfAngmar, pero esa cuenta no era de FSE sino de sneed.social, y la captura adjunta tampoco era una pantalla de FSE
• El operador observó que, tras contaminar el índice de BoardReader con una línea de tiempo falsa, cierta frase provocaba un aumento explosivo de solicitudes desde Facebook, y consideró que el reportaje de Torswats en 2024 encajó parte del contexto del interés del FBI

---

Rastreo iniciado por la llegada de usuarios ilegales

• El operador de FSE consideraba que la llegada de usuarios relacionados con pedofilia al servidor era una amenaza ontológica para FSE
  • La subida de material ilegal de abuso sexual infantil, el interés de las fuerzas del orden y la posible incautación del equipo eran riesgos directos
  • Concluyó que algunos usuarios operaban distribuyendo material ilegal en varios sitios y luego comprobando qué cuentas no eran bloqueadas
• Intentó disuadirlos publicando toda la información posible, como IP, correo electrónico y User-Agent, pero el efecto fue limitado
  • Muchos subían o descargaban archivos y luego se iban, y parecía un patrón de búsqueda de sitios donde no los bloquearan
• Mientras rastreaba la ruta de entrada, descubrió que el encabezado Referer de muchos usuarios apuntaba a boardreader.com

Método de rastreo con logs

• La premisa era que, para operar una instancia fediverse expuesta al internet público, había que poder analizar directamente bots, escáneres, worms y tráfico anómalo
• Para el análisis de logs se usaban awk, tail -f, mawk -Winteractive, grep, sqlite3, R, sed, sort, psql y más
  • awk se presenta como una herramienta parecida a SQL para logs de texto
  • También se usaron herramientas de red como dig, whois, traceroute, tcpdump, iftop, Shodan y listas de salidas de Tor
• Se modificó el formato de logs del servidor web, como nginx, para registrar encabezados arbitrarios, tiempo de respuesta y tiempo de respuesta del backend
  • Explica que los logs de FSE se acercaban a un formato delimitado por tabulaciones para poder manejarlos fácilmente con awk o herramientas tipo hoja de cálculo
• Incluso estadísticas simples se usaban para detectar anomalías
  • Calculando media y desviación estándar del número de solicitudes se identificaban IP, endpoints y patrones de solicitudes que se disparaban repentinamente
  • En cierto momento llegó a conclusiones del tipo “el 90% de las solicitudes POST viene de la misma dirección” usando este método

Seguimiento de BoardReader/SocialGist

• boardreader.com era originalmente una herramienta de búsqueda para foros, y el operador de FSE cree que el sitio no entendía bien fediverse y trataba a FSE como si fuera un único foro
  • Incluso publicaciones públicas llegadas desde otras instancias aparecían como si fueran publicaciones del foro freespeechextremist.com
  • SocialGist decía vender “accessible social data”, y el operador consideró que lo que decía un blog sobre que el desarrollador estaba en Serbia coincidía con la IP real
• El 5 de marzo de 2023, aunque no había registros explícitos de visitas de BoardReader en los logs de FSE, se detectó scraping de alta velocidad contra /api/v1/timelines/public?local=false
  • El navegador decía ser Chrome, pero iba mucho más rápido de lo que una persona podría hacer scroll
  • Había registros A desde spider1.boardreader.com hasta spider43, pero el tráfico real, según se cuenta, venía de 45.15.176.187, una IP entonces propiedad de DediPath
• Después de bloquear esa IP, siguieron muchos intentos desde IP residenciales de EE. UU., por lo que el operador concluyó que BoardReader compraba proxies residenciales para evitar la detección
• El 8 de marzo de 2023 empezó a bloquear solicitudes que usaban ciertos tokens con awk, iptables y scripts en Ruby
  • Después aparecieron solicitudes desde una IP de un ISP serbio que referenciaban devtools.boardreader.com
  • Según el relato, esas solicitudes cargaban recursos como un navegador normal, obtenían un token Bearer, ejecutaban JavaScript y luego reanudaban el scraping con ese token
• Probó devolver respuestas 429, 401, 403 y 500, pero el scraper repetía aún más las solicitudes y en la práctica se volvió un DoS
  • Después empezó a devolver 402 Payment Required, y mientras tanto el acceso a la línea de tiempo pública de TWKN quedó bloqueado

Intercambio de correos con SocialGist

• El operador pidió información sobre el crawler a [e-mail] el 5 de marzo de 2023
• El 13 de marzo de 2023 llegó una respuesta desde [e-mail] preguntando qué quería saber
  • El operador exigió que solo se llevaran publicaciones locales y que usaran un User-Agent que identificara a BoardReader
  • También entregó como rango a excluir del crawling todas las IP que poseía y avisó del problema de las llegadas vinculadas con pedofilia
• Dave dijo que lo pasaría al equipo de ingeniería, pero el operador cree que al mismo tiempo el desarrollador seguía depurando el scraper
  • En los logs quedaron solicitudes del 13 de marzo de 2023 desde 109.92.154.188 que referenciaban devtools.boardreader.com
  • El operador concluyó que SocialGist decía que se detendría mientras seguía trabajando en evasiones

La Emergency Disclosure Request del FBI

• El 14 de marzo de 2023, el operador recibió un correo desde una dirección fbi.gov con asunto Emergency Disclosure Request
  • El agente especial Peter Christenson pidió información de suscriptor sobre el usuario WitchKingOfAngmar
  • El archivo adjunto se llamaba FSE Screen Shot.PNG
• Tras revisar los encabezados del correo, los logs del servidor de correo y la información SPF de fbi.gov, concluyó que era un correo real del FBI
• La captura adjunta no era una pantalla de FSE
  • Mostraba a FSE como “forum” y arriba se veía “Forum • Blackrock Executiv...”
  • Estaban resaltados términos de búsqueda como “kill blackrock” y “larry fink”
  • También incluía un análisis de sentimiento básico
  • La publicación había sido escrita 26 días antes del correo, pero en la captura aparecían tiempos como “11 hours ago” y “13 hours”
• WitchKingOfAngmar no era usuario de FSE sino de sneed.social
• El operador respondió al FBI que no tenía información de ese usuario en FSE y que BoardReader había añadido “Free Speech Extremist”, pero la fuente de la publicación no era FSE
  • El agente del FBI preguntó a quién debía consultar, y el operador le indicó que verificara el servidor de origen

La secuencia que parecía conectar BoardReader, Facebook y el FBI

• El operador cree que el FBI y BoardReader rompían Unicode de la misma forma y coincidían en atribuir erróneamente publicaciones de servidores externos como si fueran publicaciones de FSE
  • Afirma que los codepoints Unicode originales 1f9e2, 1f438, 1f44d fueron reemplazados por cuadros con signo de interrogación que indican Unicode inválido
• A partir de estos indicios, concluyó que el FBI contactó a FSE después de ver datos de BoardReader
• El 15 de marzo de 2023 BoardReader seguía enviando solicitudes a FSE y solo recibía respuestas 402
  • El operador publicó una explicación pública limitada y puso a FSE en modo bloqueado
  • Sin cuenta ya no se podía ver ni TWKN ni la línea de tiempo pública, y también se cerró el registro
• Incluso después del 16 de marzo de 2023, BoardReader habría seguido intentando evadir con proxies residenciales, Tor y un User-Agent distinto en cada solicitud

Línea de tiempo falsa y contaminación de datos

• A partir del 24 de marzo de 2023, como continuaban el scraping de BoardReader y la llegada de usuarios vinculados con pedofilia, el operador empezó a servir una línea de tiempo falsa
• Creó un pequeño script CGI que generaba JSON combinando cuentas inexistentes con publicaciones inexistentes
  • Al principio los ID eran números aleatorios de 32 bits, y después mezcló parte de la hora de la solicitud para facilitar el rastreo dentro de BoardReader
  • Como nginx no soportaba CGI, enviaba las solicitudes a ese endpoint a lighttpd
  • Cuenta que la implementación se hizo principalmente con awk
• En la lista de palabras para las publicaciones falsas mezcló términos de búsqueda de BoardReader con una lista de palabras relacionadas con CARNIVORE
• Las publicaciones falsas fueron indexadas por BoardReader, y el operador comparaba IDs aleatorios introducidos en el buscador de BoardReader con los logs del servidor web de FSE y los elementos indexados

Observación del aumento explosivo de solicitudes desde Facebook

• El operador confirmó con histogramas de logs que llegaban solicitudes masivas desde Facebook hacia URLs de publicaciones falsas
  • Explica que las zonas con muchos 4 verdes o azules correspondían a respuestas 402 y que casi todas esas solicitudes venían de Facebook
  • Las URL solicitadas coincidían con las publicaciones falsas
• Concluyó que Facebook iba a buscar esas publicaciones justo después de que BoardReader las indexara
• Cuenta que cuando cambió la lista de palabras de las publicaciones falsas a solo “larry fink”, las solicitudes desde Facebook aumentaron casi de inmediato
  • Al quitar esa frase, el tráfico disminuyó y se detuvo
  • Al volver a ponerla, tras la espera de indexación en BoardReader, el aumento explosivo se reanudó
• El operador estimó un flujo awk CGI → lighttpd → nginx → crawler de BoardReader → índice de BoardReader → Facebook → interfaz interna de búsqueda del FBI
  • Aclara que nunca quedó claro qué papel jugaba Facebook para el FBI en ese flujo, ya fuera como herramienta o como repositorio

Cómo logró detener a SocialGist

• Para reducir los costos por exceso de ancho de banda, hizo las respuestas extremadamente lentas y las ajustó para terminar justo antes del timeout
  • A veces recortaba parte final del JSON para provocar errores de parseo
  • Concluyó que BoardReader parecía usar un parser JSON común y que gastaba cerca de un minuto sin obtener datos útiles
• Después puso el número de teléfono de Dave en publicaciones generadas aleatoriamente, y al día siguiente Dave respondió
  • Dave dijo que había creado un ticket en Jira y que pronto daría una respuesta
  • Tras un intercambio breve, el scraping se detuvo rápidamente, pero sacar a FSE del índice de BoardReader tomó alrededor de una semana

Epílogo encajado por el reportaje sobre Torswats

• El 18 de enero de 2024, Wired informó sobre el arresto de Alan Winston Filion en Lancaster, California
  • Según el artículo, estaba relacionado con Torswats y habría generado cientos de reportes falsos, incluidas amenazas de bomba y falsas situaciones de rehenes
• El operador cree que WitchKingOfAngmar era precisamente este Torswats
  • Señala que WitchKingOfAngmar parece una referencia a “Lord of the Rings”
  • Como Torswats solía hacer largas diatribas amenazantes y sin sentido dirigidas a Larry Fink, concluyó que por eso el FBI mostró interés en amenazas relacionadas con Larry Fink
• Este epílogo conecta parcialmente la solicitud del FBI, el término de búsqueda “larry fink” y el interés por amenazas contra ejecutivos de Blackrock
• Aun así quedan dudas
  • Qué es BoardReader actualmente
  • Si SocialGist usa BoardReader como una coartada plausible
  • Qué papel desempeñó Facebook en este pipeline
  • Si Facebook proporciona herramientas al FBI o si se usa como una especie de repositorio de datos

Consejo final para operadores de fedi

• El operador dice que, si alguien quiere datos de fedi, en lugar de hacer scraping sería menos destructivo crear una instancia falsa y conectarla a un relay
  • Aunque también considera inapropiado ese método, afirma que al menos permite recibir datos en tiempo real sin romper el servidor ajeno
• Opina que solo quedan expuestos los scrapers ruidosos y generales, mientras que es difícil notar a quienes recolectan datos discretamente modificando software ActivityPub o relays
• El operador advierte que pudo rastrear a SocialGist porque cometió errores, y que es difícil saber cuántas organizaciones hacen lo mismo sin cometer esos errores

[GN⁺]

Opiniones de Hacker News

• El enlace del post del blog solo lleva a una lista de instancias que optaron por la desfederación.
  La razón por la que no va a la lista oficial de Fediblock es que Fediblock cerró hace unos años. Quien creó Fediblock dejó claro que no debía usarse de ninguna manera como veredicto final, y que cada quien debía contrastar cuidadosamente los criterios de las instancias publicadas con sus propios criterios. Mi intuición es que el autor intentó enlazar una entrada de Fediblock, no la encontró y, sin verificar bien, la reemplazó por el enlace más parecido.

  • Opero un servidor Mastodon de tamaño mediano, y una persona de ese lado me dijo la n-word; la reporté al administrador, pero no hubo ninguna acción, así que la bloqueé.
    No tiene absolutamente nada que ver con Fediblock ni con otros mecanismos comunitarios de bloqueo. Los usuarios se comportaron pésimo y el administrador no hizo nada, así que simplemente decidí que no quería seguir hablando con ellos. Es gracioso que FSE se queje de que lo bloquean por culpa de alguna sociedad secreta. Sin ninguna gran conspiración, trolls comunes y corrientes pueden fastidiar directamente a otros hasta lograr que varios servidores corten la conexión.
  • Fediblock cerró en septiembre de 2023, y este texto tiene un montón de marcas de tiempo que muestran que los hechos ocurrieron antes de eso.

• Me gustó que la historia empiece con que no querían implementar CAPTCHA porque perjudica a usuarios reales, pero luego el 80% trate sobre cuánto tiempo estuvieron caídos el registro público y la línea de tiempo pública, y cuánto impactó negativamente eso a los usuarios.
  Aun así, fue una lectura entretenida, y me dejó muy claro que yo no podría encargarme de alojar por mi cuenta espacios comunitarios para otras personas en internet.

• Hay bastantes cosas que me gustan de este texto: una persona haciendo ciencia ciudadana al identificar parte del aparato de recolección de información/vigilancia del FBI, fragmentos de drama del Fediverse, y tácticas de administración de sistemas interesantes para operadores de servidores pequeños.
  El personaje torswats parece bastante problemático y acaba siendo arrestado, lo que agrega una subtrama interesante. El autor también parece bastante inteligente y me gusta su estilo. Vale la pena leerlo, cinco estrellas.

  • Es un gran texto, con una buena mezcla de detalles técnicos. Encajaría muy bien como charla en un evento como Chaos Communication Congress.
  • Hay que fijarse en la conclusión equivocada a la que llega el autor. El FBI pidió información sobre cierto usuario y envió una captura de pantalla que incluía amenazas de violencia, pero la persona de FSE concluyó de inmediato que era solo fanfarronería inofensiva.
    Más aún si se considera que otro CEO había sido asesinado apenas seis meses antes. Hacia el final del texto, esa persona ya había cometido innumerables actos de violencia por medio de intermediarios. Está bien que la persona de FSE se haya comunicado con una agencia federal, pero ver capturas de amenazas y asumir de inmediato que no podía tratarse de alguien violento revela un sesgo peligroso.

• Dice que “Fediblock dio una falsa impresión de que FSE permitía cosas que nunca permitió”, y aun así enlaza un sitio web cuyo código fuente está alojado en kiwifarms.
  La razón por la que lo bloquearon es que la mayoría de nosotros no queremos interactuar con el bando de la “libertad de expresión”, y eso es casi todo.

  • Eso suena como algo que no se conecta lógicamente con la frase a la que respondes. ¿Qué tiene que ver bloquear o no soportar a alguien con verificar hechos?

• Buen texto. Tengo una corrección muy pequeña, poco importante y quizá incluso equivocada.
  Interpretaron la palabra “Negative” en la captura del motor de búsqueda interno como análisis de sentimiento, pero en realidad parece posible que fuera un resultado “negativo” en el sentido de que esa publicación no coincidía con la intención de búsqueda: es decir, un botón para reportarlo como falso positivo en el sistema interno. No parece que el análisis de sentimiento fuera muy útil en esta situación.

  • No estoy de acuerdo. El ícono de “Negative” es una cabeza humana roja. ¿Quién elegiría ese ícono para “falso positivo”? En mi opinión, tiene más sentido interpretarlo como “sentimiento negativo”.

• Lo de que “aparecieron pedófilos en FSE” parece un problema de todo el Fediverse. Para ser justos, Discord también tiene lo mismo.

  • En la práctica, creo que pasa en cualquier lugar donde se puedan subir fotos y no esté conectado con un nombre real.
  • Signal y Telegram también.

• Es interesante que esto haya empezado por el encabezado Referer. Que el navegador le informe por defecto al servidor parte de mi historial de navegación parece un problema de privacidad.
  Si no recuerdo mal, Tor no tiene ese problema.

  • Curiosamente, esto se puede configurar tanto del lado del usuario como del lado del sitio que envía la referencia.
    La mayoría de los navegadores, al menos los relevantes, respetan el encabezado referer-policy configurado por el sitio de referencia 1. Frameworks web comunes como Django también tienen opciones para controlarlo 2. Como la mayoría de los agentes de usuario lo obedecen, si el sitio indexador hubiera querido, podría haber impedido fácilmente que ese encabezado se enviara para la mayoría de los usuarios.

• ¿No había una mejor forma técnica de bloquear scrapers? Algo como bloquear las IP o dominios en el punto de entrada, en lugar de procesar las solicitudes. Aunque quizá de todos modos habrían pagado el costo del tráfico de solicitudes.
  ¿No existe un mercado de servicios externos de protección DDoS para endpoints de API, como Cloudflare y similares? Claro que probablemente no era una solución adecuada para “Free Speech Extremist”, y además cuesta dinero. Aun así, en una situación así quizá sí habría ahorrado costos.

  • “Así que hice que el servidor descartara el tráfico de las IP que estaban haciendo scraping. ¡Problema resuelto! Entonces, de inmediato, empezaron a aparecer muchos intentos desde otras IP. Eran IP residenciales de Estados Unidos. Estaban comprando proxies residenciales.”