Linux.BackDoor.Fysbis.1

Trojan multi composants probablement créé par le groupe de hackers Sednit. Il utilise une structure modulaire qui représente chaque composant comme une classe séparée. Les modules peuvent être de deux types - les plug-ins et les contrôleurs. L'échantillon étudié contient deux plug-ins : l'un est conçu pour fonctionner avec le système de fichiers, l'autre représente un shell pour la gestion à distance et jouant le rôle de contrôleur réseau (envoie les requêtes post/get appropriées).

Lors de l'installation, le Trojan vérifie s'il possède les droits de superutilisateur du système d'exploitation (root). Si c’est le cas, le Trojan sera installé dans le dossier /bin/ sous le nom rsyncd avec la description " synchronize and backup service ". Si le Trojan n'a pas les droits de superutilisateur, Linux.BackDoor.Fysbis.1 sera installé dans ~/.config/dbus-notifier comme un fichier exécutable sous le nom dbus-inotifier avec la description "system service d-bus notifier".

Lors du lancement, le Trojan vérifie si sa copie est déjà lancée et s'il n'est pas lancé via un interpréteur de commandes nash :

1. Il vérifie que la sortie de la commande " echo $ " ne correspond pas au " nash ".
2. Il vérifie que la liste des processus en cours n'inclut pas celui nommé " rsyncd " (" dbus-inotifier " sans les droits root).

Ensuite, le malware vérifie si son auto démarrage est activé.

1. Ensuite, il consulte la liste des processus lancés et si le processus systemd est lancé, il analyse de manière récursive le répertoire " /usr/lib/systemd/ " et recherche dans chaque fichier la ligne " /bin/rsyncd ". Sinon, il utilise les fichiers rc.local trouvés dans le dossier /etc et y cherche la ligne " /bin/rsyncd ".
2. Il vérifie que le dossier " /bin/ " contient le fichier " rsyncd ".

Si le Trojan n'a pas de droits root, il cherche le fichier " dbus-inotifier " dans le répertoire " ~/.config/autostart/ ".

Si Linux.BackDoor.Fysbis.1 n’est pas déjà installé dans le système, il s'inscrit dans l'auto démarrage. Il peut le faire de deux manières :

1. Soit il écrit à la fin de tous les fichiers " rc.local " trouvés dans le dossier /etc/, la ligne " bin/rsyncd & exit 0 ".
2. Soit il crée un fichier service /usr/lib/systemd/system/rsyncd.service :

   [Unit]Description= synchronize and backup service.After=syslog.target
   [Service].ExecStart=/bin/rsyncd.OOMScoreAdjust=-500
   [Install].WantedBy=multi-user.target

   Et installe ce service en exécutant les commandes :

   ln -s '/lib/systemd/system/rsyncd.service' '/etc/systemd/system/multi-user.target.wants
   /rsyncd.service'
   systemctl daemon-reload

La présence du processus systemd lancé détermine le choix de l'enregistrement dans l'auto démarrage. Ainsi, si ce processus est présent, le Trojan utilisera la première façon, sinon, la seconde.

Si le Trojan n'a pas de droits root, il crée, afin d'assurer son démarage automatique, le fichier " ~/.config/autostart/dbus-inotifier.desktop " comme suit :

[Desktop Entry]
Type=Application
Exec=/home/user/.config/dbus-notifier/dbus-inotifier
Name[en_EN]=system service d-bus notifier
Name=system service d-bus notifier
Comment[en_EN]=
Comment=

où "/home/user/" est la valeur de la variable d'environnement HOME.

A l'étape suivante de l'installation, le malware se copie dans le dossier "/bin/rsyncd" (ou "~/.config/dbus-notifier/dbus-inotifier" sans les droits root) et lance cette copie.

L'adresse du serveur de gestion est intégrée au code du Trojan. Pour toutes les lignes de texte, le Trojan utilise l'algorithme XOR, et les clés de cryptage sont utilisées en fonction de la tâche pour laquelle cette ligne est utilisée.

Pour stocker ses fichiers, Linux.BackDoor.Fysbis.1 crée le répertoire " /usr/lib/cva-ssys " (" ~/.local/cva-ssys " sans les droits root). Le Trojan utilise la base de données SQLite3 avec le nom My_BD pour son fonctionnement, stockée dans le dossier " /usr/lib/cva-ssys/My_BD " (" ~/.local/cva-ssys/My_BD " sans le droits root). Cette base de données contient deux tables Chnnl (id, binary) et PMR (id, dword). La table prms avec " id == 0x310031 " contient la valeur du délai pour le mode de veille qui caractérise l'intervalle des requêtes au serveur de gestion, si ce dernier n'envoie pas de paquets avec la charge utile, et avec " id == 0x320032 ", la valeur du délai pour le mode actif. La table Chnnl contient les données de configuration du backdoor, cryptés à l'aide de l'algorithme RC4.

