Você está na página 1de 23

Vazamentos de informações através do side-channel da

compressão quando utilizado em conjunto com criptografia


Vinı́cius Aguiar de Oliveira

Orientado por Vinicius Cardoso Garcia


1
Centro de Informática – Universidade Federal de Pernambuco (UFPE)
Av. Jornalista Anı́bal Fernandes, s/n - Cidade Universitária - Recife - PE
Resumo. O objetivo principal deste trabalho é discutir alguns ataques de side-
channel apresentando também algumas possı́veis mitigações com o intuito de
condensar informações sobre este tópico em um único trabalho. Estes ataques
exploram o funcionamento normal da implementação de uma aplicação, ao
invés de uma vulnerabilidade da mesma. Além disso, esperamos deixar clara a
necessidade de estudos mais aprofundados em outros protocolos e aplicações.
Para conseguirmos abordar estes tópicos, iremos primeiramente mostrar como
a compressão de dados funciona, exemplificando o algoritmo LZ77 e Huffman
Coding que, quando em conjunto, apresentam uma alta taxa de compressão
e garantia de que os dados não sejam perdidos no processo. Uma breve
explicação sobre o protocolo HTTP (Hypertext Transfer Protocol) é realizada de
forma a nivelar o conhecimento deste protocolo para os leitores. Protocolo este
que é imprescindı́vel para os ataques mostrados mais a frente. Por fim, expo-
mos nossas opiniões quanto a possibilidade da existência de outros protocolos
que possam estar suscetı́veis a similares explorações, fornecendo alguns casos
que podem ser usados como passos futuros para que seja dada continuidade ao
trabalho que representa apenas uma fração deste grande assunto.
Palavras-chave: Side-channel, compressão, segurança da informação, vaza-
mento de informações, HTTP

1. Introdução
As últimas duas décadas apresentaram um aumento estrondoso da utilização da Internet
tanto no acréscimo de usuários [16] conectados/ativos quanto de aplicações [4] publicadas
disponı́veis na rede e, com esse aumento, é natural que a quantidade de dados trafegado
também esteja em uma grande crescente. Desta forma, é fácil argumentar que a com-
pressão de dados cada vez mais se torna uma técnica quase mandatória para reduzir o
tamanho dos dados a serem enviados tanto por usuários quanto pelas aplicações.
Por outro lado, com o advento da Lei Geral de Proteção de Dados, ou LGPD [8],
observamos o movimento de desenvolvedores criarem suas aplicações com segurança em
mente, visto que a penalidade imposta pela Lei pode apresentar grandes danos financeiros
à instituição. Pensando em segurança, diversas aplicações fornecem seus serviços de
forma criptografada, utilizando SSL/TLS (Secure Sockets Layer e Transport Layer Secu-
rity) em cima do protocolo HTTP.
Neste contexto, diversas aplicações utilizam tanto compressão quanto criptografia
para melhor servir seu produto aos usuários, porém, apesar dos claros benefı́cios forneci-
dos por ambas técnicas, como por exemplo o tráfego de dados criptografados de maneira
mais rápida, ainda existem desafios relacionados a possibilidade de um vazamento de
dados criptografados neste cenário especı́fico, foco de investigação deste trabalho.
Atualmente, já foram publicados, em diversos eventos de segurança da informação
(como a Ekoparty e Blackhat), alguns ataques que se exploram do fato da aplicação uti-
lizar criptografia e compressão em conjunto. Porém, a resolução deste problema não é
nada trivial, a mitigação mais efetiva é desabilitar a compressão da aplicação como um
todo, abandonando todo e qualquer benefı́cio ofertado pela técnica, como a redução de
custo.
Trazendo esse cenário e a possibilidade do vazamento de informações sensı́veis de
usuário (como o número de cartão de crédio, por exemplo), este trabalho analisará como
a compressão de dados permite o vazamento destes após a sua compressão. Além disso,
serão expostas algumas possı́veis mitigações, as desvantagens destas mitigações, o futuro
para esta pesquisa e, finalmente, esperamos que este trabalho possa trazer luz ao tema de
exploração de Side-Channel da compressão, mostrando possı́veis vazamentos de dados e
infrações à LGPD.
O ponto de partida do nosso estudo foi o trabalho de John Kelsey (2002) [17]
integralmente teórico sobre os possı́veis vazamentos de informações, em texto plano, que
foram comprimidos e cifrados. O trabalho de John Kelsey (2002) foi divulgado a cerca
de uma década antes da publicação de ataques testados e comprovados como o BREACH
(Browser Reconnaissance & Exfiltration via Adaptive Compression of Hypertext) (2013)
[14] e CRIME (Compression Ratio Info-leak Made Easy) (2012) [27] que se utilizam
da compressão e criptografia de uma maneira especı́fica, comprovando que suas teorias
estavam corretas. Dessa forma, acreditamos ser extremamente plausı́vel que outros pontos
abordados pelo autor, John Kelsey (2002), possam também se mostrar possı́vel com as
tecnologias utilizadas hoje em dia.
Desde a publicação do trabalho de John Kelsey (2002) [17], é perceptı́vel a con-
tinuidade de estudos sobre o tema. Em 2011 foi publicado o ataque BEAST (Browser Ex-
ploit Against SSL/TLS) [26], já em 2012 os mesmos autores publicaram uma versão mel-
horada chamada de CRIME [27]. Após menos de um ano, a apresentação do BREACH
[14] elevou a exploração do side-channel para focar no protoclo HTTP e não mais no
SSL/TLS. Além de novos ataques, também houveram publicações referentes a melho-
rias para os ataques, por exemplo, em 2013 foi publicado o TIME (Timing Info-leak
Made Easy) [6] que foi responsável por diminuir os requerimentos do ataque CRIME
e também foi publicado o HEIST (HTTP Encrypted Information can be Stolen Through
TCP-Windows) [34].
Este trabalho está organizado conforme se segue:
• Seção 3: descreverá a compressão de dados, os diferentes tipos, o funcionamento
e também alguns algoritmos responsáveis pela redução do tamanho do dado;
• Seção 4: faremos uma breve explicação sobre criptografia em geral, explicitando
os pontos necessários para o entendimento deste trabalho;
• Seção 5: faremos uma explicação sobre o protocolo HTTP e sua variante HTTPS;
• Seção 6: irá expor as possibilidades de uso de ambos, criptografia e compressão,
deixando clara a diferença dos resultados a depender da ordem da utilização de
ambas tecnicas;

2
• Seção 7: esta Seção explicará o conceito de side-channel e mostrará alguns exem-
plos de ataques deste tipo contra o protocolo HTTP e suas mitigações;
• Seção 8: nesta Seção iremos concluir todos os pensamentos e estudos expostos
neste trabalho;
• Seção 9: irá mostrar os próximos passos desta pesquisa, tanto para nós, como em
forma de sugestão para outros pesquisadores de segurança que se interessem pelo
assunto.

2. Metodologia do trabalho

Para a elaboração deste trabalho, foram utilizadas duas pesquisas de classificação, uma
quanto à sua natureza, que diz respeito à contribuição que o trabalho trará, outra quanto
aos objetivos, classificando o grau de familiaridade com o tema e quanto iremos apro-
fundá-los.
Quanto à sua natureza, a metodologia utilizada foi a de pesquisa aplicada, tendo o
objetivo de gerar conhecimentos de aplicação prática para os problemas que iremos abor-
dar neste trabalho. Devido ao objetivo da pesquisa aplicada que foi escolhida a segunda
metodologia para atuar em conjunto, classificada quanto aos objetivos, a metodologia de
pesquisa exploratória.
Essa metodologia é desenvolvida quando ainda não há tantos dados e informações
disponı́veis sobre o tema abordado, mas percebe-se que será alvo de pesquisas futuras.
E, para ainda dar mais riqueza para o trabalho aqui apresentado, o procedimento técnico
utilizado foi o de estudo de caso, que consiste em um estudo profundo de um ou de poucos
objetos, tendo como propósitos:

• Descrever a situação do contexto em que está sendo feita a investigação;


• Explicar as variáveis causais do fenômeno em situações complexas.

3. Compressão

A compressão de dados é uma técnica amplamente utilizada em diversos protocolos e


