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

W

systemie Linux wszystko jest plikiem. W celu uruchomienia programu w tym systemie musi on istnieć jako plik i być dostępny w jakiś sposób przez hierarchię systemu plików (tak właśnie działa execve() wykonując program, do którego odnosi się ścieżka dostępu). Plik ten może znajdować się na dysku lub w pamięci (tmpfs), ale nadal potrzebujemy ścieżki do pliku. Dzięki temu bardzo łatwo jest kontrolować, co jest uruchamiane w systemie Linux i ułatwia to wykrywanie zagrożeń oraz narzędzi atakujących. Pomaga to też w nakładaniu opowiednich praw dostępu i polityk kontroli dostępu zapobiegając nieuprzywilejowanym użytkownikom umieszczać i wykonywać pliki gdziekolwiek. Jednak technika użyta w DDexec nie uruchamia nowego procesu w danej ścieżce, ale przejmuje już istniejący.
[ czytaj całość… ]

P

roces debugowania (ang. debugging) polega na kontrolowanym wykonaniu programu pod nadzorem debugera. Podobnie wygląda proces śledzenia (ang. tracing), który działa zarówno w trybie debugowania, jak i rejestrowania wybranych zdarzeń w czasie rzeczywistym. W systemie Linux często możemy spotkać się z tego typu czynnościami w kontekście podsłuchiwania innych procesów. Zatem pozostaje pytanie, czy istnieje możliwość sprawdzenia czy dany proces jest aktualnie poddawany procesowi śledzenia lub debugowania? Otóż każdy uruchamiany proces może zajrzeć do ścieżki /proc/self/status i sprawdzić, czy klucz TracerPid ma inną wartość niż 0:

agresor@darkstar:~$ cd /proc/self; cat status | egrep -B7 ^TracerPid
Name:	bash
Umask:	0022
State:	S (sleeping)
Tgid:	2998765
Ngid:	0
Pid:	2998765
PPid:	2998764
TracerPid:	0

ponieważ wiersz „TracerPid” z wartością „0” oznacza, że żaden proces nie „śledzi” tego procesu. Za pomocą języka Python możemy napisać prosty skrypt o nazwie show_debbuger.py, który sprawdzi czy aktualnie w systemie jest uruchomiony jakiś proces, który jest śledzony i poda nam jego dane:

#!/usr/bin/env python3
# Debugger detector v0.1

import os
import re

def show_debugger(proc_path: str):
    pid_list, pid_found = [], []
    for pid in os.listdir(proc_path):
        if os.path.isdir(os.path.join(proc_path, pid)) and pid.isnumeric():
            pid_list.append(pid)
    for pid_number in pid_list:
        full_path = os.path.join(proc_path, pid_number, 'status')
        if os.path.isfile(full_path):
            with open(full_path, 'r') as proc_file:
                status_file = proc_file.read()
                tracer_pid = re.search(r'(?P<name>TracerPid.*)\s+(?P<pid>\d+)',
                                       status_file).group('pid')
            if tracer_pid != '0':
                process_name = re.search(r'Name:\s+(?P<name>\w+)',
                                         status_file).group('name')
                tracer_path = os.path.join(proc_path, tracer_pid, 'status')
                with open(tracer_path, 'r') as tracer_file:
                    status_file = tracer_file.read()
                    tracer_name = re.search(r'Name:\s+(?P<name>\w+)',
                                            status_file).group('name')
                print(f'Process: {process_name} with PID: {pid_number} is traced with:'
                      f' {tracer_name} with PID: {tracer_pid}')
                pid_found.append(pid_number)
    if pid_found:
                return True
    else:
        print('No process tracing found!')
        return False


if __name__ == '__main__':
    show_debugger('/proc')

W pierwszej konsoli możemy sprawdzić czysty system:

root@darkstar:~#./show_debbuger.py
No process tracing found!

W drugiej konsoli uruchamiamy strace na dowolnym procesie i uruchamiamy skrypt ponownie:

root@darkstar:~#./show_debbuger.py
Process: sshd with PID: 2055265 is traced with: strace with PID: 2061163

Dokładamy jeszcze gdb ponownie sprawdzając system:

root@darkstar:~#./show_debbuger.py
Process: multipathd with PID: 352 is traced with: gdb with PID: 2061871
Process: sshd with PID: 2055265 is traced with: strace with PID: 2061163

Zawsze też możemy wyłączyć możliwość śledzenia w systemie.

Więcej informacji: Detecting the Presence of a Debugger in Linux, How do you detect that you’re being ptraced?

// 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?

P