La structure des données de configuration du backdoor est la suivante :

#pragma pack(push, 1)
struct st_cncconfig
{
  _WORD id;
  _BYTE byte2;
  _BYTE byte3;
  _QWORD pCnCBeg;
  _QWORD pCnCEnd;
  _QWORD pLastElement;
};
#pragma pack(pop)

#pragma pack(push, 1)
struct st_crypted_config_data
{
  _WORD id;
  _BYTE byte2;
  _BYTE byte3;
  char* pCnC; //list of CnC addresses separated by '&'
};
#pragma pack(pop)

Avant le cryptage des données de configuration à l'aide de l'algorithme RC4, le Trojan y ajoute 11 octets de la signature (11 octets de données sont stockés dans le corps du backdoor). Une partie de la mémoire tampon est cryptée avec l'algorithme RC4 dont la longueur de la clé est de 50 octets (également stockée dans le corps du Trojan, si les clés de cryptage XOR sont disponibles, les données de configuration seront également cryptées en XOR).

Ensuite, la mémoire tampon reçue avec le bloc de configuration crypté est convertie comme suit :

1. Deux valeurs DWORD sont ajoutées au début de la mémoire tampon.
2. Le premier DWORD est égal à zéro.
3. Le second DWORD représente le hachage et est calculé par la fonction suivante (MakeHash) :

   unsigned __int16 CCryptor::ComputeHash(_BYTE *rc4_key, _DWORD rnd, _BYTE *crypted_data,
    _QWORD size)
   {
     _QWORD i;
     _WORD result;
     _BYTE CryptedByte;
     _BYTE j;
     i = 0LL;
     result = 0LL;
     while ( i < size )
     {
       CryptedByte = crypted_data[i];
       j = 0;
       while ( 1 )
       {
         result = ((unsigned __int8)result ^ CryptedByte) & 1 ? (rnd ^ (result >> 1)) :
    (result >> 1);
         ++j;
         if ( j == 8 )
           break;
         CryptedByte >>= 1;
       }
       ++i;
     }
     return result;
   }
    
   unsigned __int32 CCryptor::MakeHash(struct st_cryptor *cryptor, _BYTE *crypted_data,
    __int64 size)
   {
     _DWORD rnd;
     rnd = GetRand(0, -1);
     return (unsigned __int16)(HIWORD(rnd) ^ rnd) ^ (CCryptor::ComputeHash
   (&cryptor->rc4_key->buffer, (HIWORD(v4) ^ v4), crypted_data, size) << 16);
   }

Le processus de récupération des données de configuration de la base de données est l'inverse de celui décrit ci-dessus. Lors de la récupération de données de configuration de la base, le backdoor vérifie que la valeur du hachage est égale à la valeur sauvegardée dans la base et si la signature à 11 octets est correcte.

Puis le Trojan lance les threads dans lesquels chaque plug-in attend la réception du paquet avec la commande, ainsi qu'un thread pour surveiller l'état de la base de données et un thread pour l'échange de données avec le serveur de gestion.

Lors des requêtes au serveur de gestion, le backdoor établit l'intervalle égal à la valeur du mode veille défini. Lors de la réception de la charge utile, il modifie cette valeur pour celle du mode actif. Si le délai est activé en mode actif, mais que le paquet n'a pas été reçu, la progression d'un délai sera effectuée pour la valeur du mode actif. Ceci jusqu'au moment où le délai sera supérieur ou égal au délai du mode de veille.

Le Trojan envoie au serveur de gestion les requêtes GET suivantes :

azureon-****.com/watch/?from=W2KIa&oe=YDxQ&aq=KDRHmedegqk&btnG=G&utm=DQ&ai=Y9DmdXRnRMCsX9Mm2KPXQOTAC
azureon-****.com/search/?oe=BiQCNKF&aq=wl&oe=Zcl0al2GeHD&from=rfkpqRi-&ags=KZde&text=x
&ags=AS79lq&channel=YJa3f673&aq=GyZCExee0D&ai=CgX0bplH8YtBf2ZtNYNiCwngv

où les valeurs des paramètres from, oe, aq, btnG, utm- représentent une ligne aléatoire en BASE64 dont la longueur est de 1 à 14 caractères. le Trojan choisit au hasard les paramètres dans une liste (2 à 11 paramètres dans un ordre aléatoire) :