aplicações com o intuito de reduzir o espaço necessário para armazenar ou enviar tais
dados [22]. Atualmente, com a importância da Internet, a compressão se apresenta como
um aliado imprescindı́vel para o funcionamento atual da grande rede.
Ao reduzir o tamanho dos incontáveis dados sendo trafegados pela Internet a cada
segundo, é perceptı́vel o aumento da velocidade na troca de informações em qualquer
aplicação online. Além do ganho em velocidade, diversos provedores de hospedagem de
websites, por exemplo, baseiam parte do seu custo na quantidade de dados sendo transmi-
tidos pela aplicação, todos esses problemas são abordados diretamente com a compressão
dos dados [29].
Para melhor entendimento sobre os problemas gerados com o alto tráfego de dados
na internet e como a compressão pode ajudar, as Figuras 1 e 2 ilustram requisições sem e
com compressão para um mesmo host.

3
Figure 1. Requisição para https://2ip.ru sem compressão

Figure 2. Requisição para https://2ip.ru com compressão

A Figura 1 demonstra a requisição sem utilizar mecanismos de compressão do


HTTP, resultando em um tempo de resposta de 1438 milissegundos. Já a Figura 2 mostra
a mesma requisição, porém, utilizando compressão do protocolo HTTP ocasionando na
redução no tempo de resposta do servidor para 870 milissegundos. A fim de realizar um
teste mais acertivo, foram realizadas 100 (cem) requisições onde metade utilizou a técnica
de compressão e a outra metade não a utilizou. A Tabela 1 ilustra os tempos obtidos:

Table 1. Comparação de Tempo


COMPRESSÃO TEMPO MÉDIO TEMPO MÁXIMO TEMPO MÍNIMO
Com compressão 832 milissegundos 885 milissegundos 722 milissegundos
Sem compressão 1374 milissegundos 1412 milissegundos 1266 milissegundos

Para começarmos a destrinchar o tópico de compressão, é importante distinguir as


formas de compressão utilizadas atualmente. Existem duas principais classificações para
as formas de compressão, classificações estas que distinguem a compressão com perdas
(lossy compression) e a compressão sem perdas (lossless compression) [22]. A diferença
entre essas duas formas consiste em se o resultado dos dados, após reverter a compressão,
deverá permanecer idêntico à entrada ou se é aceitável que haja um certo nı́vel de perda
de dados, resultando em uma saı́da levemente diferente do que foi utilizado como entrada.
A compressão com perdas, também chamada de compressão irreversı́vel, é mais
utilizada em dados de multimı́dia, como imagens e áudios. Isso se dá pelo fato de que

4
a perda de alguns bytes de informação não irá impedir o entendimento daquele arquivo
[31]. Um exemplo famoso formato de compressão sem perdas é o arquivo JPEG, onde
o algoritmo apresenta uma alta redução do tamanho do arquivo, porém, é perceptı́vel a
redução da qualidade da imagem quando comparada com o formato RAW que utiliza uma
compressão sem perdas para manter a alta qualidade de imagens.
Por outro lado, a compressão sem perdas permite que, ao reverter a compressão de
uma dada entrada, o resultado seja idêntico ao dado original [31]. Este formato é utilizado
em momentos onde é de extrema importância manter a integridade dos arquivos. A tı́tulo
de exemplo, o protocolo HTTP, um dos responsáveis pelo funcionamento da transferência
de dados em aplicações web, utiliza formas de compressão sem perdas, garantindo que os
dados enviados por um usuário cheguem ao seu destinatário com as mesmas informações.
O protocolo HTTP permite que o cliente, muitas vezes o navegador do usuário, explicite
sua habilidade de enviar e ler dados comprimidos. Através do cabeçalho Accept-Encoding
o navegador permite a utilização do algoritmo de compressão de sua preferência [20].
A ponto de maximizarmos o conhecimento, o foco deste trabalho é na compressão
sem perdas, sendo imprescindı́vel a explicação, mesmo que superficial, dos algoritmos
mais utilizados por esse tipo de compressão. Vale ressaltar que um dos algoritmos mais
utilizados é o algoritmo Deflate [12], que pode ser subdivido em outros dois algoritmos
denominados Lempel-Ziv 77 e Huffman Coding (descritos nas seções 2.1 e 2.2 respecti-
vamente).
O Lempel-Ziv 77, ou simplesmente LZ77 [36], é responsável pela redução de
redundância dos dados entrados no algoritmo. Este utiliza um método de substituição
de strings por referências, representadas também como vetores, que irão apontar para
uma outra parte da entrada. Ao criar este apontamento entre strings, no momento de
descomprimir os dados, cada vetor será substituı́do pela string a qual ela faz referência,
dessa forma, reduzindo o tamanho original dos dados.
O resultado do LZ77 é utilizado como entrada para o segundo algoritmo, Huff-
man Coding [15]. Este algoritmo gera uma árvore binária onde cada nó será um código
em formato de uma cadeia de bits que representará um byte. Os bytes que tiverem maior
frequência terão seus respectivos códigos mais acima da árvore, próximos à raiz, en-
quanto os bytes de menor frequência estarão mais abaixo. Da forma que a árvore é con-
struı́da, a cadeia de bits que estiver mais acima, terá um tamanho menor do que as cadeias
mais abaixo. Assim sendo, o algoritmo garante que os sı́mbolos que forem mais utiliza-
dos serão alterados para uma cadeia de bits menor e, consequentemente, reduzindo seu
tamanho total.
Como já pontuado anteriormente, para melhor compreensão dos problemas de
segurança que iremos abordar neste trabalho, é imprescindı́vel o conhecimento básico
sobre os algoritmos de compressão brevemente citados. Como o Deflate é dividido em
dois outros algoritmos, aqui iremos destrinchar cada um dos dois na ordem em que são
utilizados pelo Deflate.
3.1. Lempel-Ziv 77
Imaginemos que iremos comprimir uma entrada contendo a string “Computando e com-
putadores”. Inicialmente o Deflate executará o algoritmo LZ77 para reduzir as re-
dundâncias do texto. A substring “computa” da palavra “computadores” também ex-

5
iste na palavra “Computando”, porém, é importante distinguir os caracteres maiúsculos
dos minúsculos, já que estes possuem uma representação computacional completamente
diferente, então, a string que se repete é na realidade “omputa”.
Percebe-se que o texto a ser comprimido possui a repetição de uma substring e o
algoritmo se aproveita dessa duplicidade para reduzir o tamanho do texto como um todo.
Dessa forma, o algoritmo realiza a substituição dessa string por uma vetor de substituição
com tamanho de dois bytes, transformando a entrada para “Computando e c(13, 6)dores”.
Esse vetor é criado para representar que no lugar onde ele foi inserido, é na reali-
dade uma substring que pode ser copiada do mesmo texto, voltando exatamente treze car-
acteres e copiando os próximos seis. Ao voltar os treze caracteres descritos pelo primeiro
número do vetor, estaremos apontando para a letra “o”, logo após isso o algoritmo copia
os seis caracteres, incluindo o “o”, salvando a substring “omputa” como já mostramos
anteriormente. Apesar de diversos outros detalhes tratados pelo algoritmo, esta é a visão
geral e mais do que suficiente para o entendimento deste trabalho.

3.2. Huffman Coding


Após termos aplicado o algoritmo LZ77 em toda entrada, o resultado gerado por esta
primeira parte é inserido como entrada para a segunda parte do deflate, o Huffman Coding.
Esta última parte consiste em criar novas representações de cadeias de bits para cada
sı́mbolo que não foi substituı́do pelo vetor do LZ77. Sabe-se que alguns sı́mbolos são
mais frequentes do que outros, como por exemplo, o aparecimento mais frequente da
letra “e” do que a letra “z” em uma entrada.
Com isso, David Huffman, idealizou que seria mais proveitoso representar a letra
“e” com uma cadeia de bits menor do que os oito bits necessários para armazenar esta
letra, enquanto o “z” terá uma cadeia maior, podendo até ser maior do que os oito bits
originais, mas que no final do algoritmo esse aumento será indiferente quando comparado
com a entrada como um todo. Além disso, também é utilizada a frequência dos sı́mbolos
presentes no string a ser comprimido.
No fim do processo de atribuição de todos os novos códigos para cada sı́mbolo, é
construı́da a “Huffman Tree”, uma simples estrutura de dados que conterá toda a tradução
de cada nova cadeia de bits para cada um dos seus respectivos sı́mbolos.
A Figura 3 apresenta o resultado da criação da Huffman Tree para a frase “Com-
putando e computadores” previamente citada como exemplo para o algoritmo LZ77. É
importante notar que para esta demonstração, foi apenas aplicado o algoritmo de Huff-
man e por isso não há nenhum vetor previamente criado. A partir desta árvore, é criada a
representação em cadeias de bits para cada caractere presente na estrutura de dados.
Cada descida de camada da árvore para esquerda, é adicionado o bit “zero” na
cadeia, e para a direita é incluı́do o bit “um”. Dessa forma, percebe-se que o caracter “o”,
com quatro ocorrências na frase, poderá ser representado pela cadeia de bits 001 enquanto
a letra “c”, com uma única ocorrência, terá uma cadeia maior, representado por “10100”.

