Criar produtos impactantes e que influenciam positivamente a vida de quem os utiliza não é uma tarefa fácil. Vivemos uma realidade em que os sistemas de software estão cada vez mais complexos, interconectados, e com capacidades cada vez maiores de extração de dados analíticos, pessoais e de fornecimento a inúmeros outros serviços.
Cuidar apropriadamente de todo esse cenário sob o viés de segurança da informação é uma maneira essencial de garantir o sucesso dessas aplicações, mas esse cuidado só é possível através da total visibilidade da superfície desse “ecossistema” digital.
O objetivo deste artigo é introduzir o conceito de “Superfície de Ataque”, explicar os passos básicos de implementação do que chamamos de ASI , “Attack Surface Intelligence”, bem como dar algumas dicas de como identificar pontos ocultos no mapeamento dessa superfície em aplicações.
O que você vai conferir:
Afinal, o que é Superfície de Ataque e o que é ASI?
Há um bom tempo que o termo “superfície de ataque” é entendido, na comunidade de segurança da informação, como uma medida de exposição de um sistema. Para ser um pouco mais descritivo, essa superfície é um conjunto de recursos digitais e físicos que interage com sistemas externos e que, por estar exposto, potencialmente apresenta vulnerabilidades.
Exemplo de superfície de ataque de uma empresa
Já quando expandimos esse conceito para o ambiente empresarial, pensar nessas portas de entrada como sendo apenas as dos produtos que a empresa desenvolve, nos leva a subestimar a amplitude da superfície de ataque exposta.
O processo de identificação e descoberta da superfície se torna muito mais complexo nesse ambiente, sendo necessário identificar todos os ativos da infraestrutura da empresa e saber como eles estão interconectados entre si, com parceiros e com outras redes.
Além disso, é necessário saber quem é responsável por cada ativo, em quais processos da empresa eles estão sendo utilizados e qual é a criticidade desses ativos caso sejam explorados. No final, o que já parece ser uma tarefa complexa se torna ainda mais quando sabemos que podem existir “pontos ocultos” na superfície que podem ser críticos para a empresa.
É dessa complexidade que surgiu o que chamamos de “Inteligência de Superfície de Ataque” (Attack Surface Intelligence), a ASI, no inglês, uma série de etapas que une boas práticas de segurança a conceitos de Threat Intelligence no processo de identificação e monitoria de uma superfície de ataque.
Etapas de uma ASI
O processo de uma ASI é organizado em quatro etapas que devem ser repetidas continuamente, de maneira a garantir boas práticas de segurança na visibilidade da superfície de ataque. O que chamamos de “Inteligência” nesse processo é a combinação da definição de “Superfície de Ataque” com os conceitos de “Inteligência Cibernética” (tema este bem abordado pela Daniele Ferreira também neste blog), resultando em um olhar sistemático e focado em associar qualquer tipo de risco aos ativos da empresa. As etapas da ASI são:
1. Descoberta
Esta etapa, também conhecida como “Mapeamento”, é talvez a mais complexa e a que mais demanda esforços de quem a executa. Ela exige que pensemos nos ativos não só como dispositivos físicos (como notebooks, servidores, e afins) e sistemas de software, mas também como uma rede de interconexões que forma a digital do ecossistema da empresa. Segundo publicado em um whitepaper da Cycognito, um inventário de ativos completo deve considerar, além dos ativos de sistemas, infraestrutura e recursos da nuvem, as seguintes categorias:
Ativos não administrados
Esses ativos são, como o próprio nome sugere, os não administrados pela empresa. Geralmente são os recursos de nuvem ou aplicações contratadas pela empresa, como os IaaS, PaaS, SaaS, as ferramentas com conectividade a algum produto da empresa e a soluções de parceiros.
Ativos abandonados
Essa categoria contempla aplicações na nuvem, repositórios de código fonte, ferramentas de desenvolvimento, certificados digitais, dentre outros, que já não estão mais em uso e que não foram devidamente desativados.
Ativos desconhecidos
Os ativos desconhecidos se relacionam ao conceito de “Shadow IT” e representam os sistemas e dispositivos utilizados sem o conhecimento do departamento de TI e que, consequentemente, não são rastreados, descobertos e assegurados pelas ferramentas utilizadas
Ativos mal configurados
Qualquer ativo utilizando credenciais padrão em seus serviços, ou com logins/parâmetros não configurados propriamente se encaixam nessa categoria. Os ativos aqui se tornam uma porta de entrada ainda mais vulnerável quando se tratam de sistemas legados, por exemplo.
Sabendo agora desses tipos de ativos, obviamente é necessário obter as informações sobre o inventário. Para obter essas informações, uma série de scans devem ser realizadas considerando quais são os domínios e subdomínios dos serviços.
Para cada um deles, informações que incluem resoluções de IPs, registros de DNS, portas abertas, conexões com APIs de terceiros, dentre outras coisas, devem ser coletadas. E não podemos nos esquecer das diversas informações que podem ser coletadas com OSINT, como nome, endereços de e-mail e redes sociais dos funcionários da empresa, histórico de máquinas comprometidas, afiliações da empresa, informações sobre a rede interna e sobre a infraestrutura de nuvem, metadados de documentos e imagens divulgadas, quais são os provedores de serviços de nuvem utilizados, as aplicações mobile disponíveis, e tantas outras coisas.
Mesmo levando em consideração todos esses pontos, ainda assim os ativos estão sujeitos a pontos ocultos que podem ser explorados, e darei exemplo de um deles, mas voltado a aplicações que utilizam HTTP, em uma próxima seção.
Fica bem claro que essa etapa é bastante custosa, requer muita organização, e que é bastante difícil obter todos esses dados utilizando uma única ferramenta, mas a boa notícia é que existem fontes de código aberto que facilitam essa obtenção e que, se aliadas a processos automatizados, auxiliarão a equipe no mapeamento da superfície de ataque.
Dentre as ferramentas que auxiliam a obtenção de domínios, subdomínios e suas informações, são amplamente utilizadas: OWASP Amass, Sublert, p0f, nmap e DNSRecon. Para a obtenção de OSINT e de outros tipos de inteligência, as ferramentas theHarvester, Shodan, Spiderfoot e o próprio Google (Dorking) podem ser utilizados. Recomendo um artigo bem legal sobre o assunto, disponível em “Attack Surface Monitoring using Open-Source Intelligence”, que mostra o quão complexo é a obtenção desse tipo de informação.
2. Análise e Priorização
A etapa de Descoberta, apesar de complexa, nos permite abordar a ASI com uma perspectiva de aprendizado, podendo mapear os ativos e suas informações necessárias. Agora, para uma boa manutenção desses ativos, devemos responder às seguintes perguntas: quão importante é e quais são os riscos envolvidos em cada ativo?
Para responder às perguntas, é necessário fazer uma avaliação de risco de cada um dos ativos baseado nos dados mapeados. Por exemplo, ativos que tratam de dados pessoais e sensíveis devem ser priorizados em relação aos que não processam esse tipo de informação. Também é necessário saber a quais tipos de ameaças um ativo está vulnerável através de técnicas de Inteligência de Ameaças e identificar as ameaças ativas.
3. Monitoramento
Monitorar os riscos e vulnerabilidades de cada ativo é uma das tarefas mais importantes da ASI, e para isso, as etapas anteriores devem ser executadas repetidamente para garantir que novos ativos estão sendo descoberto e analisados.
A etapa de monitoria representa a maneira como os alertas são gerados e como estão sendo tratadas as vulnerabilidades encontradas, seja através de um sistema de tickets ou através do SIEM implementado na empresa.
4. Remediação
A remediação de cada risco encontrado é o objetivo final desse processo de inteligência desenvolvido. Depois de analisados e resolvidos um a um, as soluções para cada risco encontrado devem ser reportadas, complementando a etapa de monitoramento. As métricas geradas nas remediações também podem contribuir para futuras automatizações na resolução de casos similares. É nessa etapa que uma equipe de TI, por exemplo, também pode decidir por assumir um risco, mas detalhando sempre os motivos pelos quais chegaram a essa decisão.
Considerando as etapas supracitadas, o procedimento de inteligência implementado permite que a empresa tenha uma visão mais completa de como um atacante externo analisa as fraquezas que ela possui. Também providencia uma forma de reduzir, com o tempo, os números de portas abertas que podem ser exploradas em sua superfície de ataque, cobrindo os riscos presentes em diversas áreas, como exposição da marca, más configurações de serviços, vulnerabilidades encontradas, possíveis ameaças, e tantas outras coisas.
Identificando pontos ocultos na superfície
A etapa de descoberta da superfície de ataque pode ser muitas vezes traiçoeira, isso porque geralmente, não procuramos por aquilo que não conhecemos e as “passagens secretas” estão, como o nome sugere, ocultas ou encobertas.
Além disso, esses pontos ocultos estão relacionados ao tipo de aplicação ou ativo disponível, o que os torna ainda mais difíceis de serem encontrados. Nesta seção vou dar um exemplo de ponto oculto na superfície de ataque, mas agora especificamente no contexto de aplicações HTTP, baseado no que foi apresentado na conferência “Black Hat – USA 2017“ por James Kettle.
Nessa palestra, o autor se utilizou de requisições HTTP malformadas e alguns headers e payloads um tanto “exotéricos”, como ele mesmo classifica, para explorar sistemas mal configurados. Nesse exemplo, observamos o que Kettle chamou de “Quebrando expectativas“, o código de uma certa empresa estava configurado para que a URL fornecida pelo usuário fosse substituída pelo endereço hard-coded do back-end do servidor.
Apesar de uma biblioteca do Apache retornar erro para caminhos não iniciados em “/“ na requisição, ele conseguiu obter acesso a informações internas sobre a empresa, incluindo acesso não autenticado a painéis de administrador, apenas fazendo a seguinte requisição:
GET @burp-collaborator.net/ HTTP/1.1
Host: empresa-vulneravel.com
Connection: close
Devido à configuração do servidor, essa requisição foi interpretada como sendo http://backend-da-empresa@burp-collaborator.net/, roteando a request realizada para o burp obtendo acesso às informações internas. É claro que, para explorar essa vulnerabilidade, diversas outras configurações foram realizadas, mas você pode analisá-las com mais detalhes em https://portswigger.net/research/cracking-the-lens-targeting-https-hidden-attack-surface.
Por que é importante ter visibilidade da Superfície de Ataque?
Ter total visibilidade da superfície de ataque faz com que a maturidade de segurança de sua empresa seja aprimorada, provendo o contexto necessário para entender quais operações e ativos serão impactados em caso de um ataque bem sucedido. Essa visibilidade pode ser constantemente melhorada através da ASI, aliada a ferramentas automatizadas, mas a atenção deve ser redobrada para que os “pontos ocultos” se tornem visíveis.
Aqui na idwall, a equipe de segurança tem despendido esforços para que o mapeamento e análise de risco de todos os nossos ativos sejam feitos da maneira mais completa possível, implementando diversas soluções para esse fim.
As políticas e os procedimentos criados pela nossa equipe preveem a revisão periódica de acessos aos nossos produtos, sistemas internos e equipamentos, evitando assim que credenciais deprecadas estejam disponíveis para utilização indevida. Também temos diversas ferramentas responsáveis pela administração dos softwares nos endpoints físicos, evitando que as aplicações utilizadas pelos idwallers se tornem gaps de segurança e garantindo a proteção dos dados sensíveis trafegados nesses equipamentos.
Através de nosso programa interno de conscientização em segurança da informação, garantimos treinamentos a todos os idwallers para evitar más práticas nos usos dos equipamentos e no agir em caso de incidentes. A conscientização ainda ajuda a reduzir o número de ativos considerados como Shadow IT e de adesão às tentativas de ataques de engenharia social, como os golpes de phishing, por exemplo. Por último, mas não menos importante, a equipe de Red Team tem trabalhado em automações que ajudam a reduzir o tempo gasto na auditoria de nossos produtos, podendo explorar as aplicações com foco maior na descoberta de “pontos ocultos” nas aplicações.
Escrito por: Mateus Francani, Analista de Segurança da Informação na idwall.
