05 de FEVEREIRO
Entender o conceito de "Superfície de Ataque" não é necessário apenas aos Analistas de Segurança, que executam testes e buscam corrigir brechas na segurança de terceiros. O correto entendimento deste termo pode auxiliar até mesmo profissionais de empresas que não possuem um setor de segurança da informação e buscam serviços terceirizados de segurança, seja este qual for.
Em seu conceito mais amplo, a Superfície de Ataque envolve todas as portas de entrada que um atacante pode utilizar para comprometer a segurança da informação. Chamamos estas portas de entrada de "vetores de ataque" e a maneira com que um atacante se aproveita delas de "vulnerabilidade". Vamos entender cada conceito separadamente para fazer sentido quando colocados em conjunto.
Vetor de ataque
Um vetor de ataque é simplesmente uma porta de entrada para que um atacante possa comprometer a aplicação em que fixou seu alvo. Em cada possível ponto de entrada, um atacante irá buscar por formas de alterar o comportamento padrão ao qual o sistema foi construído para tirar proveito e assumir o controle do mesmo.
Inclusive, um vetor de ataque pode possuir outros vetores de ataque dentro dele. Na fase inicial de um ataque, o usuário malicioso busca informações iniciais da empresa, descobrindo quais aplicações podem ser utilizadas como porta de entrada. Nesta fase, cada aplicação é um vetor de ataque a ser enumerado. Na fase seguinte, o atacante começa a fazer o mapeamento das aplicações que encontrou, identificando vetores de ataque mais específicos, para dentro destes encontrar outros vetores ainda mais específicos, e assim subsequentemente, até encontrar algum vetor que possua uma falha e possa ser valioso para sua exploração.
É importante destacar que um vetor de ataque pode ser desde um parâmetro presente na URL, uma informação que é enviada ao servidor, um cookie de sessão que não é corretamente tratado pela aplicação, ou até mesmo uma informação sensível disponível na página da empresa. Para um vetor de ataque ser utilizado por um atacante, é importante que este esteja ligado a algum tipo de vulnerabilidade.
Vulnerabilidade
Uma vulnerabilidade é simplesmente uma fraqueza que o sistema em questão possui. Não existe uma receita de bolo para corrigir e nem para explorar vulnerabilidades, elas acontecem de diferentes formas e devem ser tratadas de diferentes maneiras.
Para ilustrar como é complexo trabalhar com vulnerabilidades, veja alguns exemplos:
Em seu conceito mais amplo, a Superfície de Ataque envolve todas as portas de entrada que um atacante pode utilizar para comprometer a segurança da informação. Chamamos estas portas de entrada de "vetores de ataque" e a maneira com que um atacante se aproveita delas de "vulnerabilidade". Vamos entender cada conceito separadamente para fazer sentido quando colocados em conjunto.
Vetor de ataque
Um vetor de ataque é simplesmente uma porta de entrada para que um atacante possa comprometer a aplicação em que fixou seu alvo. Em cada possível ponto de entrada, um atacante irá buscar por formas de alterar o comportamento padrão ao qual o sistema foi construído para tirar proveito e assumir o controle do mesmo.
Inclusive, um vetor de ataque pode possuir outros vetores de ataque dentro dele. Na fase inicial de um ataque, o usuário malicioso busca informações iniciais da empresa, descobrindo quais aplicações podem ser utilizadas como porta de entrada. Nesta fase, cada aplicação é um vetor de ataque a ser enumerado. Na fase seguinte, o atacante começa a fazer o mapeamento das aplicações que encontrou, identificando vetores de ataque mais específicos, para dentro destes encontrar outros vetores ainda mais específicos, e assim subsequentemente, até encontrar algum vetor que possua uma falha e possa ser valioso para sua exploração.
É importante destacar que um vetor de ataque pode ser desde um parâmetro presente na URL, uma informação que é enviada ao servidor, um cookie de sessão que não é corretamente tratado pela aplicação, ou até mesmo uma informação sensível disponível na página da empresa. Para um vetor de ataque ser utilizado por um atacante, é importante que este esteja ligado a algum tipo de vulnerabilidade.
Vulnerabilidade
Uma vulnerabilidade é simplesmente uma fraqueza que o sistema em questão possui. Não existe uma receita de bolo para corrigir e nem para explorar vulnerabilidades, elas acontecem de diferentes formas e devem ser tratadas de diferentes maneiras.
Para ilustrar como é complexo trabalhar com vulnerabilidades, veja alguns exemplos:
- SQL Injection: Vulnerabilidade que acontece principalmente em sistemas web, permitindo que um atacante manipule instruções passadas ao banco de dados. Para sua mitigação, é necessário sanitizar o input do usuário antes de enviá-lo ao banco de dados.
- Uso de Software desatualizado: a atualização periódica de softwares utilizados em produção pode ser custosa, porém a instalação de patches pode corrigir vulnerabilidades conhecidas e que possuem formas de exploração (exploits) públicas. Um exemplo clássico é a exploração da CVE-2011-2523, que aproveita uma falha no vsftpd versão 2.3.4 (software usado para transferência de arquivos através do protocolo FTP) em que, ao ser explorada, abre uma conexão via shell, permitindo ao atacante interação direta com o sistema operacional.
- Falhas na lógica de negócio: são falhas que não exigem um conhecimento técnico tão apurado, porém podem se tornar catastróficas de acordo com o contexto em que aparecem. São falhas nos fluxos dos processos executados por uma aplicação ou usuário. Um local comum de ocorrer este tipo de vulnerabilidade é em formulários de login, em que, por exemplo, a recuperação de senha segue um processo que pode ser alterado por um usuário malicioso durante sua execução, permitindo que este modifique a senha de um usuário legítimo sem qualquer conhecimento prévio de suas credenciais.
- Phishing: E para demonstrar que não são só sistemas e processos que possuem vulnerabilidades, o phishing aparece para explorar a falha no fator humano. Um usuário descuidado pode acessar um link malicioso, fazer download de um anexo suspeito, ou até mesmo informar suas credenciais em uma página falsa. Estas ações podem comprometer toda a segurança de uma empresa.
Somente com estes quatro exemplos podemos ver que ao mesmo tempo em que devemos nos preocupar com o código da nossa aplicação, também devemos deixar os softwares que são utilizados sempre atualizados, além de treinar nossos colaboradores para que tenham maturidade suficiente em segurança da informação para não realizarem ações que comprometam a segurança através de engenharia social.
De volta para a superfície de ataque
Ao entender que vulnerabilidades acontecem em sistemas, processos e pessoas, podemos ter uma noção do quão difícil é mapear e, principalmente, conter os ataques aos nossos sistemas. Conforme nossas empresas vão crescendo, maior é a necessidade de termos visibilidade, disponibilizando nossos serviços na internet e, consequentemente, aumentando nossa superfície de ataque.
Entretanto, a especificidade de uma aplicação acaba por diminuir os vetores de ataque. Imagine dois sistemas da mesma empresa:
De volta para a superfície de ataque
Ao entender que vulnerabilidades acontecem em sistemas, processos e pessoas, podemos ter uma noção do quão difícil é mapear e, principalmente, conter os ataques aos nossos sistemas. Conforme nossas empresas vão crescendo, maior é a necessidade de termos visibilidade, disponibilizando nossos serviços na internet e, consequentemente, aumentando nossa superfície de ataque.
Entretanto, a especificidade de uma aplicação acaba por diminuir os vetores de ataque. Imagine dois sistemas da mesma empresa:
- O primeiro é um sistema de emissão de boletos. Para emitir um boleto, o usuário deve informar o número da Nota Fiscal referente ao boleto, data da emissão da Nota, e também o CNPJ ou CPF com o qual realizou sua compra. Se os dados estiverem corretos, conforme o que consta na base de dados da empresa, o boleto é emitido. Se os dados não forem condizentes, a aplicação impede que este usuário realize novas consultas por um determinado tempo.
- O segundo sistema é um portal em que a empresa divulga suas notícias, permitindo com que usuários possam criar um login e uma senha para interagir nas postagens, fazer networking, enviar críticas e sugestões, entre outras funções, do mesmo modo como funciona uma rede social, porém de uso único dos colaboradores.
Em uma rápida análise, em cada uma das aplicações podemos tirar algumas conclusões. A primeira aplicação possui uma superfície de ataque muito menor do que a segunda, afinal, a aplicação solicita três dados, e os três dados precisam estar corretos para que o boleto seja emitido. Já na segunda aplicação, podemos pensar em vetores de ataque como: campo de login/senha, criação de postagem, comentário desta postagem, mensagem à um colaborador, envio de sugestão e todas as outras funcionalidades que a aplicação possa oferecer.
É notável também que na primeira aplicação o desenvolvedor possui poucos campos de interação do usuário, tornando assim a implementação de desenvolvimento seguro muito mais fácil do que na segunda aplicação. De nenhuma forma a preocupação com a segurança nesta aplicação deve ser negligenciada por conter uma superfície de ataque pequena, afinal, os dados retornados por ela podem ter uma sensibilidade alta, visto que podem ser usados para aplicação de golpes financeiros.
No nosso segundo exemplo, uma forma comum de diminuir a superfície de ataque é implementar uma boa tela de login, impedindo que usuários não-autenticados possam interagir de qualquer forma com a aplicação. É importante que as boas práticas no desenvolvimento sejam seguidas, e que todas as funções da aplicação sejam executadas se, e somente se, o usuário possuir um token de autenticação válido. Com isso, a superfície de ataque da aplicação acaba por restringir-se apenas ao formulário de login.
O conhecimento da própria superfície de ataque é vital para que tenhamos um bom nível de segurança em nossa organização. Muito embora seja possível realizar testes de intrusão (pentests) para avaliar a segurança de nossa organização, é importante ter em mente que esta não é a "bala de prata" que irá identificar todas as vulnerabilidades presentes em nosso ambiente. Se não possuirmos o conhecimento das informações e sistemas que temos expostos, muito provavelmente teremos portas de entrada que não conhecemos, mas que um atacante está disposto à direcionar seus esforços para o comprometimento da nossa segurança.
É notável também que na primeira aplicação o desenvolvedor possui poucos campos de interação do usuário, tornando assim a implementação de desenvolvimento seguro muito mais fácil do que na segunda aplicação. De nenhuma forma a preocupação com a segurança nesta aplicação deve ser negligenciada por conter uma superfície de ataque pequena, afinal, os dados retornados por ela podem ter uma sensibilidade alta, visto que podem ser usados para aplicação de golpes financeiros.
No nosso segundo exemplo, uma forma comum de diminuir a superfície de ataque é implementar uma boa tela de login, impedindo que usuários não-autenticados possam interagir de qualquer forma com a aplicação. É importante que as boas práticas no desenvolvimento sejam seguidas, e que todas as funções da aplicação sejam executadas se, e somente se, o usuário possuir um token de autenticação válido. Com isso, a superfície de ataque da aplicação acaba por restringir-se apenas ao formulário de login.
O conhecimento da própria superfície de ataque é vital para que tenhamos um bom nível de segurança em nossa organização. Muito embora seja possível realizar testes de intrusão (pentests) para avaliar a segurança de nossa organização, é importante ter em mente que esta não é a "bala de prata" que irá identificar todas as vulnerabilidades presentes em nosso ambiente. Se não possuirmos o conhecimento das informações e sistemas que temos expostos, muito provavelmente teremos portas de entrada que não conhecemos, mas que um atacante está disposto à direcionar seus esforços para o comprometimento da nossa segurança.
