Olá, Habr! Meu nome é Maxim Teplykh, sou especialista em testes de penetração na empresa de TI Innostage. Neste artigo, quero abordar um tema que se torna cada vez mais relevante com o passar dos anos: o teste de sistemas que utilizam GOST TLS. Falarei brevemente sobre a própria tecnologia, além de apresentar as abordagens e desenvolvimentos que aplicamos na prática.
Peço desculpas antecipadamente pelo volume e pela introdução um tanto prolongada. Embora a narrativa não comece com dinossauros ou a história da Rússia antiga, o tema ainda precisa ser explorado com algum histórico.
Introdução Ao longo dos anos de prática, tivemos que lidar com uma grande variedade de tecnologias: algumas eram de nicho, outras populares, mas com um toque de exotismo. Hoje, falarei sobre algo bastante familiar, com o qual muitos se deparam diariamente, mas que muitas vezes não percebem.
Em 2015, surgiu o padrão doméstico GOST R 34.12-2015, e o mundo conheceu mais um nome incomum para uma tecnologia séria – "Kuznechik" (Grasshopper). Por trás desse nome, escondia-se um algoritmo de criptografia simétrica em bloco que, já em 2018, tornou-se parte do padrão nacional de criptografia da Rússia, GOST 34.12-2018.
Este nome tornou-se um pouco mais conhecido devido às notícias sobre os novos requisitos para equipamentos de rede 5G. Para aqueles que leem este nome pela primeira vez ou simplesmente querem conhecer o algoritmo mais de perto, recomendo dois bons artigos:
- Um artigo sobre Kuznechik em palavras simples
- Um artigo mais detalhado
Então, por que um novo algoritmo foi necessário? Isso faz parte dos esforços para alcançar a soberania tecnológica e é uma etapa importante no desenvolvimento de outra tecnologia doméstica, sobre a qual falaremos.
Essa tecnologia é o GOST TLS. Ela não é simples nem complexa. Essencialmente, é um conjunto de soluções criptográficas domésticas usadas na implementação do protocolo TLS.
O protocolo TLS (Transport Layer Security) é um dos mecanismos mais amplamente utilizados para estabelecer um canal de comunicação seguro. Ele é baseado no SSL (Secure Sockets Layer) versão 3.0 e mudou significativamente ao longo do tempo. Atualmente, a versão TLS 1.3 é a mais recente, embora o TLS 1.2 permaneça o mais comum.
Como fica claro pela descrição, é uma tecnologia para proteger dados transmitidos por canais de comunicação. A ubiquidade e familiaridade do protocolo TLS não surpreenderão ninguém; ele está literalmente em todos os lugares. Por exemplo, você está lendo este artigo via HTTPS, que também usa TLS. Mas e quanto à sua versão doméstica?
Em parte, posso entender o ceticismo de alguns de nossos compatriotas em relação às nossas tecnologias, mas foi o GOST TLS que se tornou o cavalo escuro que ganhou popularidade e provou sua viabilidade. Embora nem sempre seja perceptível, sistemas que usam GOST TLS estão presentes em praticamente todos nós. Sites governamentais suportam operação via GOST TLS. Seu aplicativo móvel Gosuslugi ou do imposto de renda criptografa a maior parte do tráfego usando o mesmo Kuznechik. Muitos sistemas de Infraestrutura de Informação Crítica (КИИ) e simplesmente sistemas críticos para negócios operam apenas com GOST TLS, que se tornou familiar e imperceptível para a maioria dos usuários.
Mas qual é o valor do artigo, então, se estou elogiando tanto essa tecnologia? Para o usuário comum, o GOST TLS se tornou uma parte imperceptível da vida, mas para desenvolvimento e testes, muitas vezes se revela um problema sério.
Problemas dos Índios Para usuários comuns de tais sistemas e sites, não há problemas especiais. Todo o trabalho pesado é assumido por aplicativos com soluções para trabalhar com GOST TLS ou pelo navegador. Para testadores e desenvolvedores, isso é completamente insuficiente.
Por exemplo, em tarefas de análise de segurança e pentest, precisamos de algo mais do que apenas um navegador com suporte a GOST. Os desenvolvedores, por sua vez, precisam encontrar maneiras de incorporar novos componentes em sua infraestrutura existente que possam trabalhar com GOST.
Existem tais soluções no mercado? A resposta é decepcionante: não há ferramentas prontas para depuração, apenas protótipos.
Soluções Técnicas Existentes
-
Trabalhar sem GOST A opção mais simples para realizar quaisquer testes é solicitar acesso a ambientes de teste onde o GOST TLS não é usado. A solução é simples, mas muitas vezes impraticável.
Na minha prática, houve casos em que consegui negociar com o cliente e obter acesso ao sistema testado contornando o GOST TLS. Mas, na maioria das vezes, ninguém quer implantar um ambiente de teste adicional ou clonar um sistema em produção – isso é caro.
Daí a pergunta: como trabalhar com GOST TLS durante os testes?
-
Trabalhar através de ferramentas existentes Há muitos anos ficou claro: não há ferramentas prontas, é necessário usar o que existe.
E o que existe?
- Navegadores com suporte a GOST TLS. Eles são construídos com base no Chromium e você pode instalar os plugins necessários, transformando-os em algo semelhante ao Burp Suite. Anteriormente, existiam navegadores com suporte nativo a GOST. Agora, eles estão desatualizados ou usam msspi (através de um provedor de criptografia de terceiros). Por exemplo, https://github.com/deemru/Chromium-Gost é um Chromium com msspi que funciona com o provedor de criptografia Crypto PRO CSP. O navegador Yandex também consegue trabalhar com msspi "out of the box".
A solução é funcional, mas inconveniente. As capacidades do Burp Suite e do ZAP não podem ser totalmente implementadas através de plugins de navegador. Existem ferramentas e utilitários que não podem ser roteados através do navegador.
Quer iterar sobre arquivos por dicionário? Não vai dar, você precisa pensar em outra maneira.
Camada Existente de Problemas Na busca por soluções, realizamos uma análise de por que as ferramentas existentes não funcionam com GOST TLS.
-
Problemas com ferramentas de depuração para trabalhar com GOST Na parte "vermelha" da segurança da informação, para testes de aplicações web, dois instrumentos têm sido usados há muitos anos:
- OWASP ZAP
- Burp Suite
Mas estávamos interessados em uma questão específica: por que nenhum deles funciona com GOST? Após investigar mais de perto, dividimos o problema em duas partes: criptografia e certificados.
-
Suporte à Criptografia Voltamos novamente a "Kuznechik" e "Stribog": o primeiro é um algoritmo de criptografia, o segundo é um algoritmo de hash. Inicialmente, parecia que as ferramentas criadas fora da Rússia simplesmente não suportavam esses algoritmos e teríamos que reescrever tudo.
A realidade acabou sendo um pouco mais interessante.
O ZAP usa OpenSSL e seus módulos, enquanto o Burp Suite usa a biblioteca Bouncy Castle. E em ambos os casos, o suporte aos algoritmos GOST existe:
- Bouncy Castle – suporta GOST "out of the box"
- OpenSSL – o suporte pode ser adicionado através de módulos ou obtido juntamente com o CryptoPRO CSP
Conclui-se que o suporte à criptografia existe. Então, por que ainda não funciona?
-
Suporte a Certificados Todas as ferramentas semelhantes implementam ataques MITM, mais precisamente a técnica de ssl-split.
Qual é a essência?
O navegador abre o site através de um proxy HTTP, no qual o ZAP ou Burp atuam. A ferramenta estabelece uma conexão com o site, obtém seu certificado e gera uma cópia autoassinada. Graças a isso, ele pode descriptografar o tráfego HTTPS: recebe dados do navegador, os processa e os envia para o servidor.
Onde surge o problema?
Tudo funciona até o momento da geração do certificado autoassinado. Mesmo que a ferramenta consiga estabelecer uma conexão usando GOST TLS, ela não consegue processar corretamente o certificado recebido do servidor. Certificados GOST parecem certificados TLS comuns externamente, mas diferem no conteúdo. Os campos, seus identificadores e valores, embora suportados pelas bibliotecas, não têm trabalho completo com eles nessas ferramentas. Nem o Burp Suite nem o ZAP conseguem converter certificados GOST para o formato RSA/ECC familiar. Os desenvolvedores simplesmente não previram tal cenário.
Abaixo estão exemplos de diferenças entre OIDs e valores de campos em certificados:
Característica Certificado Internacional (RSA/ECC) Certificado GOST Algoritmo de Assinatura sha256WithRSAEncryption (1.2.840.113549.1.1.11) 1.2.643.7.1.1.3.2 (para 256 bits) Algoritmo de Hash SHA-256 (2.16.840.1.101.3.4.2.1) GOST R 34.11-2012 (1.2.643.7.1.1.2.2) Algoritmo de Chave RSA (1.2.840.113549.1.1.1) ou EC (1.2.840.10045.2.1) GOST R 34.10-2012 (1.2.643.7.1.1.1.1 para 256 bits) Parâmetros de Chave Parâmetros de curva elíptica (ex: prime256v1) ou NULL para RSA Parâmetros de curva elíptica específicos para GOST. DN (Distinguished Name) Campos padrão: CN, O, C, etc. Podem ser usados os mesmos campos, mas às vezes com campos específicos adicionados, como INN (ИНН) ou OGRN (ОГРН).
Invenção de "Muletas"
-
Tarefa Básica Com base no conhecimento adquirido, surgiram duas opções de ação:
- Reescrever partes do ZAP/Burp Suite
- Delegar o trabalho com GOST para outra ferramenta
Escolhemos a segunda opção.
O que isso implica:
- O ZAP/Burp Suite é configurado para implementar a lógica de ssl-strip. Ou seja, ele recebe tráfego criptografado, descriptografa e o encaminha.
- Trabalhamos com os dados descriptografados: visualizamos, modificamos.
- O ZAP/Burp Suite envia os dados descriptografados para outra ferramenta.
- Essa outra ferramenta interage com o site original usando GOST TLS e transmite os dados.
Um esquema bastante lógico que permite descarregar do ZAP/Burp Suite a tarefa que eles não conseguem executar.
Se imaginarmos tudo em forma de esquema, ficaria assim:
[Diagrama esquemático mostrando ZAP/Burp Suite recebendo tráfego criptografado, descriptografando e enviando para uma ferramenta externa que lida com GOST TLS, e vice-versa.]
A vantagem desse esquema é que podemos rotear qualquer coisa que quisermos através da nova ferramenta (fuff, dirb, sqlmap, iisns). E com poder de processamento suficiente, podemos usar uma ferramenta para vários especialistas simultaneamente, o que simplificará um pouco a vida de quem for configurar isso.
Para implementar tal esquema, temos quatro opções de "muletas".
-
Opção Zero A mais simples, rápida e gratuita.
O pacote do CryptoPro CSP inclui a utilidade stunnel com suporte a GOST TLS. Com sua ajuda, você pode criar um túnel para o site desejado, e ele cuidará de toda a criptografia. Link para o site da cryptopro: https://cryptopro.ru/products/other/stunnel
Exemplo de configuração para tal construção (stunnel.conf):
pid=/var/opt/cprocsp/tmp/stunnel_cli.pid output=/var/opt/cprocsp/tmp/stunnel_cli.log socket = l:TCP_NODELAY=1 socket = r:TCP_NODELAY=1 debug = 7 [https] client = yes accept=127.0.0.1:1500 connect = gost.site.ru:443 verify=0Execução da nossa configuração:
/opt/cprocsp/sbin/amd64/stunnel_thread stunnel.confApós a execução, o site desejado estará disponível em
localhostna porta 1500. A conexão com ele ocorre via HTTP normal, sem criptografia.Não se esqueça de adicionar o novo endereço do site ao seu arquivo
hosts.Prós: A solução funciona, há suporte para autenticação por certificado. Contras: Cada site requer configuração separada. Não é adequado para trabalhar com aplicativos móveis (voltaremos a este problema mais tarde).
-
Opção Um Opção com custos mínimos de desenvolvimento ou compra. Foi nela que finalmente paramos.
Essa abordagem se baseia no fato de que o nginx em distribuições Unix utiliza criptografia do OpenSSL com bastante tranquilidade. Ao mesmo tempo, nenhum patch especial ou configuração complexa é necessária.
-
Entendendo o OpenSSL Há um pequeno obstáculo aqui: após a versão 1.1.0, o OpenSSL parou de suportar criptografia GOST. Mas isso é corrigível. Na comunidade open-source, existe o repositório https://github.com/gost-engine/engine, que contém a implementação de criptografia doméstica para OpenSSL. Você pode pegar e compilar o módulo necessário com criptografia para suas necessidades.
Após compilar a biblioteca, mova-a para
/usr/local/ssl/lib/engines-3/e adicione-a à configuração do OpenSSL.openssl_conf=openssl_def [openssl_def] engines = engine_section [engine_section] gost = gost_section [gost_section] engine_id = gost dynamic_path = /usr/local/ssl/lib/engines-3/gost.so default_algorithms = ALL CRYPT_PARAMS = id-Gost28147-89-CryptoPro-A-ParamSetSe você não quiser compilar o módulo a partir do código-fonte, existe outra maneira: https://github.com/rnixik/docker-openssl-gost
Este repositório contém exemplos de contêineres Docker e seus arquivos de build. Dentro dos contêineres estão compilações prontas do OpenSSL, nginx e curl. Uma descrição detalhada da implementação é fornecida em um artigo separado.
Observe que o repositório e os contêineres não são atualizados há muito tempo. Versões antigas contêm bugs de segurança, não diga que não avisamos.
Se você compilar sua própria imagem copiando bibliotecas de um exemplo pronto, não se esqueça de ativá-las.
bashecho "/usr/local/ssl/lib" >> /etc/ld.so.conf.d/ssl.conf && ldconfigVocê também pode fazer isso em vez de especificar a configuração para o OpenSSL durante a compilação manual.
-
Configurando o Nginx Após resolver o OpenSSL, passamos para a parte do Nginx.
Existem dois caminhos:
- Instalamos após compilar tudo para o OpenSSL
- Recompilamos se foi instalado antes da compilação.
A configuração do Nginx para nossos propósitos é um simples reverse-proxy, mas com algumas nuances:
nginxserver { listen 8081; server_name _; large_client_header_buffers 16 32k; resolver 127.0.0.11; location / { proxy_pass https://$host; proxy_ssl_protocols TLSv1 TLSv1.1 TLSv1.2; proxy_ssl_ciphers GOST2012-GOST8912-GOST8912:HIGH:MEDIUM; proxy_buffering off; proxy_buffer_size 128k; proxy_busy_buffers_size 256k; proxy_buffers 64 32k; } }Sem dúvida, a parte principal desta configuração é a configuração dos algoritmos de criptografia suportados. Duas linhas são responsáveis por isso:
proxy_ssl_protocols TLSv1 TLSv1.1 TLSv1.2;proxy_ssl_ciphers GOST2012-GOST8912-GOST8912:HIGH:MEDIUMAs versões antigas do TLS incluídas podem ser removidas, mas as mantivemos para diversos cenários. Não foi possível adicionar suporte a TLSv1.3 para trabalhar com GOST TLS; eles não conseguiram se entender.
Como bônus agradáveis desta configuração: ela permite trabalhar não apenas com a porta 443 no recurso de destino. O cabeçalho Host é tratado corretamente mesmo ao especificar a porta após o endereço. Condicionalmente, ao receber uma solicitação com o cabeçalho:
Host: gost.site.ru:8443Esta configuração usará:
proxy_pass https://$hostO que será equivalente a:
proxy_pass https://gost.site.ru:8443Falando sobre outros parâmetros, as configurações de buffer chamam a atenção. Essas são alterações de configuração que alcançamos durante o trabalho. Algumas delas aceleram o proxying, outras permitem processar grandes cabeçalhos de solicitação HTTP (por exemplo, com um grande número de cookies).
O bloco com a especificação do resolvedor é situacional e depende da sua configuração.
A configuração fornecida funciona corretamente apenas para HTTP/1.1 e inferior. A razão é simples: embora o HTTP/2 formalmente não exija TLS, a maioria dos navegadores e clientes o utiliza apenas com criptografia.
Se você precisar adicionar suporte a http2, altere a configuração:
nginxserver { listen 8081 ssl http2; server_name _; ssl_certificate /certs/def.crt; ssl_certificate_key /certs/def.key; large_client_header_buffers 16 32k; resolver 127.0.0.11; location / { proxy_pass https://$host; proxy_ssl_protocols TLSv1 TLSv1.1 TLSv1.2; proxy_ssl_ciphers GOST2012-GOST8912-GOST8912:HIGH:MEDIUM; proxy_buffering off; proxy_buffer_size 128k; proxy_busy_buffers_size 256k; proxy_buffers 64 32k; } }Prós: O método é óbvio: não precisa ser reconfigurado para cada site. O trabalho através do Burp Suite ocorre como se o problema com GOST TLS não existisse. Contras: Devido às peculiaridades da construção, para iterar sobre vhosts, a configuração precisará ser alterada.
-
-
Opção Dois A opção é semelhante à primeira, mas requer custos. O produto CryptoPRO CSP inclui um componente com suporte a msspi (o mesmo mecanismo usado em navegadores para trabalhar com GOST TLS).
Servidores web nginx e Apache podem trabalhar com msspi, mas isso requer modificação de seu código. A CryptoPRO tem soluções prontas:
- Para nginx, há um patch binário
- Para apache, há um módulo customizado mod_ssl
Você pode se familiarizar com isso neste link.
As desvantagens dessa abordagem são que ela requer licenças bastante caras do Crypto PRO CSP, e o uso de patches binários limita a capacidade de atualizar servidores web.
Vantagens: O suporte a TLSv1.3 funciona e tal solução pode passar pela certificação.
Do ponto de vista da configuração de servidores para nossas tarefas, não há diferenças em relação à primeira opção.
-
Opção Três A última opção é desenvolver sua própria ferramenta.
Para aqueles que se atreverem a embarcar nesta jornada fascinante, daremos alguns links para materiais úteis:
- um artigo sobre desenvolvimento usando GOST TLS
- https://github.com/deemru/msspi – repositório com msspi
- https://github.com/deemru/go-msspi — implementação de msspi para Go. Go tem sua própria criptografia "under the hood", então fazê-lo funcionar com GOST é uma tarefa e tanto, mas a solução já existe
- https://www.bouncycastle.org/ – aqui há criptografia para todos os gostos e linguagens. E GOST também está lá.
Nós, por nossa vez, não nos aventuramos em tal jornada, mas a possibilidade de implementação é visível (e, na verdade, implora por isso).
Integração de Ferramentas com as Soluções Escolhidas Terminamos com as opções de implementação e passamos para a configuração do Burp Suite/ZAP.
-
Trabalhando com Stunnel Se você escolheu a opção de trabalhar via stunnel, nenhuma configuração séria será necessária. É preciso apenas rotear o tráfego para a porta do stunnel através da ferramenta. Apenas verifique antecipadamente nas configurações de proxy do navegador e do sistema se o endereço do stunnel não está nas exceções (muitas vezes, redes "cinzas" estão nas exceções de proxy e o proxying para
localhostestá desativado por padrão). -
Trabalhando via Nginx/Apache Ao usar Nginx/Apache, a configuração é mais complexa. Burp Suite e ZAP para este esquema devem operar no modo ssl-strip.
Para o Burp Suite, você pode configurar outro listener com uma configuração especial:
[Captura de tela da configuração do listener do Burp Suite]
Essa configuração exigirá a ativação do HTTPS no lado do reverse-proxy, pois não funciona como ssl-strip. A opção "Convert HTTPS links to HTTP" na aba de configurações do proxy funciona de forma instável e nem sempre é adequada. Também podem ocorrer problemas com o processamento do cabeçalho
Host: em algum momento, essa configuração parou de adicionar a porta usada ao final do endereço, o que prejudica o funcionamento com quaisquer portas no reverse-proxy.Para resolver isso, você pode usar uma extensão gratuita para Burp Suite – Target Redirector. Ela pode encaminhar solicitações de saída para o endereço desejado com base em regras simples, executar ssl-strip e reescrever o cabeçalho
Hostem formato correto.Exemplo de configuração da extensão:
[Captura de tela da configuração da extensão Target Redirector]
Aqui tudo é lógico e compreensível:
- Redirecionamento de solicitações para quaisquer sites
- Operando via HTTPS
- Encaminhamento para o endereço 127.0.0.1, porta 8081
- Encaminhamento em formato HTTP (plaintext), essencialmente executando ssl-strip
- O cabeçalho
Hosté definido como na solicitação original, mas com a porta especificada.
Tal extensão com a configuração fornecida permite usar todas as vantagens do reverse-proxy.
Se ocorrerem erros com o protocolo http2, desative a opção de seleção de http2 por padrão nas configurações Network -> HTTP -> HTTP2. Se o http2 for necessário, use o exemplo de configuração para nginx fornecido e nas configurações do Target Redirector, defina a opção
redirect as https.A configuração do ZAP para este esquema requer implementação adicional. Provavelmente, será necessário criar uma extensão com funcionalidade semelhante à do Target Redirector, ou usar soluções prontas para essa tarefa, se disponíveis.
-
Trabalhando com Aplicativos Móveis Configuramos as ferramentas para trabalhar com sites via GOST TLS. Mas também precisamos considerar aplicativos móveis.
Tudo poderia ser simples e bonito: configurações familiares, ações familiares, scripts conhecidos para Frida. Mas… Aplicativos móveis que podem trabalhar com GOST TLS têm clientes HTTP personalizados "under the hood". Podem ser soluções escritas em torno de produtos da CryptoPRO, ou podem ser implementações próprias (usando o mesmo Bouncy Castle). Dependendo da implementação, tais clientes podem funcionar com todas as cifras (GOST/não-GOST) ou apenas com um tipo específico (apenas GOST). Daí surge um novo problema: como fazer com que os clientes GOST funcionem e, ao mesmo tempo, ver seu tráfego?
A resposta foi encontrada rapidamente. Já temos um servidor web com suporte a GOST TLS, resta apenas construir uma estrutura que aceite conexões com criptografia GOST e encaminhe as solicitações em plaintext para nosso Burp Suite aberto, e daí para a estrutura criada anteriormente.
A visão geral desse esquema é:
[Diagrama esquemático mostrando um aplicativo móvel se conectando a um servidor Nginx com suporte a GOST TLS, que encaminha o tráfego descriptografado para o Burp Suite, que por sua vez o encaminha para um servidor Nginx com suporte a TLS padrão.]
-
Configuração do Nginx Exemplo de configuração para nosso servidor Nginx:
nginxserver { resolver 127.0.0.11; listen 8082 ssl; server_name _; ssl_certificate /certs/gost.crt; ssl_certificate_key /certs/gost.key; ssl_certificate /certs/def.crt; ssl_certificate_key /certs/def.key; ssl_ciphers GOST2001-GOST89-GOST89:HIGH:MEDIUM; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_prefer_server_ciphers on; location / { proxy_pass http://host.docker.internal:8083; proxy_set_header Host $host; } }Este é outro reverse-proxy. Neste caso, ele encaminha o tráfego já descriptografado para o Burp Suite.
O bloco de configuração responsável por isso é:
nginxlocation / { proxy_pass http://host.docker.internal:8083; proxy_set_header Host $host; }A configuração especifica duas opções de certificados. O Nginx suporta o uso de diferentes certificados e chaves para diferentes algoritmos de criptografia. Em nosso caso, é um certificado para GOST TLS e um certificado para TLS padrão. Isso permite usar um proxy para todas as variantes de clientes HTTP (já que temos suporte para todas as variantes de criptografia).
Na seção
ssl_ciphers, especificamos o suporte GOST -GOST2001-GOST89-GOST89:HIGH:MEDIUM. -
Configuração do Burp Suite A carrossel de solicitações dentro do Burp Suite apresentado no esquema é implementado usando dois novos listeners e uma regra para TLS-passthru.
Primeiro listener:
- Porta 8084 em um endereço acessível para o aplicativo móvel
- Request handling – redirecionamento para o endereço 127.0.0.1:8082, Invisible proxy ativado
Segundo listener:
- Porta 8083 em
localhost - Request handling – Invisible proxy ativado
Regra para TLS-passthru (na seção Proxy):
- endereço 127.0.0.1 porta 8082
As configurações para o Target Redirector são ligeiramente alteradas, as regras de redirecionamento mudam de
redirect only httpspararedirect both.Você pode verificar a funcionalidade usando
curlcom suporte a GOST TLS. Observe que o novo listener criado na porta 8084 é usado como proxy.curl -k https://gost.cryptopro.ru/ -x "http://host.docker.internal:8084" -vvv --ciphers GOST2012-GOST8912-GOST8912 -
Configuração do Aplicativo Móvel Para o aplicativo móvel em teste, é necessário especificar o http-proxy
<endereço_BurpSuite>:8084. Alguns clientes HTTP no Android ignoram as configurações do sistema. Nesses casos, você pode usar as seguintes opções.Usando iptables para redirecionar a porta necessária para nosso proxy:
bashiptables -t nat -A OUTPUT -p tcp --dport 443 -j DNAT --to-destination <endereço_BurpSuite>:8084 iptables -t nat -A POSTROUTING -p tcp --dport 443 -j MASQUERADEOu instale o ProxyDroid no telefone e configure o proxy através dele:
[Captura de tela da configuração do ProxyDroid]
A fixação de certificados e a desativação de sua verificação dependem do aplicativo específico. Se você tem experiência em testar aplicativos móveis, é necessário descompilar o APK, encontrar a função desejada e escrever um script de hook para Frida.
-
Vantagens das Soluções Construídas em Torno do OpenSSL A principal vantagem da implementação através da compilação de um módulo para OpenSSL é que muitas utilidades e ferramentas o utilizam para implementar criptografia.
Por exemplo, ao escrever automação em Python, você pode usar as bibliotecas urllib3 e requests para implementar um cliente HTTP com suporte a GOST TLS.
Um pequeno "hello world":
pythonimport requests import urllib3 urllib3.disable_warnings() requests.packages.urllib3.util.ssl_.DEFAULT_CIPHERS += ':GOST2012-GOST8912-GOST8912' response = requests.get("https://gost.cryptopro.ru/", verify=False) print(response.text)
Ou outra opção: compilar o curl após instalar o módulo para OpenSSL. Neste caso, ele funcionará corretamente com GOST TLS.
Conclusão O GOST TLS está se tornando cada vez mais comum em nossos projetos, e para trabalhar com ele, frequentemente precisamos buscar soluções alternativas. Ao mesmo tempo, grandes fornecedores envolvidos em criptografia doméstica não oferecem recomendações básicas e soluções adequadas para depuração. A questão de como a situação se desenvolverá com o surgimento de padrões 5G domésticos, que também usam GOST, permanece em aberto.
Esperamos que as abordagens apresentadas no artigo sejam úteis em seu trabalho. Elas não são universais, mas todos os métodos descritos acima foram testados em projetos reais.
