atddd;
cupsdd;
cupsddh;
ksapdd;
kysapdd;
skysapdd;
xfsdxd.
Os arquivos cupsdd e cupsddh são detectados por produtos da Kaspersky Lab como Backdoor.Linux.Ganiw.a; atddd e os arquivos restantes são detectados como Backdoor.Linux.Mayday.f. O arquivo com os sub-arquivos, também continha um elemento de configuração para o cron - o "task scheduler" do Linux. Neste caso, o utilitário é usado pelo Trojan como meio de obter uma posição no sistema. O Trojan usa cron para executar as seguintes tarefas:
Once a minute: finalizar os processos de todos os aplicativos que podem interferir no seu funcionamento: .IptabLes, nfsd4, profild.key, nfsd, DDosl, lengchao32, b26, codelove, node24
Approximately once in ninety minutes: terminar todos os seus processos: kysapd, ATDD, skysapd, xfsdx, ksapd
Approximately once in two hours: o download de todos os seus componentes para o /etc a partir da pasta http://www.dgnfd564sdf.com:8080/[module_name] (module_name = nome do módulo do Trojan, por exemplo, cupsdd), depois de excluir esses arquivos a partir da pasta /etc
Once in ninety minutes: relançar todos os seus módulos
Every minute: logs do sistema e histórico de comandos bash e executar chmod 7777 [module_name]
Durante a análise posterior dos arquivos, não foram encontrados quaisquer códigos responsáveis por salvar o arquivo de configuração do cron. Provavelmente, o arquivo foi baixado manualmente para a máquina da vítima por um cybercriminoso, depois deste ganhar acesso remoto ao sistema.
Backdoor.Linux.Mayday.f (atddd)
O arquivo atddd, é um backdoor que foi desenvolvido para realizar vários tipos de ataques DDoS contra os servidores especificados. Como foi mencionado acima, os produtos da Kaspersky Lab conseguiram detectá-lo como Backdoor.Linux.Mayday.f. Os arquivos kysapdd, skysapdd, xfsdxd, ksapdd são cópias quase exatas de atddd - com uma exceção, que será discutida mais adiante no texto.
Vale ressaltar que o backdoor inicia sua operação chamando a função daemon (1, 0), continuando a ser executado em segundo plano e redirecionando a entrada padrão, saída e erros para /dev/null
Em seguida, atddd recolhe informações relevantes sobre o sistema, incluindo:
Versão do sistema (by calling uname())
Número de núcleos de CPU e seus clock rates (taken from /proc /cpuinfo)
Carga da CPU (taken from /proc /stat)
network load (dados para interfaces com o prefixo "eth" a partir de /proc/net/dev)
Importante ressaltar que as informações listadas acima são armazenadas na estrutura g_statBase.
Depois de todo esse processo, o backdoor decifra strings que definem o endereço IP e o número da porta do servidor C & C. O algoritmo de criptografia usado é muito simples: uma string criptografada é analisada caractere por caractere, com adição a um código ASCII de um caractere, se o número for ímpar e subtraído, se o número do caratere for o mesmo. Como resultado, a string "3/3-2/4-269-85" produz os IP-адрес "202.103.178.76", enquanto o "2/:82" representa o número da porta "10991".
Após isso, o arquivo atddd lê o arquivo fwke.cfg, o qual está localizado na mesma pasta com o programa malicioso. Todas as informações do arquivo de configuração, são salvas na estrutura g_fakeCfg. Se o arquivo não existir, haverá tentativas do backdoor para criá-lo e armazenar nele as seguintes informações:
1st line: 0 //flag, if 1 then begin attack, if 0 then terminate attack
2nd line: 127.0.0.1:127.0.0.1 //range of outgoing IP addresses
3rd line: 10000:60000 //outgoing port range for an attack
4th line: an empty line //domain name in the case of DNS flood
Esta informação é, posteriormente, enviada para o servidor C & C e pode ser atualizada com um comando para estabelecer comunicação com o servidor. Em seguida, o backdoor cria uma nova thread, CThreadTaskManager::ProcessMain(), em que os comandos iniciam um ataque e terminam-no, colocando na fila de execução. Depois disso, uma nova thread é criada - CThreadHostStatus::ProcessMain(). Neste segmento, os dados sobre CPU e payload network é atualizado a cada segundo e pode, posteriormente, ser enviado para o servidor C & C, caso seja solicitado.
Criação de Threads
Depois disso, 20 threads serão criados, fazendo a leitura das informações da fila de tarefas e, dependendo dessas informações, será lançado um ataque ou mesmo ele será finalizado. No entanto, algumas das threads não podem ser utilizada em um ataque, se o respectivo comando C & C tiver um parâmetro (o número de threads a ser usado). Em seguida, o malware entra em um loop infinito de processamento de mensagens do C & C. Depois de estabelecer uma comunicação com o C & C, as informações sobre a versão do sistema e clock rates do processador, bem como os dados a partir da estrutura g_fakeCfg, são enviadas para o servidor C & C a cada 30 segundos. Em resposta, o servidor deve enviar 4 bytes, o primeiro dos quais é o número de série de um comando - de 1 a 4.
Em seguida, se o comando não apresentar parâmetros, o servidor de C & C envia mais 4 bytes que definem a quantidade de dados que serão enviados (ou seja, os parâmetros). Em seguida, os parâmetros próprios são enviados; o seu tamanho deve corresponder ao número da resposta anterior oriunda do C & C.
Sobre cada comando, em maiores detalhes:
- 0x01. Comando para lançar um ataque. Parâmetros definem o tipo do ataque e o número de threads a ser usado. O tipo de ataque definido por um byte pode assumir valores de 0x80 a 0x84. Isto significa que cinco tipos de ataque são possíveis:
- 0x80 - TCP Flood: O número da porta de destino é enviado pelo C & C, em sua resposta como um parâmetro. O intervalo de portas de origem é definido no fwke.cfg. Cada nova solicitação é enviada a partir de uma nova porta dentro da faixa definida, na ordem crescente de números de porta. O endereço IP de destino também é definido em parâmetros.
- 0x81 - UDP Flood. O mesmo que 0x80, mas o UDP é utilizado como o protocolo da transport layer.
- 0x82 - ICMP flood. O mesmo que acima, mas via ICMP.
- 0x83, 0x84 - dois ataques de DNS Flood. A única diferença é o nome de domínio enviado no pedido de DNS. No primeiro caso, o nome é gerado de forma aleatória, no segundo, que é definido em um parâmetro (a quarta linha de fwke.cfg). Essencialmente, ambos os ataques são semelhantes aos 0x81, exceto que a porta 53 (a porta padrão para o serviço de DNS) é usada como porta de destino.
- 0x02. Comando para encerrar um ataque. O valor na primeira linha de fwke.cfg é alterado para 0 e o ataque é terminado.
- 0x03. Comando para atualizar o arquivo fwke.cfg. A resposta também inclui uma estrutura semelhante a g_fakeCfg, dados a partir do qual é utilizada para criar o novo ficheiro fwke.cfg.
- 0x04. Comando para enviar status de execução do comando atual para o servidor C & C.
Além do exposto, o backdoor inclui vários métodos (sem qualquer código), que têm nomes curiosos: CThreadAttack:: EmptyConnectionAtk, CThreadAttack :: FakeUserAtk, CThreadAttack :: HttpAtk. Aparentemente, o desenvolvedor de malware tinha planos para estender a funcionalidade do programa malicioso, e esta é uma versão de teste, ao invés de ser uma versão final. O arquivo cupsdd, que será discutido a seguir, apresenta uma confirmação disso.
Os arquivos kysapdd, skysapdd, xfsdxd, ksapdd são cópias quase idênticas de atddd, com a ressalva de que eles contêm diferentes endereços de servidor de comando e controle: 112.90.252.76:10991, 112.90.22.197:10991, 116.10.189.246:10991 e 121.12.110.96:10991 , respectivamente. Os nomes de seus arquivos de configuração também são diferentes: fsfe.cfg, btgw.cfg, fake.cfg, xcke.cfg, respectivamente.
Isso significa que, ao contrário das nossas expectativas, os arquivos atddd, kysapdd, skysapdd, xfsdxd, ksapdd não são módulos de um único pedaço de malware, mas sim diferentes cópias do mesmo Trojan, cada conexão com o seu próprio servidor de C & C. No entanto, esta não é a parte mais curiosa do que de longe.
Backdoor.Linux.Ganiw.a (cupsdd)
Como os arquivos descritos acima, este arquivo é um backdoor projetado para realizar vários tipos de ataques DDoS. No entanto, cupsdd é significativamente mais sofisticado do que seus "colegas", é bem mais rico em recursos, embora em certos lugares seu código seja muito semelhante ao encontrado no atddd. O backdoor inicia sua operação por inicializar as variáveis de que necessita a partir da string "116.10.189.246:30000:1:1:h:578856:579372:579888" (separador - ":"), que ele primeiro decritografa usando o algoritmo RSA. A seqüência contém as seguintes variáveis:g_strConnTgt = 116.10.189.246 - endereço IP C & C do servidor
g_iGatsPort = 30000 - porta da C & C servidor
g_iGatsIsFx = 1 e g_iIsService = 1 - bandeiras usadas mais tarde
g_strBillTail = h - postfix para o nome do arquivo que será descartado (veja abaixo)
g_strCryptStart = 578856, g_strDStart = 579372, g_strNStart = 579888 - pointers para dados RSA (string encriptada e chave)
Em seguida, o malware faz um "dropper" e executa um arquivo, que está localizado no deslocamento 0xb1728 a partir do início do arquivo original, que é de 335,872 bytes de tamanho, desde que o arquivo não esteja em execução. As verificações de malware são feitas se o arquivo estiver sendo executado por tentar vincular um socket para 127.0.0.1:10808. Se a tentativa for bem-sucedida, isso significa que o arquivo não está em execução, e que precisa ser descartado e executado.
Saiba Mais:
[1] Secure List http://securelist.com/analysis/publi...jan-for-linux/
Mensagem do Sistema