1 pontos por GN⁺ 2024-11-06 | 1 comentários | Compartilhar no WhatsApp
  • A combinação de documentação Swagger exposta da API de autenticação/gateway da EA com falha na validação de autorização para atualização de persona poderia impactar até os dados de conta e o fluxo de login de outros usuários
  • O ponto central era que a requisição PUT para /identity/pids/{pidId}/personas/{personaId} podia ser acessada com o escopo dp.client.default de um cliente OAuth comum do EA Desktop, e havia verificação insuficiente de propriedade do pidId no corpo e do personaId no caminho
  • O atacante podia combinar alteração do nome de usuário da persona, definição do status como BANNED, movimentação de persona, busca de IDs de persona de contas ocultas e bypass de login com base em persona do Xbox para chegar até o login web da conta
  • O impacto incluía roubo de nome de usuário e alguns dados de jogo, bloqueio de acesso a jogos online, evasão de banimento em jogos e login na conta EA via Xbox, com gravidade avaliada em CVSS 10.0
  • A vulnerabilidade foi reportada à EA em 16 de junho de 2024; a EA a classificou como critical em 25 de junho e distribuiu correções de 8 de julho a 8 de outubro, incluindo checagem de propriedade da persona e remoção da documentação

Exposição de documentação de API a partir do ambiente de autenticação da EA

  • O ponto de partida foi um teste no ambiente de desenvolvimento integration encontrado no EA Desktop
    • A API de autenticação de produção era accounts.ea.com
    • O host de autenticação de integration era accounts.int.ea.com
  • No ambiente integration era possível obter um access token com privilégios, e a partir daí começou a busca por documentação exposta para verificar quais APIs esse token podia acessar
  • Os endpoints de autenticação estavam atrás de um reverse proxy, e os formatos de resposta 404 para o caminho /connect e para o caminho comum / eram diferentes; o header server era istio-envoy
  • Como /connect/api-docs retornava um 404 vazio, diferente de outros caminhos em /connect, isso sugeria roteamento para um serviço separado, e em /connect/api-docs/index.json foi encontrada documentação Swagger 1.1
  • A documentação Swagger apontava para /api-docs/connect; isso foi convertido para especificação OpenAPI 3.0 com swagger-codegen-cli e visualizado localmente no Swagger UI

Lista de APIs internas revelada no Gateway

  • O EA Desktop usa uma API GraphQL chamada “Service Aggregation Layer”, mas o SAL do ambiente integration estava atrás de firewall
  • A API gateway em gateway.ea.com, aparentemente de uma versão anterior, usa endpoints no formato proxy/{service}/{route}
  • gateway.int.ea.com/proxy/api-docs/index.json retornava uma lista de documentação de mais de 80 serviços
    • Incluindo serviços como addresses, agerequirements, billing, commerce e outros
  • Após baixar a documentação de cada API e convertê-la para a especificação OpenAPI mais recente, foi possível verificar quais funções estavam acessíveis
  • Alguns endpoints retornavam dados de “projects” relacionados a equipes de jogos da EA e exigiam o escopo basic.domaindata; também foi encontrado em produção um cliente com esse escopo
    • Entre os dados de exemplo havia um jogo cancelado de Star Wars e itens de Apex Legends exibidos com nome de grupo relacionado a Titanfall3
  • No ambiente integration também havia documentação sobre como conceder entitlement personalizado de jogo, mas os serviços de integration necessários para download e execução estavam atrás de firewall, então a utilidade prática era baixa
  • Havia ainda um endpoint que retornava Xbox Live Server Token, mas como o sandbox ID não era RETAIL, isso não foi investigado mais a fundo

