jackofmosttrades/gadgetinspectorUm analisador de bytecode para encontrar cadeias de gadgets de desserialização em aplicações Java
Este projeto inspeciona bibliotecas Java e classpaths em busca de cadeias de gadgets. Cadeias de gadgets são usadas para construir explorações de vulnerabilidades de desserialização. Ao descobrir automaticamente possíveis cadeias de gadgets no classpath de uma aplicação, testadores de penetração podem construir rapidamente explorações e engenheiros de segurança de aplicações podem avaliar o impacto de uma vulnerabilidade de desserialização e priorizar sua correção.
Este projeto foi apresentado no Black Hat USA 2018. Saiba mais sobre ele lá! (Links pendentes)
AVISO: Este projeto é alfa na melhor das hipóteses. Precisa de testes e documentação adicionados. Sinta-se à vontade para ajudar adicionando qualquer um deles!
Supondo que você tenha um JDK instalado no seu sistema, você deve conseguir executar ./gradlew shadowJar. Depois, execute a aplicação com java -jar build/libs/gadget-inspector-all.jar <args>.
Esta aplicação espera como argumento(s) um caminho para um arquivo war (nesse caso, o war será descompactado e todas as suas classes e bibliotecas serão usadas como classpath) ou qualquer número de jars.
Observe que a análise pode consumir muita memória (e até agora o gadget inspector não foi otimizado para ser menos voraz em memória). Para bibliotecas pequenas, provavelmente você deve alocar pelo menos 2 GB de tamanho de heap (ou seja, com a flag -Xmx2G). Para aplicações maiores, use o máximo de memória que puder dispensar.
O kit de ferramentas passará por vários estágios de inspeção do classpath para construir conjuntos de dados para uso em estágios posteriores. Esses conjuntos de dados são gravados em arquivos com extensão .dat e podem ser descartados após a execução (são escritos principalmente para que estágios anteriores possam ser pulados durante o desenvolvimento).
Após a análise ser executada, o arquivo gadget-chains.txt será gerado.
A seguir, um exemplo da execução contra commons-collections-3.2.1.jar, por exemplo com
wget http://central.maven.org/maven2/commons-collections/commons-collections/3.2.1/commons-collections-3.2.1.jar
java -Xmx2G -jar build/libs/gadget-inspector-all.jar commons-collections-3.2.1.jar
Em gadget-chains.txt está a seguinte cadeia:
com/sun/corba/se/spi/orbutil/proxy/CompositeInvocationHandlerImpl.invoke(Ljava/lang/Object;Ljava/lang/reflect/Method;[Ljava/lang/Object;)Ljava/lang/Object; (-1)
com/sun/corba/se/spi/orbutil/proxy/CompositeInvocationHandlerImpl.invoke(Ljava/lang/Object;Ljava/lang/reflect/Method;[Ljava/lang/Object;)Ljava/lang/Object; (0)
org/apache/commons/collections/map/DefaultedMap.get(Ljava/lang/Object;)Ljava/lang/Object; (0)
org/apache/commons/collections/functors/InvokerTransformer.transform(Ljava/lang/Object;)Ljava/lang/Object; (0)
java/lang/reflect/Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object; (0)
O ponto de entrada desta cadeia é uma implementação da classe JDK InvocationHandler. Usando o mesmo truque da cadeia de gadgets original do commons-collections, qualquer implementação serializável desta classe é alcançável em uma cadeia de gadgets, então a cadeia descoberta começa aqui. Este método invoca classToInvocationHandler.get(). A cadeia de gadgets descoberta indica que o classToInvocationHandler pode ser serializado como um DefaultedMap de modo que esta invocação salta para DefaultedMap.get(). O próximo passo na cadeia invoca value.transform() a partir deste método. O parâmetro value nesta classe pode ser serializado como um InvokerTransformer. Dentro do método transform desta classe, vemos que chamamos cls.getMethodName(iMethodName, ...).invoke(...). O gadget inspector determinou que iMethodName é controlável pelo atacante como um membro serializado, e assim um atacante pode executar um método arbitrário na classe.
Esta cadeia de gadgets é o bloco de construção da cadeia de gadgets completa do commons-collections descoberta por Frohoff. No caso acima, o gadget inspector descobriu a entrada através de CompositeInvocationHandlerImpl e DefaultedMap em vez de AnnotationInvocationHandler e LazyMap, mas é praticamente a mesma.
Se você está procurando por mais exemplos de que tipo de cadeias esta ferramenta pode encontrar, as seguintes bibliotecas também têm alguns resultados interessantes:
Não se esqueça de que você também pode apontar o gadget inspector para uma aplicação completa (empacotada como um JAR ou WAR). Por exemplo, ao analisar o war da aplicação Zksample2, obtemos a seguinte cadeia de gadgets:
net/sf/jasperreports/charts/design/JRDesignPieDataset.readObject(Ljava/io/ObjectInputStream;)V (1)
org/apache/commons/collections/FastArrayList.add(Ljava/lang/Object;)Z (0)
java/util/ArrayList.clone()Ljava/lang/Object; (0)
org/jfree/data/KeyToGroupMap.clone()Ljava/lang/Object; (0)
org/jfree/data/KeyToGroupMap.clone(Ljava/lang/Object;)Ljava/lang/Object; (0)
java/lang/reflect/Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object; (0)
Como você pode ver, isso utiliza várias bibliotecas diferentes contidas na aplicação para construir a cadeia.
P: Se o gadget inspector encontrar uma cadeia de gadgets, uma exploração pode ser construída a partir dela?
R: Nem sempre. A análise usa algumas suposições simplificadoras e pode reportar falsos positivos (cadeias de gadgets que não existem realmente). Como um exemplo simples, ela não tenta resolver a satisfatibilidade de condições de ramificação. Assim, ela reportará o seguinte como uma cadeia de gadgets:
public class MySerializableClass implements Serializable {
public void readObject(ObjectInputStream ois) {
if (false) System.exit(0);
ois.defaultReadObject();
}
}
Além disso, o gadget inspector tem condições bastante amplas sobre as funções que considera interessantes. Por exemplo, trata reflexão como interessante (ou seja, chamadas a Method.invoke() onde um atacante pode controlar o método), mas muitas vezes premissas negligenciadas significam que um atacante pode influenciar o método invocado, mas não tem controle total. Por exemplo, um atacante pode ser capaz de invocar o método "getError()" em qualquer classe, mas não qualquer outro nome de método.
P: Se nenhuma cadeia de gadgets foi encontrada, isso significa que minha aplicação está segura contra exploração?
R: Não! Primeiro, o gadget inspector tem um conjunto muito restrito de funções "sink" que ele considera ter efeitos colaterais "interessantes". Isso certamente não significa que não existam outros comportamentos interessantes ou perigosos não listados.
Além disso, existem várias limitações da análise estática que significam que o gadget inspector sempre terá pontos cegos. Como exemplo, o gadget inspector atualmente perderia isso porque não segue chamadas de reflexão.
public class MySerializableClass implements Serializable {
public void readObject(ObjectInputStream ois) {
System.class.getMethod("exit", int.class).invoke(null, 0);
}
}