P

odsłuchiwanie ruchu sieciowego najczęściej kojarzy się nam z systemami typu: IDS/IPS lub narzędziami takimi, jak: tcpdump. Głównie programy te wykorzystywane są z różnych uzasadnionych powodów np. ochrona sieci lub rozwiązywanie problemów sieciowych. Czasami jednak proces ten może zostać użyty przez złośliwe oprogramowanie lub atakującego w celu kradzieży informacji, czy też aktywacji uśpionych tylnych wejść do systemu. Na szczęście za pomocą bezpośredniego dostępu do pliku /proc/net/packet możemy szybko zidentyfikować procesy powiązane z gniazdami pakietów. Tego typu gniazda (ang. sockets) służą do odbierania lub wysyłania surowych pakietów na poziomie sterownika urządzenia sieciowego (warstwa 2 OSI ; najczęściej karty sieciowej) pozwalając na bardziej bezpośrednią interakcję ze stosem sieciowym niż standardowe gniazda Berkeley w warstwie 4’tej (np. AF_INET / AF_INET6 + SOCK_STREAM / SOCK_DGRAM). Nas będzie interesować typ gniazda albo SOCK_RAW (dla surowych pakietów zawierających nagłówek warstwy łącza), albo SOCK_DGRAM (dla pakietów przetworzonych z usuniętym nagłówkiem warstwy łącza):

root@darkstar:~# cat /proc/net/packet
sk               RefCnt Type Proto  Iface R Rmem   User   Inode
ffff8f34c7d7d000 3      3    88cc   2     1 0      998    6666
ffff8f34c7d7c000 3      3    88cc   3     1 0      998    6685
ffff8f34c0b80000 3      3    0003   0     1 0      0      8767
ffff8f34c5243800 3      2    0003   0     1 0      0      9350

Nas będzie interesować ostatnia kolumna, czyli Inode, która pozwoli nam na identyfikację procesów i ich właścicieli. Pozostaje nam przeszukanie procfs pod numerach ze wspomnianej kolumny, aby otrzymać numery identyfikacyjne procesów odpowiedzialnych za otwarte gniazda pakietów:

root@darkstar:~# ls -al /proc/*/fd/* 2> /dev/null | egrep '(6666|6685|8767|9350)'
lrwx------ 1 root            root            64 Sep 1 19:44 /proc/1053/fd/3 -> socket:[8767]
lrwx------ 1 root            root            64 Sep 1 19:44 /proc/1067/fd/5 -> socket:[9350]
lrwx------ 1 systemd-network systemd-network 64 Sep 1 19:44 /proc/404/fd/18 -> socket:[6666]
lrwx------ 1 systemd-network systemd-network 64 Sep 1 19:44 /proc/404/fd/19 -> socket:[6685]

Powyżej widzimy dwa procesy (ID: 404) systemd przechwytujące ruch sieciowy (często są to protokoły wykrywania sieci i urządzeń sieciowych – tutaj LLDP [88cc]). Mamy również dwa kolejne podejrzane procesy (ID: 1053 oraz 1067), które wymagają zbadania – tym bardziej, że ich właścicielem jest administrator systemu i mają wartość protokołu 0003, który reprezentuje ETH_P_ALL. Oznacza to, że tego typu gniazdo pakietów skonfigurowane jest do przechwytywania każdego pakietu przechodzącego przez dany interfejs sieciowy (tryb promiscuous). Kiedy program tworzy gniazdo pakietów z protokołem ETH_P_ALL, w zasadzie mówi jądru systemu: „- Daj mi kopię wszystkich surowych ramek danych, które widzisz na tej karcie sieciowej”. Jest to podstawowa funkcja wykorzystywana przez narzędzia do analizy sieci:

root@darkstar:~# ls -al /proc/1053/cwd
lrwxrwxrwx 1 root root 0 Sep 16 19:57 /proc/1053/cwd -> /root

root@darkstar:~# ls -al /proc/1053/exe
lrwxrwxrwx 1 root root 0 Sep 16 19:57 /proc/1053/exe -> /usr/sbin/netsniff-ng

root@darkstar:~# cat /proc/1053/comm
netsniff-ng

root@darkstar:~# cat /proc/1053/cmdline
netsniff-ng--inany--filterport 80--jumbo-support--ascii-V

root@darkstar:~# cat /proc/1053/maps
62484cd10000-62484cd15000 r--p 00000000 08:02 533368  /usr/sbin/netsniff-ng
75fc96400000-75fc966c5000 r--p 00000000 08:02 683102  /usr/share/GeoIP/GeoIP.dat
75fc91c00000-75fc95c00000 rw-s 00000000 00:08 8767    socket:[8767]