Informações de conta em produção e estrutura de persona

  • Cada endpoint da documentação mostrava os escopos de autenticação exigidos, e a análise se concentrou nos endpoints acessíveis com clientes OAuth de produção
  • /identity/pids/me retornava informações gerais da conta
    • Incluindo valor mascarado de e-mail, status do e-mail, parte da data de nascimento, país, idioma, status da conta, versão dos termos, horários de criação/modificação/última autenticação e se o 2FA estava ativado
  • /identity/pids/me/personas retornava a lista de personas vinculadas à conta
    • A conta EA padrão usa o namespace cem_ea_id
    • Contas externas vinculadas, como Steam e Xbox, também aparecem cada uma como uma persona
  • Os jogos geralmente podem armazenar dados como estatísticas e inventário sob a persona, então os dados podem ficar separados por plataforma
  • A partir daí, a persona no namespace cem_ea_id passou a ser chamada de persona “Origin”

Vulnerabilidade central: falha na validação de autorização para atualização de persona

  • O endpoint /identity/pids/{pidId}/personas/{personaId} aceitava requisições GET, PUT e DELETE
  • A requisição PUT permitia os escopos dp.client.default e dp.server.default, e o cliente de autenticação comum do EA Desktop possuía dp.client.default
  • O corpo da requisição podia receber displayName, namespaceName, status, statusReasonCode, lastAuthenticated, nickName, pidId e outros campos
  • Uma requisição PUT para alterar displayName da própria persona Origin funcionou, e o nome de usuário no site da conta EA foi alterado
    • Essa requisição burlava o cooldown de alteração de nome de usuário e a verificação por e-mail para mudança de nome
  • Alterar namespaceName não teve efeito
  • O valor de status podia ser ACTIVE, DISABLED, PENDING, DELETED ou BANNED; ao mudar o status da própria persona Origin para BANNED, o EA Desktop continuou utilizável, mas o login nos jogos foi bloqueado
  • O problema mais grave era que o pidId no corpo da requisição podia ser trocado pelo ID de outra conta
    • Uma requisição para mover a persona Steam própria para a conta EA de um amigo foi bem-sucedida
    • Depois também foi possível movê-la de volta para a conta original

Verificação de login e tentativa de XSS

  • Depois de mover a própria persona Steam para a conta do amigo, ao tentar login no site da EA via Steam surgiu verificação por e-mail baseada em nova localização/dispositivo não confiável
  • Parte dos e-mails exibidos não era do pesquisador, mostrando que o fluxo já havia chegado à tentativa de login na conta do amigo, mas foi barrado na etapa de 2FA baseada em localização
  • Também funcionou uma requisição para alterar o nome de usuário da persona para algo como BattleDash <script>alert(1)</script>
  • O alert foi executado na página de vínculo de contas, tornando possível um XSS
    • Se um usuário logado na conta EA fosse induzido a abrir essa página de vínculo, seria possível executar código no navegador e extrair a sessão

Manipulação direta de personas de outras contas

  • Para verificar se o personaId no caminho também tinha validação insuficiente de propriedade, foi tentada a alteração de nome de usuário em um persona ID que não pertencia ao pesquisador
  • Após obter o persona ID de uma nova conta de teste, a requisição para mudar o nome de usuário dessa conta teve sucesso sem autenticação da vítima
  • Da mesma forma, foi possível mudar status para BANNED, impedindo essa conta de fazer login em jogos
  • /identity/personas permite buscar persona por displayName e retorna persona ID, ID da conta, data de criação e horário do último login
    • Porém, usuários que ocultaram a conta não aparecem
  • /identity/namespaces/{namespace}/personas faz a busca em um namespace específico e retorna apenas nome de usuário e persona ID, mas também retorna contas ocultas
    • Só esse endpoint já bastava para obter os persona IDs necessários

