exopteron/bibliorceCVE-2023-29478 - Exploit de Manipulação de Arquivos/Execução Remota de Código do BiblioCraft afetando versões do BiblioCraft anteriores à v2.4.6
Este método requer apenas o BiblioCraft! Não é preciso muito truque e nenhum outro mod é necessário para obter execução de código!
O artigo original focado no CoreTweaks pode ser encontrado aqui. Recomendo que você leia isto primeiro, pois posso pular alguns detalhes que serão importantes abaixo.
A execução de código é possível através de múltiplos métodos. Isso afeta o BiblioCraft 1.7.10 v1.11.7 e o BiblioCraft 1.12.2 v2.4.5 (confirmado) e provavelmente todas as versões do BiblioCraft anteriores à v2.4.6 (não confirmado, não testado)
Os patches existentes que corrigem o bug de path traversal ainda impedirão este novo caminho de execução de código.
Desta vez, estamos focando no salvamento de livros escritos do Vanilla.
Livros escritos são salvos em world/books/<nome-do-autor>, <título-do-livro>.
O formato desses livros é, por linha:
Continuando a partir do início, as páginas do livro são iniciadas com um marcador #pgx<número-da-página> e, da próxima linha até o próximo marcador, faz parte dessa página. O BiblioCraft sempre adicionará uma nova linha ao final das linhas, mesmo que nada siga.
Como antes, podemos controlar tanto o título do livro quanto o nome do autor através da tag NBT do livro, além de realizar path traversal.
O local onde vamos escrever é a pasta mods/. Os mods neste diretório são geralmente armazenados como arquivos JAR. Uma propriedade interessante dos arquivos JAR é que eles são na verdade apenas arquivos ZIP disfarçados.
Então, por que isso nos ajuda?
Arquivos ZIP têm uma propriedade interessante: eles ainda podem ser válidos mesmo com dados inúteis acrescentados no início ou no final.
O EOCD (End of central directory) dentro de um arquivo ZIP é colocado no final.
Ele consiste (aproximadamente) de uma assinatura mágica 0x06054b50, bem como o número, tamanho e deslocamento dos registros do diretório central dentro do arquivo.
O campo final em um registro EOCD é um comentário com prefixo de comprimento, que pode ser praticamente qualquer sequência de bytes que não seja a mágica (não testado).
(Acho que os parsers de arquivos ZIP começam pelo final e procuram pela assinatura EOCD para analisar o arquivo, mas não tenho total certeza.)
Se tudo o que o parser de ZIP precisa para encontrar os arquivos dentro do arquivo é o registro EOCD, e se quaisquer dados (com limitações) podem seguir o registro EOCD, então podemos criar um ZIP válido mesmo que haja alguns outros dados dentro do arquivo.
(Muito crédito para https://github.com/c0ny1/ascii-jar! Usei muito essas ferramentas!)
Primeiro, precisamos estruturar nosso payload. O Forge carregará classes como mods se elas tiverem a anotação especial @Mod, então usaremos isso aqui.
Nosso payload aproximado:
@Mod(modid = "payload-mod")
public class Payload {
// ...
static {
System.out.println("Hello World!");
}
// ...
}
Para evitar problemas de codificação, usamos um script para criar um arquivo JAR apenas ASCII contendo apenas nossa classe payload.
Preenchemos o início com PK\3\4.jar\n../../mods/\nprivate\n#pgx0\naaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
A razão pela qual prefixamos PK\3\4 (a assinatura do cabeçalho do arquivo local do ZIP) ao preenchimento é devido a uma estranha peculiaridade no Forge que não consegui reproduzir externamente, onde arquivos JAR são verificados para começar com esta assinatura, apesar de isso não ser um requisito do ZIP? Pode ser um bug no Forge.
Usamos a longa sequência de 'A's e 'a's para garantir que o deslocamento seja maior que 255, garantindo que o inteiro de 2 bytes que codifica o deslocamento não tenha bytes fora do intervalo ASCII.
Preenchemos o final com \n para evitar problemas com o BiblioCraft adicionando novas linhas.
Com nosso novo jar preenchido, pegamos todos os bytes após a última nova linha dos dados com que preenchemos o início e criamos uma nova String a partir deles (chamaremos isso de <dados-jar>) e criamos um novo livro escrito com dados NBT:
TAG_Compound(''): 2 entries
{
TAG_String("author"): "../../mods/"
TAG_String("title"): "PK\3\4.jar"
TAG_List("pages"): 1 entry
{
TAG_String(None): "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA" + <jar-data>
}
}
Quando salvamos este livro no disco através do BiblioCraft, todos os dados de preenchimento serão "regenerados" pelo seu formato, tornando nosso JAR válido novamente.
E agora, na próxima vez que o servidor reiniciar (mesmo uma reinicialização normal, ou se você causar um crash) nosso JAR de mod será carregado e nosso código será executado.
Em BiblioPOC/tools/ há um script Python3 para auxiliar na geração de um payload válido.
Os argumentos são:
python3 create_payload.py [java_file] [forge_jar_location] [class_name] [output_dir]
Então, quando estiver no jogo segurando um atlas do BiblioCraft, execute
/jarpoccommand [completed_jar_path] onde [completed_jar_path] é o caminho para [output_dir]/completed.jar.