Segurança em DNS

 Por Thiago Alvarenga

Valinhos SP 11 de Setembro de 2022

Segurança aplicada ao DNS

Há uma complexidade muito grande quando o assunto é DNS e por este motivo é que este estudo precisa ser aprofundado. É taxativo dizer que todo administrador de segurança ou infraestrutura tenha a capacidade de gerir, identificar e aplicar as devidas mitigações em todo ecossistema que envolve este tema.

O acrônimo de DNS é Domain Name System (Sistema de Nomes de Domínio), traduzindo de uma forma mais avançada, o DNS é um grande concentrador ou melhor expressando: um banco de dados redundante hierárquico e distribuído, usado para passar informações sobre nomes de domínio. Em linhas gerais, a terminologia utilizada para descrever o DNS é a de uma árvore. 

Ainda sobre as definições do DNS, fazendo uma analogia com a raiz de uma árvore onde vários TLDs (Top Level Domains - Domínios de Nível Superior) são semelhantes aos galhos que saem da raiz e cada ramificação tem ramificações menores que podem ser denominados de Second Level Domains (Domínios de Segundo Nível), e ainda nesta analogia, as folhas - os FQDNS (Fully Qualifed Domain Names - Nomes de domínios totalmente Qualificados) é conhecido por hostnames. Não imagine que esta analogia é estática, pelo contrário, é uma árvore monstruosa arguida no concreto por assim dizer. 

É comum relacionar o DNS de forma simplista, servindo apenas para o funcionamento da internet, contudo, praticamente qualquer organização de tamanho razoável com um servidor de DNS mal configurado pode causar impactos irreversíveis. 

Observe o exemplo recente da  CVE-2020-1350, uma vulnerabilidade de gravidade "wormable" pela Microsoft com criticidade CVSS de maior gravidade, pontuação 10, esta vulnerabilidade permite o invasor ter acesso remoto (vetor de ataque por execução remota - RCE) por uma simples abertura de e-mail cuja a imagem de uma assinatura de um e-mail é liberada pelo usuário; por exemplo. Neste cenário, quando o usuário que abriu o e-mail interage, o servidor de DNS interno da empresa abre uma consulta para resolução de nomes e neste momento da consulta a resposta onde esta imagem está alocada é carregado um payload malicioso abrindo a possibilidade de estabelecer uma comunicação por shell reverso. 

A figura abaixo extraída do site:  www.graplsecurity.com - Consultado em: 11 de setembro de 2022

Adentrando um pouco sobre esta vulnerabilidade, trata-se de um vetor de ataque do tipo RCE usando técnicas de buffer-over-flow. Atinge a versão 2008 até a versão mais atual do windows 2019. Ela foi descoberta pela empresa Check Point Research em 04 de novembro de 2019. A boa notícia que esta vulnerabilidade só pode ser explorada em ambientes que utilizam o windows server dns. 

Arquivo hosts.txt

O arquivo hosts.txt é um resquício de traços antigos que ficou do DNS, que pode ser encontrado em vários sistemas operacionais. Este arquivo pode ser encontrado nos seguintes locais: 

• Unix: /etc/hosts.txt
• Windows: %systemroot%\system32\drivers\etc\hosts.txt

Em dezembro de 1973 em conjunto com uma descrição na RFC 592 uma convenção "oficial" para a nomenclatura de hosts foi definida. Números, letras e traços eram os únicos caracteres permitidos e parênteses eram permitidos como parte dos nomes de rede. Em seguida veio a RFCs 606 e 608 que descreveram a criação de um novo arquivo centralizado chamado de hosts.txt e poderia ser baixado por um servidor ftp para que todos administradores online pela Arpanet tivessem os mesmos dados referentes aos nomes de hosts. 

Estando online em 25 de março de 1974 e foi anunciado pela RFC 627. Já a RFCs 623 e 625 discutiram colocar o arquivo hosts.txt em um servidor adicional caso o servidor principal OFFICE-1 apresentasse indisponível, esta ideia é muito semelhante ao que é adotado nos dias atuais. 

Com o intuito de não adentrar muito sobre a história do DNS, vale ressaltar que em 1998, o governo norte-americano publicou um artigo que descrevia a passagem do então controle do DNS que estava sob a responsabilidade de uma entidade privada, a Network Solutions, para uma organização independente que incentivasse a concorrência e estimulasse novas oportunidades para a internet, a então: ICANN (Internet Corporation for Assigned Names and Numbers) no ano de 1999 iniciando ao processo de registros de nomes com estas premissas. 

Atualizado em: 12 de setembro de 2022. 

Em fase de conclusão.

Guia de Agosto de 2022 - CyberSecurity

 Cyber Security

Por Thiago Alvarenga

Valinhos SP / Agosto de 2022

Necessidade: Identificar se um site está com o TLS vulnerável

O primeiro passo é identificar portas que possuem serviços embrulhados SSL/TLS. Normalmente, as portas tcp com SSL para serviços web e de e-mail são, mas não se limitam a:  443 (https), 465 (ssmtp), 585 (imap4-ssl), 993 (imaps), 995 (ssl-pop).

