No mesmo dia, foi confirmada a existência do Flame e publicada a análise técnica em relação a este ataque bastante sofisticado. Este novo lado do Flame era tão avançado, que apenas os principais criptógrafos do mundo poderiam ser capaz de implementá-lo. Desde então, piadas céticas sobre o Flame começaram a surgir. Mais tarde, no mês de junho, foi confirmado definitivamente que os desenvolvedores do Flame mantinham uma estreita comunicação com a equipe de desenvolvimento do Stuxnet, que foi outro fato convincente de que Flame foi desenvolvido com o apoio do Estado-nação.
Além disso, a equipe de pesquisadores da Kaspersky Lab também fez uma análise minuciosa dos servidores de comando e controle do Flame (C & C), com base em observações externas e informações publicamente disponíveis. Isso ajudou muito em relação ao entendimento de que os servidores C & C foram localizados, e como eles foram registrados. Sendo assim, através dessa publicação, está sendo possível lançar novas informações que foram coletadas durante a análise forense dos servidores C & C do Flame. Esta investigação foi realizada em parceria com a Symantec, ITU-IMPACT e CERT-Bund/BSI.
Brief C&C Server Facts
Virtualização: Na maioria dos casos, em execução no OpenVZ
Linguagens de programação utilizadas: PHP (a maior parte do código), Python, bash
Base de dados: MySQL com tabelas InnoDB
Servidor Web: Apache 2.x com certificados auto-assinados
Análise do Servidor
Trabalhando com os containeres do sistema de arquivos OpenVZ, foram adicionados elementos que tornaram difícil o processo de análise forense. Por exemplo, tendo apenas containeres OpenVZ, não permite que você visualize o "slack space" do disco rígido para recuperar alguns arquivos apagados. Essa configuração do servidor foi um típico setup LAMP (Linux, Apache, MySQL, PHP). Ele foi usado para hospedar um painel de controle baseado na Web, e também com a finalidade de executar alguns scripts totalmente automatizados no background.
Ele era acessível através do protocolo HTTPS, portas 443 e 8080. O diretório root do documento foi /var/www/htdocs/ que tem sub-diretórios e scripts PHP. Enquanto os sistemas tinham PHP5 instalado, o código foi feito para rodar em PHP4 também. Por exemplo, /var/www/htdocs/newsforyou/Utils.php tem a função "str_split" definida, que implementa as "str_split" lógicas de funcionamento do PHP5, que não estava disponível em PHP4. Os desenvolvedores do código C & C, de maneira muito provável, implementaram mais compatibilidade com PHP4, porque eles não tinham certeza de que uma das duas principais versões do PHP seria instalada no C & C.
O código do painel de controle C & C, foi descoberto em "newsforyou/ CP/CP.php". Ao abri-lo com um navegador da Web, foi exibida uma tela de login:
O hash de nome de usuário e senha foram mais tarde encontrados em banco de dados MySQL, em "settings" (table).
Login: username
Password hash (MD5): 27934e96d90d06818674b98bec7230fa
(ok, cracked: 900gage!@#)
O hash de senha e o login foram redefinidos, com a intenção de saber como o "panel" é visto sob a ótica do atacante.
A primeira impressão dos pesquisadores, foi a de que o painel de controle apareceu sendo implementado por um script-kiddies. Parecia uma versão alfa de um painel de controle C & C - botnet. No entanto, revisitar esta imagem, novamente, torna as coisas bem mais claras, porque os atacantes escolheram, deliberadamente, esta interface. Ao contrário dos cybercriminosos tradicionais que implementam interfaces "eye-candy" da Web, as quais o usuário médio pode facilmente reconhecer como um painel de controle de uma botnet, os desenvolvedores do servidor C & C do Flame fizeram-no muito genérico e despretensioso.
Vale ressaltar que os desenvolvedores de C & C não usam termos profissionais, como bot, botnet, infecção, malware, comando ou qualquer coisa relacionada em seu painel de controle. Ao invés disso, são usadas palavras comuns, como dados, carregar, descarregar, cliente, notícias, blogs, anúncios, dentre outras do gênero. Dessa forma, a equipe da Kaspersky acredita que isso foi feito deliberadamente para enganar empresa de hospedagem, que poderia executar verificações inesperadas.
Não há nenhuma maneira de enviar comandos para os sistemas infectados, utilizando apenas a interface Web do painel C & C e esta é outra diferença de botnets tradicionais. Um computador infectado foi controlado através de um mecanismo de troca de mensagens com base em arquivos (os desenvolvedores chamaram os arquivos de "data containers"). Para enviar um comando ou conjunto de comandos para a vítima, o atacante carregou um arquivo tar.gz especialmente criado, que foi processado no servidor.
Um script de servidor especial extraía o conteúdo do arquivo e dava ênfase para arquivos *.news e *.ad. Esses arquivos foram colocados em diretórios correspondentes "notícias" e "anúncios". Além disso, o servidor C & C permite que um atacante libere uma atualização para uma vítima específica, ou para todas as vítimas de uma só vez. Vale ressaltar que é possível priorizar um comando que permite organizar uma ordem (ou seja, coletar todos os dados e só depois dar início ao processo de auto-remoção).
A prioridade e o target-client ID foram transferidos de uma forma não convencional. Eles foram armazenados no nome do arquivo que o atacante enviou para um C & C. Abaixo, está um modelo do nome do arquivo de notícias esperado pela C & C:
<random_number>_<user_type>_<user_id>_<priority>.<file extension>
Os arquivos de origem da análise mostram que a C & C pode compreender diversos protocolos de comunicação para falar com diferentes clientes:
OldProtocol
OldProtocolE
SignupProtocol
RedProtocol (mencionado, mas não implementado)
Um análise mais atenta sobre estes manipuladores de protocolo, revelou quatro tipos diferentes de clientes "codenamed" SP, SPE, FL e IP. Dessa forma, é possível confirmar que o malware Flame foi identificado como tipo de cliente FL. Obviamente, isso significa que há pelo menos três outras ferramentas de cyber-espionagem ou cyber-sabotagem desconhecidas, criadas pelos mesmos autores: SP, SPE e IP.
Uma sessão típica de cliente tratada pelo C & C, começou a partir de reconhecimento da versão do protocolo, e em seguida, houve o registro de informações de conexão, seguida pela decodificação da solicitação do cliente e o processo de salvá-lo para o armazenamento de arquivos local, de forma criptografada. Todos os metadados sobre os arquivos recebidos do cliente foram mantido em um banco de dados MySQL.
O script do servidor C & C criptografa todos os arquivos recebidos do cliente. Na sequência o servidor de comando e controle utiliza um mecanismo semelhante ao PGP para criptografar arquivos. Em primeiro lugar, os dados do arquivo são encriptados, utilizando o algoritmo Blowfish em modo CBC (com IV estático). A chave Blowfish é gerada aleatoriamente para cada arquivo. Depois do processo de criptografia de arquivos, a chave Blowfish é criptografada com uma chave pública, usando o algoritmo de criptografia assimétrica da função openssl_public_encrypt PHP.
The encryption parameters:
IV: 12345678
ОpenSSL public key:
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtZslxFiR9KJE05Nhh7Xk
+lVVpD9F6AQnvZeknDiwL3SBjZB/dB/LLXtwiet8LUS6JYCXnaIq4NxW1PymwGFZ
zuc/B3p+ZAFPt06veOHOfaMAI0KDMb+laNPINvn/jJ8TfvCaUMUuMEY4sayh0xwD
MwSAazMYI8rvaaS/BqhI/6vPN6D02UIpwT1TSBVeRRoPBHuYE7A93b8vJw9sBGIp
KXZ90sgP1CjdAmCbhYelelninKdeTKCGvd5YXt86grWgEVf5WXzxXi3ZK1T4w0Yt
mNhUEAwS7zCdtZ+Ak8b0M83wAirASvPZiBl6qF8hqCT5pKkwgBG//kk8JicboLsM
VQIDAQAB
-----END PUBLIC KEY-----
Isto garante que ninguém que não seja o atacante, possa ler os arquivos obtidos a partir do armazenamento de arquivos do servidor, porque só o atacante tem a chave privada, o que é essencial para decriptografar os arquivos dos clientes.
Em termos de funcionalidade, os clientes infectados oferecem suporte a poucos comandos:
GET_NEWS: Obtém arquivo(s) a partir de ./news sub-directory que são atribuídos a atual ID do cliente. Os arquivos contêm atualizações de notícias e módulos extras do Flame, bem como comandos especiais, como alterar valores de chave do Registro.
Add_entry: Armazena informações coletadas pelo cliente.
ADD_SUB_ENTRY: O mesmo procedimento que add_entry.
GET_AD: Obtém arquivos de ./ad_path directory. Esta funcionalidade parece ter sofrido um "broken" no C & C, porque não havia nenhum diretório ./ad_path e sim ./ads. No entanto, o atacante pode fazer upload de arquivos para o diretório ./ads com a utilização do painel de controle.
Saiba Mais:
[1] Secure List http://securelist.com/blog/incidents...ol-servers-27/