4. Criptografia
Apesar de a criptografia ser um dos ingredientes principais para os ataques que serão abor-
dados neste trabalho, não é necessário ter um conhecimento aprofundado sobre formas de

6
Figure 3. Representação gráfica da Huffman Tree da frase “Computando e com-
putadores”

criptografia. Precisaremos apenas explicitar o fato de que após criptografar um stream de


dados, o resultado gerado serão dados inelegı́veis com um alto ı́ndice de entropia. Este
output praticamente remove as repetições e redundâncias do texto original.
Além disso, é interessante distinguirmos o conceito de block cipher e stream ci-
pher, visto que estes possuem diferenças a serem levadas em consideração para cada
ataque que iremos descrever. De maneira geral, a principal diferença entre estes diz re-
speito à quantidade de dados a serem criptografados por vez. Na stream cipher, cada byte
é criptografado separadamente, é realizada uma operação de ”ou exclusivo” ou XOR, dos
dados a serem cifrados com a chave criptográfica [3].
Já a block cipher utiliza um tamanho fixo para cada bloco, como por exemplo
64 bits por bloco. De maneira similar à stream cipher, estes blocos serão criptografados
utilizando a chave escolhida, chave esta que deverá ser a maior possı́vel para dificultar a
quebra da criptografia. A depender do tamanho dos dados a serem cifrados, é possı́vel
que um bloco não seja suficiente para armazenar todos os dados, havendo a necessidade
de dividir os dados em diversos blocos diferentes [2]. Caso não existam dados suficientes
para preencher o último bloco, este deverá ser preenchido com bits aleatórios, garantindo
que todos os blocos sempre tenham o mesmo tamanho [2].
Os ataques a serem introduzidos aqui, tem como intuito vazar informações
cifradas, a forma como estes dados estão sendo cifrados não oferecem grandes diferenças
nos ataques a serem descritos. Existem ataques de side-channel da compressão das mais
diversas maneiras, que possuem os mais diversos protocolos e aplicações como alvo. Para
este trabalho, como já explicitado, iremos nos ater nas variantes dos ataques focados no
protocolo HTTPS.

5. Protocolo HTTP
Como neste trabalho iremos nos ater aos casos relacionados ao protocolo HTTP, é de
suma importância que tenhamos um conhecimento básico também sobre este protocolo

7
que, basicamente, rege a Internet.
O HTTP, ou Hypertext Transfer Protocol, é um protocolo da camada de aplicação
responsável pela transferências de documentos como o HTML (Hypertext Markup Lan-
guage). Este protocolo foi criado, principalmente, para a comunicação entre navegadores
e servidores web seguindo o modelo cliente-servidor. É através deste protocolo que um
usuário pode acessar diversos websites na Internet.
A Internet funciona, basicamente, em requisições e respostas, podendo um usuário
enviar uma requisição através de seu navegador, requisitando um certo recurso do servidor
destino. Essas requisições podem ser divididas em alguns verbos HTTP, como os mais
comuns, GET, comumente utilizado para ler algum dado e POST, mais usado para criar e
editar recursos na aplicação.
Apesar de existerem recomendações de como implementar cada verbo HTTP, isto
cabe ao desenvolvedor que pode, ou não, seguir as recomendações. Logo, é possı́vel en-
contrar requisições GET que alterem dados e POST que leem dados do servidor. Quando
o navegador enviar a requisição desejada, o servidor irá tratar esta requisição e responder
da maneira necessária.
Uma resposta do servidor contém um código de status da resposta, estes códigos
são agrupados em cinco classes de mensagem:
• 1xx - Respostas informacionais;
• 2xx - Respostas de sucesso;
• 3xx - Respostas de redirecionamento;
• 4xx - Respostas de erros do cliente;
• 5xx - Respostas de erro do servidor.
Tanto requisições, como respostas, possuem seus respectivos cabeçalhos onde
cada um possui uma finalidade distinta. Cabeçalhos como User-Agent existem mais para
fins informacionais e de controle dos servidores, fornecendo informações do navegador
e do sistema operacional por exemplo [21]. Outros como o já citado Accept-Encoding
[20], atuam de forma mais direta na comunicação entre cliente e servidor, é através deste
onde o cliente pode especificar o algoritmo de compressão a ser utilizado, como o gzip ou
deflate, por exemplo.
Com o imenso aumento do tráfego nos últimos anos, o assunto de segurança na
Internet se tornou mais importante e muito mais cobrado pelo público, esperando que os
responsáveis pelas aplicações web garantam uma maior segurança para seus clientes.
Com segurança em mente, o protocolo HTTPS foi criado para implementar os
protocolos SSL/TLS no já existente protocolo HTTP. A implementação dos algoritmos
criptográficos permite maior segurança durante a autenticação em aplicações, melhoria
da privacidade dos usuários assim como integridade dos dados em tráfego. O protocolo
SSL foi descontinuado desde o lançamento to TLS versão 1.0, atualmente a versão mais
atualizada é a 1.3 [33].
Estes protocolos servem para estabelecer conexões criptografadas entre com-
putadores e quando utilizados em conjunto com o protocolo HTTP, estes permitem a
comunicação entre cliente e servidor com um maior nı́vel de segurança. A utilização
destes protocolos permitem que usuários possam enviar informações sensı́veis de seus

8
navegadores para os servidores das aplicações que utilizam, como por exemplo a
realização de uma compra online utilizando um cartão de crédito. Dessa forma,
garantindo que atacantes que possam ter acesso a comunicação não terão acesso às
informações em texto plano [33]. A utilização do protocolo HTTPS pode ser observada
diretamente no navegador dos usuários conforme ilustrado na Figura 4.

Figure 4. Cadeado que ilustra a utilização do protocolo HTTPS

6. Relação Criptografia e Compressão


Com os conhecimentos sobre os algoritmos de compressão já é possı́vel começar a con-
struir o conceito do principal assunto ao qual desejamos trazer mais informações nesta
pesquisa. Dito isso, o primeiro passo para começar a discutir sobre os impactos de
segurança é entender as diferentes formas de utilização de compressão juntamente com a
criptografia.
Partindo do pressuposto que os dados devem ser cifrados e comprimidos, um de-
senvolvedor possui apenas duas opções: a primeira delas é cifrar para depois comprimir
os dados, ou, cifrar os dados já comprimidos. Precisamos diferenciar cada um dos casos
a fim de mostrar o porquê de uma dessas opções não ser viável.
A primeira opção, cifrar para depois comprimir, não apresenta nenhum ganho.
Como já expomos anteriormente, o algoritmo LZ77 é responsável por reduzir as re-
dundâncias, repetições, da entrada de dados. A criptografia, por outro lado, aumenta a
entropia dos dados de forma que, idealmente, não haja nenhuma repetição ou redundância.
Com isso, a utilização de algoritmos de compressão em dados com entropia extremamente
alta, não resulta em nenhuma redução de tamanho.
Desse modo, nos resta a última opção, primeiro comprimir os dados para depois
cifrar que é uma alternativa que apresenta bons resultados tanto na compressão quanto na
criptografia.
Ao comprimir os dados, a entrada terá todas suas redundâncias reduzidas, o texto
será comprimido normalmente de acordo com o algoritmo utilizado. Este resultado será
fornecido como entrada para o algoritmo de criptografia que também obterá sucesso em
sua execução, dessa forma, obtendo a segurança da criptografia juntamente com a redução
do tamanho após a compressão de dados.
Agora que concluı́mos que a melhor opção para segurança dos dados é comprimir
os dados para depois criptografá-los, para o escopo desta pesquisa, partiremos sempre
do pressuposto de que os dados estarão sujeitos à compressão e criptografia nesta ordem
especı́fica.
Os ataques a serem explanados neste trabalho são todos exemplos de um tipo
especı́fico de ataque e, para a melhor compreensão de todos, é necessário que façamos

9
uma breve descrição acerca do tópico de side-channel e o que pode ser categorizado como
ataques neste meio.

7. Ataques de Side-Channel contra o HTTP

