Resumo

A lógica de validação de URL aplicada ao processar /appsuite/api/oxodocumentfilter&action=addfile apresenta três defeitos que podem ser usados para executar um ataque de SSRF do tipo Time of Check Time of Use (ToCToU). Esse problema permite que atores mal-intencionados executem requisições HTTP GET em serviços de rede internos e pode levar ao vazamento de informações protegidas.

Defeito #1: Vulnerabilidade Time of Check Time of Use (ToCToU)

A lógica de validação de URL no método URITools.getFinalURL implementado aqui sofre de vulnerabilidade ToCToU

URL u = new URL(url);
if (validator.isPresent()) {
    Optional<OXException> exception = validator.get().apply(u);
    if (exception.isPresent()) {
        throw exception.get();
    }
}

URLConnection urlConnnection = u.openConnection();

No código acima, a resolução de DNS do nome de host da URL de entrada é feita tanto no momento da verificação (validator.get().apply(u)) quanto no momento do uso (u.openConnection()), chamando o método InetAddress.getByName. Portanto, se um atacante puder alterar o resultado da resolução de DNS após o momento da verificação e antes do momento do uso, ele poderá ignorar o validador. Esse defeito isoladamente é extremamente difícil de explorar devido às seguintes limitações:

1. Por padrão, o InetAddress.getByName armazena em cache os resultados da resolução de DNS por 30 segundos se a resolução for bem-sucedida e por 10 segundos se falhar.
2. O intervalo de tempo entre validator.get().apply(u) e u.openConnection() é extremamente pequeno (menos de um milissegundo para URLs normais). O Defeito #2 é usado para contornar essa limitação.

Defeito #2: O comprimento da URL de entrada não é limitado

O validador de URL AddFileAction.validator implementado aqui não valida o comprimento da URL de entrada. Ao fornecer uma URL de tamanho grande, o atacante pode aumentar o intervalo de tempo entre as chamadas ao método InetAddress.getByName no momento da verificação e no momento do uso. Um intervalo de tempo maior permite que o atacante explore facilmente o Defeito #1.

Defeito #3: O validador de URL permite a URL de entrada se sua resolução de DNS falhar

O método HostList.contains implementado aqui retorna falso se a resolução de DNS do nome de host da URL de entrada falhar.

// Need to resolve as last resort
try {
    return contains(InetAddress.getByName(toCheck), false);
} catch (UnknownHostException e) {
    // Cannot be resolved
    return false;
}

O AddFileAction.validator chama o método blackImageUrlHostlist.contains para verificar se o nome de host da URL de entrada ou o endereço IP para o qual ele resolve está na lista negra. Se um atacante fizer a resolução de DNS do nome de host falhar, as verificações de endereço IP são ignoradas e a URL é aceita.

Estratégia de ataque

Considere um nome de host randomid.dns.pointer.pw com um servidor DNS autoritativo controlado pelo atacante. A estratégia de ataque é fazer a resolução de DNS de randomid.dns.pointer.pw falhar no momento da verificação (validator.get().apply(u);) e ser bem-sucedida no momento do uso (u.openConnection()). Isso permite que o atacante ignore os filtros de lista negra de endereços IP e execute uma requisição HTTP GET em qualquer endereço IP incluído na lista negra. As etapas a seguir podem ser seguidas pelo atacante para executar esse ataque:

1. Dispare o cache de InetAddress.getByName no servidor executando a ação addfile com os dados de requisição {"add_imageurl": "http://randomid.dns.pointer.pw"}. Nesse momento, o servidor DNS autoritativo será configurado para falhar a resolução de DNS de randomid.dns.pointer.pw retornando o status SERVFAIL. O InetAddress.getByName armazenará em cache esse resultado de falha por 10 segundos.
2. Anote o momento em que a resposta da requisição acima foi recebida. Esse é o horário de início do cache.
3. Instrua o servidor DNS autoritativo do domínio pointer.pw a retornar 127.0.0.1 para requisições DNS do tipo A do nome de host randomid.dns.pointer.pw.
4. Aguarde por uma duração especificada a partir do horário de início do cache, de modo que, na próxima etapa, o InetAddress.getByName retorne a resposta em cache (SERVFAIL) no momento da verificação e retorne 127.0.0.1 no momento do uso (url.openConnection()).
5. Execute a requisição SSRF com o valor de add_imageurl definido no formato . Aqui, u{25MB} significa que a parte do nome de usuário é uma string de 25 x 1024 x 1024 caracteres.

Passos para reproduzir

1. Instale o golang em https://golang.org/dl/

2. Instale o Open-Xchange e o Documents em uma máquina virtual com pelo menos 4GB de RAM seguindo os guias https://oxpedia.org/wiki/index.php?title=AppSuite:Open-Xchange_Installation_Guide_for_Debian_9.0 e https://oxpedia.org/wiki/index.php?title=AppSuite:Documents_Installation_Guide#Debian_GNU.2FLinux_9.0_.28valid_from_v7.10.29

3. Baixe e extraia o arquivo poc.zip

4. Abra o terminal / linha de comando e defina o diretório atual para a pasta poc.zip extraída

5. Execute o comando

   root@kitploit:~

    go run . -serverRoot="http://172.16.66.130" -username="testuser" -password="secret" -targetPath="appsuite/v=7.10.3-9.20200409.083030/apps/themes/logo.png" -targetPort="80" -payloadSize=25 -startSleepDuration=6600
   

   onde 172.16.66.130 é o endereço IP da VM