Neste exemplo, buscamos serviços SSL usando nmap com opção "-sV", usado para identificar serviços e também é capaz de identificar serviços SSL. Outras opções são para este exemplo em particular e devem ser personalizadas. Muitas vezes, em um escopo de teste de penetração de aplicativos da Web é limitado à porta 80 e 443.

1. Verificando informações sobre certificados, cifras fracas e SSLv2 via Nmap

Comando: 

# nmap --script ssl-cert,ssl-enum-ciphers -p 443,465,993,995 siteapesquisar.com.br

2. Verificando a renegociação iniciada pelo cliente e renegociação segura via OpenSSL (manualmente)

O OpenSSL pode ser usado para testar manualmente SSL/TLS. Neste exemplo, o testador tenta iniciar uma renegociação pelo cliente conectando-se ao servidor com o OpenSSL. O teste então escreve a linha de punho de um pedido HTTP e digita em uma nova linha. Em seguida, ele aguarda a renegociação e a conclusão da solicitação HTTP e verifica se a renegociação segura é suportada olhando para a saída do servidor. Usando solicitações manuais também é possível ver se a Compactação está habilitada para TLS e verificar se há inconsistência, para cifras e para outras vulnerabilidades.

Comando: 

#openssl s_client -connect avaetec.com:443

Fonte:

 WSTG - v4.1 | Fundação OWASP

Scan TLS heath and configuration - Geekflare Tools

Resumo - CloudFormation

 Por Thiago Alvarenga

O CloudFormation é utilizado para simplificar o gerenciamento da infraestrutura cloud por meio de automação. 

Recursos:

• É uma linguagem de infraestrutura usado apenas em AWS;
• Recursos definidos por JSON ou Yaml;
• É possível criar recursos direto em Cloud;
• Ajuda na manutenção e automação da infraestrutura em redes;
• Gerencia estados;
• Pode ser manipulado por Templats (Dinâmico ou Estático);
• Por meio de Stacks é possível definir parâmetros específicos (stecks é a configuração definida na aws);
• Stackset (É usado para aplicar de forma ampla todas configurações no definidas no templat em várias contas da AWS quando a conta tem uma Aws Organization configurada);

Resumo finalizado

Introdução ao Kubernetes

 kumernetes

Por Thiago Alvarenga

21 DE JUNHO DE  2022

1 Introdução

Este nome tem a sua terminologia conhecida por k8s, uma solução open Source utilizada para automatizar e simplificar todo o processo de gerenciamento de containers linux. Tendo o Google como uma das empresas pioneiras a desenvolver e utilizar a tecnologia de containers, o Kubernets simplifica o gerenciamento de aplicações que utilizam containers e precisam de segurança, performance, escalabilidade, monitoramento e suporte em diferentes provedores cloud.

A premissa aqui é entender o que é o Kubernetes, seus principais recursos, tais como Pods, Service, ConfigMap, Nodeport, Replicaset/deployments, Storage classes e Liveness, por fim, mas não menos importante, Readiness Probes. Talvez o artigo não consiga alcançar todos os pontos princicpais, contudo, servirá para ter uma base sobre o assunto. 

2 Entendendo Kubernetes

Antes de adentrar sobre o assunto de kubernetes,  é necessário fazer uma pausa e falar sobre Docker. O Docker é uma ferramenta padrão para deployar/implementar uma aplicação usando containers, ou seja, é possível criar uma máquina com todos serviços do xampp e instalar todas as dependências necessárias e disponibilizá-la como containers.

Em poucas palavras, a grande vantagem de um container é o de compilar todas as suas dependências necessárias para rodá-la, isto inclui bibliotécas, o runtime e o código da aplicação, todo este compilado é chamado de imagem que pode ser versionado ao distribuí-lo. 

Há alguns percalsos que o Docker sozinho não irá resolver, não precisamente um percalso, mas cenários complexos com demandas de alta disponibilidade, escalabilidade e microserviços. Explanando um pouco mais sobre este último exemplo, imagine uma aplicação que estava em um único container e passou a ser dividida em vários outros que precisam interagir entre si de maneira confiável passando por vários hosts garantindo a alta disponibilidade e escalabilidade necessário para rodar a aplicação. Este é um dos percalsos que a Docker sozinho não irá atender.  

Pensando nesta necessidade de gerenciamento, de uma maneira de garantir que todo este ecosistema continue rodando, é que volta-se ao título deste artigo, o Kubernetes.

É o kubernetes que gerencia os containers em execução e por isso ele também é denominado de "Orquestrador de Containers", através dele é possível realizar o rollbacks, garantir a altadisponibilidade, atualizações em lote e entre outros. Os maiores Playres de provedores de nuvem dão suporte ao kubernetes. Um adendo para este parágrafo, é sobre a alternativa de montar todo este ecosistema localmente usando o Minikube que simula um cluster kubernetes, ideal para testes e estudos, o atrativo disto é que após realizar este ensaio local, o usuário pode subir toda aplicação para nuvem. Vale ressaltar que o kubernetes não é o único Orquestrador de Containers, a própria Docker disponibiliza o Docker Swarm.