Linux.Rekoobe.1

SHA1

• a11bda0acdb98972b3dec706d35f7fba59587f99 (SPARC)
• 04f691e12af2818015a8ef68c6e80472ae404fec (SPARC)
• 466d045c3db7c48b78c6bb95873b817161a96370 (SPARC)
• cd274e6b73042856e9eec98d258a96cfbe637f6f (Intel x86)
• 8e93cfbaaf7538f8965080d192df712988ccfc54 (Intel x86-64)

Trojan capable d'infecter des appareils avec l'architecture SPARC et Intel x86, x86-64, tournant sous OS Linux. Le Trojan garde les données de configuration dans un fichier, crypté par XOR. Les spécialistes connaissent les placements du fichier de configuration suivants :

/usr/lib/liboop-trl.so.0.0.0
/usr/lib/libhistory.so.5.7
/usr/lib/libsagented.so.1
/usr/lib/libXcurl
/usr/lib/llib-llgrpc

Ce fichier a la structure suivante :

SECRET value
MAGIC value
PROXYHOST value
PROXYPORT value
USERNAME value
PASSWORD value
ENDPOINT value
SERVER_PORT value
CONNECT_BACK_DELAY value

Au lieu de " value " il contient la valeur du paramètre approprié. Après avoir lu le fichier de configuration, le Trojan s'adresse périodiquement (l'intervalle est spécifié par CONNECT_BACK_DELAY), au serveur C&C dont l'adresse est spécifiée par le paramètre ENDPOINT. Si la valeur du paramètre PROXYHOST est différente de « none », le Trojan établit une connexion avec le serveur C&C via un serveur proxy, dont il extrait les données d'authentification de son fichier de configuration.

La session avec le serveur C&C commence par l'envoi de la valeur du paramètre MAGIC depuis le fichier de configuration et la réception de la réponse dont la longueur est de 40 octets. Puis les 40 octets reçus sont divisé en deux blocs de 20 octets et seront utilisés pour initialiser les contextes AES, un pour chaque donnée envoyée ou reçue :

int __cdecl AES_Init(st_aes_ctx *aes_ctx, char *data, char *salt)
{
  ...
  if ( RecvPacket(fd, buffer, 40, 0) != 1 )
    goto err_occured;
  *(_DWORD *)dec_salt = *(_DWORD *)buffer;
  *(_DWORD *)&dec_salt[4] = *(_DWORD *)&buffer[4];
  *(_DWORD *)&dec_salt[8] = *(_DWORD *)&buffer[8];
  *(_DWORD *)&dec_salt[12] = *(_DWORD *)&buffer[12];
  *(_DWORD *)&dec_salt[16] = *(_DWORD *)&buffer[16];
  *(_DWORD *)enc_salt = *(_DWORD *)&buffer[20];
  *(_DWORD *)&enc_salt[4] = *(_DWORD *)&buffer[24];
  *(_DWORD *)&enc_salt[8] = *(_DWORD *)&buffer[28];
  *(_DWORD *)&enc_salt[12] = *(_DWORD *)&buffer[32];
  *(_DWORD *)&enc_salt[16] = *(_DWORD *)&buffer[36];
  AES_Init(&aes_ctx_encrypt, secret, enc_salt);
  AES_Init(&aes_ctx_decrypt, secret, dec_salt);
  ...
}

où la fonction AES_Init génère une clé de chiffrement basée sur la valeur de SHA1 du paramètre secret et du bloc enc_salt ou dec_salt transmis :

int __cdecl AES_Init(st_aes_ctx *aes_ctx, char *data, char *salt)
{
  ...
  sha1_init(&ctx);
  sha1_update(&ctx, data, strlen(data));
  sha1_update(&ctx, salt, 0x14u);
  sha1_final(&ctx, hash);
  AES_InitKey(aes_ctx, hash, 128);
  ...
}

La fonction AES_Init pour chaque contexte AES génère également deux blocs spéciaux de 40 octets chacun qui seront utilisés comme une signature. Pour ce faire, le bloc de données verify_1 est rempli par 40 octets avec la valeur 0x36, et le bloc de données verify_2 est rempli par 40 octets avec la valeur 0x5C. Puis les premiers 20 octets de chaque bloc de données sont cryptés par XOR avec les 20 octets appropriés de la clé AES.

Toutes les données suivantes envoyées pendant cette session seront envoyées via des paquets spéciaux.

Le premier paquet contient 16 octets de l'identificateur. Le Trojan les compare avec l'identificateur dans son corps et s'ils sont les mêmes les envoie au serveur comme confirmation.

Cela établit la connexion avec le serveur et le Trojan essaie d'obtenir la commande. Lors de la réception de la commande, ses 2 premiers octets sont ignorés, le troisième représente l'identificateur de la commande.

Lors de la réception du colis du serveur C&C le Trojan reçoit 16 octets, qui seront décryptés en mode AES-CBC-128. Le premier WORD (MSB) du tampon représente la taille du bloc de données suivant (paramètre size).

Puis le Trojan calcule la taille du paquet par la formule «packetsize = size + 2 octets + égalisation» et reçoit les données dont la taille est packetsize + 4 octets dans le même tampon à offset 0x10 octets de son début. Les derniers 20 octets représentent la signature.

Pour vérifier la signature, le premier DWORD de la signature est modifié comme suit : les premiers trois octets sont remplacés par des zéros et le quatrième reçoit le numéro du paquet (le Trojan calcule le nombre de paquets envoyés/reçus dans les contextes AES). Puis le tampon qui a reçu les données et dans lequel le DWORD a été modifié est utilisé pour générer le hachage SHA1 (le tampon est nommé buffer) :

...
sha1_init(&sha1_ctx);
sha1_update(&sha1_ctx, aes_ctx_decrypt.verify_1, 0x40u);
sha1_update(&sha1_ctx, buffer, size + 4);
sha1_final(&sha1_ctx, &hash);
sha1_init(&sha1_ctx);
sha1_update(&sha1_ctx, aes_ctx_decrypt.verify_2, 0x40u);
sha1_update(&sha1_ctx, &hash, 0x14u);
sha1_final(&sha1_ctx, &hash);
...

Il faut noter que seule la charge utile et la valeur DWORD contenant le numéro de séquence du paquet sont hachés. 4 DWORD et la signature ne sont pas hachés.

Les 20 premiers octets de la valeur de hachage sont comparés avec la signature du paquet, si cela correspond, le colis sera décrypté, sinon - il est considéré comme non valide.

Le Trojan envoie le colis au serveur de contrôle et de commande de la même façon.

Il peut exécuter trois commandes :

• Reverse Shell (cmd == 0x03)
• Télécharger le fichier (cmd == 0x02)
• Télécharger le fichier sur un serveur de contrôle et de commande (cmd == 0x01)

News sur cette menace