O L em Linux significa movimento lateral
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 área de trabalho remota
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
Ao discutir sobre movimento lateral, técnicas 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 que possam 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 a 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 é sobre 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 para passar 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).
Há também algumas portas que foram tratadas por sshd (o processo daemon SSH) mesmo que não tenham nada a ver com SSH. Presumimos que sejam utilizadas em túneis SSH e, portanto, estão fora do nosso escopo de investigação.
Por exemplo, as portas 135 e 5985, utilizadas no Windows para RPC e WinRM, respectivamente. Não esperamos essas portas em máquinas Linux, especialmente quando o sshd está ouvindo sobre elas. É 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.
xinetd (e seu antecessor, inetd) são utilizados para controlar e gerenciar daemons. Ao observar a lista padrão de daemons que ele gerencia, podemos encontrar o rexec, bem como o rlogin e rsh, todas as partes do conjunto Berkeley r-commands . Também podemos encontrar vários FTP daemons, 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 Autoridade de números atribuídos pela Internet (IANA). 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 (normalmente chamado de snmpd) que escuta as conexões pela 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.
À medida que isso acontece, também é possível executar comandos remotos por meio do SNMP com o plug-in EXTEND, que foi carregado por padrão em versões mais antigas do agente SNMP. Embora essa opção esteja desativada em versões mais recentes do SNMP (v5.8 ou mais avançadas), após um semirrelacionado CVE, ainda vimos 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 do EXTEND SNMP
A despeito dos recursos integrados do SNMP, ele também é um alvo para invasores, com alguns agentes de ameaça que utilizam vulnerabilidades em implementações de SNMP em roteadores e dispositivos de IoT para violar redes. O abuso do SNMP chegou a tal ponto que a Agência de Segurança Cibernética & de Infraestrutura (CISA) lançou um aviso 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 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 área de trabalho remota
10% dos ambientes Linux testados
Não, não estamos falando especificamente do RDP, o protocolo de área de trabalho remota proprietário da Microsoft (mas ele aparecerá, não se preocupe). Existem outros protocolos de área de trabalho remota que podem ser executados em máquinas Linux. Eles são muito menos comuns do que em ambientes Windows, pois se destinam a compartilhar áreas de trabalho gráficas e a maioria dos servidores Linux é instalada sem nenhum ambiente de área de trabalho.
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 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 área de trabalho 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 X, o número da porta aumenta com cada servidor de área de trabalho 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 dos protocolos de área de trabalho remota são mais seguros do que outros, mas todos podem ser utilizados de forma abusiva por agentes de ameaça. 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
Muito parecido com SSH e rlogin, o Telnet também é um protocolo para console e controle remotos. Também é desprotegido e não criptografado, da mesma forma que o rlogine 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 da suíte 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 remoto e console; 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 o controle remoto ou a execução, apenas ter a capacidade de transferir arquivos para a máquina de destino pode ser valioso para o desenvolvimento de ataques. Vamos dar uma olhada, por exemplo, na técnica de movimento lateral comum (e ferramenta) 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, que discutiremos a seguir nesta publicação.
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 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 (consulte o rsync, por exemplo). Por que alguém configuraria esses serviços com tanta 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. Há muitos exemplos de Web shells disponíveis online, para que os invasores nem tenham que inventar 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 parece também ser permitido por design. 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 fornecido pelo SSH de criptografia. 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.
Segmentation
Mesmo que toda a comunicação esteja protegida, não significa que todos possam acessar tudo. Uma rede plana é fácil para os invasores se propagarem; uma rede segmentada é um obstáculo 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, mais oportunidades terão de detectar a violação e dar 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ção. Esquerda: sem segmentação; direita: com segmentação.
Resumo
Nesta publicação, destacamos vários protocolos e programas comuns em máquinas Linux e 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 seu redor.
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 que o exigem, sem muito impacto na operabilidade normal da rede.
