Falhas em autenticação da EA permitiam sequestro de contas de jogadores

Cadeia combinava subdomínio abandonado no Azure, confiança entre domínios da EA e redirecionamentos OAuth para capturar tokens SSO sem exigir senha da vítima.

Componente	Plataforma Origin e serviços de autenticação da EA em ea[.]com, origin[.]com, accounts[.]ea[.]com e signin[.]ea[.]com, com subdomínio eaplayinvite[.]ea[.]com apontando para Azure.
Vetor	A exploração dependia de um registro CNAME pendente para ea-invite-reg[.]azurewebsites[.]net, combinado com manipulação de returnURI, uso de iframe em subdomínio confiável e redirecionamento OAuth/SSO.
Impacto	A cadeia poderia permitir tomada de conta de jogadores por captura de token SSO, sem necessidade de a vítima entregar usuário e senha.
Prioridade	Remover apontamentos DNS órfãos, validar destinos OAuth permitidos, restringir confiança entre subdomínios e revisar exposição de tokens em redirecionamentos e cabeçalhos.
Artefatos	Subdomínio eaplayinvite[.]ea[.]com, serviço Azure ea-invite-reg[.]azurewebsites[.]net, parâmetros returnURI e redirectback, cabeçalho HTTP Referer e fluxo SSO entre accounts[.]ea[.]com e signin[.]ea[.]com.
Mitigação	A EA foi notificada e as lacunas foram corrigidas para proteger contas de clientes da plataforma.

Resumo técnico

Uma cadeia de vulnerabilidades no ecossistema de autenticação da EA demonstrou como uma falha aparentemente periférica em DNS e nuvem podia evoluir para comprometimento de contas em uma plataforma de jogos de grande escala. O caso envolvia a plataforma Origin, usada para compra, execução e integração social de jogos da EA, e serviços distribuídos entre domínios como ea[.]com e origin[.]com. A condição inicial estava em um subdomínio corporativo que continuava apontando para um serviço do Azure que não estava mais em uso. Esse tipo de configuração deixa um CNAME válido no domínio da organização, mas sem recurso correspondente controlado pela própria empresa no provedor de nuvem.

A partir desse estado, um operador poderia registrar o nome de serviço abandonado em uma conta própria do Azure e receber requisições destinadas ao subdomínio da EA. O risco não se limitava à posse de uma página esquecida: o subdomínio estava dentro do perímetro de confiança usado por mecanismos de autenticação e SSO da empresa. A cadeia explorava essa confiança para influenciar o fluxo OAuth, gerar ou redirecionar tokens vinculados à sessão do jogador e capturar o material de autenticação em um servidor controlado pelo atacante. O efeito técnico descrito era tomada de conta sem exigir que a vítima digitasse credenciais em uma página falsa.

Fluxo técnico

A primeira parte da cadeia era um sequestro de subdomínio causado por apontamento DNS residual. O registro eaplayinvite[.]ea[.]com continuava direcionando tráfego para ea-invite-reg[.]azurewebsites[.]net, mas o serviço correspondente não estava mais ativo no Azure. Em provedores de nuvem, esse padrão é perigoso porque o nome de aplicação pode voltar a ser registrado por outro locatário, desde que o recurso original tenha sido liberado. Com isso, o domínio da EA permanecia publicamente resolvível, enquanto o backend efetivo podia ser recriado fora do controle da organização. Para defesa, o ponto central é que a confiança do navegador e dos serviços internos costuma acompanhar o nome DNS corporativo, não a propriedade real do recurso em nuvem.

A segunda parte envolvia a implementação de SSO e OAuth da EA. O login trocava credenciais por um token SSO, usado posteriormente para autenticar o jogador em diferentes serviços da rede EA sem novo fornecimento de senha. O fluxo passava por accounts[.]ea[.]com, por signin[.]ea[.]com e pelo serviço final solicitado. A pesquisa identificou que o parâmetro returnURI podia ser manipulado para fazer o token ser gerado para o subdomínio controlado. A validação de origem considerava o cabeçalho HTTP Referer, exigindo que a requisição parecesse vir de domínio confiável. Como o subdomínio sequestrado ainda era um nome legítimo sob ea[.]com, um iframe hospedado nele podia iniciar a sequência de autenticação com aparência compatível com a política de confiança existente.

