Cómo IdentityLogger neutralizó a los tramposos de CSGO
(mobeigi.com)- Invex Gaming operó servidores comunitarios de CSGO en Australia y Nueva Zelanda entre 2014 y 2019, y la evasión repetida de baneos aumentó la carga para los administradores que tenían que revisar demos manualmente
- Los baneos existentes rastreaban combinando dirección IP y Steam ID, pero si un tramposo cambiaba ambos al mismo tiempo, al servidor le resultaba difícil confirmar si era el mismo jugador
- IdentityLogger aprovechó las cookies persistentes del navegador VGUI integrado en CSGO para guardar un Tracking ID, y usó la dirección IP, el Steam ID y el Tracking ID como huella conjunta
- Tras desplegarse en todos los servidores en febrero de 2017, incluso los jugadores que cambiaban tanto su Steam ID como su dirección IP volvían a ser identificados mediante el Tracking ID y eran baneados de inmediato
- Este método funcionó hasta que Valve eliminó el navegador VGUI en octubre de 2017 para reforzar la seguridad, y después se publicaron tanto la técnica como el plugin
Operación de Invex Gaming y la carga de combatir a los tramposos
- Invex Gaming fue un servidor comunitario de CSGO con base en Australia y Nueva Zelanda que operó de 2014 a 2019
- Las tareas de operación abarcaban mantenimiento del foro y de la infraestructura de servidores, gestión de costos y donaciones, adición de modelos de jugador, corrección de hitboxes, automatización del sistema VIP, desarrollo de plugins personalizados, parches para exploits y bugs del juego, defensa contra DDoS y gestión de reportes
- Entre todo eso, la tarea más tediosa y desgastante era la identificación y el baneo repetido de tramposos
- Para la detección automática existían métodos como código del lado del servidor y Valve Anti-Cheat, pero debido al ciclo constante de respuesta entre desarrolladores de cheats y de anticheat, era difícil atrapar automáticamente todos los cheats
- Al final, el último recurso era el análisis manual viendo demos de CSGO, y los administradores tenían que decidir por sí mismos si un jugador estaba haciendo trampa
Dónde se rompe el baneo por dirección IP y Steam ID
- Un baneo típico consiste en guardar información identificable para bloquear el acceso a un servicio
- Los servidores de Invex Gaming usaban sobre todo dos identificadores
- Dirección IP: un identificador de internet asignado por un ISP o proveedor de servidores
- Steam ID: un identificador único vinculado a una cuenta de Steam
- Cuando un jugador era baneado, su dirección IP y su Steam ID se guardaban en la lista de baneos, y si luego se conectaba con la misma dirección IP o el mismo Steam ID, era expulsado del servidor
- Si alguien volvía cambiando solo el Steam ID pero usando la misma dirección IP, se podía vincular el nuevo Steam ID al baneo existente y volver a banearlo
- Lo mismo ocurría si cambiaba solo la dirección IP pero seguía usando el mismo Steam ID: la nueva dirección IP quedaba vinculada al baneo existente
- El problema aparecía cuando el tramposo cambiaba al mismo tiempo el Steam ID y la dirección IP
- Desde la perspectiva del servidor, era una combinación nunca antes vista de dirección IP y Steam ID
- No había forma de vincularla con un baneo previo, así que podía volver a jugar
- Incluso si volvía a ser baneado, podía seguir evadiendo el baneo cambiando ambos identificadores a la vez
- También se evaluó mantener listas de VPN populares y sus direcciones IP relacionadas, pero el equipo no prefería esa opción por la carga constante de mantenimiento
- El análisis posterior mostró que el tramposo más notorio tenía acceso a direcciones IP geográficamente distribuidas y a más de 87 cuentas de Steam con CSGO comprado
Posibles falsos positivos creados por la huella de dirección IP
- Aunque el Steam ID identifica de forma única a un jugador, la dirección IP no es un identificador único
- Si dos hermanos se conectaban al servidor desde la misma casa y solo uno hacía trampa, sus huellas podían quedar mezcladas por compartir la misma dirección IP, y ambos podían terminar baneados
- También podía haber problemas en redes compartidas, como una universidad, donde todo el tráfico externo sale por una sola dirección IP
- Una persona era baneada por hacer trampa desde la red del campus
- El Steam ID de otro jugador de esa misma red, junto con la IP de su casa, podía quedar vinculado y terminar baneado injustamente
- Para estos casos poco comunes, Invex Gaming creó un sistema de excepciones y recomendaba no jugar desde redes no confiables
Usar cookies del navegador VGUI como tercer identificador
- A inicios de 2017, el problema de evasión de baneos en el servidor empeoró mucho, y los administradores seguían obligados a revisar demos manualmente
- El reto central era reconocer al mismo jugador incluso cuando cambiaba al mismo tiempo su Steam ID y su dirección IP
- CSGO tenía un navegador web básico dentro del juego que permitía a los operadores del servidor mostrar un MOTD al conectarse, y se le llamaba navegador VGUI
- El navegador VGUI permitía a los operadores abrir cualquier sitio web en la pantalla del jugador, e incluso ocultar la ventana
- Ese navegador venía preautenticado con cookies de Steam, podía iniciar sesión automáticamente en dominios de Steam y también permitía ejecutar en el cliente JavaScript enviado por el operador del servidor
- La clave de IdentityLogger era que el navegador VGUI soportaba cookies y las conservaba entre sesiones
- Las pruebas mostraron que las cookies guardadas por el navegador VGUI seguían ahí incluso después de cerrar y volver a abrir CSGO
- Tampoco parecía haber un límite práctico en la fecha de expiración, y se podían guardar cookies con vencimientos de más de 10 años
- Los datos de cookies se almacenaban en un archivo dentro del directorio de instalación de Steam del jugador
- Con este método se podía asignar a cada jugador un tercer identificador llamado Tracking ID
- Para parecer un jugador nuevo, había que cambiar el Steam ID, la dirección IP y también la carpeta de instalación de Steam, y se asumía que ningún jugador llegaría a cambiar también la carpeta de instalación de Steam
Flujo de implementación de IdentityLogger
- IdentityLogger es un sistema unificado que crea huellas de jugadores con base en dirección IP, Steam ID y Tracking ID
- Cuando un jugador se conecta al servidor, primero se realiza una verificación de baneo en la base de datos
- La dirección IP, el Steam ID y el Tracking ID son los valores revisados
- Si existe un baneo previo, el jugador es expulsado del servidor y el nuevo identificador se vincula al baneo ya existente
- A los jugadores no baneados se les hace abrir una página web secreta en una ventana oculta del navegador VGUI
- La solicitud se autenticaba con un valor secreto, y aunque la petición del navegador VGUI se generaba en el cliente, el tráfico iba cifrado con HTTPS
- Un script PHP verificaba si ya existía una cookie con el Tracking ID
- Si no existía, generaba y guardaba un nuevo Tracking ID
- El Tracking ID era una cadena aleatoria alfanumérica de 64 caracteres como
TeStsCOhZO1TQsumJkDUOdMMo13ReRLEngrQTg7S49LKT2rBvgPhauzSYbegscOT - La cookie terminaba almacenándose en el archivo
vgui.browser.cookies.datdentro del directorio de instalación de Steam del jugador
- El Steam ID, la dirección IP y el Tracking ID se guardaban en la base de datos cada vez que el jugador se conectaba al servidor
- Esa base de datos estaba integrada con un panel web para que los administradores investigaran huellas de jugadores y con un plugin modificado de SourceBans, basado en software de gestión de baneos para juegos basados en Source
Cómo impedía la evasión de baneos
- Por ejemplo, si un jugador se conectaba por primera vez con la dirección IP
198.51.100.1y el Steam IDSTEAM_1:1:1111, se generaba un nuevo Tracking ID - Si ese jugador era baneado por hacer trampa, la dirección IP, el Steam ID y el Tracking ID entraban todos a la base de datos de baneos
- Más tarde, si el mismo jugador se conectaba con la dirección IP
100.64.50.74y el Steam IDSTEAM_1:1:3333, la nueva dirección IP y el nuevo Steam ID pasaban la verificación de baneo - Pero el Tracking ID guardado previamente seguía vinculado al baneo anterior, así que no superaba la verificación
- El sistema volvía a banear de inmediato al jugador y vinculaba la nueva dirección IP y el nuevo Steam ID al baneo existente
- Después de eso, sin importar qué dirección IP o Steam ID usara, sería baneado en cuanto se conectara debido al mismo Tracking ID
Resultados del despliegue en 2017 y publicación
- Tras las pruebas, Invex Gaming desplegó IdentityLogger en todos sus servidores de CSGO en febrero de 2017
- Justo después del despliegue, el número de tramposos baneados aumentó de forma notable
- También se descubrió que algunos miembros confiables y de larga data de la comunidad habían hecho trampa desde cuentas secretas
- Algunos tramposos incluso preguntaron directamente por qué habían sido detectados por evasión de baneo a pesar de haber cambiado su Steam ID y su dirección IP
- Otros operadores de servidores también mostraron interés en el plugin, y en algunos casos incluso ofrecieron dinero
- Como, si la técnica se hacía ampliamente conocida, bastaría con borrar el archivo de cookies para esquivarla, la implementación se mantuvo en secreto dentro del equipo de administración
- Este método siguió funcionando hasta que Valve eliminó por completo el navegador VGUI en octubre de 2017 como parte de un refuerzo de seguridad del juego
- Después de la eliminación del navegador VGUI, la técnica se hizo pública y el plugin también se liberó como código abierto
1 comentarios
Opiniones de Hacker News
En UT2004 se puede bloquear a jugadores por GUID (hash de la clave de CD) o por IP, pero después de que Epic abandonó el juego aparecieron muchos generadores de claves, así que el bloqueo por GUID quedó inutilizado; hoy en día también puedes usar una VPN por 2 dólares, por lo que el bloqueo por IP tiene límites importantes.
La principal solución que se usa ahora es, además de bloquear IPs, cargar en el firewall todas las bases de datos de subredes VPN conocidas para hacer bloqueo de VPN, y también una técnica similar de huella digital que revisa la estructura de ciertas carpetas del sistema.
Nació para Tremulous (un fork de ioquake3) porque la gente seguía evadiendo los bloqueos por IP, pero también puede usarse en otros juegos. No es mi proyecto, pero conozco al autor y, si hay demanda, podría forkearse y adaptarse para un juego específico o para uso general.
En schachtmeister2 también se pueden usar heurísticas como
whois -10 "Hosting",whois -13 "VPN",whois +7 "residential".Anexo: vi que el repositorio Git devuelve 502 y contacté al administrador.
Ya no juego online porque mi nivel se quedó atrás, pero cuando tengo unos 30 minutos libres sigue siendo divertido entrar a una partida rápida contra la IA.
El dueño del servidor permite conexiones de cuentas non-Steam (copias pirata), así que no podemos depender de bloquear por SteamID como con el GUID de Unreal. Cambiar una ID falsificada debe ser algo un poco engorroso, en algún lugar profundo de la carpeta de instalación, pero se puede. Es un juego bastante popular en el norte de África, los antiguos países bálticos y regiones cercanas, y el norte y oeste de Asia; sin esos jugadores el servidor quedaría vacío.
Así que usamos zanahoria y garrote. Los jugadores de Steam reciben recarga casi instantánea, exención de algunas funciones agresivas de administración automática/kick, nicks reservados y una etiqueta “VIP”. Por lo que cuestan unas cuantas claves de VPN, obtienen ventajas legítimas y la propiedad del juego, y el pago único va directo al desarrollador. O también pueden obtenerlo gratis si juegan al menos una partida por semana durante 5 semanas y contactan al staff por redes sociales.
Del lado del garrote, no los expulsamos/bloqueamos sin más; a propósito les hacemos la experiencia molesta para dejar claro que no son bienvenidos y que no quieran volver. Cosas como desarmarlos y darles el peor arma, teletransportarlos al azar fuera del mapa o hacer que queden atorados en el piso, repetir
amx_rocketpara convertirlos en fuegos artificiales, usaramx_drugpara subir al máximo el ángulo de visión y darles efecto de borrachera, o burlarnos de ellos diciéndoles que son losers sin habilidad que solo se divierten si una IA juega por ellos.También hay plugins amx y comandos considerados “ilegales”; normalmente se evitan porque se prestan mucho al abuso, pero en situaciones así son útiles. En especial
amx_exec, que da bastante miedo porque permite al administrador acceder directamente a la consola dentro del juego del cliente y ejecutar comandos o configuraciones arbitrarias.Por ejemplo, con comandos como
rate 1000,name iCaNtAiM,unbind all,bind y quit,fps_max 50se puede arruinar la velocidad de red, cambiar el nombre, borrar los keybinds, vincular la tecla de chat predeterminada a salir del juego y bajar los FPS máximos a un nivel que no sea demasiado evidente pero sí molesto. Restaurar los valores por defecto es fácil borrando el archivo de configuración, pero si no tienes un respaldo puede ser muy frustrante.Curiosamente, muchos servidores venden ventajas VIP por hasta 20 dólares al mes. Al principio me impactó, pero luego entendí que para aparecer en una posición decente en navegadores de servidores de terceros hay una especie de cartel turbio de guardianes, con costos bastante altos, y que gran parte de los ingresos se va en “boost”.
Cuando el dueño de nuestro servidor dejó de pagar “boost” durante dos meses, el promedio de jugadores cayó de 14/32 a 3/32, y el pico de concurrencia, que los fines de semana normalmente llegaba a 28/32, pasó a rondar 12/32 en una noche de viernes con suerte. En cuanto volvió a pagar, el número de jugadores subió de inmediato; lo loco es que cuesta 180 dólares al mes.
Antes de participar en la administración pensaba que bastaba con un deathmatch divertido, buena moderación, baja latencia, un servidor de alto rendimiento y estar dedicado a un remake/remix del segundo mapa más popular del juego para ser suficientemente popular. Pero parece que, para que la mayoría de los jugadores te vea, hay que pagarles de más a los guardianes existentes.
Igual que decirle a un scraper web que su IP fue bloqueada: con esa estrategia no ganas nada. Un mejor enfoque es marcar por detrás la IP del scraper y servirle solo datos basura mezclados aleatoriamente en la página.
Creo que con la detección de cheats pasa lo mismo. Si los bloqueas, solo pierdes ventaja estratégica, y cambiar de IP, clave de CD o cuenta es apenas una molestia menor para un tramposo.
Es un área que me interesa tanto profesional como personalmente, así que puedo ayudar si necesitan propuestas.
Me gusta que el autor haya usado una dirección TEST-NET-2 de RFC5737 como ejemplo de IPv4: “An example of an IPv4 IP address is 198.51.100.1.”
https://www.rfc-editor.org/rfc/rfc5737
Algún día en mi carrera me gustaría trabajar sí o sí en anti-cheat exclusivamente del lado del servidor. Esta clase de carrera armamentista adversarial parece realmente divertida para pensarla a fondo durante mucho tiempo.
Es una pelea perdida porque hay muchísimos más jugadores que desarrolladores.
Pasar todas las acciones importantes al servidor no es fácil ni barato, pero es una forma más integral de frenar los cheats.
Si a eso le sumas juegos con mucha simulación física, 120 de tickrate (quizá más alto después de más pruebas), combate de acción basado en controles precisos y el objetivo de escalar al tamaño de un MMORPG, se vuelve realmente difícil.
Ahora existen aimbots basados en YOLO, así que el mundo se volvió mucho más complejo, y la conclusión realista es que el anti-cheat eventualmente puede ser vulnerado.
Del lado del cliente puedes crear binarios privados cuyos hashes no estén registrados en los principales servicios anti-cheat, y del lado del servidor solo puedes ver lo que permiten las reglas del juego.
No hay un mecanismo para impedir reflejos sobrehumanos, y probablemente tampoco debería haberlo, así que se convierte en un problema que ya no se puede resolver.
Por eso hace falta el juicio de la comunidad, pero eso también es aburrido. En Counter-Strike, que a un jugador bueno lo acusen de cheater es un problema viejo y a la vez interesante.
Hace unos años compré varios Battlefield, pero varios eran injugables por cheaters con speedhacks y aimbots. Parecía algo fácil de detectar del lado del servidor, y me preguntaba por qué no hacían nada.
Si el sitio está caído o lento y quieres leer el artículo, hay una captura de pantalla de la página completa: https://i.imgur.com/SPp6IHX.jpeg
No esperaba que el artículo recibiera tanto tráfico.
Este artículo no trata de detener a los cheaters, es decir, de detección de cheats, sino de impedir la evasión de bloqueos, cuando un cheater bloqueado vuelve una y otra vez.
La detección de cheats es un juego completamente distinto, sobre todo hoy con cheats de hardware como DMA. Personalmente, creo que una de las formas más eficaces de frenar a quienes evaden bloqueos es cobrar dinero real por el juego.
A la gente de CS:GO no le preocupa demasiado que les bloqueen cuentas con skins por cientos de dólares. Es porque compraron una cuenta robada de otra persona por unos 5 dólares, o porque de todos modos ya pagan 30 dólares al mes por un servicio de cheats.
Sospecho que hay una superposición enorme entre los cheaters frecuentes y las ballenas pay-to-win.
Una forma más confiable de reducir cheaters en un juego es un honeypot para cheaters. En lugar de bloquearlos y luego volver a rastrear al cheater que compró una cuenta nueva, simplemente los metes en silencio en matchmaking solo con otros cheaters, bots diseñados para ser molestos a propósito, latencia falsa y cosas como ignorar de vez en cuando sus pulsaciones de teclas.
Si arruinas su diversión, dejan de arruinar el juego. Entonces la guerra de información se invierte: para saber si necesitan comprar una cuenta nueva, primero tienen que averiguar si están jugando regularmente contra cheaters o bots.
Claro que, si algún proveedor descuidado filtra claves TPM algún día, quizá sea posible falsificarlas.
A los jugadores de países grandes les resulta fácil perderse el sentido de comunidad que existe en países pequeños.
Si solo hay jugadores diarios para llenar 3 o 4 servidores, se conocen rápidamente entre todos, y eso suma mucho a los chistes y la diversión.
Es mucho mejor que los juegos con millones de jugadores en los que nunca vuelves a ver a alguien con quien jugaste una partida. Por la misma razón, también me gustan los juegos con servidores operados por la comunidad.
Terminabas entrando siempre a los mismos servidores según quién estuviera conectado y, sobre todo, qué tan buena era tu conexión.
El enfoque de “si se conecta con otro Steam ID pero usa una IP ya bloqueada, lo vuelvo a bloquear” funciona bien solo hasta que te das cuenta de que castiga a jugadores inocentes por culpa de CGNAT y la rotación de direcciones IP.
Los cheaters normalmente saben cómo hacer que su router pida una IP nueva, y esa IP luego se le asigna a otra persona.
Aun así fue bastante raro: en varios meses solo se reportó un puñado de casos. Si el servidor hubiera sido más popular, lo habríamos visto con mucha más frecuencia.
Si “solo compartió la solución y las técnicas con otro operador de servidores en Reino Unido en quien confiaba completamente”, probablemente éramos nosotros.
Al final lo combinamos con otras señales de fingerprinting, pero la forma de usar VGUI era sorprendentemente eficaz. Recuerdo que el navegador web se eliminó alrededor de 2018, y fue una lástima. Era muy potente porque permitía crear árboles de habilidades personalizados vinculados al servidor o integraciones divertidas.
Que “el tráfico en sí está cifrado con HTTPS, así que no se pueden encontrar tokens sin procesar usando herramientas de sniffing de paquetes como Wireshark” no es tan cierto: si el navegador integrado usaba el proxy del sistema y la lista de certificados del sistema, descifrar HTTPS con herramientas como Fiddler o Burp Suite es muy fácil.
La solicitud también queda camuflada de forma normal entre otras solicitudes, que son previsibles. Normalmente, una solicitud MOTD estaría ahí, así que no se vería sospechosa.
En una situación donde la forma de evadirlo era mucho más simple, como borrar un archivo local, esto funcionaba suficientemente bien frente a tener que encontrar la solicitud real y configurar Fiddler o Burp Suite.
No hace falta sobrediseñarlo.
Son unos cuantos clics y, según el TLS que se use, quizá haya que hacerlo por cada conexión, pero no es tan difícil.
Sé que “debió haberlo patentado” era una broma, pero si lo hubiera patentado, habría tenido que hacer pública la técnica y se habría vuelto inútil de inmediato.
Aun así, eso no le resta nada al artículo. Me pareció entretenido.