Início > Blog > Ataques de canal lateral contra aplicações web

Ataques de canal lateral contra aplicações web

O que são e como se proteger

03 de Dec 2019

Alto Constraste

Aumentar fonte

Diminuir fonte

Por: Eduardo Vasconcelos

Introdução

O propósito desse artigo é informar o leitor a respeito de ataques de canal lateral, em especial, ataques baseados em aferição de delta temporal de resposta contra aplicações web. De forma muito breve, o leitor é exposto ao modelo de segurança de uma aplicação e à definição de “canal lateral”. Em seguida, uma visita à metodologia de ataque de aferição de delta temporal contra aplicações web é apresentada. Finalmente, uma possível contramedida a esse tipo de ataque, por parte de engenheiros de software, é discutida.

Modelo de Segurança de Aplicações

Uma aplicação qualquer se comunica com o mundo externo através de canais de entrada/saída projetados para essa finalidade. Por exemplo, podemos pensar em uma aplicação web que se comunica com o usuário através de uma interface no browser e com um banco de dados hospedado em um servidor externo como se ela tivesse dois canais de comunicação: um com o usuário que a acessa usando o browser, através do protocolo HTTP, e outro com o banco de dados que ela utiliza, através de um protocolo baseado em SQL. Esses canais de entrada/saída são chamados de “fronteiras de confiança” (de security boundaries), para denotar que a aplicação não pode “confiar”, a priori, em nada que venha do mundo externo (entrada). Da mesma forma, a aplicação deve tomar cuidado com o que ela externaliza (saída), de forma a evitar retornar em suas saídas informação que ela não deveria. Ao conjunto de todas as fronteiras de confiança de uma aplicação se dá o nome de “superfície de ataque” (de attack surface). Portanto, para se proteger de ataques, a aplicação deve ser capaz de reconhecer entradas maliciosas, de forma a tomar a providência defensiva aplicável (por exemplo, parar de aceitar entradas do IP de onde partiu a entrada maliciosa, criar uma linha de log para  o evento ocorrido, bloquear a conta de usuário associada à entrada, etc.) Ademais, a aplicação deve evitar, a todo custo, retornar como saída informação que possa trazer benefícios a um adversário que tenha provido entradas maliciosas. Assim, durante o projeto de uma aplicação, é preciso que os engenheiros de software encarregados conheçam muito bem todas as fronteiras de confiança que compõem a superfície de ataque da aplicação desenvolvida, para que sejam capazes de protegê-la de entidades maliciosas. O problema é que é possível que algumas fronteiras de confiança, muitas vezes bastante sutis, passem despercebidas durante o projeto da aplicação, resultando em algumas possibilidades de ataque. Essas fronteiras de confiança “esquecidas”, que correspondem a canais de comunicação não mapeados no modelo da aplicação durante o projeto, recebem o nome de “canais lateriais” e podem ser explorados por entidades maliciosas em ataques homônimos, os chamados “ataques de canal lateral”. A figura a seguir resume os conceitos introduzidos até esse ponto.  

Figura 1 – Modelo de segurança de uma aplicação genérica

Canais Laterais

Usando a definição provida anteriormente, podemos agora listar três dos canais laterais considerados mais comuns, encontrados em aplicações e dispositivos de diversos tipos:

  • Radiação eletromagnética;
  • Consumo de potência;
  • Tempo para executar operações.

Os dois primeiros canais laterais listados acima são comumente usados para atacar hardware. Grosseiramente, utilizam equipamentos especiais para medir a radiação eletromagnética emitida ou a potência consumida por dispositivos, de forma a extrair deles informação sensível passível de aproveitamento por parte do adversário (por exemplo, chaves criptográficas). Ambos exigem que o adversário tenha acesso ou proximidade física ao computador ou ao dispositivo atacado e, normalmente, são ataques “caros”, por exigirem equipamentos especializados bastante precisos. O terceiro tipo de canal lateral, tempo para executar operações, por outro lado, não necesariamente exige acesso físico ao dispositivo atacado e é perfeitamente aplicável a aplicações web, o tipo de sistema discutido nesse artigo. Ataques de canal lateral baseados em tempo contra aplicações web se baseiam na aferição do tempo que a aplicação leva para executar operações específicas, desencadeadas por entradas cuidadosamente construídas pelo adversário, para o propósito de extrair a informação sensível que ele deseja. O grande desafio de atacar aplicações web usando essa estratégia é que o canal lateral em questão é inerentemente ruidoso. Imagine só: uma vez disparada uma requisição à aplicação web, é difícil saber quanto do delta temporal até o recebimento da resposta se deve unicamente à demora da aplicação para responder e quanto se deve a fatores relacionados aos atrasos de roteamento entre o adversário e a aplicação atacada. Há muitos eventos imprevisíveis que podem atrapalhar a precisão de medida exigida para um ataque desse tipo. Entretanto, existem técnicas que combinam conhecimento estatístico e conhecimento sobre a maneira como os browsers modernos se comportam que podem atenuar, ou mesmo anular, os efeitos de ruído esperados na aferição de tempo em ataques de canal lateral contra aplicações web. As técnicas em questão fogem ao escopo informativo desse artigo. Na seção seguinte, a metodologia de ataque de canal lateral baseado em aferição de tempo contra uma aplicação web é superficialmente apresentada.