Restrições na movimentação de persona e takeover parcial de conta

  • Ao tentar mover a persona Origin de outro usuário para a própria conta, surgiu o erro TOO_MANY_PERSONAS_FOR_NAMESPACE
    • Isso porque a conta do pesquisador já tinha uma persona Origin
  • Como contas criadas por console podem ter apenas a persona da plataforma e não ter persona Origin, foi usado um console account para evitar conflito de namespace
  • Foi possível mover a persona Origin de uma conta de teste para a conta de console e depois mover a persona Origin da vítima para a própria conta
  • Nesse estado, ao fazer login, eram exibidos o nome de usuário da vítima, estatísticas de jogos sem cross-platform e alguns outros detalhes da conta
  • Ao entrar na conta da vítima, aparecia o fluxo “Finish setting up my account”, pedindo para escolher nome de usuário como se fosse uma conta recém-criada
  • Entitlements, amigos e dados salvos de jogos cross-platform mais novos, como Battlefield 2042, eram armazenados na própria conta EA, não na persona, então não eram transferidos
  • Ainda assim, o atacante podia banir usuários, burlar banimentos em jogos, roubar nomes de usuário e fazer sequestro de dados da conta

Bypass de login usando persona do Xbox

  • No estado já obtido, as ações possíveis eram mover a própria linked account persona para qualquer conta EA, mover qualquer persona para a própria conta e alterar banimento/nome de usuário de persona
  • Ao tentar fazer login em outra conta movendo a própria persona, ainda surgia verificação por e-mail
  • Como nunca havia aparecido prompt de 2FA ao jogar títulos da EA no console, foi verificado o login baseado em token do Xbox/PSN
  • A documentação da API Nexus Connect mostrava como enviar tokens do Xbox/PSN, e a partir do fluxo de login PSN no site da EA foi obtido o client ID da PSN para testar login com token PSN
  • O login com token PSN criava uma persona no namespace ps3 e permitia login na conta sem 2FA, mas clientes com dp.client.default não podiam manipular o namespace ps3
  • Ao adicionar o header X-Include-Namespace a /connect/tokeninfo, foi possível confirmar que havia uma lista de namespaces de persona manipuláveis por cliente OAuth
    • Por exemplo, JUNO_PC_CLIENT incluía os namespaces cem_ea_id, steam, epic e xbox
  • O namespace Xbox era permitido, mas como não era possível gerar manualmente um token Microsoft XSTS válido para jogo, o teste foi feito em um Xbox real
  • Após criar uma nova conta Microsoft e vincular a persona Xbox a uma conta EA de teste, essa persona Xbox foi movida para a conta da vítima
  • Ao tentar login no site da EA com a conta Xbox, surgiu verificação por e-mail de nova localização; porém, ao instalar Battlefield 2042 no Xbox e entrar no jogo, o acesso ocorreu como conta da vítima
  • Depois disso, ao fazer login no site da EA com a mesma conta Xbox, o login web na conta da vítima também funcionou sem verificação por e-mail

Impacto e gravidade

  • Havia dois caminhos principais para exploração pelo atacante
    • Mover dados de persona de outras pessoas para fora da conta, roubando nomes de usuário e dados de jogo
    • Mover a própria persona Xbox para a conta da vítima, entrar em um jogo da EA no Xbox e, depois que a rede passasse a ser considerada confiável, fazer login no site da EA com a conta Xbox
  • O impacto adicional também era grande
    • Era possível banir a persona de outras pessoas e bloquear a maioria dos jogos online
    • Era possível mudar o nome de usuário de outras pessoas e depois tomar esse nome para si
    • Como banimentos de jogo são tratados como desativação do entitlement da conta inteira, mover a persona para uma nova conta permitia burlar banimentos
  • Esse fluxo era possível principalmente por um único endpoint de API, sem interação do usuário
  • A gravidade foi avaliada como CVSS 10.0 com base em AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