Havia ainda uma limitação no envio direto do token por causa da relação de origem entre signin[.]ea[.]com e o destino final. A cadeia contornava isso por meio de um caminho alternativo de redirecionamento associado ao parâmetro redirectback, fazendo a navegação passar por URLs do fluxo SSO até retornar ao servidor no subdomínio tomado. Nesse processo, o token acabava exposto no cabeçalho Referer da requisição recebida pelo servidor controlado pelo atacante. O ponto defensivo mais importante é que tokens de autenticação não devem atravessar redirecionamentos de forma que possam aparecer em cabeçalhos, histórico, logs de proxy, ferramentas de análise ou qualquer superfície observável por terceiros.

Superfície afetada

A superfície afetada abrangia serviços da EA integrados à autenticação comum e à plataforma Origin. O risco era ampliado pelo uso de múltiplos subdomínios e pela relação de confiança entre ea[.]com, origin[.]com e serviços como fóruns, suporte, contas e áreas sociais. A plataforma também integrava recursos de perfil, rede de amigos, chat, entrada direta em jogos e conexões com redes de terceiros, o que torna tokens SSO particularmente sensíveis. Um token válido pode representar a sessão do usuário em vários componentes, mesmo que o usuário não tenha revelado a senha e mesmo que a captura tenha ocorrido em um ponto distante da tela clássica de login.

O impacto descrito incluía a possibilidade de acesso a contas de jogadores, consulta de informações associadas à conta e compras fraudulentas de moeda ou itens dentro do ecossistema de jogos. O contexto também mencionava potencial acesso a informação de cartão de crédito vinculada à conta, sem detalhar quais campos seriam expostos nem se dados completos poderiam ser recuperados. Portanto, a avaliação defensiva deve tratar esse ponto como risco associado à tomada de conta e aos fluxos de compra, não como confirmação independente de vazamento de dados financeiros. O elemento confirmado da cadeia é a captura de token SSO por combinação de subdomínio tomado e redirecionamentos de autenticação.

Ambientes com desenho parecido devem considerar vulneráveis os subdomínios que apontam para recursos de nuvem removidos, especialmente quando esses nomes continuam incluídos em listas de confiança, políticas CORS, allowlists de OAuth, mecanismos de SSO, integrações sociais ou validações baseadas em domínio. A condição fica mais crítica quando o subdomínio abandonado recebe tráfego autenticado, carrega iframes, participa de redirecionamentos ou tem permissão para iniciar jornadas de login.

• Subdomínio corporativo com CNAME para aplicação Azure não mais utilizada.
• Serviços SSO que aceitam destinos ou origens com base em domínio amplo de confiança.
• Fluxos OAuth em que returnURI e redirectback influenciam a navegação pós-autenticação.
• Aplicações que podem registrar tokens em cabeçalhos, logs de acesso, analytics, proxies ou histórico de navegação.

Hunting e telemetria

A detecção deve começar pelo inventário de DNS e nuvem. Equipes de segurança precisam comparar registros CNAME públicos contra recursos realmente existentes no provedor associado. Um subdomínio que aponta para nome de aplicação inexistente, liberado ou pertencente a outra conta é uma exposição direta. A mesma verificação deve cobrir ambientes Azure, aplicações web, APIs, máquinas virtuais, buckets, front doors, endpoints gerenciados e qualquer serviço cujo nome público possa ser reatribuído. A telemetria útil inclui histórico de resolução DNS, mudanças em registros, erros de provisionamento, respostas HTTP inesperadas e certificados emitidos para subdomínios que não constam no inventário.

