Depois do meu primeiro
artigo publicado no codeby, que entrou nas três principais publicações da semana, fiquei muito motivado a escrever a próxima. Mas a 11ª série impõe restrições ao tempo livre na preparação para o exame e para as olimpíadas. Portanto, escrevo o segundo apenas depois de alguns meses depois de
voar para fora de todas as Olimpíadas .
Esta publicação abordará um caso interessante quando uma vulnerabilidade encontrada em um recurso implicou uma cadeia de localização em vários outros sites.
Começo
Tudo começou com a verificação do local de um dos principais fabricantes de produtos forjados. A conta pessoal do usuário não estava lá e a área de pesquisa de vulnerabilidades não era muito extensa.
Ao testar o formulário de envio de pedidos, várias vulnerabilidades foram descobertas nele.
Em primeiro lugar, este é um XSS armazenado bastante padrão nos dados do comprador, com o qual esse emaranhado se estendeu. O XSS é padrão, e a falta de um sinalizador de "ativação" em um cookie claramente não era padrão. Muitas vezes recebi cookies de vários sites, mas nunca recebi autorização, e comecei a duvidar que, na natureza, existissem sites que não usassem o sinalizador "activationponly", porque seu uso reduz significativamente o risco de ataques XSS. Foi ainda mais surpreendente conhecer esse evento no site de uma grande empresa. Mas, como se viu, o serviço que permitiu essa supervisão era muito maior do que eu esperava. Mas mais sobre isso depois.
Substituí os cookies recebidos e entrei na conta crm do sistema do site (não resisti, pela primeira vez tive tanta sorte). Os direitos não eram administrativos, mas eram suficientes para acessar as estatísticas de pedidos, incluindo e dados do cliente.
Fiz capturas de tela para provar a existência de uma vulnerabilidade e enviei um relatório. Mais de uma semana se passou e eu não estava mais esperando por uma resposta. Segundo as estatísticas, se você não receber uma resposta dentro de três dias, poderá esquecê-las. Mas depois de 8 dias, uma resposta inesperada veio. E ainda mais, eles foram os primeiros a me pagar pela vulnerabilidade encontrada.
Voltando ao teste do formulário de envio de pedidos, também encontrei uma vulnerabilidade do iDOR que permite alterar o preço do pedido editando os parâmetros "json_order [0] [price]" e "json_order [0] [total]" na solicitação POST domain.ru/shop.php . A substituição do link do pedido na mesma solicitação no campo json_order [0] [href] levou a um RFI.
Nenhuma resposta foi recebida na mensagem sobre novas descobertas ...
Continuação
Nesse site de CRM, o sistema acabou não sendo auto-escrito, mas foi fornecido para pagamento por um serviço conhecido. Após o erro deles com o cookie, era lógico supor que haveria outras vulnerabilidades.
Se o script enviado por mim através do formulário de pedido funcionou, não houve validação de campo no site desejado e no sistema crm. x2 Portanto, tendo recebido uma conta de avaliação, comecei pesquisando campos vulneráveis ao xss.
Após longas viagens pelo extenso sistema de CRM, foram identificados mais de uma dúzia de campos com validação insuficiente. Em algum lugar, você pode inserir diretamente a tag de script, em algum lugar que você precise usar scripts em linha do tipo "onmouseover = alert ()". Além disso, em alguns lugares foi possível incorporar um script, mas em alguns lugares, eu me pergunto por qual lógica eles foram guiados, adicionando filtragem em alguns lugares, mas não em outros? Do ponto de vista do objetivo lógico dos campos, não vi um padrão. Em alguns lugares, onde quase todo mundo não vai, tudo funcionou bem, mas, por exemplo, eles não se preocuparam em adicionar filtragem ao nome da contraparte.
Os campos mais vulneráveis não puderam ser influenciados externamente. Eles só poderiam ser usados pelos funcionários para aumentar seus direitos no sistema, o que também é importante.
Nele, com o xss terminado, era possível passar para coisas mais interessantes.
Eu nunca procurei por vulnerabilidades de CSRF antes, os sites que eu testei não estavam na classe contra a qual eles usariam phishing. Portanto, eu não queria incomodar a mim ou aos proprietários de sites com vulnerabilidades que nunca seriam usadas contra eles. Foi um caso radicalmente diferente. Esse sistema de CRM era popular, também era usado por grandes lojas on-line, além da possibilidade de conectar caixas de pontos de varejo off-line, o que tornava a questão de segurança ainda mais importante.
Surpreendentemente, não havia proteção contra a CSRF. Foi possível enviar solicitações, as verificações não foram realizadas em lugar algum.
- Alterar informações da conta? - por favor
- Alterar o nome e o preço da mercadoria? - Sem dúvida
Ao mesmo tempo, os cookies continham algo chamado "csrftoken".
Então eu ainda pensei: qual é o sentido de colocar o token csrf nos cookies? Pesquisando no Google, descobri que existe uma maneira conveniente de proteger contra o csrf com um token nos cookies e duplicá-lo em uma solicitação de postagem, na qual você não precisa armazenar o token no servidor. Mais detalhes
aqui .
Porém, no nosso caso, apenas metade do trabalho foi realizado, o token foi colocado em cookies e estava ausente nas solicitações ao servidor. E ainda mais, a remoção completa dos cookies não mudou nada. Por que foi adicionado?
Em conjunto com o csrf descoberto, nosso xss, não acessível anteriormente de fora, ganha uma segunda vida. Afinal, não precisamos entrar em nossa conta para editar campos vulneráveis.
Além disso, através da substituição do tipo MIME do arquivo, foi possível fazer upload de arquivos arbitrários no servidor. Mas o servidor foi configurado corretamente e os scripts php não foram executados lá.
Ainda mais interessante. Todos os dados sobre mercadorias que a loja on-line retirou da crm. I.e. nome, descrição, foto. O link para a imagem do produto era "aaaa.domínio.ru/file/get/id=xxx". Para que a loja online possa capturar imagens, eles devem ter direitos de leitura para todos. 122
Depois de verificar os caminhos pelos quais outros arquivos mais privados estão armazenados, vi o mesmo URL. Parece nada surpreendente, eles provavelmente têm outros direitos de acesso. Definitivamente não inferior a 022. Mas, a realidade acabou sendo um pouco diferente, eles também tiveram acesso gratuito a usuários não autorizados.
- Você fez um pedido para importar dados do pedido em um arquivo exel? - Ótimo, agora qualquer um pode baixá-lo.
Talvez lá parecesse "yt5bjFb54hb # HJ% $ p" e não cedeu à força bruta? Também não. Todos os arquivos de identificação tinham um formato numérico e estavam na faixa de vários milhares. Proteção contra brutus, eu também não percebi. A verificação de todos os IDs de 1 a 10.000 obstáculos não foi possível. Repetidas várias vezes, ninguém estava interessado em tal atividade.
Eles responderam ao meu relatório em 3 dias.
Em relação à falta de uma bandeira, o confirmponly disse que estava faltando "Aparentemente, há muito tempo, desde que a versão php foi atualizada." Ligado no mesmo dia.
De acordo com o xss, eles disseram que todo mundo sabe que o filtro foi desligado no início do verão (na época já era agosto), claro que isso não explica por que havia filtragem em algum lugar, mas não em algum lugar, mas vamos fingir que não percebemos isso inconsistência. Eles também garantiram que o filtro será lançado em alguns dias. De fato, isso aconteceu em alguns meses. Mas aqui eu os entendo perfeitamente: também planejei começar a me preparar para os exames em alguns dias ...
O upload de arquivos arbitrários para o servidor era de pouca preocupação para eles, porque eles não são executados no servidor, o que significa que não há com o que se preocupar. Somente no momento em que escrevi o artigo, eu tive uma idéia se um site que já estivesse em uma hospedagem diferente da crm estava tentando tirar uma imagem do produto para a vitrine, mas recebe um script php, ele será executado? Ou devido ao fato de ser destinada à tag img, ela será processada apenas como uma imagem? Ou isso depende das configurações do servidor? Por favor, responda pessoas conhecedoras.
A resposta ao relatório csrf acabou sendo bastante interessante. Eles responderam com uma pergunta: "O que você considera um token para proteção contra ataques csrf?" Sério, do que estou falando?
Eles disseram sobre o acesso gratuito a arquivos que não levaram em consideração esse momento. Fechado imediatamente.
Devo dizer que essa foi a única vez em que realmente esperava receber uma recompensa em dinheiro. O site é grande, exceto que ainda não existe um projeto pago. Revista online popular. Mas ele recebeu apenas gratidão verbal.
Devo agradecê-los, fiquei ainda mais calmo com a questão do pagamento. O trabalho em prol da gratidão, sob qualquer forma, acabará por levar a nada. Você se acostumará a quaisquer elogios e outras honras, e eles deixarão de trazer satisfação. E se você fez tudo por eles, o significado de fazer algo será perdido. E você não pode perder o prazer do processo de sua atividade, resolvendo novos problemas, criando algo novo. Trabalhe em prol do trabalho, por mais banal que possa parecer. Trabalho durante o qual você não percebe como as horas passam, como o sol conseguiu não apenas ir além do horizonte, mas subir novamente por causa disso.
'' '
Estamos satisfeitos com pequeno, a felicidade não está em muito dinheiro
"Faça o que você ama" - apreciado em nossos círculos
'' '© Kolya Manyu - Todos os dias
Terminando
No suporte técnico do site anterior, foi utilizado o sistema de recepção de tickets de terceiros UserEcho. Não deixei de verificar. Nos sonhos, é claro, era possível ter a oportunidade de ler os ingressos particulares. Naturalmente, não tive sucesso. Eu tinha que me contentar com pouco.
Ao testar a API trabalhando com tickets, inicialmente não foram observadas anomalias, o direito de não procurar as de outra pessoa, de não assinar não era possível. Porém, após um estudo mais aprofundado do site, os desenvolvedores fizeram uma pequena falha.
No perfil, você pode encontrar uma seção sobre o gerenciamento de seus tickets, que indica aqueles em que você se inscreveu ou se inscreveu anteriormente.
Se enviarmos uma solicitação para cancelar a inscrição no ticket de outra pessoa, como esperado, somos informados de que não temos direitos a essa ação. Mas, ao mesmo tempo, ele está incluído em nossa lista de tickets, como um daqueles para os quais assinamos anteriormente. Assim, temos a oportunidade de descobrir seu nome e URL no formato "ticket_name_name_in_translate". Esse dano, é claro, não carregava nenhum. Em casos muito raros, será possível aprender algo importante e valioso com o nome. Mas era melhor do que ficar sem nada.
Depois de algumas semanas, o bug foi corrigido.
Agradeço a todos que leram até o fim!