Os ataques que iremos descrever neste trabalho são todos categorizados como ataques
de side-channel e, para entendê-los com maior facilidade e profundidade, precisare-
mos introduzir o conceito base desta forma de ataque. Estes ataques se aproveitam de
informações ganhas através da implementação de um sistema e não de uma vulnerabil-
idade em si [32], chama-se de side-channel este canal alternativo que possibilita a in-
ferência de informações a partir do funcionamento normal do sistema.
O principal objetivo destes ataques é utilizar o conhecimento dos algoritmos para
observar o tamanho das respostas que serão enviadas do servidor até seus navegadores e, a
partir desta informação, inferir se os dados enviados estão apresentando uma alta ou baixa
taxa de compressão. Através da inferência do quão bem os dados foram comprimidos, os
atacantes conseguem vazar informações sensı́veis de seus alvos, mesmo quando estes
utilizam criptografia na comunicação dos dados.
Com o rápido aumento de aplicações SaaS (Software as a Service) [19], a pos-
sibilidade da realização destes ataques na Internet aumentou significativamente, mesmo
com os dados trafegados entre servidor e o cliente (navegador, por exemplo) estando de-
vidamente cifrados via HTTPS [9]. Para este trabalho, iremos nos ater aos ataques que
utilizam o side-channel criado através da utilização de algoritmos de compressão como
os já citados anteriormente.
Apesar de nosso foco ser na compressão, é importante clarificar que este não é
o único tipo de Side-Channel que pode ser explorado. Existem casos de exploração do
Side-Channel acústico consequente de processamento computacional, utilizando este som
para extrair uma chave criptográfica [13]. Nesta mesma linha, um outro trabalho mostra a
possibilidade de identificar códigos digitados em smartphones através do som emitido do
contato do dedo com a tela do dispositivo [30]. Estes são alguns exemplos que ilustram o
potencial dessas explorações dos Side-Channels.
No decorrer desta Seção, iremos explicar e exemplificar como os conhecimentos
descritos na Seção anterior (Ataques de Side-Channel) podem ser aproveitados por um
atacante com a finalidade de visualizar dados cifrados, e algumas mitigações que os de-
senvolvedores devem ter em mente. Alguns ataques serão descritos com maior nı́vel de
detalhe que outros.
Estas informações também podem ser proveitosas para o trabalho de outros
pesquisadores e de pessoas da área de segurança da informação como um todo. E é de
extrema importância pontuar que não faz parte do nosso objetivo principal explicar todas
as minúcias de cada um dos ataques já publicados até hoje.
A Tabela 2 ilustra um breve resumo sobre os exemplos de ataques a serem abor-
dados nesta Seção. Cada linha mostra o ataque com o protocolo ao qual este explora,
o principal impacto de cada um dos ataques assim como a mitigação mais certeira para
cada um. Note que cada ponto da tabela será expandido com maiores detalhes no decorrer
desta Seção.

10
Table 2. Resumo dos ataques abordados
NOME PROTOCOLO IMPACTO MITIGAÇÃO
Vazamento de cookies
de sessão ou outros Utilizar de TLS
BEAST SSL/TLS
segredos em cabeçalhos versão 1.1 ou maior
da requisição
Vazamento de cookies
de sessão ou outros Desativar compressão
CRIME SSL/TLS
segredos em cabeçalhos do SSL/TLS
da requisição
Vazamento de segredos Desativar compressão
BREACH HTTP
na resposta do servidor do HTTP

7.1. BREACH
O ataque Browser Reconnaissance & Exfiltration via Adaptive Compression of Hypertext,
ou como iremos nos referir a este ataque daqui para frente, BREACH, foi apresentado no
evento de segurança Black Hat no ano de 2013 [14]. Os três pesquisadores responsáveis
por tal apresentação propuseram melhorias ao ataque CRIME, que iremos descrever na
Seção 7.2. Após a rápida ação dos navegadores em mitigar o CRIME ao desabilitar a
compressão do protocolo TLS, o ataque se viu mitigado rapidamente, como mencionado
anteriormente. Porém, o BREACH se aproveita da compressão a nı́vel do protocolo HTTP
ao invés do TLS, que permanece, até os dias de hoje, em utilização em grande parte da
Internet. Ademais, o ataque que iremos descrever nesta Seção ataca a resposta do HTTP,
mais uma vez diferenciando do seu antecessor que atacava a requisição do HTTP.

7.1.1. Pré-requisitos

Para este ataque ser possı́vel é necessário que o cenário tenha alguns ingredientes obri-
gatórios. Primeiramente, é imprescindı́vel que a aplicação alvo faça uso da compressão
do protocolo HTTP, mas por conta dos benefı́cios trazidos pela compressão, este pré-
requisito é facilmente preenchido. Também é necessário que a aplicação reflita na re-
sposta do servidor uma entrada fornecida na requisição enviada pelo usuário. Por fim, é
preciso que a aplicação apresente um secret, seja ele informações sensı́veis do usuário ou
um CSRF (Cross-Site Request Forgery) token1 , por exemplo. Este segredo será o dado a
ser exfiltrado pelo ataque.
Existem alguns pontos que apesar de não serem obrigatórios, influenciam no al-
goritmo implementado pelo ataque, aumentando ou diminuindo a dificuldade do mesmo.
É interessante que a aplicação não apresente grandes diferenças em suas respostas no
ponto a ser atacado, isso se dá pelo fato de que o ataque utiliza o tamanho da resposta
como principal meio para exfiltração de dados, caso a aplicação retorne tamanhos muito
diferentes, isto irá dificultar o ataque.
1
CSRF (Cross-Site Request Forgery) token é um código de uso único que deve ser enviado em um
formulário HTML e validado no servidor para garantir que o formulário foi enviado pelo usuário. Dessa
forma, impossibilitando que um atacante force sua vı́tima a realizar a submissão de um formulário de forma
não desejada.

11
Além das obrigatoriedades técnicas do ataque, existem dois pontos que devem ser
executados pelo atacante antes que o ataque seja realizado. O atacante precisa ter acesso
aos dados cifrados do usuário que estão em trafego e isso pode ser realizado através de
um ataque de Man-in-the-Middle, dando ao atacante a habilidade de analisar o tamanho
das respostas sendo enviadas pelo servido até o navegador da vı́tima.
Por fim, o atacante também precisará conseguir enviar requisições através do nave-
gador da vı́tima, a forma mais factı́vel de obter isso seria enviando um site malicioso para
a vı́tima, sendo ele responsável pelo envio das requisições.

7.1.2. Metodologia do ataque

Com o conhecimento já descrito sobre os algoritmos de compressão Huffman Coding e


LZ77, é importante fazer a distinção de que o LZ77 é o algoritmo que permite que o
side-channel da compressão exista e, consequentemente, esse ataque seja explorável. Por
outro lado, o Huffman Coding apresenta um obstáculo para o atacante, visto que este
algorı́tmo influencia no tamanho do arquivo retornado pelo servidor de uma maneira não
intencional pelo atacante. No decorrer desta Seção, iremos explanar o ataque de maneira
geral, deixando clara a distinção entre ambos os algoritmos na visão do atacante.
Para exemplificar, assumiremos que o atacante está realizando um ataque de Man-
in-the-Middle em sua vı́tima, enquanto esta acessa o site malicioso enviado pelo próprio
atacante. Uma vez que o atacante tenha ambos pré-requisitos realizados, iremos assumir
que a vı́tima estará utilizando uma aplicação fictı́cia de Internet Banking que tenha os três
ingredientes previamente citados, compressão do HTTP habilitada, um segredo que está
sendo enviado na resposta do servidor e, nesta mesma resposta, a possibilidade de refletir
a entrada do usuário.
Com isso, o BREACH consiste em o atacante efetuar requisições a partir do site
malicioso para o site que contém o segredo da vı́tima a ser exfiltrado. Estas requisições
serão enviadas com um payload a ser refletido na resposta do servidor, que tem o objetivo
de inserir texto arbitrário na resposta do servidor (mesma resposta que contém o segredo)
e observar o tamanho da mesma. Dessa forma o atacante poderá inferir o quão bem os
dados estão sendo comprimidos. À vista disso, será possı́vel descobrir o segredo através
do tamanho da resposta.
Para exemplificar, suponhamos que a aplicação de Internet Banking possui uma
funcionalidade que permite ao usuário a enviar o nome de uma pessoa para realizar
uma transferência bancária, e ao enviar este nome, a aplicação retorna, entre outras
informações, as informações do cartão de crédito do usuário autenticado na aplicação.
Imaginemos que ao fornecer o nome ”João Silva” para a transferência bancária a
aplicação retorne uma resposta que contém a seguinte mensagem: ”João Silva, Número
do cartão: 1234 5678 9012 3456” e que esta resposta possua um tamanho de 100 bytes.
Caso o usuário, ao invés de enviar o nome envie a string ”cartão: 0” isto resultará
em uma substring no retorno de ”cartão: 0, Número do cartão: 1234 5678 9012 3456”
e com a utilização do algorı́timo LZ77, este texto pode ser representado por ”cartão: 0,
Número do (21, 8)1234 5678 9012 3456”. Com esta nova resposta, os 10 (dez) bytes do
nome da pessoa foram substituı́dos por 9 (nove) bytes da entrada do usuário.

