3 pontos por GN⁺ 11 일 전 | 3 comentários | Compartilhar no WhatsApp
  • A Vercel confirmou oficialmente um incidente de segurança envolvendo acesso não autorizado a sistemas internos e está colaborando com especialistas em resposta a incidentes e com as autoridades
  • A causa da violação foi o comprometimento do app OAuth do Google Workspace da ferramenta de IA de terceiros Context.ai, o que levou ao comprometimento de contas de funcionários da Vercel
  • O invasor enumerou variáveis de ambiente não sensíveis (non-sensitive) para obter privilégios de acesso adicionais, e essas variáveis estavam armazenadas sem criptografia
  • Um hacker que se apresenta como ShinyHunters afirma em um fórum de hacking que está vendendo chaves de acesso, código-fonte, dados de banco de dados e chaves de API, exigindo um resgate de US$ 2 milhões
  • A Vercel confirmou a segurança dos projetos open source como Next.js e Turbopack e recomendou aos clientes revisar as variáveis de ambiente e ativar o recurso de variáveis sensíveis

Visão geral do incidente de segurança

  • A Vercel é uma plataforma de infraestrutura de hospedagem em nuvem e implantação especializada em frameworks JavaScript, desenvolvedora do Next.js e fornecedora de funções serverless, edge computing e serviços de pipeline de CI/CD
  • Em um comunicado de segurança, confirmou oficialmente que ocorreu acesso não autorizado (unauthorized access) a sistemas internos
  • Foi anunciado que um subconjunto limitado de clientes foi afetado, mas que o serviço em si não sofreu impacto
  • A empresa contratou especialistas em resposta a incidentes e notificou as autoridades, com a investigação em andamento

Vetor de invasão e detalhes técnicos

  • A causa raiz da violação foi o comprometimento do app OAuth do Google Workspace da plataforma de IA de terceiros Context.ai
  • O CEO da Vercel, Guillermo Rauch, divulgou mais detalhes no X (antigo Twitter)
    • O invasor comprometeu a conta Google Workspace de um funcionário da Vercel por meio da invasão da Context.ai
    • Depois, a partir dessa conta, elevou os privilégios de acesso (escalate) no ambiente da Vercel
  • O invasor acessou variáveis de ambiente marcadas como "não sensíveis (non-sensitive)", que eram armazenadas sem criptografia em repouso (not encrypted at rest)
  • A Vercel afirma armazenar todas as variáveis de ambiente dos clientes com criptografia completa em repouso (fully encrypted at rest) e possuir mecanismos de defesa em várias camadas, mas as variáveis marcadas como "non-sensitive" funcionaram como ponto fraco
  • A Vercel recomenda que administradores do Google Workspace verifiquem o seguinte app OAuth:
    • 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com

Alegação de venda de dados pelo hacker

  • Um agente de ameaça que se apresenta como ShinyHunters publicou em um fórum de hacking um anúncio sobre a violação da Vercel e a venda de dados
    • Itens à venda: chaves de acesso, código-fonte, dados de banco de dados, acesso interno de implantação e chaves de API (incluindo tokens do NPM e do GitHub)
    • Ele apresentou dados do Linear como prova e afirmou possuir acesso a várias contas de funcionários
  • Atores de ameaça anteriores associados ao grupo ShinyHunters negaram à BleepingComputer qualquer envolvimento com este incidente
  • Um arquivo de texto compartilhado pelo invasor contém 580 registros de informações de funcionários da Vercel, compostos por nome, endereço de e-mail da Vercel, status da conta e timestamps de atividade
  • Também foi compartilhada uma captura de tela que parece mostrar um dashboard interno do Vercel Enterprise
  • A BleepingComputer não conseguiu verificar de forma independente a autenticidade desses dados e da captura de tela
  • Em mensagens no Telegram, o agente de ameaça afirmou estar em contato com a Vercel e ter exigido um resgate (ransom) de US$ 2 milhões

