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?

P

odczas wykrywania różnego rodzaju szkodliwych procesów zazwyczaj używamy podstawowych poleceń systemowych, takich jak: ps, lsof oraz netstat (lub jego następcę ss). Dla przypomnienia: ps – wyświetla aktualne procesy w systemie; netstat – wyświetla połączenia sieciowe, tablice routingu i statystyki pakietów; lsof – listuje otwarte deskryptory plików i procesy, które je otworzyły. Polecenia te opierają się na prostej koncepcji (w systemach *nix prawie wszystko jest reprezentowane jako deskryptor pliku: pliki, katalogi, połączenia sieciowe, potoki, zdarzenia itd.) i przydają się w wielu sytuacjach. W rezultacie polecenia te mogą zobaczyć wiele rzeczy i być użyte do odpowiedzi na wiele interesujących pytań.
[ 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ść… ]

W

yobraźmy sobie taki scenariusz – jesteś członkiem zespołu Red Team, który ma kompetencje w zakresie systemu Linux. Twoim zadaniem jest opracowanie ćwiczenia, w którym musisz zachować dostęp do skompromitowanego systemu przez jak najdłuższy czas. Posiadając uprawnienia administratora myślisz o dodaniu jakiegoś zadania w cron lub innej klasycznej lokalizacji (np. rc.local), ale wiesz że Blue Team je systematycznie sprawdza. Przez chwilę myślisz o doczepieniu tylnej furki jakieś binarce, tylko problem w tym, że dostęp ma być utrzymany jak najdłużej, a skompromitowana maszyna jest ustawiona na regularną aktualizację łatek bezpieczeństwa, więc wszelkie pliki wykonawcze lub inne krytyczne komponenty systemu mogą zostać nadpisane wersjami domyślnymi.
[ 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ść… ]

Użycie polecenia timeout do uruchomienia wybranego polecenia na określony czas działania:

timeout 1h tcpdump -n -i eth0 -w network.pcap not host 192.168.1.5

lub

tcpdump -n -i eth0 -w & pid=$! ; (sleep 3600 ; kill $pid)

Jednym z sposobów uzyskania parent pid na przykład dla serwera nginx może być proste polecenie: ps -p `pidof -s nginx` -o ppid=. Zwróci ono nam parent PID serwera nginx, który możemy dalej wykorzystać do przesłania sygnałów typu USR1, QUIT i innych… Do pewnego momentu jest to bezpieczne. Ponieważ wystarczy, że serwer nginx dostanie sygnał SIGHUP, a jego PPIDem według wymienionego polecenia nagle stanie się /sbin/init aka PID 1. Dalsze operowanie na wyniku tego polecenia (np. w skrypcie) może doprowadzić do dość drastycznych skutków: kill -INT 1 – restart systemu, kill -SEGV 1, kill -ABRT 1 – kernel panic.

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ść… ]

D

la crackera włamującego się do cudzego systemu informatycznego najważniejsze jest… skuteczne zatarcie śladów po całej operacji. Nawet najbardziej spektakularne włamanie przy użyciu stworzonego przez siebie exploita nie przyniesie włamywaczowi wiele korzyści, jeśli nazajutrz pojawią się u niego agenci CBŚ.
[ czytaj całość… ]

W

iększość z nas jest zaznajomiona z możliwościami typowego laptopa pod względem hibernacji. W tym trybie cała zawartość pamięci RAM zostaje zapisana na dysk naszej maszyny, a ona sama wyłączana. Przy ponownym uruchomieniu system jest odtwarzany dokładnie do tego samego stanu, przed którym został uśpiony, z wszystkimi programami, które były uruchomiony w taki sposób w jaki działały dotychczas.
[ czytaj całość… ]