12
Além disso, o algoritmo LZ77 é responsável pela criação da referência de 2 (dois)
bytes e substituir pela string ”cartão: ”, de 8 (oito) bytes, resultando em um retorno de
93 (noventa e três) bytes. A entrada fornecida pelo usuário anteriormente termina com o
número 0 (zero) que não foi incluı́do na referência criada pelo LZ77, caso fosse enviado
um 1 (um) em seu lugar, este numeral seria comprimido pelo LZ77 reduzindo o tamanho
total da resposta por 1 (um) byte.
A Tabela 3 ilustra uma série de entradas, suas respectivas respostas e o tamanho
de cada uma delas, mostrando o comportamento da aplicação e da compressão a depender
da entrada do atacante.

Table 3. LZ77
ENTRADA RESPOSTA PÓS COMPRESSÃO TAMANHO DA RESP.
cartão: 0 cartão: 0, Número do (21, 8)1234 5678 9012 3456 93 bytes
cartão: 1 cartão: 1, Número do (21, 9)234 5678 9012 3456 92 bytes
cartão: 11 cartão: 11, Número do (21, 9)234 5678 9012 3456 93 bytes
cartão: 12 cartão: 12, Número do (21, 10)34 5678 9012 3456 92 bytes

O BREACH utiliza um ataque de brute-force2 para poder exfiltrar os dados dese-


jados. Porém, este ataque não se trata de um brute-force comum, visto que, o atacante tem
a possibilidade de identificar, através do tamanho da resposta, se o payload enviado foi
comprimido com um texto já presente na resposta ou não. A Tabela 3 ilustra esse ponto.
Ao enviar a string ”cartão: 11” o atacante percebe que o tamanho da resposta
aumentou por 1 (um) byte, quando comparado com a string anterior. Isso significa dizer
que o segundo número 1 (um) não comprimiu com o algoritmo LZ77. E é a partir dessa
informação que o atacante assume que: apesar do segredo começar com o número 1 (um),
o segundo dı́gito é diferente de 1 (um), fazendo com que o algoritmo implementado envie
um segundo caracter.
Por sua vez, ao enviar o texto ”cartão: 12”, o atacante identifica que o tamanho da
resposta se manteve igual quando comparado com o payload que enviou apenas o número
1 (um), comprovando que o cartão de fato começa com o número 1 (um) seguido do 2
(dois). Para sumarizar, o atacante se aproveita dessas informações para realizar seu brute
force byte a byte3 , onde é possı́vel identificar se o byte enviado está correto.

7.1.3. Obstáculos técnicos

Os autores do ataque BREACH perceberam alguns desafios para a exploração do side-


channel da compressão, que, apesar da simplicidade da ideia do ataque, na prática, este
se apresenta relativamente mais desafiador. Isso se dá pelo fato do comportamento do
algoritmo LZ77 permitir com que o atacante descubra os segredos presentes na aplicação,
porém, o algoritmo Huffman Coding se coloca como um obstáculo para o atacante, difi-
cultando a sua execução.
2
Ataque de força bruta consiste em realizar diversas tentativas para descobrir um segredo, como por
exemplo uma senha, tentando todas as combinações possı́veis para a senha.
3
O ataque de força bruta byte a byte diferencia de um ataque de força bruta normal no momento em que
é possı́vel distinguir se o caracter enviado no ataque está correto ou não.

13
Este obstáculo ocorre porque este algoritmo, Huffman Coding, pode fazer com
que a resposta do servidor comprima os dados de forma tal que o tamanho total reduza da
mesma maneira que no LZ77, resultando em um comportamento similar ao demonstrado
na Tabela 3. Para superar alguns desses desafios, primeiro foi preciso criar uma forma de
garantir que o algoritmo do atacante consiga distinguir a compressão por conta do LZ77
do Huffman Coding.
Retomando o exemplo da Tabela 3, se o atacante enviar o payload cartão: 121,
apesar do último caracter enviado, o número um, não ser o valor correto do cartão de
crédito da vı́tima, caso este caracter tenha um alto ı́ndice de ocorrências dentro da re-
sposta como um todo, este será representado por uma cadeia de bytes menor que a normal,
podendo resultar em uma resposta de 92 (novaneta e dois) bytes, o que, normalmente, in-
dicaria que o payload foi bem sucedido. Iremos detalhar as formas criadas para contornar
este problema nas Subseções a seguir.

7.1.4. Two-Tries Method

Este método consiste em enviar duas requisições distintas com o intuito de identificar se o
último caracter enviado, foi comprimido pelo LZ77 ou Huffman Coding. Este workaround
utiliza um padding antes e depois do último caracter do payload, da seguinte maneira:
• nome=(payload)(padding);
• nome=(padding)(payload).
É importante que o padding utilizado seja um conjunto de caracteres que não
possam existir no tipo de texto do segredo a ser exfiltrado. Para descobrir um número
de cartão, por exemplo, podemos utilizar qualquer conjunto de caracteres que não sejam
números. Se fosse um segredo que segue o padrão alfanumérico, não poderı́amos utilizar
números ou letras. Dessa forma, o padding que iremos utilizar para este caso serão os
caracteres ”{” e ”}”.
O intuito do padding é tentar o mesmo caracter duas vezes mas em lugares do
payload distintos, caso a resposta tenha o mesmo tamanho em ambas as requisições, isso
será suficiente para atribuir a responsabilidade da compressão para o Huffman Coding.
Por outro lado, se o tamanho das respostas forem diferentes e no payload onde o caracter
a ser comprimido se encontra no final do payload e antes do padding, pode-se assumir
que a compressão foi realizada através do LZ77 e, consequentemente, este caracter faz
parte do segredo.

Table 4. Two-Tries Method


ENTRADA TAMANHO DA RESPOSTA
cartão: 12{}2 91 bytes
cartão: 122{} 91 bytes
cartão: 12{}3 93 bytes
cartão: 123{} 92 bytes

A Tabela 4 ilustra a lógica explanada anteriormente de forma visual. Foram real-


izadas duas requisições para a tentativa do caracter 2 (dois) e 3 (três). As duas primeiras

14
requisições resultaram em uma resposta de mesmo tamanho, ilustrando a compressão
através do Huffman Coding, visto que para este não importa a localidade do caracter na
string.
Por sua vez, as requisições para o caracter 3 (três) mostram que a string cartão:
123{} possui uma melhor compressão do que cartão: 12{}3, já que o caracter 3 (três)
faz parte do segredo a ser descoberto, mostrando a compressão sendo realizada através do
algoritmo LZ77.

7.1.5. Guess Swap

Esta forma de distinguir a compressão de ambos os algoritmos consiste, assim como a


anterior, em introduzir o caracter da vez em diferentes locais do payload, porém, difer-
entemente do Two-Tries Method, este não utiliza nenhum padding para seu objetivo.
Continuaremos utilizando o mesmo exemplo do método anterior, onde o algortimo
gerado pelo atacante já descobriu os dois primeiros caracteres e está no brute-force do
terceiro, que é o caracter 3. Nesta técnica, iremos enviar duas requisições, uma com o
caracter da vez no final e outra trocando de lugar com o último caracter descoberto. Por
fim, analisaremos o tamanho das respostas assim como realizado anteriormente.

Table 5. Guess Swap


ENTRADA TAMANHO DA RESPOSTA
cartão: 123 92 bytes
cartão: 132 93 bytes
cartão: 124 91 bytes
cartão: 142 91 bytes

As duas primeiras linhas da Tabela 5 se referem a ambas requisições do caracter


