NFsec Logo

Ochrona przed użyciem ptrace

28/12/2014 w Bezpieczeństwo Możliwość komentowania Ochrona przed użyciem ptrace została wyłączona

P

trace(2) jest wspaniałym narzędziem do rozwiązywania problemów dla programistów, którzy chcą poznać jak funkcjonują procesy w systemie Linux. Umożliwia odnajdywanie błędów programistycznych, czy wycieków pamięci. Z drugiej strony ptrace może zostać wykorzystane przez osoby o złych intencjach np. w celu debugowania procesu jako nieuprzywilejowany użytkownik, aby odczytać zawartość pamięci programu.
[ czytaj całość… ]

Hakowanie aplikacji Rootkity i Ptrace

11/01/2010 w Magazyny Możliwość komentowania Hakowanie aplikacji Rootkity i Ptrace została wyłączona

P

rzede wszystkim muszę zastrzec, że ten tekst jest specyficzny dla Linuksa i potrzebna jest pewna wiedza o programowaniu w ANSI C oraz trochę o asemblerze. Było już dawniej parę różnych technik wstrzykiwania procesu z udziałem, kilka publicznych, jak i prywatnych exploitów, furtek i innych aplikacji. Przyjrzymy się bliżej funkcji i nauczymy się, jak pisać własne furtki.
[ czytaj całość… ]

Ukrywamy nazwę procesu i jego parametry za pomocą programu zapper

Dzisiaj w Bezpieczeństwo, Pen Test Możliwość komentowania Ukrywamy nazwę procesu i jego parametry za pomocą programu zapper została wyłączona

Z

apper to mały program, który za pomocą ptrace() manipuluje stosem wektora pomocniczego (ang. auxiliary vector) formatu ELF (ang. Executable and Linkable Format), który posiada format tablicy w postaci par: „klucz – wartość” i jest przekazywany z jądra systemu do procesu w przestrzeni użytkownika, gdy program jest uruchamiany za pomocą funkcji systemowej execve(). Celem wspomnianego wektora (nazywanego również tablicą pomocniczą) jest dostarczenie programowi dodatkowych informacji konfiguracyjnych i środowiskowych, które są niezbędne lub przydatne dla programu w trakcie jego działania (np. jak argumenty linii poleceń czy zmienne środowiskowe – argc, argv, envp).
[ czytaj całość… ]

Obchodzenie flagi montowania noexec za pomocą ddexec

27/01/2025 w Bezpieczeństwo Możliwość komentowania Obchodzenie flagi montowania noexec za pomocą ddexec została wyłączona

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

Wszystko w Linuksie jest plikiem na który można zerkać

03/12/2024 w Bezpieczeństwo Możliwość komentowania Wszystko w Linuksie jest plikiem na który można zerkać została wyłączona

W

szystko jest plikiem to koncepcja zakładającą, że w systemach z rodziny *nix wejście / wyjście do i z zasobów (dyski twarde, urządzenia sieciowe, urządzenia peryferyjne) jest prostym strumienim bajtów udostępnionych przez przestrzeń nazw systemu plików. Oznacza to, że jesteśmy w stanie wykonać ten sam zestaw operacji opisany dla plików na każdym obiekcie w systemie, ponieważ każdy z nich jest „plikiem”. Możemy otworzyć konkretne urządzenie / plik, odczytać z niego, zapisać do niego i zamknąć je po zakończeniu. Dane z tego zasobu są również przesyłane strumieniowo. Jedyną rzeczą, która się zmienia jest źródło danych. Na przykład, gdy piszemy w terminalu w rzeczywistości zapisujemy dane do zasobu o nazwie standardowe wejście (ang. standard inputstdin). Gdy dane są wyświetlane na terminalu, używane jest standardowe wyjście (ang. standard outputstdout).
[ czytaj całość… ]

Wykrywanie procesu debugowania w systemie Linux

21/11/2024 w Bezpieczeństwo, Debug Możliwość komentowania Wykrywanie procesu debugowania w systemie Linux została wyłączona

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?

Siphon – przechwytywanie strumieni wejścia / wyjścia / błędów dla dowolnego procesu

09/11/2022 w Bezpieczeństwo Możliwość komentowania Siphon – przechwytywanie strumieni wejścia / wyjścia / błędów dla dowolnego procesu została wyłączona

L