Cronograma de correção e observações posteriores

  • A vulnerabilidade foi reportada à EA em 16 de junho de 2024
  • Em 25 de junho de 2024, a EA confirmou o problema e atribuiu gravidade critical
  • O cronograma de correções foi o seguinte
    • 8 de julho de 2024: Patch 1 implantado, persona ownership check
    • 18 de julho de 2024: Patch 2 implantado, detalhes não informados
    • 6 de setembro de 2024: Patch 3 implantado, detalhes não informados
    • 10 de setembro de 2024: Patch 4 implantado, remoção da documentação
    • 8 de outubro de 2024: Patch 5 implantado, detalhes não informados
  • A previsão inicial da EA era de que a correção poderia levar até o fim do ano, e a avaliação feita foi que, em um caso cujo núcleo estava em documentação exposta e um único endpoint inseguro, uma mitigação temporária mais rápida teria sido desejável
  • A EA ainda não tem programa de bug bounty, e permanece a preocupação de que, sem recompensa prática por reportar, algumas pessoas possam preferir manter vulnerabilidades em sigilo
  • A conta de amigo usada nos testes iniciais foi utilizada com consentimento

1 comentários

 
GN⁺ 2024-11-06
Comentários no Hacker News
  • A EA gosta de usar sistemas comuns em vários jogos. Fuçando no Madden, descobri que havia um backend comum chamado blaze e endpoints web/TCP genéricos
    Criei uma ferramenta para chamar esse endpoint, mas era preciso fazer upload de XML; depois descobri que, a cada chamada, os servidores da EA estavam caindo
    Como cada requisição alocava um novo servidor, eu estava derrubando todos os servidores do Madden, um por um, até que a EA acabou criando uma API para impedir que as pessoas ficassem fuçando

    • Blaze é o nome de um framework/serviço em C++ para criar backends customizados para jogos online. Ele permite que equipes de jogos desenvolvam recursos online de uma forma padronizada, com MySQL por trás
      Pelo que me lembro, era necessária mais ou menos uma instância do Blaze para cada 5 mil a 10 mil jogadores
    • Sou o autor do post e, no ano passado, também escrevi bastante sobre várias vulnerabilidades do Blaze que encontrei, mas não publiquei
      Hoje ele usa um formato proprietário e parecia haver bastante comodismo com a segurança baseada na suposição de que ninguém descobriria como a interface funciona — ou seja, segurança por obscuridade
      Um dia quero voltar a esse texto; no mínimo, há coisas bem interessantes nele
    • Acho que vi essa API recentemente em outro jogo. É um frontend GraphQL, certo? A introspecção estava desativada, mas as mensagens de erro sugeriam gentilmente o nome correto quando eu errava um campo
      Uma dica para fazer engenharia reversa da API de um serviço famoso como esse é usar a busca de código do GitHub. Se você procurar por um nome de endpoint único, muitas vezes aparecem pessoas parecidas que hackearam seus próprios clientezinhos de API, e isso acaba ajudando a investigação de formas inesperadas
    • Se você varrer valores repetidos de IDs de cliente da PSN tentando fazer login no proxy de gateway da EA, ele retorna o valor namespacename obtido dos dados pessoais. As informações do token de 2FA deveriam ser geradas como hash no endpoint /tokeninfo/ vindo do JUNO
      Ao tentar uma integração posterior, a infraestrutura da API em C++ às vezes retornava o ID de usuário da PSN
  • Como qualquer pessoa normal obviamente faria, encomendei um Xbox com entrega no dia seguinte, instalei Battlefield 2042, esperei o momento decisivo e consegui entrar
    Hackers são bons demais <3

  • Achei interessante o fluxo detalhado de como foram de um ponto ao outro. Imagino que não tenha sido tão limpo e linear quanto em um post de blog
    Para mostrar o tempo e o esforço reais envolvidos nesse tipo de ataque, provavelmente haveria uma montanha de anotações; seria interessante vê-las também

  • O mais estranho em tudo isso é que, durante anos, a EA afirmou que era tecnicamente impossível desvincular uma conta Xbox existente e vinculá-la novamente a uma conta nova. Basta ver posts como https://www.reddit.com/r/XboxGamePass/comments/12gsy4i/ea_xb... e inúmeros tópicos nos fóruns da EA
    Eu também bati nessa parede e passei horas em chamadas com o suporte da EA, mas eles não conseguiram vincular minha conta Xbox muito antiga. Por isso, não consigo fazer login em nenhum jogo da EA no Xbox e acabei impedido de jogar a maioria deles na plataforma
    Mas aqui ficou claro que era perfeitamente possível

    • Lembro que, em 2004–2005, minha conta do Hotmail tinha os 4 MB de armazenamento comuns, numa época em que a Microsoft estava distribuindo um upgrade gratuito para 250 MB para todo mundo
      Estranhamente, minha conta demorava demais; ao longo de 1 ou 2 anos, escrevi várias vezes para o suporte, e sempre recebia a resposta de que estavam fazendo o upgrade das contas o mais rápido possível, mas que o trabalho era tão grande que levaria anos
      Mais tarde, vi em algum fórum um truque: fechar temporariamente a conta e reabri-la permitia aumentar para 25 MB, mas não para os 250 MB prometidos
      A situação — contas antigas com 2–4 MB, contas novas com 25 MB e uma distribuição de vários anos até chegar a 250 MB — dava a impressão de que a Microsoft estava tendo uma dificuldade enorme para encontrar armazenamento sobrando. Então, alguns meses depois, quando precisou competir com o Gmail, decidiu dar 2 GB para todo mundo, e isso foi aplicado de uma vez a todas as contas do Hotmail, inclusive a minha. Alienígenas devem ter trazido um OVNI cheio de discos rígidos
      [1] Exemplo de post antigo em fórum sobre esse truque, com uma resposta elogiando o recém-lançado GMail: https://bimmersport.co.nz/topic/5232-hotmail-upgrade-2mb-to-...
    • Este ataque mostra que é possível mudar a vinculação e jogar, mas não dá para saber quais efeitos colaterais podem surgir fora do cenário facilmente verificado no post
      A mudança de vínculo poderia invalidar dados armazenados no sistema de cobrança, bagunçar os relatórios mensais enviados à divisão Xbox da Microsoft ou fazer alguma página interna de administração travar durante o carregamento
      Não estou tentando defender a EA, mas, quando se lida bastante com sistemas complexos de microsserviços, mudar a estrutura de dados em um ponto nem sempre é algo simples
    • Talvez eles estivessem justamente adicionando esse recurso para corrigir o problema, e ele infelizmente tenha sido explorado antes do lançamento público
    • Infelizmente, em jogos multiplataforma modernos como Battlefield 2042, os direitos de jogo, amigos e dados salvos ficam armazenados na própria conta EA, não na persona, então esses dados não são transferidos
    • Provavelmente não era tecnicamente impossível; o mais provável é que fosse impossível para a equipe de suporte ao cliente lidar com isso
  • Também teria sido divertido banir todas as contas e torcer para não haver backup do banco de dados

    • Quero ver toda empresa de US$ 1 bilhão que não tem um programa de bug bounty passar por isso. Se não há nenhuma recompensa por reportar vulnerabilidades, é como incentivar hackers a explorá-las em benefício próprio ou a causar caos
      Como cliente pagante, espero uma postura melhor dessas empresas e, se não houver programa, pessoalmente não culparia hackers por explorarem o que encontraram
    • Pode até ser divertido por um instante, mas eles certamente têm backups
      Ninguém armazena 400 milhões de registros em uma única máquina e, no fim, você só derrubaria o serviço por uma tarde inteira e passaria 15 anos em uma prisão federal
    • É por coisas assim que o mundo virou as costas para a indústria de tecnologia
      Porque a primeira reação — ou pelo menos o comentário mais bem avaliado agora — é achar que seria "divertido" prejudicar milhões de pessoas para dar uma lição à empresa com a qual elas faziam negócio
    • Teria sido muito mais divertido ativar todos os jogos em todas as contas. Literalmente todos. Falta imaginação
    • Também pensei nisso. Se ele tivesse decidido aprontar e não reportar de fato, qual teria sido o resultado? Teriam rastreado? A EA teria ficado fora do ar por semanas?
  • Há este trecho no texto:
    I had found a way to obtain a privileged access token within the environment (a story for another day, but a certain game's executable had hardcoded credentials!), but I wasn't sure what I could do with it.
    Alguém pode explicar um pouco mais essa parte? Eu imaginava que não deveria ser fácil ler credenciais assim a partir de um binário executável, e também não sei bem o que mais um desenvolvedor deveria fazer se o executável do jogo precisa se autenticar em um servidor remoto

    • Credenciais são armazenadas como strings, então, se você procurar no binário por padrões que pareçam credenciais, elas estarão em algum lugar
      Em uma arquitetura cliente-servidor, o cliente nunca é confiável. O executável não deveria precisar se autenticar como ele mesmo no servidor. O executável deve autenticar o usuário ou a conta com as informações fornecidas pelo usuário
      No caso de telemetria, por exemplo, esses endpoints normalmente aceitam dados sem autenticação ou com autenticação fraca e fazem várias etapas de validação para evitar abuso. Em geral, também são somente de escrita/anexação
    • Não sei por que você presumiria que um binário não seria fácil de ler. Em uma plataforma não bloqueada, binários são bastante legíveis
      Você precisaria de um sistema em que o executável fosse criptografado e uma área segura no die da CPU lidasse com a descriptografia usando uma chave privada; ainda assim, provavelmente seria questão de tempo até alguém decapsular o chip e obter a chave
    • Se o computador consegue ler e você tem controle total sobre esse computador, então você também consegue ler. Com acesso físico, acabou
      Mesmo que você criptografe e coloque a chave de criptografia em um HSM, isso provavelmente é inviável em uma máquina cliente arbitrária; além disso, em algum momento o jogo precisa descriptografar aquela string e carregá-la na memória. E essa memória pode ser lida
    • Se um programa consegue acessar as credenciais e esse programa roda no meu computador, então, por mais ofuscadas que estejam, eu também consigo acessar essas credenciais
      O que o desenvolvedor do jogo deveria fazer é ter um sistema de contas no backend e fazer o jogador inserir suas próprias credenciais dentro do jogo. Assim, o jogo consegue se identificar ao servidor de backend como esse jogador
      Isso permite atribuir ações no backend a um jogador específico e dá uma boa base para tomar decisões de segurança
    • Encontrar esse tipo de credencial em um binário executável é difícil, mas não impossível. É mais trabalhoso do que extrair strings de um arquivo JavaScript minificado, mas está longe de ser impossível
      Existem ferramentas como o IDA, então você nem precisa procurar credenciais a olho nu entre tudo que parece string
      O problema não é tanto o fato de haver credenciais hardcoded no binário, mas sim o fato de essas credenciais terem privilégios elevados
  • Como engenheiro de uma empresa assim, às vezes fico imaginando como deve ser ver APIs privadas, bugs estranhos e a sujeira interna aparecerem em um relatório público de invasão
    Dito isso, nesse tipo de caso é pouco provável que um único indivíduo tenha sido o responsável pela vulnerabilidade. Provavelmente 5 ou 6 equipes eram donas de partes diferentes que foram exploradas, e por isso o exploit existia em primeiro lugar. É um sistema enorme e complexo em que todo mundo entende só o seu pedacinho

    • Quando você está investido emocionalmente na equipe — ou mesmo só financeiramente — isso incomoda, mas, quando eu estava na EA, parecia que eles quase se esforçavam para dificultar qualquer investimento emocional
      Em uma empresa do tamanho da EA, quase certamente isso será usado em política interna, e as pessoas vão aproveitar para obter mais controle sobre uma empresa menor, mesmo que isso prejudique a empresa como um todo
    • Em uma corporação tão grande, ninguém liga. É só um trabalho para receber salário
      Todo mundo é um recurso substituível; por que alguém se envolveria emocionalmente com o trabalho?
    • Como alguém que trabalhou, uns 10 anos atrás, provavelmente na mesma equipe que ainda mantém exatamente esse código, passei os olhos rapidamente pelo texto para ver se era algum código que eu escrevi ou alguma parte em que mexi
      Na época, o nome da equipe era Nucleus, e por isso, em uma das respostas do texto, o refType era NUCLEUS. Essa equipe criava e mantinha APIs de backend para permissões, contas e pagamentos
      Foi um estágio de verão, e um ano depois recebi uma proposta para trabalhar naquela equipe. Naquele momento o nome da equipe já tinha mudado para EADP e ela estava sendo lentamente incorporada ao Origin. Não me lembro bem se DP era Data Platform, mas é por isso que um dos endpoints começa com dp.
      Na época não havia banco de dados GraphQL; era tudo Enterprise Java, OCI, Spring, Hibernate etc., e antes de eu sair também havia algumas partes mais novas em Groovy/SpringBoot. Rodava em servidores de data center, não na nuvem
      Ainda assim, fiz trabalhos interessantes e, embora eu tenha saído 2 ou 3 anos depois de um grande incidente, aprendi muito sobre desenvolvimento de backend com bons engenheiros
      Não sei nada sobre como a equipe é hoje, quem são os engenheiros ou o que está acontecendo, mas é triste ver algo assim. Na época éramos muito conscientes em relação à segurança e também trabalhamos em sistemas para detectar e lidar com tentativas de força bruta na página de login
      Não sei se ainda estão ativos ou em execução, mas verificações/revisões de segurança para reduzir a possibilidade de invasões e a superfície de ataque faziam parte do trabalho das sprints
    • É especialmente ruim quando você não trabalha naquele departamento e não tem controle, mas sabe que conseguiria fazer melhor do que eles
    • Se eu lesse um texto desses sabendo que fui eu que implementei aquela API, acho que me daria um frio na barriga
  • Se você achou este texto interessante, dá para ver mais em plataformas de bug bounty como o Hacktivity da HackerOne: https://hackerone.com/hacktivity

  • Existe em algum lugar um guia de melhores práticas para configurar um programa de bug bounty?

    • Como trabalho nessa área, é difícil saber quais informações estão faltando, mas para mim parece bem simples
      Basta publicar em algum lugar do site que é permitido avaliar a segurança técnica desde que se siga um processo coordenado de divulgação de vulnerabilidades, e indicar quais recompensas serão pagas por quais tipos de bugs dentro de qual escopo. Claro que é preciso detalhar um pouco mais do que essa frase
      Também é melhor deixar claras de antemão exceções como não pagar se a pessoa for jovem ou velha demais, ou se for alvo de sanções por ter nascido no país “errado”, para evitar ressentimentos depois
      Se tiver perguntas específicas, posso responder ou tentar encontrar boas referências
  • Olhando para esta parte do texto:
    It's also disappointing that EA has yet to start a bug bounty program. Without any real incentive to report vulnerabilities, I know people who have instead chosen to keep them to themselves. I would love to see EA follow the rest of the industry's lead here.
    Então o autor reportou isso e não recebeu nada?

    • Não é verdade dizer que não recebeu nada. Sempre existe a possibilidade de receber ameaças de medidas legais por ter reportado uma vulnerabilidade
    • É decepcionante que tantas empresas não ofereçam bug bounty. Vulnerabilidades que encontrei ao longo dos anos só vão se acumulando na minha cabeça
      Reportar envolve risco jurídico, e também não ajuda o fato de que, tecnicamente, a empresa pode levar um processo até o fim. Isso considerando UE/Reino Unido
    • Desse jeito, as pessoas acabam indo para partes mais obscuras da internet e vendendo as informações para quem pagar mais
    • Sim, não recebeu nada