root@darkstar:~# ls -al /proc/1067/cwd
lrwxrwxrwx 1 root root 0 Sep 16 20:10 /proc/1067/cwd -> /root

root@darkstar:~# ls -al /proc/1067/exe
lrwxrwxrwx 1 root root 0 Sep 16 20:10 /proc/1067/exe -> /usr/bin/tcpflow

root@darkstar:~# cat /proc/1067/comm
tcpflow

root@darkstar:~# cat /proc/1067/cmdline
tcpflow-iany-cport80

root@darkstar:~# cat /proc/1067/maps
60590f0bd000-60590f0c5000 r--p 00000000 08:02 531829  /usr/bin/tcpflow
7c0bf2b0a000-7c0bf2d0a000 rw-s 00000000 00:08 9350    socket:[9350]

Oczywiście, aby przyśpieszyć ten proces, możemy użyć takich poleceń jak lsof oraz ss. Programy te są przydatne, jeśli są już zainstalowane w systemie, ale istnieją pewne zastrzeżenia. Po pierwsze – jeśli ich nie ma w systemie nie możemy ich zainstalować, ponieważ zmienimy stan badanego systemu i możemy nadpisać dowody kompromitacji systemu. Po drugie niektóre warianty złośliwego oprogramowania często przechwytują wywołania systemowe i filtrują wyniki programów, aby ukryć się przed takimi narzędziami, więc istnieje ryzyko, że nic nie ustalimy. Niemniej warto znać ich zastosowanie:

root@darkstar:~# lsof -p 1053
COMMAND    PID USER   FD   TYPE DEVICE SIZE/OFF   NODE NAME
netsniff- 1053 root  cwd    DIR    8,2     4096 655362 /root
netsniff- 1053 root  txt    REG    8,2   250136 533368 /usr/sbin/netsniff-ng
netsniff- 1053 root  mem    REG    0,8            8767 socket:[8767]
netsniff- 1053 root    3u  pack   8767      0t0    ALL type=SOCK_RAW

root@darkstar:~# lsof -p 1067
tcpflow 1067 root  cwd       DIR    8,2     4096 655362 /root
tcpflow 1067 root  txt       REG    8,2   581064 531829 /usr/bin/tcpflow
tcpflow 1067 root  mem       REG    0,8            9350 socket:[9350]
tcpflow 1067 root    5u     pack   9350      0t0    ALL type=SOCK_DGRAM

root@darkstar:~# ss -0 -p
Netid  Recv-Q  Send-Q  Local Address:Port  Peer Address:Port  Process
p_raw  0       0              LLDP:enp0s3              *      users:(("systemd-network",
                                                                       pid=404,fd=18))
p_raw  0       0              LLDP:enp0s8              *      users:(("systemd-network",
                                                                       pid=404,fd=19))
p_raw  0       0                 *:*                   *      users:(("netsniff-ng",
                                                                       pid=1053,fd=3))
p_dgr  0       0                 *:*                   *      users:(("tcpflow",
                                                                       pid=1067,fd=5))

Teraz już wiemy, jak /proc/net/packet może pomóc nam ujawnić podsłuchujące ruch sieciowy procesy, a nawet może ujawnić rozbieżność z tym, co widzimy w wynikach ze standardowych narzędzi.

Więcej informacji: Detecting Packet Sniffing Malware on Linux, List packet sniffers

// sleeper.c

#include <stdio.h>
#include <unistd.h>

int main()
{

    sleep(60);
    printf("Infecting Linux Host.");
    return 0;
}

agresor@darkstar:~$ gcc -o sleeper sleeper.c
agresor@darkstar:~$ exec -a '/lib/systemd/systemd --abuse' ./sleeper &
[1] 5354
agresor@darkstar:~$ ps x
    PID TTY      STAT   TIME COMMAND
   4925 ?        Ss     0:00 /lib/systemd/systemd --user
   4926 ?        S      0:00 (sd-pam)
   4988 ?        R      0:00 sshd: agresor@pts/0
   4989 pts/0    Ss     0:00 -bash
   5354 pts/0    S      0:00 /lib/systemd/systemd --abuse
   5357 pts/0    R+     0:00 ps x

Należy mieć na uwadze, że exec najlepiej w tym przypadku działa z plikami binarnymi. I bardzo prosto wykryć ten trick:

agresor@darkstar:~$ ls -al /proc/5354/exe
lrwxrwxrwx 1 agresor agresor 0 Oct 27 19:24 /proc/5354/exe -> /home/agresor/sleeper
agresor@darkstar:~$ cat /proc/5354/cmdline
/lib/systemd/systemd --abuse
agresor@darkstar:~$ cat /proc/5354/comm
sleeper

Więcej informacji: Why isn’t `exec -a` working the way I expect?

W

artykule ukrywanie procesów za pomocą ld.so.preload poznaliśmy zasadę działania podstawowych narzędzi do zarządzania procesami w systemie Linux oraz w jaki sposób za pomocą biblioteki współdzielonej możemy je oszukać. W tej publikacji postaramy się napisać prosty skrypt w języku Python, który za pomocą enumeracji sprawdzi czego nam nie mówią oszukane narzędzia. Jego zasada działania jest bardzo prosta – jego zadaniem jest wejść do katalogu /proc i pobrać wszystkie katalogi, które mają format numeryczny ([0-9]) i dodać je do listy:

proc_path = '/proc'

def process_list_behind_the_fog():
    pid_list = []
    for pid_number in os.listdir(proc_path):
        if os.path.isdir(os.path.join(proc_path, pid_number)):
            if pid_number.isnumeric():
                pid_list.append(int(pid_number))
    return(pid_list)

[ czytaj całość… ]

P

oniżej zaprezentuje, jak za pomocą polecenia mount ukryć dowolny proces w systemie przed takim poleceniem jak np. ps. Dokonamy tego dzięki funkcji bind. Klasyczne montowanie tworzy widok urządzenia pamięci masowej jako drzewa katalogów. Funkcja bind zamiast tego pobiera istniejące drzewo katalogów i replikuje je w innym punkcie. Montując katalog w ten sposób możemy myśleć o montowaniu jak o aliasie do innej ścieżki. Katalogi i pliki w są takie same jak w oryginale. Każda modyfikacja po jednej stronie jest natychmiast odzwierciedlana po drugiej stronie, ponieważ oba widoki przedstawiają te same dane. Na przykład, kiedy powiążemy katalog /tmp/narf z /tmp/nfsec, oba będą odwoływać się do tych samych danych:
[ czytaj całość… ]

N

arzędzie pamspy jest programem, który został zainspirowany przez podobną pracę, ale stworzoną znacznie wcześniej (Brendon Tiszka poczynił to dzieło na swoich studiach): 3snake. W przeciwieństwie do swojego poprzednika nie korzysta już z mechanizmu odczytu pamięci wywołań systemowych sshd i sudo, które obsługują uwierzytelnianie oparte na hasłach, ale wykorzystuje technologię eBPF. Dzięki temu jest w stanie śledzić konkretną funkcję w przestrzeni użytkownika wewnątrz biblioteki PAM (ang. Pluggable Authentication Modules) używanej przez wiele krytycznych aplikacji (sudo, sshd, passwd, gnome, X11 itp.) do obsługi uwierzytelniania. Ponieważ pamspy opiera się na libpam przed uruchomieniem programu musimy podać ścieżkę, gdzie biblioteka ta jest zainstalowana na naszej dystrybucji. W tym celu należy wydać następujące polecenie:

ldconfig -p | egrep -o '\/.*libpam\.so.*'

Po uzyskaniu ścieżki możemy uruchomić program:

sudo ./pamspy -p /lib/x86_64-linux-gnu/libpam.so.0

Załaduje on program eBPF, aby podczepić się pod funkcję pam_get_authtok z libpam.so. Za każdym razem, gdy proces uwierzytelnienia spróbuje sprawdzić nowego użytkownika, wywoła on wspomnianą funkcję pam_get_authtok, a pamspy będzie na konsolę zrzucać zawartość krytycznych sekretów. Jeśli teraz w drugiej konsoli zalogujemy się do serwera i podniesiemy swoje uprawnienia program powinien odnotować ten fakt:

1500   | sshd            | agresor              | K0ci.0g0n
1528   | sudo            | agresor              | K0ci.0g0n
3815   | passwd          | agresor              | P5i3.U5zy

Jeśli chcemy przeprowadzić kompilację programu ze źródeł to wymaga on kilku pakietów (Ubuntu 22.04):

apt install git make clang-11 gcc libelf-dev pkg-config -y 
apt install linux-tools-common linux-tools-5.15.0-41-generic -y
git clone https://github.com/citronneur/pamspy --recursive
cd pamspy/src
make

Nie musimy kompilować programu od podstaw, ponieważ w repozytorium jest już także plik zbudowany jako statyczna binarka bez żadnych zależności.

