Overblog Suivre ce blog
Editer l'article Administration Créer mon blog
quoideneuf1.over-blog.com

Les utilisateurs de Linux ciblés par le nouveau cheval de Troie Rekoobe

4 Décembre 2015 , Rédigé par nicko Publié dans #informatique

Une mauvaise surprise pour les utilisateurs de Linux arrive pour noël, celle-ci prend forme dans l'arrivée d'un nouveau cheval de Troie appelé par l'entreprise en sécurité informatique Dr web qui l'a découvert Rekoobe ou Linux.Rekoobe .1 .

Les utilisateurs de Linux ciblés par le nouveau cheval de Troie Rekoobe

Les chercheurs en sécurité ont commencé à observer le cheval de Troie au début du mois d'octobre, mais il leur a fallu un certain temps pour observer son comportement et de disséquer son activité.

Rebooke peut cibler les machines Linux 32 et 64 bits

Selon le personnel de Dr.Web, la première version du cheval de Troie ne visait que les architectures SPARC Linux, mais il n'a pas fallu longtemps avant qu'une version améliorée ait été en mesure de cibler les PC Linux fonctionnant avec des puces Intel, avec des architectures 32 bits et 64 bits.

En interne, le cheval de Troie est extrêmement simple, mais celui-ci se protège contre l'ingénierie inversé. Il utilise un fichier de configuration crypté (via l'algorithme XOR) afin de se garder des regards indiscrets, et dans certains cas, il se connecte périodiquement à son serveur C & C via un proxy pour cacher l'emplacement principal du serveur maître.

Quant à ses capacités, le cheval de Troie ne peut pas faire grand-chose, mais ce qu'il fait est plus que suffisant pour assurer une compromission complète du système si l'exploitant du cheval de Troie le désire.

Rebooke peut exécuter seulement trois opérations:

→ téléchargement de fichiers de son serveur C & C

→ télécharger des fichiers vers le serveur C & C

→ exécuter des commandes sur le shell local

Une petite, mais puissante menace

Alors que beaucoup pourrait penser que Rebooke est inoffensif et une simple nuisance, la conception simple du cheval de Troie permet aux pirates de variés leurs attaques et de livrer des charges utiles plus puissantes sur les systèmes infectés.

Le fait que le cheval de Troie utilise le cryptage pour son fichier de configuration plus un mécanisme compliqué de validation des communications C & C montre que ses opérateurs ont pris grand soin de s'assurer que leur outil ne peut pas être facilement deviné.

Nous sommes peut-être en face d'une nouvelle souche de logiciels malveillants en train de naître, et Linux.Rebooke.1 étant juste à un stade alpha dans le développement de cheval de Troie.

Source: Softpedia

Description détaillée par Dr web

SHA1

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

Une cheval de Troie pour Linux vise l'architecture SPARC et l'architecture Intel x86, x86-64. Les données de configuration du cheval de Troie sont stockées dans un fichier chiffré à l'aide d'un algorithme XOR.


Possible emplacement connu du fichier de configuration:
/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
Le dossier 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 d'une variable de «valeur», il stocke la valeur du paramètre correspondant. Une fois que les données à partir du fichier de configuration sont reçues avec succès, le cheval de Troie se réfère au serveur C&C à des intervalles spécifiés via le paramètre CONNECT_BACK_DELAY, L'adresse du serveur est spécifiée par le paramètre ENDPOINT. Si la valeur est différente de proxyHost «none», la connexion est établie en utilisant un serveur proxy, les données d'autorisation sont également récupérées à partir du fichier de configuration.

Une session de communication avec le serveur de gestion commence par l'envoi de paramètre MAGIC du fichier de configuration et reçoit 40 octets en réponse. En outre, les 40 octets reçus sont divisés en deux blocs de 20 octets qui sont utilisés pour initialiser le contexte AES, un bloc sert à la réception des données et l'autre, pour en envoyer.

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 d'AES_INIT produit une clé de cryptage basée sur la valeur de SHA1 via le paramètre "secret" et du bloc envoyé d'enc_salt ou de dec_salt :

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 d'AES_INIT pour chaque contexte AES crée aussi deux blocs de 40 octets spéciaux qui seront utilisés plus tard comme une signature. Pour cela, 40 octets avec la valeur de 0x36 sont ajoutés au tableau verify_1 et 40 octets avec la valeur de 0x5C sont ajoutés au tableau verify_2. Alors les 20 premiers octets de chaque tableau sont cryptés avec l'algorithme XOR contenant 20 octets correspondants de la clé d'AES.

Toutes les informations transmises postérieurement qu'elles soient envoyées ou reçues pendant la connexion établie seront envoyées comme des paquets spécifiquement formés.

Le premier paquet reçu contient l'identifiant de 16 octets. Le cheval de Troie le compare avec un identifiant qu'il a déjà stocké. Si l'objectif est trouvé, le logiciel malveillant envoie la vérification au serveur.

Une fois que la connexion au serveur C*C est établi, le cheval de Troie tente d'obtenir une commande du serveur. lors de la réception, les deux premiers octets sont ignorés et le troisième représente un identifiant de commande.

Pendant la réception d'un paquet du serveur, le logiciel malveillant acquière 16 octets, qui sont cryptés dans le mode AES-CBC-128. Le premier mot (MSB) de la mémoire-tampon qui en résulte est la taille du bloc de données suivant (taille du paramètre).

Après ceci, le cheval de Troie calcule la taille de paquet via "packetsize = la taille + 2 octets + l'alignement" le formule et reçoit les données de packetsize + 4 octets dans la même mémoire-tampon utilisant la compensation d'octets 0x10 depuis le début. Les derniers 20 octets sont la signature.

Afin de vérifier la signature, la modification de son premier DWORD est comme ceci: les trois premiers octets sont remplacés par des zéros, et le quatrième contient le numéro de paquet.
(Le cheval de Troie conserve une trace du nombre de paquets reçus / envoyés dans le contexte approprié d'AES). En outre, la mémoire-tampon qui reçoit les données et DWORD qui a été modifié, sont utilisés pour générer le SHA1 de hachage (la mémoire-tampon est spécifiée en tant que tamp
on):

...
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 devrait être noté que seule une charge utile et une valeur de DWORD qui contient le numéro de paquet sont hachés. 4 DWORDS utilisés pour la signature ne sont pas inclus dans les données hachées.

Les premiers 20 octets reçu du hachage sont comparés avec une signature de paquet. Si une similarité est trouvée, le paquet est décrypté. Sinon, il est considéré comme invalide.

L'envoi du paquet au serveur est exécuté de la même façon.

Rebooke peut exécuter seulement trois opérations:

→ téléchargement de fichiers de son serveur C & C

→ télécharger des fichiers vers le serveur C & C

→ exécuter des commandes sur le shell local

Partager cet article

Repost 0

Commenter cet article