correto, 3, e as duas últimas mostram as requisições de um caracter incorreto, neste caso
o número 4. Observe que independente do lugar onde o número 4 se encontra no payload,
a resposta gerada tem o mesmo tamanho. Com esse fato, pode-se concluir que, visto que
as últimas duas requisições possuem o mesmo tamanho, independente de onde o número
4 se encontre, ele é um caracter incorreto, não fazendo parte da requisição.
Por outro lado, isso não é verdade quando a requisição é feita com o caracter
correto, tendo as respostas com tamanhos diferentes, variando de acordo com a posição
em que o número 3 se encontra. Assim, é possı́vel identificar que a primeira requisição
obteve um melhor resultado de compressão, ilustrando que aquele caracter está no lugar
correto.

7.1.6. Charset Pools

Este método, diferentemente dos dois anteriores, necessita de apenas uma requisição
para cada byte a ser tentado. Este, consiste em enviar na requisição todos os carac-
teres possı́veis depois de um padding. Neste exemplo, os caracteres do segredo são ape-

15
nas números, logo, após o payload teremos o padding e todos os caracteres do charset.
Seguindo o mesmo exemplo utilizado anteriormente, a Tabela 6 ilustra o método:

Table 6. Charset Pools


ENTRADA TAMANHO DA RESPOSTA
cartão: 122{}013456789 100 bytes
cartão: 123{}012456789 99 bytes
cartão: 124{}012356789 100 bytes

A lógica deste método consiste em transferir o caracter a ser tentado no payload


do charset completo para o lugar antes do padding e removendo-o do charset. Dessa
forma é esperado que o tamanho total da resposta seja reduzido apenas em casos onde o
algoritmo LZ77 seja responsável pela compressão. Em casos onde o caracter da vez não é
o correto, este será comprimido pelo Huffman Coding e, consequentemente, o tamanho da
resposta com esse caracter antes do padding ou dentro do charset não deverá apresentar
diferenças.

7.1.7. Mitigações

Após esta breve explicação do ataque criado pelos pesquisadores, é importante também
citar as possı́veis mitigações para este ataque e, antes de partirmos para a descrição de
cada mitigação, é relevante pontuar que a única solução realmente definitiva para este
problema é desabilitar a compressão do protocolo HTTP como um todo [14]. Porém,
como já detalhado anteriormente, a não utilização da compressão impactará diretamente
na performance da aplicação.
Além deste meio, uma outra opção seria introduzir um mecanismo para esconder
o tamanho da resposta retornada pelo servidor. Isto pode ser alcançado ao introduzir
dados aleatórios na resposta, de tamanhos variados, para forçar cada resposta a retornar
tamanhos distintos, mesmo apresentando um comportamento idêntico [14].
Uma outra recomendação seria separar entradas do usuário dos segredos da
aplicação. Apesar de efetivo, isso pode causar grandes dificuldades no funcionamento
da aplicação e requer uma reorganização desta, removendo todas entradas de dados do
usuário em funcionalidades que retornariam este dado espelhado juntamente com o seg-
redo [14]. A depender do tipo da aplicação web, este método pode ser impraticável visto
que seria necessária uma revisão da aplicação em busca de todos os pontos em que a
aplicação reflete a entrada do usuário em uma resposta que contém informações sensı́veis.
Além disso, estas modificações podem influir diretamente na usabilidade da aplicação, e
tudo isto deve ser levado em consideração no momento de implementar mitigações para
este ataque.
Por fim, mencionamos também que uma importante técnica de segurança a ser
seguida em toda e qualquer aplicação web a ser desenvolvida, é a segurança em camadas4 .
Através desta técnica, a aplicação dificulta a exploração para este, e outros, ataques, in-
serindo diversos bloqueios para que os atacantes precisem levar em consideração quando
4
Implementação de diversos mecanismos de segurança.

16
forem explorar o side-channel. Com isso, pontuamos que apesar da dificuldade de invi-
abilizar este ataque, é recomendado que a aplicação comporte diversas mitigações para
prover uma melhor segurança aos usuários contra este e outros ataques.

7.2. BEAST

Durante o evento de segurança Ekoparty de 2011, Duong e Rizzo [26] apresentaram suas
pesquisas que resultaram no ataque BEAST, um dos primeiros ataques que exploram o
side-channel da compressão na Internet. Este ataque foca em inferir o valor do cookie de
sessão atrelado à sua vı́tima após a autenticação bem sucedida. Em posse deste cookie o
atacante terá acesso a conta da vı́tima sem ter conhecimento de suas credenciais.
Para este ataque, é necessário que a aplicação faça uso do protocolo TLS 1.0
ou SSL 3.0, incluindo as versões mais antigas do SSL [18]. Também é necessário que
a aplicação suporte criptografia de blocos, o que é fácilmente encontrado visto que as
versões vulneráveis dos protocolos TLS e SSL dão preferência à este tipo de criptografia.
Assim como o BREACH, para a realização deste ataque, o atacante precisa realizar um
man-in-the-middle contra sua vı́tima, para garantir que terá a possibilidade de observar o
tamanho dos dados após compressão.
Uma vez que a vı́tima acesse a página maliciosa de controle do atacante, está será
responsável por capturar as informações dos cabeçalhos da requisição e consequente-
mente o cookie de sessão. Como estas informações estarão criptografadas pelo protocolo
SSL, ou TLS, estes dados capturados não poderão ser lidos pelo atacante. Para isso, o
atacante utiliza uma vulnerabilidade nestas versões especı́ficas do SSL/TLS para inferir
os dados cifrados.
O modo da criptografia de bloco utilizado é a chamada de CBC (Cipher Block
Chaining), este modo é utiliza um vetor de inicialização (Inicialization Vector – IV), um
valor aleatório a ser incluı́do no bloco para que o resultado da criptografia não seja pre-
visı́vel. Porém, a medida que a comunicação faz-se necessário a concatenação de novos
blocos, a partir do segundo bloco, o vetor de inicialização é substituı́do pelo resultado da
criptografia do seu bloco anterior, fazendo com que todo e qualquer bloco subsequente da
cadeia, tenha um valor único e, aparentemente, aleatório [5].
Com as informações já conhecidas pelo atacante como o vetor de inicialização e as
informações depois de criptografadas, o atacante poderia realizar um ataque de força bruta
no bloco criptografado inteiro, porém, dada a alta quantidade de combinações possı́veis
para um bloco de 16 bytes, por exemplo, isto não seria viável. Porém, os autores pro-
puseram uma alternativa de inferir os dados em texto plano de maneira mais simples do
que inferir o bloco como um todo.
O ataque BEAST faz com que o atacante precise realizer um ataque de força
bruta em apenas um byte por vez. Isto é possı́vel enquanto o atacante forneça quaisquer
informações visto que este tem o poder de modificar as requisições de sua vı́tima. Com
isso, o atacante pode forçar que o caracter a ser descoberto seja o último byte do bloco,
tendo todos os outros bytes anteriores em seu conhecimento visto que foram inclusos pelo
próprio atacante. Logo, o ataque de força bruta se resumo a um único caracter, ou byte,
por vez, reduzindo consideravelmente a quantidade de tentativas para descobrir o segredo
em questão [1].

17
Após o ataque ter se tornado público, a resolução para este já havia sido publicada
anos antes. O protocolo TLS versão 1.1 e 1.2 já existiam e para as aplicações que ainda
utilizavam uma versão legada deste protocolo, ou do seu antecessor SSL, bastava modi-
ficar seus serviços para comportar estas novas versões, impossibilitando este ataque por
completo [1].

7.3. CRIME
Os mesmos pesquisadores responsáveis pelo estudo e publicação do BEAST5 , realizaram
a apresentação do CRIME[27], Compression Ratio Info-leak Made Easy, apenas um ano
depois, na conferência de segurança Ekoparty do ano de 2012. Este ataque, é considerado
um dos propulsores da exploração do side-channel da compressão.
Os pesquisadores responsáveis pelo ataque, fazem menção ao trabalho produzido
por John Kelsey (2002) [17], como uma das referências base para o desenvolvimento do
CRIME. Isto nos mostra o quão atual, apesar de antigo, o trabalho de Jonh Kelsey se
mostra, podendo servir como insumo para diversos outros ataques que ainda podem ser
explorados.

7.3.1. Pré-requisitos

Este ataque se utiliza da compressão do protocolo TLS, protocolo este responsável pela
introdução de criptografia ao protocolo HTTP. O algoritmo de compressão utilizado pelo
TLS é o mesmo descrito anteriormente utilizado pelo HTTP, o DEFLATE. Além disso,
antes da atualização dos navegadores para a mitigação deste ataque, tanto o protocolo
SSL quanto o TLS deixavam expostos os tamanhos das requisições enviadas pelo cliente
e das respostas enviadas pelos servidores, permitindo que essa informação seja utilizada
como insumo para este ataque.
Assim como no BREACH, o CRIME também requer que a vı́tima acesse uma
aplicação web maliciosa, aplicação esta que será responsável por enviar requisições que
terão seus tamanhos analisados pelo atacante. O atacante pode realizar um ataque de
phishing[7] para sua vı́tima com o intuito de conseguir fazer com que esta acesse a página
maliciosa.