iam Galvin napisał w języku Go ciekawe narzędzie o nazwie siphon, które za pomocą ptrace potrafi przechwycić strumień wejścia (stdin) wyjścia (stdout) i błędów (stderr) dla dowolnego procesu podając tylko jego PID:

root@darkstar:~# wget 'https://github.com/liamg/siphon/releases/download/v0.0.2/siphon'
root@darkstar:~# chmod +x siphon-linux-amd64
root@darkstar:~# ps xuaw| egrep ^agresor.*bash
agresor     2297  0.0  0.1   8728  5536 pts/2    Ss+  19:38   0:00 -bash
root@darkstar:~# ./siphon-linux-amd64 2297
agresor@darkstar:~$ echo elemelek
elemelek
agresor@darkstar:~$ export
declare -x DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/1000/bus"
declare -x HOME="/home/agresor"
declare -x LANG="en_US.UTF-8"
declare -x LC_ALL="en_US.UTF-8"
declare -x LC_CTYPE="UTF-8"
declare -x LC_TERMINAL="iTerm2"
declare -x LC_TERMINAL_VERSION="3.4.16"
declare -x LESSCLOSE="/usr/bin/lesspipe %s %s"
declare -x LESSOPEN="| /usr/bin/lesspipe %s"
declare -x LOGNAME="agresor"

Podobnie możemy zrobić z strace. W celu powstrzymania przechwytywania za pomocą ptrace – wystarczy wyłączyć tą możliwość:

root@darkstar:~# sysctl -w kernel.yama.ptrace_scope=3
kernel.yama.ptrace_scope = 3
root@darkstar:~# ./siphon-linux-amd64 2297
Error: could not attach to process with pid 2297: 
operation not permitted - check your permissions

Więcej informacji: Siphon

Nadużywanie rozszerzonych zdolności kontenerów Dockera do eskalacji uprawnień

03/07/2021 w Bezpieczeństwo Możliwość komentowania Nadużywanie rozszerzonych zdolności kontenerów Dockera do eskalacji uprawnień została wyłączona

W

yobraźmy sobie następujący scenariusz. Wyciekł klucz SSH umożliwiający zalogowanie się do zwykłego konta platformy wdrożeniowej. Był on używany do wdrażania i aktualizacji repozytoriów za pomocą ansible. Umożliwia on zalogowanie się na powłokę systemową grupy serwerów, na której są budowane i uruchamiane kontenery Docker. Samo konto nie posiada żadnych dodatkowych uprawnień ani grup. Zastanówmy się teraz w jaki sposób możemy dokonać eskalacji uprawnień wykorzystując jedną z przestrzeni nazw (ang. namespace) kontenera Docker oraz rozszerzonej zdolności Linuksa (ang. capabilities).
[ czytaj całość… ]

Uciekając z sudo – część czwarta

13/04/2019 w Bezpieczeństwo Możliwość komentowania Uciekając z sudo – część czwarta została wyłączona

T

a część będzie zupełnie inna od poprzednich trzech (1, 2, 3). Jako użytkownik polecenia sudo na pewno zauważyłeś, że czasami sudo nie prosi o hasło, ponieważ pamięta nas jako użytkownika. Jak to się dzieje, że jesteśmy pamiętani? Czy możemy sfałszować taką tożsamość i uzyskać prawa administratora? Otóż sudo tworzy plik dla każdego użytkownika Linuksa w /var/run/sudo/ts/$USER. Pliki te zawierają udane i nieudane procesy uwierzytelnienia, które są używane przez sudo do zapamiętywania wszystkich uwierzytelnionych procesów.
[ czytaj całość… ]

Inwigilacja połączeń SSH za pomocą strace

12/11/2016 w Bezpieczeństwo 1 komentarz.

T

o, że używamy SSH do połączeń z serwerami nie oznacza, że możemy czuć się bezpiecznie. Szczególnie musimy uważać na te maszyny, którymi zarządzają niezaufane osoby. Dlaczego? Ponieważ odczyt niezaszyfrowanych danych w systemie można wykonać na różnych poziomach dostępu. Za przykład weźmy wywołanie ptrace, które jest używane do monitoringu i kontroli innych procesów. Głównie jest używane do debugowania, a chyba najpopularniejszym programem wykorzystującym jego możliwości jest strace.
[ czytaj całość… ]