No lado de identidade, o hunting deve procurar anomalias em redirecionamentos SSO e OAuth. São relevantes requisições em que returnURI aponta para subdomínios raros, antigos, pouco usados ou não associados ao serviço de destino esperado. Também é necessário revisar eventos em que signin[.]ea[.]com ou serviço equivalente redireciona para propriedades que não fazem parte do fluxo documentado. Cabeçalhos Referer contendo tokens, parâmetros de sessão ou valores de autenticação indicam falha de desenho e devem ser tratados como incidente de exposição de credencial temporária, mesmo quando não houver evidência de abuso externo.

Em endpoints e navegadores corporativos, sinais de iframe inesperado durante login, navegação automática entre múltiplas URLs de autenticação e carregamento de páginas de login a partir de subdomínios fora do catálogo oficial são indicadores de risco. Em servidores, logs de acesso a subdomínios recuperados após abandono podem revelar tráfego residual de usuários legítimos. Para times de resposta, a presença de tokens em logs exige contenção cuidadosa: esses registros deixam de ser apenas evidência e passam a ser material sensível que precisa de controle de acesso, expurgo ou retenção protegida.

• CNAME para recurso de nuvem inexistente, liberado ou recriado em conta não autorizada.
• returnURI direcionando autenticação para subdomínio sem relação funcional com o serviço solicitado.
• Uso de redirectback em jornadas de SSO que terminam fora dos destinos permitidos.
• Tokens, fragmentos de token ou parâmetros de sessão aparecendo em Referer, logs de proxy, logs web ou ferramentas de monitoramento.
• Picos de tráfego autenticado para subdomínios legados, convites antigos, campanhas encerradas ou aplicações desativadas.

Mitigação

A resposta mais imediata é eliminar a pré-condição de sequestro de subdomínio. Todo registro DNS que aponta para nuvem deve ter dono, finalidade, data de revisão e recurso correspondente ativo. Quando uma aplicação é descomissionada, o registro CNAME precisa ser removido antes ou junto com a exclusão do recurso no provedor. Também é recomendável bloquear a recriação indevida de nomes críticos por meio de governança de assinaturas, grupos de recursos e políticas de nomenclatura. Em ambientes grandes, essa validação deve ser contínua, porque mudanças em campanhas, microsserviços e páginas temporárias frequentemente deixam resíduos exploráveis.

No fluxo OAuth, a mitigação exige validação estrita de destinos. Parâmetros como returnURI e redirectback devem aceitar apenas URLs previamente cadastradas, com correspondência exata de esquema, host, caminho e finalidade. A confiança não deve ser concedida a qualquer subdomínio sob uma zona corporativa ampla, porque um único subdomínio órfão pode herdar privilégios indevidos. Validações baseadas em Referer são frágeis como controle principal e devem ser substituídas por checagens server-side de cliente OAuth, estado, nonce, PKCE quando aplicável e allowlists administrativas. Tokens devem ser mantidos fora de URLs e fora de qualquer caminho que possa ser refletido em cabeçalhos.

Depois da correção, a organização deve invalidar tokens emitidos durante a janela de exposição, revisar logs sensíveis, verificar se houve tráfego para o subdomínio vulnerável e auditar compras ou alterações de conta realizadas por sessões suspeitas. Para reduzir impacto futuro, sistemas de compra dentro de jogos e alteração de dados de conta devem exigir sinais adicionais de risco, como reautenticação, desafio adaptativo ou verificação de sessão recente. A correção técnica informada no caso mostra que a cadeia foi encerrada, mas o padrão de falha continua aplicável a qualquer empresa que combine SSO federado, múltiplos subdomínios e infraestrutura elástica em nuvem.

• Remover registros DNS órfãos e impedir que nomes de serviço em nuvem sejam reaproveitados fora da conta autorizada.
• Aplicar allowlist exata para URLs de retorno OAuth e rejeitar destinos derivados apenas por pertencerem ao domínio corporativo.
• Substituir confiança baseada em Referer por controles de protocolo e validação server-side.
• Garantir que tokens SSO não apareçam em URLs, cabeçalhos, logs, ferramentas de analytics ou redirecionamentos observáveis.
• Invalidar sessões potencialmente expostas e revisar atividade de conta, compras e alterações de perfil durante a janela de risco.