Resposta da Vercel e recomendações aos clientes

  • Foi confirmado que Next.js, Turbopack e outros projetos open source estão seguros
  • Foi implantada no dashboard uma página de visão geral das variáveis de ambiente e uma interface aprimorada para gerenciar variáveis de ambiente sensíveis
  • Medidas recomendadas aos clientes:
    • Revisar as variáveis de ambiente (environment variables)
    • Ativar o recurso de variáveis de ambiente sensíveis (sensitive environment variable feature) para garantir criptografia quando não estiver em uso
    • Realizar rotação de segredos (secret rotation), se necessário

3 comentários

 
GN⁺ 11 일 전
Comentários do Hacker News
  • O aviso acabou de ser atualizado, e pareceu importante que agora diga que a invasão começou com o comprometimento de um aplicativo Google Workspace OAuth de uma ferramenta de IA de terceiros
    Também foram divulgados IOCs para apoiar a investigação, e a orientação era para que administradores verificassem imediatamente se esse app estava em uso
    O OAuth App é 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com, e o texto original pode ser visto no aviso de segurança da Vercel

    • Pela explicação de Guillermo Rauch, o ponto de partida parece ter sido uma violação na conta de cliente da Context.ai usada por um funcionário da Vercel, e depois disso houve acesso em cadeia à conta Google Workspace e ao ambiente da Vercel
      Chamou atenção, em especial, a explicação de que a enumeração de variáveis de ambiente não sensíveis permitiu acesso adicional, além da estimativa de que os atacantes pareciam ser um grupo sofisticado fortemente acelerado por IA
      Mesmo assim, o fato de ainda não haver um aviso por e-mail aos usuários era bem preocupante
    • Achei que seria bom divulgar não só o ID do cliente OAuth, mas também o nome real do app
      Entendo não querer apontar diretamente o responsável, mas esconder o nome do serviço dá a sensação de que só atrasa a resposta
    • De qualquer forma isso vai acabar vindo à tona, então não entendi bem por que não nomear diretamente o app responsável
    • Já parecia que o app tinha sido removido
    • Isso pareceu o resultado natural da direção que o desenvolvimento web tomou nos últimos 10 anos
      Hoje ficou normal demais juntar várias combinações de terceiros em vez de construir sobre uma base estável, e com isso os pontos de falha também aumentaram
      No fim, ficou claro mais uma vez que a segurança só é tão forte quanto o elo mais fraco, e apoiar um negócio em ferramentas de IA com cara de vibe-coded me parece um risco evidente
      Isso me fez perguntar se realmente devemos continuar insistindo nessa direção, e quanta complexidade ainda precisa crescer para voltarmos a refletir sobre isso
  • Ao ver a análise da stack recomendada pelo Claude Code, tive a sensação de que o Claude Code está tornando a web mais homogeneizada ao recomendar por padrão certos provedores e frameworks
    Parece que essa falta de diversidade acaba ampliando o raio de impacto quando acontece algum incidente

    • Quando vejo os projetos vibe-coded de baixo esforço que aparecem no Reddit, com muita frequência eles estão rodando na Vercel
      Fica a impressão de que virou quase a escolha padrão
    • Uns dias atrás tentei forçar o Claude Code a criar um novo app CRUD em React, e ele despejou uma montanha de dependências de Node JS e NPM por padrão
      Então pedi explicitamente para fazer sem Node, e ele imediatamente reescreveu tudo com backend em Python, explicando por conta própria que também estava reduzindo as dependências
      Só para constar, isso foi um experimento para gerar algo descartável, não uma recomendação de vibe coding
    • É uma boa observação, mas não acho que o núcleo do problema seja o Claude em si
      No fim, é uma questão de como ele é usado, e acho que precisamos orientar melhor os desenvolvedores para não deixar o Claude tomar as decisões por eles
      Dá para aceitar conselhos, mas no fim um humano precisa revisar tudo de forma crítica; nesse ponto, não me parece tão diferente de colaborar com outro membro da equipe
    • Não consigo tirar da cabeça a ideia de que a IA está acelerando muito a convergência para a média
      A internet já tinha essa tendência, mas desta vez parece um pouco diferente
    • Não sou totalmente contra transformar o agente em bode expiatório, mas acho que esse tipo de problema sempre foi um padrão visível entre humanos também
  • Como alguém que já trabalhou em uma equipe de resposta a incidentes de segurança, consegui ter empatia pelo quanto essa equipe deve estar sofrendo agora
    Mesmo assim, o primeiro aviso pareceu uma comunicação péssima
    Não dizia o que tinha acontecido, mas usava uma linguagem sugerindo que era sério o bastante para envolver as autoridades, e a única orientação prática ao cliente era algo como "reveja as variáveis de ambiente"
    Só que, do ponto de vista do cliente, isso era vago demais. Era para ver se os valores ainda existiam? Como exatamente alguém deveria determinar se já houve vazamento?
    Para mim, deveriam ter dito imediatamente para rotacionar todas as senhas, tokens de acesso e dados sensíveis confiados à Vercel, e em seguida orientar auditoria dos logs de acesso e de sinais anômalos nos dados dos clientes
    O motivo de pagar caro por hospedagem é justamente a expectativa de que segurança e estabilidade serão geridas de forma profissional, e agora, mesmo considerando a incerteza inicial, isso pareceu excessivamente vago de forma deliberada

    • Ao ver a página do incidente, constava que as variáveis de ambiente marcadas como sensitive na Vercel são armazenadas de modo que não possam ser lidas, e que até agora não havia evidência de acesso a elas
      Ainda assim, se segredos como chaves de API, tokens, credenciais de banco de dados ou chaves de assinatura não estavam marcados como sensitive, então deveriam ser tratados como potencialmente expostos e trocados com prioridade
      A fonte era a incident page, e o momento em que vi isso foi às 16:22 no horário do leste dos EUA
    • Sinceramente, não entendi por que eu estava lendo isso primeiro aqui
      Sou cliente pagante há mais de um ano, e é absurdo que um agregador de notícias me informe antes de um e-mail da empresa
    • No ano passado a Vercel também lidou mal com a resposta a uma vulnerabilidade no Next middleware, então isso não pareceu totalmente novo
      O contexto pode ser visto na thread do HN e na reação da época
    • Segurança é realmente difícil, e os únicos fornecedores em que confio são AWS, Google e IBM
      O resto, em geral, me parece uma escolha de procurar problema
    • O motivo de pagar caro é também a expectativa de segurança e estabilidade, mas a conveniência de fazer deploy com poucos cliques pesa muito
      Ainda assim, decidi que não vou mais depender dessa conveniência e já migrei tudo do Render para o linode
      Antes eu pagava mais de US$ 50 por mês no Render, agora fico na faixa de US$ 3 a US$ 5, então dificilmente voltarei a usar esse tipo de hospedagem
  • Ao ler a frase “a Vercel não revelou quais sistemas foram comprometidos”, mesmo sem ser especialista em segurança isso me pareceu uma postura bem difícil de aceitar
    Também passou a impressão de que eles estavam mais focados em se proteger do que em ajudar os clientes a entender o impacto

    • Por outro lado, pensei que dizer o nome do sistema de forma mais específica nem sempre seria tão útil assim
      Por exemplo, se dissessem que um subsystem X pouco conhecido dentro do GitHub foi comprometido, isso talvez não ajudasse muito mais na prática do que o que já foi dito, algo como “ambientes de alguns clientes foram comprometidos”
  • Ao ver novamente que o aviso ganhou IOCs, ficou claro que o fato de o incidente ter começado com o comprometimento de um app OAuth do Google Workspace era uma informação importante para toda a comunidade
    Administradores e donos de conta deveriam verificar imediatamente esse identificador de app, e os detalhes estavam no aviso da Vercel

    • Fiquei muito curioso para saber que ferramenta era esse app OAuth
  • Estou em um MacBook Pro com Chrome 147.0.7727.56, e o app do Chrome travou imediatamente assim que cliquei no logo da Vercel no canto superior esquerdo da página
    Pareceu um bug bem curioso

    • No meu caso é Arch Linux, e o mesmo travamento aconteceu no Chrome 147.0.7727.101, mas não no Firefox 149.0.2 nem no Chromium 147.0.7727.101
      Foi estranhamente engraçado ver todo mundo lendo sobre a possibilidade de a Vercel ter sofrido algum tipo de comprometimento e, ao mesmo tempo, tentando reproduzir crash de página web
      Claro que também pensei que essa brincadeira coletiva de reproduzir o problema não tinha como não ter algum efeito colateral
    • Infelizmente, no meu Windows 11 Pro com Chrome 147.0.7727.101, não consegui reproduzir o travamento
      Até gravei um vídeo, e como eu uso uBlock Origin Lite achei que pudesse ser isso, mas mesmo desligando continuou sem travar
      Cheguei a pensar que, se reproduzisse, teria sido um pouco engraçado
    • Isso me lembrou um bug do Chromium por volta de 2021 em que abrir um menu dropdown do GitHub no Linux derrubava o sistema inteiro
      Ficou assim por um tempo até que acabaram corrigindo
    • Eu também vi a mesma coisa no Chrome do Windows 11
      Mas depois de abrir a home da Vercel uma vez diretamente pela URL, clicar no logo não causou mais o travamento
    • No meu ambiente, com MBP M4 Max e Chrome 146.0.7680.178, não houve crash
      Em compensação, agora fiquei meio receoso de clicar no botão Finish update
  • Eu estava acompanhando junto outra thread do HN e alguns posts no X sobre o assunto
    Na primeira menção do Theo, ele disse que parecia crível; no post seguinte, afirmou que env vars marcadas como sensitive estavam seguras e que valores não marcados deveriam ser trocados preventivamente
    Em outro post, disse que esse tipo de invasão poderia acontecer com qualquer host, e em outra menção foi levantada a possibilidade de ligação com o ShinyHunters

    • Se os valores não marcados como sensitive realmente não fossem sensíveis, então não vejo motivo para trocá-los
      Se são valores que precisam necessariamente ser trocados, então isso não quer dizer que já eram sensíveis desde o começo e deveriam ter sido marcados como sensitive?
    • Fiquei me perguntando quem é esse Theo para tanta gente ficar citando ele
      Pelo menos neste momento, não parecia haver tanto conteúdo realmente substancial assim
  • Incidentes como esse me fazem lembrar de novo o quanto o ecossistema web moderno está concentrado em pontos únicos de falha
    Até aqui, a divulgação me parece relativamente transparente, mas me fez recalcular o perfil de risco de depender totalmente de um PaaS gerenciado

  • A expressão “alguns clientes limitados” pode ser tecnicamente verdadeira mesmo que sejam 99%, então soa como uma formulação bem ambígua

  • Fiquei suspeitando se isso não poderia significar, na prática, que muitos clientes foram afetados, mas só os grandes clientes que não podem se dar ao luxo de sair estão sendo chamados de subset

    • É só especulação, mas tive a sensação de que raramente “limited subset” foi uma boa notícia
      Normalmente, quando a situação realmente permite tranquilizar, a empresa fala algo como “menos de 1% dos usuários”, com um número concreto, e desta vez isso não aconteceu
      Então imaginei que talvez ainda falte visibilidade, ou que os números não tenham agradado
      Ainda assim, consigo ter empatia pelo quanto a equipe de resposta deve estar sofrendo, e espero que daqui para frente a comunicação seja mais aberta e transparente
 
click 10 일 전

Aqui também aparecem caracteres em híndi. Ultimamente, com certa frequência, independentemente de ser openai, claude ou google, o output em coreano vem misturado com híndi; será que o pessoal da Índia fez a rotulagem do dataset em coreano?
Eu não gostava dos modelos chineses porque as respostas em coreano vinham misturadas com chinês, mas recentemente os modelos de ponta ficam misturando híndi o tempo todo, então minha rejeição aos modelos chineses até diminuiu

 
slowandsnow 10 일 전

Quando uso muito o Claude, o japonês aparece com frequência. Ontem também foi assim.