text=    
from=    
ai=
ags=     
oe=
aq=
btnG=    
oprnd=   
ai=
utm=     
channel= 

L'adresse de la page dans le domaine du serveur de gestion est sélectionnée dans la liste :

watch/?  
search/? 
find/?   
results/?
open/?   
search/? 
close/?  

La valeur du paramètre " ai " est " l'en-tête " de la charge utile. La valeur de ce paramètre est formée comme suit :

1. La valeur DWORD aléatoire et 7 octets de la valeur UID pour les requêtes GET/POST stockée dans le backdoor. UID est suivi par DWORD égal à -1 si le premier DWORD de données est égal à zéro, sinon le second prend la valeur du premier DWORD de données.
2. 11 octets de la mémoire tampon sont cryptés en utilisant l'algorithme XOR comme suit :

   i = 0
   while ( 1 )
   {
     crypted_buffer = (_BYTE *)this_->crypted_buffer;
     if ( i gt;= this-gt;crypted_buffer_size - 4 ) // this-gt;crypted_buffer_size == 15
       break;
     ++i;
     crypted_buffer[i + 4] ^= crypted_buffer[i & 3];

3. La mémoire tampon résultant est cryptée en utilisant l'encodage BASE64 avec l'alphabet, où les deux derniers caractères sont remplacés par " - " et " _ ".
4. Au début du tampon BASE64 crypté, une ligne aléatoire en codage Base64 d’une longueur de 5 caractères est écrite.

En réponse à cette requête, le Trojan reçoit la valeur " 400 " ou bien le paquet crypté. La réponse positive du serveur est vérifiée par la recherche d'une sous-ligne " OK " dans la réponse du serveur. Ensuite, le Trojan vérifie la taille de la réponse du serveur. Si elle comprend 7 octets et plus, le backdoor comprend que le serveur a envoyé un paquet crypté. Le Trojan décrypte le paquet en utilisant l'encodage BASE64 avec l'alphabet, où les deux derniers caractères sont remplacés par " - " et " _ ". Une fois le paquet décrypté, s’il dépasse 3 octets, le Trojan décrypte les 11 premiers octets en utilisant XOR.

Dans le paquet reçu, les 4 premiers octets sont ignorés, puis 7 octets représentent la clé qui sera utilisée dans le requêtes POST, le reste du paquet représente la charge utile.

Le module principal du Trojan peut exécuter les commandes suivantes :

Le module Remote Shell Module peut exécuter les commandes suivantes :

Le module de l'interaction avec le système de fichiers peut exécuter les commandes suivantes :

Le rapport sur les commandes exécutées par ce module s'affiche en html : la ligne contenant ce code (le rapport) est générée dans la mémoire de l'ordinateur infecté puis utilisée sans être enregistrée dans un fichier.

Le module responsable de la surveillance de la base de données, avec un intervalle d'une 1 milliseconde, vérifie la connexion au serveur de gestion, et si la connexion est établie, vérifie les valeurs dans la table prms de la base de données. Si ces valeurs ne sont pas égales à zéro, le module les envoie en requête POST au serveur de gestion.

Lors de l'envoi d'une requête POST, le Trojan utilise la valeur DWORD aléatoire et 7 octets de la clé de la réponse précédente avec le paquet crypté pour la requête GET. Les 11 octets reçus sont cryptés en utilisant l'algorithme XOR (la même méthode est utilisée lors du décryptage de la réponse du serveur à la requête GET). Puis les données pour la requête POST sont ajoutées aux 11 octets de la clé et le tampon obtenu est crypté en utilisant l'algorithme BASE64 avec l'alphabet déjà mentionné. Ensuite, une ligne aléatoire BASE64 avec la longueur de 5 caractères est ajoutée au début de la ligne BASE64 obtenue. L'en-tête de la requête POST est généré comme celui de la requête GET. La charge utile est générée comme suit :

1. La valeur DWORD aléatoire est enregistrée à offset zéro.
2. Puis les 11 octets de la clé reçue dans la requête GET sont écrits pour les requêtes POST.
3. Ensuite, le reste des données est enregistré.
4. Les 11 premiers octets du tampon obtenu sont cryptés en XOR.
5. Après le cryptage XOR, le tampon est crypté en BASE64 et une ligne aléatoire en codage BASE64 avec la longueur de 5 caractères est écrite au début.

Le même thread après 4 requêtes POST attend une seconde et envoie au serveur de gestion une requête POST avec le nombre de fonctions de la bibliothèque sqlite3, dont les adresses que le Trojan a réussi à obtenir (le nombre maximum est de 13).