7.3.2. Metodologia do ataque

A exploração implementada por este ataque consiste na mesma lógica apresentada anteri-
ormente pelo seu sucessor BREACH. O atacante se aproveitará do side-channel criado a
partir do resultado do algoritmo LZ77 e precisará se antecipar a possı́veis compressões via
Huffman Coding que poderá influenciar diretamente no tamanho dos dados em tráfego.
Todavia, existe uma diferença na exploração do CRIME e do BREACH que é
crucial distinguir. Enquanto o BREACH analisa o tamanho das respostas enviada pelo
servidor para o cliente, o CRIME analisa o tamanho das requisições enviadas pelo cliente
5
Ataque precursor do CRIME. Este não será abordado neste trabalho visto que foge do escopo da
pesquisa.

18
com o intuito de exfiltrar cookies[23] de sessão do usuário e efetuar um sequestro de
sessão6 , por exemplo.
Observando o tamanho da requisição, o atacante irá enviar duas requisições para
cada payload, de forma similar ao Two-Tries Method do BREACH. A diferença entre
ambas requisições está no local onde o payload será enviado. Uma das requisições enviará
a tentativa dentro da janela de compressão enquanto a outra requisição enviará fora da
janela de compressão.
Se o tamanho da requisição, pós compressão, for o mesmo para ambas as
requisições, o atacante pode inferir que seu payload estava incorreto e que a compressão
foi realizada através do Huffman Coding, por outro lado, caso seja obtido um tamanho
distinto, observa-se que o payload enviado estava correto já que a compressão foi real-
izada pelo LZ77. Esta informação é suficiente para o atacante ir para o próximo byte a ser
exfiltrado.

7.3.3. Mitigações

Apesar de ter um impacto muito alto, a resolução para este ataque foi relativamente sim-
ples de se obter. No momento de apresentação do CRIME, os navegadores Mozila Firefox
e Google Chrome já possuı́am uma atualização [25] que desabilitava a compressão do
TLS, o que rapidamente reduziu a quantidade de navegadores vulneráveis a este ataque
para meros 7% do total dos navegadores.
Esta atualização foi fácil de ser implementada visto que os servidores já utilizavam
a compressão do protocolo HTTP, com isso, utilizar ambas compressões não resultava em
nenhuma redução do tamanho dos dados em tráfego. A desabilitação da compressão do
TLS apresentou apenas benefı́cios para os usuários e responsáveis por aplicações web,
visto que, a compressão do TLS não apresentava altos ı́ndices de compressão visto que o
protocolo HTTP já estava comprimindo os dados em uma camada anterior.

8. Conclusão
Apesar de termos exemplificado apenas poucos ataques que exploram o side-channel da
compressão, mais especificamente em cenários de utilização do protocolo HTTP, este tipo
de ataque se estende para diversos outros meios como por exemplo serviços de VPN (Vir-
tual Private Network). Dito isso, julgamos necessário trazer atenção para a possibilidade
de novos tipos de ataques serem desenvolvidos nos próximos anos, ataques estes que não
necessariamente serão publicados, pois atacantes mal intencionados podem manter estes
conhecimentos para benefı́cio próprio.
Assim como explanado por John Kelsey (2002) [17], acreditamos na possibilidade
de diversos outros protocolos e aplicações que façam uso tanto de compressão quanto de
criptografia na mesma ordem que foi citado anteriormente. Este autor, anos antes da
publicação de ambos CRIME [27] e BREACH [14], descreveu a metodologia de ambos
os ataques de forma teórica, prevendo a possibilidade da exploração do side-channel da
6
Sequestro de sessões é quando o atacante tem posse da sessão de sua vı́tima, podendo utilizar a
aplicação web se passando por sua vı́tima.

19
compressão. Apesar desta precisa previsão, o artigo não aborda especificamente os ca-
sos possivelmente exploráveis relacionado ao protocolo HTTP, deixando suas afirmações
levemente mais abrangentes.
Além disso, destacamos também que Juliano Rizzo e Thai Duong (2012) na
pesquisa do ataque CRIME [27] também fazem menções a diferentes protocolos e
aplicações que eles acreditam na possibilidade de serem vulneráveis a exploração do
side-channel mas que estes não foram testados por eles. Dentre essas suspeitas, os au-
tores citam protocolos como, por exemplo, o amplamente utilizado SSH que faz uso da
compressão durante sua comunicação.
Ademais, os responsáveis pelo CRIME, ao final de sua apresentação, apontam um
slide intitulado de ”We believe”, que pode ser traduzido diretamente para ”Nós acredita-
mos”. Neste ponto da apresentação, eles deixam claro suas suspeitas para uma variante
do próprio ataque CRIME que poderia ser explorado a nı́vel do protocolo HTTP, o que
poderia ser ainda mais problemático que o CRIME, visto a alta utilização da compressão
do HTTP quando comparado ao TLS. Esta suspeita, pode ser diretamente relacionada à
publicação do ataque BREACH que comprova as suspeitas apenas um ano depois.
Além de, comprovadamente, terem acertado em suas previsões sobre a com-
pressão do protocolo HTTP, também destacamos o momento onde a apresentação do
CRIME [27] cita a OpenVPN, solução de VPN, Virtual Private Network, amplamente
utilizada, como um ponto a ser estudado no futuro. Apesar de não ser um ataque ape-
nas contra o sistema da OpenVPN, o VORACLE [24] foi um ataque apresentado no ano
de 2018 contra túneis VPN como um todo. De maneira geral, o ataque consiste em se
aproveitar do side-channel da compressão utilizada no túnel VPN inteiro para inferir da-
dos em tráfego, de maneira análoga com os ataques previamente descritos. Sendo assim,
uma segunda previsão pelos autores (Juliano Rizzo e Thai Duon 2012), se comprova ver-
dadeira após seis anos.
Dito isso, seria imprudente da nossa parte se não deixassemos o mais claro
possı́vel a possibilidade de vermos mais ataques dessa natureza sendo publicados com
o passar do tempo. O acerto de algumas das previsões realizadas por Rizzo e Duong
(2012) e Kelsey (2002) apenas reforça na capacidade dos mesmos de estarem certos em
outras de suas previsões. Há uma alta probabilidade de que sejam realizadas melhorias
para os ataques já publicados, como foi alcançado pelo ataque HEIST [34] em 2016,
que possibilita a realização de ataques como CRIME e BREACH sem a necessidade do
Man-in-the-Middle.

9. Trabalhos futuros
Esta pesquisa focou em trazer luz para as possibilidades de vazamento de informação no
side-channel da compressão. Com os pontos explanados neste estudo, esperamos que
possamos dar continuidade nesta pesquisa em algumas maneiras diferentes e esperamos
que a comunidade de segurança possa também oferecer suas contribuições, dando con-
tinuidade a esta pesquisa.
Como já deixamos claro nas seções passadas, os ataques publicados nos últimos
anos em conjunto com as corretas previsões de diversos autores, acreditamos na pos-
sibilidade de novos ataques ou melhorias para ataques já existentes, continuem sendo
publicadas com o passar do tempo.

20
O protocolo SSH permite que o usuário utilize compressão juntamente com a
criptografia naturalmente utilizada pelo protocolo. Segundo a RFC do protocolo [35],
o metodo de compressão utilizado é o zlib [11] que também faz uso do LZ77. Para
começarmos o estudo neste protocolo e melhor entender o funcionamento do mesmo,
é imprescindı́vel o entendimento deste método de compressão. Apesar de não ser a
mesma explanada neste documento, sabe-se que a base permanece, logo, a curva de apren-
dizado para obter um conhecimento mı́nimo sobre esta forma de compressão não seria tão
ı́ngreme, considerando o conhecimento aqui mostrado.
Adicionalmente, o protocolo XMPP [28] também merece uma menção neste
estudo. Este protocolo possui algumas utilizações diferentes como por exemplo para
aplicações de Instant Messaging e Internet das coisas. O XMPP permite que o desen-
volvedor, caso deseje, comprimir os dados em tráfego, é obrigatório que a aplicação que
utilize compressão, implemente o zlib em ambas as pontas da comunicação.
Finalmente, também listamos o protocolo IMAP [10] como um dos protocolos que
merecem serem estudados com maior cautela. O IMAP é utilizado por clientes de e-mail
para requisitar os e-mails do usuário ao servidor responsável. Por padrão, o protocolo
já aceita o tráfego de mensagem comprimidas utilizando o algoritmo deflate [12] [10],
brevemente explicado anteriormente.
Por fim, importante pontuarmos que as possibilidades de estudos aqui listados, não
são certezas de que estão corretos nem errados. Apenas uma pesquisa aprofundada nos
protocolos de comunicação e nas aplicações que fazem uso poderá prover o conhecimento
da possibilidade de vazamentos de informação por conta da compressão de dados.