Więcej informacji: pamspy

W

biologii symbiont to organizm żyjący w symbiozie z innym organizmem (np. bakterie w jelicie grubym u człowieka, bakterie; które trawią celulozę u przeżuwaczy). Symbioza może być obustronnie korzystna dla obu organizmów, ale czasami może być pasożytnicza, gdy jeden organizm zyskuje, a drugi jest uszkadzany. Kilka miesięcy temu zespoły bezpieczeństwa z firmy Intezer oraz BlackBerry odkryły nowe, dobrze maskujące się złośliwe oprogramowanie dla systemu Linux, które działa właśnie w taki pasożytniczy sposób. Tym, co odróżnia Symbiote od innych złośliwych programów dla systemu Linux, z którymi zazwyczaj można się spotkać, jest fakt, że musi zainfekować inne uruchomione procesy, aby wyrządzić szkody zainfekowanym maszynom. Nie jest to samodzielny plik wykonywalny uruchamiany w celu zainfekowania systemu, ale biblioteka obiektów współdzielonych (.so), która jest ładowana do wszystkich uruchomionych procesów przy użyciu LD_PRELOAD (T1574.006) i pasożytniczo infekuje maszynę. Po zainfekowaniu wszystkich uruchomionych procesów zapewnia aktorowi funkcjonalność rootkita, możliwość zbierania poświadczeń oraz zdalny dostęp.
[ czytaj całość… ]

P

rzewiduje się, że do końca 2025 roku ponad 30 miliardów urządzeń IoT będzie podłączonych do internetu. To doskonale definiuje cele na kolejne lata dla szkodliwego oprogramowania. Aktualnie w internecie występuje wzmożona aktywność programu XorDDoS. Jest to koń trojański z funkcjami rootkita wykorzystywany do przeprowadzania ataków DDoS na dużą skalę. Jego nazwa pochodzi od szyfrowania XOR, które często jest wykorzystywane w złośliwym oprogramowaniu, jak i w komunikacji sieciowej do C&C. Inspirowany projektem rooty został stworzony dla wielu architektur systemu Linux: ARM, x86 i x64. Wykryty w 2014 roku przez grupę badawczą zajmującą się bezpieczeństwem MalwareMustDie i do dzisiaj pozostaje aktywny. De facto w 2021 roku aktywność tego malware wzrosła o 123% w porównaniu do 2020 roku. Z kolei według telemetrii firmy Microsoft XorDDoS od początku roku zwiększył swoją aktywność o 254%. Prześledźmy jego działanie.
[ czytaj całość… ]

S

zkodliwe oprogramowanie na systemach Linux bardzo często usuwa swoje pliki binarne po uruchomieniu. Ma to na celu oszukanie skanerów oraz systemów kontroli integralności, które bazują na analizie plików. Dla przykładu takiego zachowania posłużymy się kopią polecenia sleep:

cd /tmp
cp /bin/sleep x
./x 3600 &
rm x

Możemy teraz sprawdzić, czy rzeczywiście plik już nie istnieje:

root@darkstar:~# ls -al /tmp/x
ls: cannot access /tmp/x: No such file or directory

Spójrzmy teraz na listę procesów:

root      1437  0.0  0.0   6176   780 pts/1    S    21:11   0:00 ./x 3600

Idąc tropem PID możemy sprawdzić informacje w /proc

root@darkstar:/tmp# ls -al /proc/1437/exe
lrwxrwxrwx 1 root root 0 Jun 17 21:15 /proc/1437/exe -> '/tmp/x (deleted)'

System pokazuje nam skasowany obiekt w podanej ścieżce, ale system plików Linuksa tak naprawdę nie usunie tego pliku, dopóki uruchomiony proces ma go w stanie otwartym. Plik tam jest, ale po prostu nie jest nam pokazywany. Link symboliczny /proc/1437/exe z łatwością jest nam w stanie dostarczyć plik binarny, który uruchomił dany proces. Po prostu możemy go skopiować w dowolne miejsce, aby poddać go dalszej analizie:

root@darkstar:/tmp# cp /proc/1437/exe /tmp/y
root@darkstar:/tmp# sha1sum /tmp/y
bebcce23072c4d831ce8e2822a0858d6aa813067  /tmp/y
root@darkstar:/tmp# sha1sum /bin/sleep
bebcce23072c4d831ce8e2822a0858d6aa813067  /bin/sleep

Więcej informacji: How To Recover A Deleted Binary From Active Linux Malware