Como invadi o Chess.com com um exploit para iniciantes

Descoberta de XSS no Chess.com

• Enquanto curtia xadrez como hobby e brincava com tecnologia, encontrei uma vulnerabilidade de XSS no Chess.com.
• O Chess.com é o maior site de xadrez da internet, com mais de 100 milhões de membros.

Visão geral

• No começo de 2023, comecei a passar bastante tempo no Chess.com.
• Convidei um amigo para se cadastrar no site e viramos amigos imediatamente usando o recurso de amizade.
• Fiquei curioso se seria possível automatizar a adição de amigos de forma parecida com o worm do MySpace.
• Criei uma nova conta e, ao verificar a aba de rede nas ferramentas de desenvolvedor, encontrei a URL de adição automática de amigos.

Meio-jogo

• Tentei explorar XSS usando o editor de texto rico TinyMCE.
• Usei o proxy do Burp para inserir código HTML diretamente na descrição de "About".
• Verifiquei a configuração do TinyMCE e criei um payload de XSS usando a propriedade de estilo background-image.
• Testei vários símbolos e descobri como executar o XSS.
• No fim, desenvolvi uma forma de extrair cookies e objetos JavaScript.

Final

• Trabalhei para executar o XSS por completo.
• Descobri um novo método usando o atributo srcset para permitir uma sintaxe JS mais ampla.
• Usei codificação Base64 para executar diretamente o payload de XSS.
• O impacto era grande porque o editor TinyMCE era usado em todo o site.

Análise

• A causa raiz da vulnerabilidade é o recurso de reenvio de imagens.
• Era possível contornar a verificação de hospedagem de imagens incluindo o nome de domínio do Chess.com.
• O editor de texto rico permitia vários elementos HTML, o que o tornava favorável para alcançar XSS.
• O TinyMCE estava atualizado, mas faltava sanitização do HTML final.
• O Chess.com deveria aplicar sanitização ao HTML final exibido aos usuários.

Opinião do GN⁺:

1. Este post de blog explica de forma interessante o processo de descobrir e relatar uma vulnerabilidade de segurança que pode surgir em uma grande plataforma online como o Chess.com.
2. Vulnerabilidades de XSS podem representar uma ameaça grave à segurança de um site, e encontrar e corrigir essas falhas é muito importante para proteger a privacidade dos usuários.
3. O texto destaca, para desenvolvedores de software e profissionais de segurança, a importância de reconhecer vulnerabilidades em componentes de aplicações web, como editores de texto rico, e de preveni-las.

[GN⁺]

Comentários no Hacker News

• Apresentação e informações de contexto sobre o autor original (OP)

  • É um estudante britânico de 17 anos, cursando A-Levels, e está considerando opções de universidade e programas de aprendizagem com diploma.
  • No perfil do GitHub, é possível ver que ele é membro central do HashPals, criador do Search-That-Hash e mantenedor de um repositório open source de software gratuito para tablets ReMarkable.
  • Há menção a uma avaliação positiva do lichess.org e ao compartilhamento de interesses técnicos.

• Comentário sobre recursos relacionados ao worm do MySpace

  • Menciona o worm do MySpace por volta de 2005, e o autor afirma que ainda não tinha nascido naquela época.
  • Aponta que outro usuário testemunhou e registrou o fenômeno de alguém controlar os movimentos em sua partida de xadrez, relatou o problema ao chess.com, mas isso não foi corrigido.

• Perguntas técnicas relacionadas à vulnerabilidade XSS

  • Levanta dúvidas sobre por que o cookie PHPSESSID não é HttpOnly e por que uma vulnerabilidade XSS conhecida não foi corrigida.
  • Expressa interesse em relatórios de bug bounty de XSS e reconhecimento das dificuldades desse processo.

• Opinião sobre o editor de texto rico do chess.com

  • Reação divertida ao fato de chamarem o editor de texto rico de "cálice sagrado", além de preocupação de que esse tipo de recurso possa ter vulnerabilidades mesmo em um site grande.

• Pergunta sobre sigla técnica

  • Pergunta o significado de "OSRF" e especula se isso significa "Own-Site Request Forgery", semelhante a CSRF.

• Pergunta técnica relacionada a redirecionamento de subdomínio

  • Pede uma explicação de como um redirecionamento em um subdomínio (chess.com.foo.bar) contornou a política de mesma origem (same-origin policy).