GromHacks Labs — As listas de payloads que eles não querem que você tenha. 1.324 sondas de injeção enviadas da nave-mãe para detectar o que é injetável em 20 classes de vulnerabilidade. Nós não exploramos, apenas batemos na porta e vemos quem atende. Cada payload testado contra parsers reais porque os alienígenas exigem provas. Não confie em nenhuma entrada. Questione tudo!
Encontrou um payload que não funciona? Por favor abra um issue com o payload, contexto do alvo e o que você esperava que acontecesse. Pull requests com correções ou novos payloads são sempre bem-vindos.
A pesquisa está em andamento. Este projeto está em desenvolvimento ativo e será atualizado regularmente com novos payloads, classes de vulnerabilidade e melhorias de validação.
Aviso Legal: Estes payloads são fornecidos apenas para testes de segurança autorizados, educação e fins de pesquisa. Os autores não assumem qualquer responsabilidade por uso indevido ou efeitos indiretos. Use totalmente por sua conta e risco. Ao usar este projeto, você aceita total responsabilidade por suas ações.
Licença: MIT - veja LICENSE
1,353 payloads de injeção validados cobrindo 20 classes de vulnerabilidade, 31 frameworks de desserialização e 14 mecanismos de template. Cada payload produz um sinal detectável. Zero payloads teóricos.
Validação: 1,353 testados / 1,353 acionam / 0 falhas / 0 ignorados contra 35 ambientes de teste Docker. A validação rigorosa comprova exploração real (computação no lado do servidor, erros reais de parser, atrasos de temporização medidos, callbacks OOB de contêineres alvo) -- não correspondência de strings.
A maioria das listas de payloads disponíveis publicamente são organizadas por tipo de vulnerabilidade: uma lista para injeção SQL, outra para XSS, outra para injeção de comandos, e assim por diante. Um testador escolhe a lista que acha que corresponde ao alvo, carrega-a em uma ferramenta de intrusão e a executa contra um parâmetro. Se ele errar sobre a classe de vulnerabilidade, toda a varredura não produz nada. Se o backend for um banco de dados incomum, um mecanismo de template não padrão, ou uma linguagem que a lista não considerou, os payloads falham silenciosamente. O testador segue em frente pensando que o parâmetro está limpo.
Essa abordagem tem dois problemas fundamentais. Primeiro, exige que o testador saiba qual vulnerabilidade existe antes de encontrá-la. Segundo, a maioria dos payloads em circulação são teóricos -- copiados entre projetos e postagens de blog sem nunca serem testados contra um parser real. Eles parecem corretos. Eles podem até ser sintaticamente válidos. Mas eles não provocam uma resposta detectável do alvo.
Este projeto adota uma abordagem diferente. A unidade principal de trabalho é o poliglota -- uma única string de payload projetada para ser válida (ou significativamente inválida) em tantos contextos de injeção quanto possível simultaneamente. Um poliglota escapa de aspas simples, aspas duplas, parênteses, comentários de bloco, atributos HTML, delimitadores de template e contextos de crase de uma só vez. Em vez de precisar saber qual é a vulnerabilidade, o testador dispara poliglotas em cada parâmetro e observa os sinais.
Cada payload nesta coleção é construído em torno de pilares de detecção -- respostas observáveis que confirmam a existência de uma vulnerabilidade sem exigir acesso a logs do servidor, código fonte ou sistema de arquivos:
7*191 que resulta em 1337. Se esse número aparecer na resposta e o payload enviou apenas 7*191 (não o literal 1337), o backend computou a expressão -- prova de execução de código.Se um payload não produzir pelo menos um desses sinais quando testado contra seu contexto alvo, ele não pertence à lista. Cada um dos 1,353 payloads aqui foi validado contra ambientes de teste Docker construídos para o propósito, com prova rigorosa de exploração. Zero são teóricos.
Payloads tradicionais de OOB e temporização dependem de comandos shell: curl, nslookup, ping, sleep. Estes quebram constantemente. Eles dependem do SO alvo, do PATH disponível, de qual shell interpreta o comando e se o processo tem permissão para gerar subprocessos. Um payload OOB baseado em curl que funciona no Ubuntu falha no Alpine (sem curl), falha no Windows (sem curl) e falha dentro de um contêiner restrito (sem execução de processo de saída).
Este projeto substitui comandos shell por funções nativas da linguagem sempre que possível. Payloads Python usam urllib.request.urlopen() e time.sleep(). Payloads Java usam java.net.URL.openStream() e Thread.sleep(). Ruby usa Net::HTTP.get() e Kernel.sleep. PHP usa file_get_contents() e sleep(). Essas funções existem em toda instalação padrão de suas respectivas linguagens -- sem busca de PATH, sem subprocesso, sem dependência de SO.
Onde até mesmo importações da biblioteca padrão podem ser bloqueadas (eval em sandbox, exec restrito), os payloads recorrem a alternativas sem importação: loops de CPU para temporização (sum(range(500000000)) em Python, Atomics.wait() em Node) e conexões socket brutas para OOB (__import__('socket').create_connection(), fsockopen(), TCPSocket.new()).
Nem tudo pode ser um poliglota. Mecanismos de template usam sintaxe fundamentalmente incompatível -- {{}} no Jinja2 não significa nada para o <%= %> do ERB, e nenhum deles é analisado como ${} do Freemarker). Formatos de desserialização são binários ou dados estruturados específicos de um framework. Para essas categorias, o projeto usa payloads por mecanismo organizados sob o mesmo sistema de pilares de detecção, cobrindo 14 mecanismos de template e 31 frameworks de desserialização em 7 linguagens.
O resultado é um único corpus onde os poliglotas lidam com os contextos que podem (SQLi, injeção de comando no SO, XSS, injeção de código) e payloads por mecanismo construídos para o propósito lidam com o restante, todos validados, todos produzindo sinais detectáveis, todos prontos para ferramentas de injeção linha por linha.
83 payloads cobrindo todas as 35 pilhas de teste, todos os 55+ endpoints e todos os 4 pilares de detecção por categoria. Validado: 83 ACIONAM / 0 NÃO ACIONAM / 0 IGNORADOS.
Toda categoria de injeção recebe cobertura de erro + matemática + temporização + OOB onde arquiteturalmente possível. Frameworks de desserialização que suportam execução de código (Pickle, PyYAML, jsonpickle, node-serialize, XMLDecoder, .NET Json.NET) recebem cobertura completa de múltiplos pilares. Frameworks limitados a sondagem (PHP unserialize, Ruby Marshal, SnakeYAML, etc.) recebem detecção baseada em erro. Dispare isso em cada parâmetro antes de mudar para listas de categoria completa para profundidade.