References
[1] Acunetix. What Is the BEAST Attack. maio 2020. URL: https : / / www .
acunetix . com / blog / web - security - zone / what - is - beast -
attack/.
[2] Salah Albermany and Fatima Radi. “Survey: Block cipher Methods”. In: 5 (Nov.
2016).
[3] Musbah Aqel et al. “Analysis of Stream Cipher Security Algorithm”. In: Journal
of Information and Computing Science 2 (Jan. 2007), pp. 288–298.
[4] Martin Armstrong. How Many Websites Are There? outubro 2019. URL: https:
//www.statista.com/chart/19058/how-many-websites-are-
there/.
[5] Zbigniew Banach. How the BEAST Attack Works. Jan. 2020. URL: https : / /
www . netsparker . com / blog / web - security / how - the - beast -
attack-works/.
[6] Tal Be’ery. A perfect CRIME? Only TIME will tell. Mar. 2013. URL: https :
//www.imperva.com/docs/adc/ADC_2013_A_Perfect_CRIME-
TIME_Will_Tell.pdf.
[7] Ivan Belcic. O que é phishing, exatamente? fevereiro 2020. URL: https://www.
avast.com/pt-br/c-phishing.
[8] Brasil. LEI Nº 13.709, DE 14 DE AGOSTO DE 2018. agosto 2018. URL: http:
/ / www . planalto . gov . br / ccivil _ 03 / _ato2015 - 2018 / 2018 /
lei/l13709.htm.

21
[9] Shuo Chen et al. “Side-Channel Leaks in Web Applications: a Reality Today, a
Challenge Tomorrow”. In: Proceedings of the IEEE Symposium on Security and
Privacy (Oakland). IEEE Computer Society, May 2010. URL: https://www.
microsoft.com/en-us/research/publication/side-channel-
leaks-in-web-applications-a-reality-today-a-challenge-
tomorrow/.
[10] M. Crispin. INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1. RFC
3501. RFC Editor, Mar. 2003. DOI: DOI10.17487/RFC3501. URL: https:
//tools.ietf.org/html/rfc3501.
[11] P. Deutsch and J-L. Gailly. ZLIB Compressed Data Format Specification version
3.3. RFC 1950. RFC Editor, maio 1996. DOI: DOI10.17487/RFC1950. URL:
https://tools.ietf.org/html/rfc1950.
[12] Peter Deutsch. DEFLATE Compressed Data Format Specification version 1.3. RFC
1951. RFC Editor, maio 1996. DOI: DOI10.17487/RFC1951. URL: https:
//tools.ietf.org/html/rfc1951.
[13] Daniel Genkin, Adi Shamir, and Eran Tromer. “RSA Key Extraction via Low-
Bandwidth Acoustic Cryptanalysis”. In: Advances in Cryptology – CRYPTO 2014.
Ed. by Juan A. Garay and Rosario Gennaro. Berlin, Heidelberg: Springer Berlin
Heidelberg, 2014, pp. 444–461. ISBN: 978-3-662-44371-2.
[14] Yoel Gluck, Neal Harris, and Angelo Prado. “BREACH: Reviving the CRIME At-
tack”. In: (July 2013). URL: http://breachattack.com/resources/
BREACH%20-%20SSL,%20gone%20in%2030%20seconds.pdf.
[15] D. A. Huffman. “A Method for the Construction of Minimum-Redundancy Codes”.
In: Proceedings of the IRE 40.9 (1952), pp. 1098–1101. DOI: 10 . 1109 /
JRPROC.1952.273898.
[16] Joseph Johnson. Number of internet users worldwide from 2005 to 2019. Nov.
2020. URL: https : / / www . statista . com / statistics / 273018 /
number-of-internet-users-worldwide/.
[17] John Kelsey. “Compression and Information Leakage of Plaintext”. In: Fast Soft-
ware Encryption, 9th International Workshop, FSE 2002, Leuven, Belgium, Febru-
ary 4-6, 2002, Revised Papers. Vol. 2365. Lecture Notes in Computer Science.
Springer, 2002, pp. 263–276. DOI: 10 . 1007 / 3 - 540 - 45661 - 9 _ 21. URL:
https://iacr.org/archive/fse2002/23650264/23650264.pdf.
[18] Ryan Mazerik. BEAST vs. CRIME Attack. outubro 2013. URL: https : / /
resources . infosecinstitute . com / topic / beast - vs - crime -
attack/.
[19] Microsoft. O que é o SaaS? abril 2021. URL: https://azure.microsoft.
com/pt-br/overview/what-is-saas/.
[20] Mozilla. Accept-Encoding. fevereiro 2021. URL: https : / / developer .
mozilla . org / en - US / docs / Web / HTTP / Headers / Accept -
Encoding.
[21] Mozilla. Accept-Encoding. fevereiro 2021. URL: https : / / developer .
mozilla.org/en-US/docs/Web/HTTP/Headers/User-Agent.
[22] Mozilla. Compression in HTTP. fevereiro 2021. URL: https://developer.
mozilla.org/en-US/docs/Web/HTTP/Compression.

22
[23] Mozilla. Using HTTP cookies. Mar. 2021. URL: https : / / developer .
mozilla.org/en-US/docs/Web/HTTP/Cookies.
[24] OpenVPN. The VORACLE attack vulnerability. abril 2021. URL: https : / /
openvpn . net / security - advisory / the - voracle - attack -
vulnerability/.
[25] Ivan Ristic. CRIME: Information Leakage Attack against SSL/TLS. setembro 2012.
URL: https://blog.qualys.com/product- tech/2012/09/14/
crime-information-leakage-attack-against-ssltls.
[26] Juliano Rizzo and Thai Duong. BEAST. setembro 2011. URL: https : / /
vnhacker.blogspot.com/2011/09/beast.html.
[27] Juliano Rizzo and Thai Duong. “The CRIME Attack”. In: (setembro 2012). URL:
http://netifera.com/research/crime/CRIME_ekoparty2012.
pdf.
[28] P. Saint-Andre. Extensible Messaging and Presence Protocol (XMPP): Core. RFC
6120. RFC Editor, Mar. 2011. DOI: DOI10.17487/RFC6120. URL: https:
//tools.ietf.org/html/rfc6120.
[29] Amazon Web Services. Amazon S3 pricing. abril 2021. URL: https://aws.
amazon.com/s3/pricing/.
[30] Ilia Shumailov et al. “Hearing your touch: A new acoustic side channel on smart-
phones”. In: CoRR abs/1903.11137 (2019). arXiv: 1903.11137. URL: http:
//arxiv.org/abs/1903.11137.
[31] Manjari Singh et al. “Various Image Compression Techniques: Lossy and Loss-
less”. In: International Journal of Computer Applications 142 (maio 2016), pp. 23–
26. DOI: 10.5120/ijca2016909829.
[32] François-Xavier Standaert. “Introduction to Side-Channel Attacks”. In: dezembro
2010, pp. 27–42. ISBN: 978-0-387-71827-9. DOI: 10 . 1007 / 978 - 0 - 387 -
71829-3_2.
[33] SSL Support Team. What is SSL? outubro 2019. URL: https://www.ssl.
com/faqs/faq-what-is-ssl/.
[34] Mathy Vanhoef and Tom Van Goethem. “Lossless and Lossy Data Compres-
sion”. In: (July 2016). URL: https : / / tom . vg / papers / heist _
blackhat2016.pdf.
[35] T. Ylonen and C. Lonvick. The Secure Shell (SSH) Transport Layer Protocol. RFC
4253. RFC Editor, Jan. 2006. DOI: DOI10.17487/RFC4253. URL: https:
//tools.ietf.org/html/rfc6120.
[36] Jacob Ziv and Abraham Lempel. “A Universal Algorithm for Sequential Data
Compression”. In: IEEE Transactions on Information Theory 23.3 (maio 1977),
pp. 337–343.

23

Você também pode gostar