Introdução à Metodologia de Ataque

  1. De forma a extrairmos informação de uma aplicação web usando aferição de tempo, antes de qualquer coisa, devemos nos fazer uma pergunta binária, isto é, uma pergunta que possa ser respondida com “Sim” ou “Não”. Por exemplo, “O usuário está autenticado na aplicação?”
  2. O próximo passo é “traduzir” essa pergunta de forma que a aplicação possa entendê-la, isto é, formulá-la como um request à aplicação. Por exemplo, de forma a descobrir se um usuário está autenticado na aplicação, poderíamos requisitar a página de perfil de usuário. Se a resposta à nossa perguntar for afirmativa, então a aplicação web deverá retornar a página de perfil. Por outro lado, se a resposta à pergunta for negativa, então a aplicação web irá retornar alguma outra coisa que não a página de perfil do usuário. Chamaremos essa requisição de “Request A”.
  3. Em seguida, precisamos de outra requisição, cujo tempo de resposta iremos comparar com o do “Request A”. Essa requisição pode ser, por exemplo, um request a uma página inválida da aplicação, para o qual a aplicação responderá com HTTP 404. Chamaremos essa requisição de “Request B”. Com essa requisição extra, poderemos atenuar os efeitos de ruído de canal, conforme o procedimento descrito no próximo passo.
  4. Finalmente, fazemos as duas requisições à aplicação – usando uma estratégia que não vêm ao caso nesse artigo – e, em seguida, comparamos os tempos de resposta de ambas. Se pudermos identificar diferença estatisticamente significativa entre os tempos aferidos (por exemplo, se verificarmos que o Request A leva em torno de 1000 ms para retornar e o Request B leva algo em torno de 300 ms), então podemos afirmar com certo grau de segurança que a aplicação está carregando mais dados para o “Request A” do que para o “Request B”, o que é um indicativo de que “Sim, o usuário está autenticado na aplicação.”

Obviamente, de forma a conduzir o ataque com sucesso, o adversário deve ser capaz de executar os passos acima no contexto da vítima alvejada, isto é, a partir do browser da vítima. Obviamente, diversos detalhes de execução foram omitidos nos parágrafos acima. Entretanto, o processo ilustrado provê uma ideia bastante razoável da metodologia básica de um ataque via canal lateral usando aferição temporal contra aplicações web. A figura a seguir ilustra o processo.  

Figura 2 – Processo simplificado de ataque de canal lateral usando aferição de delta temporal

Como se prevenir?

Diversos padrões de desenvolvimento seguro existem para auxiliar engenheiros de software a implementarem contramedidas a ataques de canal lateral. Para o caso específico de ataques baseados em aferição de tempo de resposta contra aplicações web, recomenda-se a introdução de atrasos com duração aleatória quando do retorno de uma resposta ao cliente. A introdução sistemática de ruído por parte da aplicação dificulta bastante o uso das técnicas estatísticas necessárias à execução desse tipo de ataque. Entretanto, abusos na utilização desse desse recurso podem levar a quedas indesejadas (e até desnecessárias) de desempenho da aplicação. Por isso, é impossível prescrever tal contramedida a aplicações de uma maneira genérica. Como regra geral, não se ganha em segurança sem prejudicar outros aspectos importantes de um projeto de software (e vice-versa). Assim, antes de implementá-la, é necessário avaliar os ganhos e as perdas esperados após a sua adoção para cada aplicação em particular.