ocząwszy od wersji 4.19 jądra systemu Linux możliwe jest uniemożliwienie otwierania FIFO lub zwykłych plików niebędących własnością użytkownika w globalnie zapisywalnych katalogach z ustawionym sticky bit (np. /tmp). Ochronę tę można stosować osobno dla FIFO, zwykłych plików, symlinków / hardlinków poprzez odpowiednie ustawienia z poziomu sysctl. Ustawienia te oparte są na łatce HARDEN_FIFO, która znajdowała się w projekcie Openwall Solar Designera, a ich celem jest utrudnienie ataków polegających na spoofingu danych. Poniżej znajduje się krótka lista starych luk, którym można było zapobiec dzięki tej funkcji (niektóre z nich pozwalają nawet na eskalację uprawnień):
[ czytaj całość… ]

S

ystemy wieloużytkownikowe zaprojektowane są na udostępnianie dużej liczby informacji użytkownikom. Wiele z tych informacji jest „publiczna” i może być współdzielona pomiędzy różnymi użytkownikami. Nigdy nie można lekceważyć wpływu takich informacji na bezpieczeństwo. Poniżej znajduje się prosty skrypt, który umożliwia złośliwemu użytkownikowi podsłuchiwanie naciśnięć klawiszy innych użytkowników przy użyciu takich informacji. Atak wykorzystuje zwykłe nieuprzywilejowane konto i informacje o procesie ujawnione przez wirtualny system plików procfs (ang. process file system) obsługiwany przez m.in. system Linux. Zawiera on hierarchię plików wirtualnych, które opisują aktualny stan jądra, w tym dane statystyczne o pamięci procesów i niektórych ich wartościach rejestrów. Są one używane przez takie programy jak ps i top, aby zbierać i prezentować informacje o systemie oraz pomagać w debugowaniu oprogramowania. Domyślnie wiele z tych plików jest czytelnych dla wszystkich użytkowników systemu, co w naturalny sposób rodzi obawy, czy ich zawartość nie może ujawnić wrażliwych informacji innego użytkownika.
[ czytaj całość… ]

O

d samego początku Uniksa (na którym oparty jest Linux) wszystko jest plikiem. Możemy spierać się o szczegóły, ale w większości przypadków jest to prawda. W dodatku w systemach Unix i pokrewnych systemach operacyjnych istnieje taki obiekt, jak deskryptor pliku (ang. file descriptor – FD, rzadziej fildes), który jest abstrakcyjnym wskaźnikiem / uchwytem (ang. handle) używanym do uzyskiwania dostępu do pliku lub innego zasobu wejścia / wyjścia, takiego jak potok (ang. pipe) lub gniazdo sieciowe (ang. network socket). Deskryptory plików stanowią część interfejsu programowania aplikacji POSIX – są nieujemną liczbą całkowitą, zwykle reprezentowaną w języku programowania C jako typ int (ang. integer) (wartości ujemne są zarezerwowane, aby wskazać „brak wartości” lub stan błędu).
[ czytaj całość… ]

C

raig H. Rowland na konferencji Purplecon 2018 opowiedział o szybkiej ocenie kompromitacji systemu Linux. Jak zauważył, 90% wdrożeń opartych na publicznych chmurach obliczeniowych odbywa się na systemie operacyjnym Linux. Nawet jeśli nie mamy z nim bezpośrednio do czynienia z powodu wysokich poziomowo abstrakcji i wywołań (np. API) – prędzej czy później natchniemy się na niego, a jako przyszły administrator dobrze posiadać wiedzę o jego działaniu oraz czy jego zachowanie nie budzi jakiś zastrzeżeń. Jeśli posiadamy podejrzenie, że doszło do naruszenia jego bezpieczeństwa – nie panikujmy. Podstępując pochopnie możemy tylko pogorszyć sytuację poprzez zniszczenie krytycznej informacji z punktu widzenia analizy pozwalającej ustalić główną przyczynę włamania.
[ czytaj całość… ]

N

arzędzie to pozwala na podglądanie procesów bez konieczności posiadania uprawnień administratora. Pozwala zobaczyć polecenia uruchamiane przez innych użytkowników, zadania cron w trakcie ich wykonywania itp. Świetnie nadaje się do badania systemów podczas testów penetracyjnych oraz CTFach. Jak to możliwe, że widzimy polecenia innych użytkowników? Dopóki proces trwa wiele informacji jest widocznych w procfs. Jedynym problemem jest to, że trzeba czasem złapać te krótko żyjące procesy w bardzo krótkim czasie. Skanowanie katalogu /proc w poszukiwaniu nowych PIDów w nieskończonej pętli może zdać egzamin, ale tym samym będzie zużywać bardzo dużo zasobów procesora.
[ czytaj całość… ]

W

styczniu 2012 Vasiliy Kulikov zaproponował poprawkę do Linuksa, która poprzez dodanie frazy hidepid do opcji montowania wirtualnego systemu plików procfs umożliwia ukrywanie procesów przed użytkownikami, do których dany proces nie należy. Patch został umieszczony w jądrze w wersji 3.3, a w między czasie backportowany do Debiana Wheezy i jego jądra w wersji 3.2 oraz RedHat Enterprise Linux 6.3 (2.6.32), jak i 5.9 (2.6.18).
[ czytaj całość… ]