Relembrando um antigo caso de invasão no Roblox, havia um site de staging não produtivo em que usuários podiam se cadastrar, com um banner dizendo "tudo aqui não é permanente". Quando uma nova conta de administrador foi adicionada à conta de produção, alguém se registrou no site de staging com o mesmo nome de usuário e usou cookies e tokens para sequestrar a conta de produção e comprometer o site. Não é difícil imaginar que esse tipo de problema não seja raro: ao gerar tokens criptográficos com base em nome de usuário ou ID de usuário, se não houver segredos diferentes para produção/staging, se o site de staging se comunicar com serviços externos que confundem permissões de staging e produção etc.
A fronteira entre desenvolvimento e produção em grandes empresas é muito mais permeável do que as pessoas imaginam. Pensando em um dia comum, você faz login no PC, checa o e-mail e depois entra no portal do Azure usando as mesmas credenciais (tudo sustentado pelo mesmo tenant). A conta está conectada ao GitHub e às contas de nuvem.
Para permitir trabalho no Teams ou no OneDrive, grupos e equipes com permissões difíceis de entender são criados por toda parte, e eles acabam ficando no diretório da empresa como grupos de segurança quase indistinguíveis.
Às vezes você recebe e-mails automáticos perguntando se ainda usa algo de que precisa, mas a mensagem é opaca, e numa empresa realmente grande não há ninguém para perguntar (o help desk leva dois dias para responder, e você também não pode chamar o John Savill no Twitter, então só clica em confirmar e segue em frente).
No fim, a estrutura se rasga e um atacante dá sorte num ponto fraco e consegue o que quer atravessando tenants.
Como um CISO sábio certa vez disse, hackers não invadem, eles fazem login.
No setor de cibersegurança, isso é comumente conhecido como "whoopsie".
O pesquisador e especialista em segurança Kevin Beaumont apontou no Mastodon que uma conta capaz de atribuir a um app OAuth a função full_access_as_app deveria ter privilégios administrativos. Ele disse que "alguém" cometeu um erro de configuração bastante grande em produção.
Não conheço os detalhes do sistema, mas não parece que esse seja o problema, e me surpreende que um especialista diga que esse é o problema. Não deveria existir uma forma de cometer esse tipo de erro. Os designers e administradores deveriam tornar isso impossível, e eles deveriam ser responsabilizados.
Apesar de todas as belas certificações de segurança, parece que práticas recomendadas bem pensadas de um livro de US$ 36 da Amazon são completamente ignoradas.
O que falta neste post: como os autores definem "produção" e em que caso uma conta "não produtiva" pode ter direitos administrativos sobre o domínio de produção.
Esse padrão é a regra, não a exceção, em todo o ecossistema da MS, mas a própria Microsoft fazer isso é especialmente constrangedor.
Em uma empresa, as senhas de todos os servidores e bancos de dados de produção eram guardadas em um arquivo de texto no repositório de código, porque o arquiteto-chefe não queria ter que lembrar as senhas. Quando apontei ao CTO o quão idiota isso era, recebi como resposta "nós confiamos nos nossos funcionários" e "nós passamos na auditoria de segurança".
Odeio quando, ao entrar num novo emprego, alguém me concede um monte de privilégios "porque é mais fácil". Não deveria ser assim. Isso não só expõe a empresa, como também coloca em mim uma responsabilidade que eu não quero. Posso estragar algo importante por acidente e, se eu for hackeado, podem suspeitar que fui eu, já que eu tinha as permissões.
Por que isso é considerado um "erro"? Pode muito bem ser a ação de um espião trabalhando como administrador na Microsoft.
1 comentários
Opiniões do Hacker News
full_access_as_appdeveria ter privilégios administrativos. Ele disse que "alguém" cometeu um erro de configuração bastante grande em produção.