O L em Linux significa “lateral movement”, ou “movimento lateral” em português
Introdução
Além do SSH, o que você pode fazer?
Seleção de candidatos
Protocolos que permitem a execução imediata do código
SNMP
Protocolos de desktop remoto
Telnet
Berkeley r-commands
Vou deixar essa informação aqui: protocolos que permitem a transferência de arquivos
FTP
Samba
NFS
rsync
Execução remota por meio de transferência de arquivos
Persistência remota
Web shells
Os contêineres não devem vazar, certo?
Proteja-se antes de se destruir
Resumo
Introdução
Quando se trata de técnicas de movimento lateral que não dependem da exploração de vulnerabilidades, existem muitos protocolos e ferramentas legítimos que os invasores podem empregar: PsExec, RDP, SSH, WMI e muito mais. A maioria geralmente está disponível somente em máquinas Windows. No entanto, quando se trata de máquinas Linux, apenas um protocolo vem à mente: SSH. Nesta publicação, veremos outros protocolos no Linux que podem ser empregados para alcançar (ou ajudar a alcançar) o movimento lateral.
É claro que o Linux não é um sistema operacional; é apenas o kernel. Seria mais preciso dizer que vamos analisar os sistemas operacionais baseados em Linux ou as distribuições do Linux. Tentar encontrar um serviço ou protocolo comum que funcione em várias distribuições imediatamente é praticamente impossível (nem mesmo o SSH é instalado imediatamente em todas as distribuições). Em vez disso, vamos nos concentrar nos protocolos e serviços mais proeminentes, independentemente da distribuição do Linux que os acompanha.
Esta publicação não se destina a ser um guia para a invasão do Linux; o objetivo é informar os defensores da rede sobre possíveis ameaças que podem afetar suas redes.
Além do SSH, o que você pode fazer?
A maioria (se não todos) dos protocolos que abordaremos nesta publicação não está disponível imediatamente, mas deve ser configurada de uma forma específica para alcançar o movimento lateral. Não forneceremos guias para abusar dos protocolos abordados nesta publicação.
Esperamos aumentar a conscientização sobre outros protocolos que possam ser configurados de forma a servir como um ponto vulnerável que pode ser abusado por invasores. Um hacker determinado pode e vai encontrar e abusar dos protocolos abordados nesta publicação sem que nós o informemos sobre isso. Queremos que a equipe azul esteja preparada para reagir.
Para ajudar ainda mais os defensores, fizemos uma parceria com nossa equipe da Infection Monkey. A Infection Monkey é uma plataforma de ataque e violação automática de código aberto que testa sua rede contra muitas técnicas comuns de movimento lateral e propagação de rede.
A equipe de desenvolvimento usou os resultados de nossa pesquisa e os incorporou como uma nova técnica de exploração dentro da ferramenta. Os defensores podem utilizar a Infection Monkey para testar sua rede contra algumas das técnicas de execução remota mencionadas nesta publicação.
Seleção de candidatos
[Observação: Esta seção aborda o método que empregamos para encontrar alvos interessantes de movimento lateral. Caso seu interesse não seja por metodologia e você prefira ir diretamente para a ação, fique à vontade e passe para os protocolos que permitem a execução imediata do código.]
Como estamos procurando protocolos e serviços de movimento lateral, podemos considerar tanto o aspecto do sistema operacional quanto o da rede ao procurar possíveis candidatos; ou seja, podemos procurar os processos mais comuns em máquinas Linux ou nas portas de escuta mais comuns. Não devemos negligenciar um em favor do outro, pois pode haver implementações diferentes do mesmo protocolo (nome de processo diferente, mesma porta) ou um único processo com várias portas ou portas em mudança (como portas efêmeras no RPC).
Quando analisamos as principais portas utilizadas na comunicação com máquinas Linux, vimos que o SSH (porta 22) dominou a lista, mas também havia outros candidatos promissores para investigação: FTP (porta 21), SNMP (porta 161) e Sun RPC (porta 111).
Existem também algumas portas que eram gerenciadas por sshd (o processo daemon do SSH), mesmo que não tenham qualquer relação com o SSH. Presumimos que sejam utilizadas em túneis SSH e, portanto, estão fora do nosso escopo de investigação.
Por exemplo, vamos considerar as portas 135 e 5985, utilizadas no Windows para RPC e WinRM, respectivamente. Não esperamos encontrar essas portas em máquinas Linux, principalmente quando o sshd está escutando nelas. É mais provável que um túnel SSH tenha sido aberto em uma máquina Linux que esteja disponível externamente para permitir o acesso a máquinas internas. Como os túneis SSH apenas redirecionam o tráfego para outro destinatário, eles não são muito importantes quando se considera o movimento lateral para o host do túnel.
Entre nossas descobertas, dois processos interessantes surgiram para consideração: xinetd e rpcbind. Eles não são viáveis como alvos de movimento lateral, pois não oferecem muitos recursos; eles são empregados principalmente para operações de pesquisa para mapear a comunicação e as portas para outros processos. Em vez disso, podemos usá-los para encontrar outros serviços interessantes.
O xinetd (e seu antecessor, o inetd) é utilizado para controlar e gerenciar daemons. Ao analisar a lista padrão de daemons gerenciados, encontramos o rexec, além do rlogin e do rsh, todos parte do conjunto de Berkeley r-commands. Também podemos encontrar vários daemons FTP, VNC e Telnet.
rpcbind é o processo portmapper RPC para Sun RPC. Os servidores RPC são registrados com o portmapper, e os clientes podem consultá-lo para encontrar a porta efêmera do servidor. Ao contrário do MS-RPC, o Sun RPC utiliza números de programa para identificar servidores RPC específicos, e eles são registrados na IANA (Internet Assigned Numbers Authority). Ao observar os programas registrados, podemos ver alguns nomes interessantes, como rexec e NFS.
Protocolos que permitem a execução imediata do código
SNMP
24% das máquinas Linux testadas
O SNMP (Simple Network Monitoring Protocol) tem a função de monitoramento. As máquinas executam um processo daemon (geralmente chamado de snmpd) que escuta conexões na porta UDP 161. Embora a função do SNMP seja geralmente consultar parâmetros e estatísticas da máquina, também é possível definir alguns parâmetros e configurações remotamente com o protocolo. As versões anteriores do SNMP (v1 e v2) também não têm muita criptografia ou autenticação, e exigem apenas uma senha (chamada de “string de comunidade”) que pode ser obtida por meio do tráfego de rede ou por força bruta.
Acontece que também é possível executar comandos remotos via SNMP utilizando o plugin EXTEND, que já vinha habilitado por padrão em versões anteriores do agente SNMP. Embora essa opção esteja desabilitada nas versões mais recentes do SNMP (v5.8 em diante), devido a uma CVE semirrelacionada, ainda encontramos ambientes com a versão vulnerável do SNMP instalada. Também é possível criar seu próprio agente SNMP e ativar o plug-in EXTEND (Figura 1).
Fig. 1: Execução de um script remoto com o plug-in EXTEND SNMP
Apesar das funcionalidades integradas do SNMP, ele também é alvo dos invasores. Alguns agentes de ameaças exploram vulnerabilidades presentes em implementações do SNMP em roteadores e dispositivos IoT para invadir redes. O abuso do SNMP chegou a tal ponto que a Agência de Segurança Cibernética de Infraestrutura (CISA) lançou um comunicado sobre o protocolo.
Para ajudar a testar essa ameaça, fizemos uma parceria com nossa equipe do Infection Monkey para desenvolver um plug-in de exploração para o plug-in EXTEND remoto do SNMP. A execução do Infection Monkey permitirá que você veja como seria esse ataque em seu ambiente e verifique se a sua postura de segurança é suficiente para repelir o ataque. O ataque SNMP está disponível na versão mais recente do Infection Monkey, v2.2.1.
Protocolos de desktop remoto
10% dos ambientes Linux testados
Não, não estamos falando especificamente do RDP, o protocolo de desktop remoto proprietário da Microsoft (mas ele aparecerá, não se preocupe). Existem outros protocolos de desktop remoto que podem ser executados em máquinas Linux. Eles são muito menos comuns do que em ambientes Windows, pois se destinam a compartilhar desktops gráficos, e a maioria dos servidores Linux é instalada sem nenhum ambiente de desktop.
No entanto, vemos os protocolos em algumas redes, por isso eles entraram na lista e estão incluídos aqui:
O X Window System é um sistema de janelas de área de trabalho disponível para Unix, e também pode ouvir conexões remotas. Ele utiliza as portas TCP 6000 ou superior (começa com a porta 6000, mas o número da porta aumenta posteriormente para cada servidor de desktop em execução).
O VNC é baseado no protocolo RFB (Remote framebuffer, buffer de quadros remoto) e utiliza mais de 5900 portas TCP (da mesma forma que no X, o número da porta aumenta a cada servidor de desktop em execução).
Xrdp é uma implementação do protocolo Microsoft RDP que pode ser utilizado em máquinas que não sejam Windows. Como uma implementação do RDP, ele utiliza a porta 3389.
Alguns protocolos de desktop remoto são mais seguros do que outros, mas todos podem ser explorados por agentes de ameaças. Há também várias implementações dos protocolos no Linux, e é por isso que incluímos números de porta aqui em vez de nomes de programas.
Telnet
4% dos ambientes Linux testados
Assim como o SSH e o rlogin, o Telnet também é um protocolo para controle e console remotos. Ele também é inseguro e não criptografado, assim como o rlogin, e está vulnerável a ataques de interceptação ou sniffing de pacotes. Só o vimos em aproximadamente 4% das redes que examinamos, mas isso significa que ainda é utilizado e pode afetar sua rede. O protocolo utiliza a porta TCP 23 ou 2323.
Berkeley r-commands
1% dos ambientes Linux testados
O Berkeley r-commands é um conjunto de programas que permitem operações remotas entre máquinas na rede. Originalmente desenvolvidos como parte do BSD, eles foram amplamente substituídos pelo SSH, principalmente devido às preocupações com a segurança desses protocolos (sem criptografia e com autenticação mínima ou inexistente).
Ainda assim, vimos alguns dos daemons do pacote aqui e ali, por isso é cedo demais para descartá-los totalmente. Há três daemons que gostaríamos de mencionar:
rexec: fornece execução remota de comando; utiliza a porta TCP 512
rlogin: fornece login e console remotos; utiliza a porta TCP 513
rsh: semelhante ao rexec, mas não requer autenticação; utiliza a porta TCP 514
Vou deixar essa informação aqui: protocolos que permitem a transferência de arquivos
Mesmo que não permita diretamente execução ou controle remotos, a simples capacidade de transferir arquivos para a máquina de destino pode ser valiosa para o desenvolvimento de ataques. Vamos dar uma olhada, por exemplo, na técnica (e ferramenta) comum de movimento lateral PsExec, mesmo que seja baseada no Windows.
Primeiro, ela copia seu binário de serviço para a máquina de destino via SMB, e só então obtém o serviço para ser executado comunicando-se com o gerenciador de serviços remotamente. Por isso, achamos importante mapear também as várias maneiras pelas quais as ferramentas e os binários do invasor podem ser colocados nos computadores de destino. Também teorizamos alguns métodos de abuso da transferência de ferramentas para obter execução remota, o que discutiremos mais adiante neste post.
FTP
31% dos ambientes Linux testados
O FTP (File Transfer Protocol) é um dos protocolos mais clássicos (foi o primeiro protocolo de camada de aplicação ensinado nas aulas de rede). Com a função de transferir arquivos, é um protocolo baseado em texto que não é seguro, pois utiliza texto não criptografado.
Samba
20% dos ambientes Linux testados
O Samba é um conjunto de programas que ajuda na interoperabilidade do Windows. Ele implementa o protocolo SMB (porta TCP 445) e pode hospedar ou interagir com servidores de arquivos, além de poder integrar-se ao Active Directory ou servir como um próprio controlador de domínio (Figura 2).
Embora o SMB por si só seja apenas um protocolo de transferência de dados, a integração com o Active Directory significa que você pode encontrar várias implementações de servidores e clientes RPC, o que pode gerar uma boa safra de possíveis caminhos de movimento lateral.
Felizmente, não conseguimos encontrar uma forma clara de abusar do Samba para o movimento lateral. Como o Samba se preocupa apenas em fazer as coisas funcionarem, muitas lógicas e funcionalidades de RPC desnecessárias não foram implementadas, de modo que a superfície de ataque foi limitada. Também há menos verificações no código, como se pode ver pelos vários comentários em todo o código-fonte.
Pode ser prudente fazer com que uma equipe vermelha verifique a segurança do controlador de domínio ao utilizar um Samba Active Directory, mesmo que não haja caminhos de movimento lateral óbvios para ele.
Fig. 2: Comentário TODO no código-fonte do Samba
NFS
18% dos ambientes Linux testados
O NFS (Network File System, sistema de arquivos de rede) é outra maneira de criar servidores de arquivos. Ele é construído sobre o Sun RPC (porta TCP 111). Há muitas funções RPC que podemos analisar, mas não encontramos uma maneira imediata de obter a execução remota de comandos por meio dele.
rsync
16% dos ambientes Linux testados
O rsync é um utilitário para transferência de arquivos e sincronização entre máquinas na rede. Ele pode ser executado como um serviço ou um daemon e pode servir arquivos através de seu protocolo dedicado (porta TCP 873), rsh ou SSH.
Execução remota por meio de transferência de arquivos
Podemos discutir a transferência de arquivos o quanto quisermos, mas ela não é muito útil, a menos que os invasores possam executar os arquivos transferidos de alguma forma. Além de enganar o usuário para que ele mesmo execute o arquivo, pensamos em duas opções para conseguir a execução, ambas requerem algum tipo de configuração incorreta ou um afrouxamento (grave) das configurações de segurança.
Persistência remota
Há muitos locais legítimos no sistema de arquivos Linux que podem ser empregados para instalar a persistência, mas, para o movimento lateral, vamos nos concentrar em /etc/cron.hourly. Se um invasor puder carregar um arquivo lá, com permissões de execução, ele simplesmente será executado na próxima hora da rodada, obtendo assim o tão cobiçado movimento lateral.
Mas, para isso, um invasor precisaria de permissões sudo ou root, que não são fáceis de obter. Infelizmente, é possível configurar servidores de arquivos de uma forma não segura, o que permitiria esse cenário exato (para ver um exemplo, consulte o rsync). Por que alguém configuraria esses serviços com tão pouca segurança? Porque é conveniente e facilita a vida deles. Não seja essa pessoa: proteja-se.
Web shells
Um cenário muito mais plausível, em vez de acesso a /etc, seria o acesso remoto a uma pasta raiz da Web de um servidor da Web ativo. Nesse caso, deve ser possível carregar um Web shell personalizado e usá-lo para executar comandos remotos. Existem muitos exemplos de web shells disponíveis na internet, então os invasores nem precisam reinventar a roda.
Os contêineres não devem vazar, certo?
Outro aspecto que está se tornando cada vez mais popular nos últimos anos são os contêineres. Em nossa pesquisa, vimos várias instâncias de programas de contêiner ouvindo e aceitando conexões, e isso parece também ser permitido por padrão. Se os invasores conseguirem acesso a um gerenciador de contêineres remoto, poderão carregar sua própria imagem mal-intencionada e usá-la para se propagar ainda mais dentro da rede.
Proteja-se antes de se destruir
Agora que abordamos as possíveis maneiras de os invasores entrarem nas máquinas, é hora de discutir como mantê-los fora delas.
Visibilidade
Como já mencionamos, nenhum dos protocolos que discutimos aqui vem instalado e configurado com o Linux pronto para uso. Alguém precisa instalá-los especificamente. Dessa forma, a primeira ordem do dia seria ter uma boa visibilidade do que está sendo executado e se comunicando (ou ouvindo a comunicação) na rede, como Sun Tsu escreveu: “Se você não conhece nem o inimigo nem a si mesmo, sucumbirá em todas as batalhas”.
Configuração
Depois de fazer o inventário da sua rede e identificar um dos serviços discutidos aqui, a próxima etapa é verificar a configuração desses serviços. Por exemplo, um agente SNMP atualizado que esteja configurado para utilizar o SNMPv3 com autenticação Kerberos é perfeitamente adequado. SNMPv2 com uma string de comunidade fácil de adivinhar? Nem tanto.
Segurança em vez de obscuridade
Outros protocolos ou serviços podem ser substituídos por protocolos mais novos e mais seguros, como a utilização de SSH em vez do conjunto de r-Command ou Telnet. Alguns protocolos, como FTP ou rsync, também podem ser encapsulados via SSH, para o benefício adicional de criptografia que o SSH oferece. Não é preciso dizer que: Você também terá que garantir que o SSH esteja configurado corretamente, com PKI ou senhas de alta segurança que não sejam facilmente decifráveis.
Segmentação
Mesmo que toda a comunicação esteja protegida, não significa que todos possam acessar tudo. Uma rede plana é facilmente propagada pelos invasores, enquanto uma rede segmentada representa um desafio muito maior (Figura 3).
Se os invasores tiverem que passar por obstáculos e gastar muitos recursos para cada etapa na rede, talvez desistam do ataque porque não é econômico. Além disso, quanto mais ações os invasores tiverem que realizar dentro da rede, maiores serão as oportunidades de detectar a violação e emitir o alarme. Em seguida, você pode iniciar um procedimento de resposta a incidentes para expulsá-los e fechar a violação.
Fig. 3: Segmentação como uma estratégia de mitigação de violações. À esquerda: sem segmentação; à direita: com segmentação.
Resumo
Nesta publicação, destacamos vários protocolos e programas comuns em máquinas Linux e que podem ser úteis para os invasores, à medida que tentam se mover lateralmente pela rede. Escolhemos especificamente não incluir exemplos concretos, pois visamos o lado azul da cerca. Queremos aumentar a conscientização sobre esses protocolos para que as redes não apresentem um ponto exposto.
No que diz respeito a mitigações ou proteções, recomendamos utilizar as versões seguras dos protocolos discutidos nesta publicação (SNMPv3, SFTP em vez de FTP etc.). Além disso, sempre que possível, recomendamos empregar estratégias de segmentação de rede ao redor deles.
Para a maioria dos protocolos discutidos aqui, geralmente há um pequeno subconjunto de processos de cliente ou servidor, bem como números de porta ou intervalos exclusivos. Como tal, deve ser possível restringir o acesso à rede bloqueando portas ou processos específicos para o subconjunto de servidores relevante, sem muito impacto na operabilidade normal da rede.
