Z

e względu na ograniczoną liczbę publicznych adresów IPv4, a także aby chronić systemy przez zagrożeniami z internetu wiele komputerów umieszczanych jest za zaporami sieciowymi. W wielu przypadkach funkcję zapory sieciowej pełni domowy / firmowy router, który również tłumaczy lokalny adres sieciowy komputera np. 192.168.0.10 na publiczny adres IP od ISP za pomocą mechanizmu translacji adresów sieciowych, czyli NAT (ang. Network Address Translation). W połączeniu ze stanowymi regułami zapory sieciowej teoretycznie oznacza to, że atakujący nie może bezpośrednio z internetu połączyć się z komputerem wewnątrz takiej sieci – pierwsze / inicjujące połączenie musi być nawiązane z wewnątrz chronionej sieci. W takiej konfiguracji, gdy dwa komputery są za różnymi zaporami stanowymi (ang. stateful firewall) z mechanizmem NAT i będą chciały skomunikować się ze sobą bezpośrednio – niezależnie od tego, który z nich rozpocznie połączenie, zapora sieciowa tego drugiego może odrzucić przychodzące pakiety danych.
[ czytaj całość… ]

K

orzystając z protokołu NTP (ang. Network Time Protocol) możemy mieć pewność, że nasze serwery synchronizują swój czas z wyspecjalizowanymi serwerami czasu opartymi na zegarach atomowych (w zależności od poziomu stratum). Utrzymanie precyzyjnego i aktualnego czasu na serwerach (i ogólnie urządzeniach biorących udział w komunikacji) nie jest tylko kwestią możliwości odpowiedzi na pytanie: „- która godzina?”. Poprawny czas na różnego rodzaju urządzeniach to krytyczny element stabilności, bezpieczeństwa i spójności danych. Jeśli zegar serwera znacząco odbiega od rzeczywistości to wiele usług używających czasu w swoich mechanizmach może zacząć działać niepoprawnie. Na przykład duże różnice w postaci dni, miesięcy i lat mogą powodować uznawanie certyfikatów SSL/TLS za nieważne (wydane w przeszłości lub przyszłości). Mniejsze różnice mieszczące się w oknie od 2 do 5 minut mogą powodować problemy z kodami uwierzytelniającymi dla OTP, 2FA, czy Kerberos – bo różnica czasu między klientem, a serwerem spowoduje ich odrzucenie.
[ czytaj całość… ]

O

podstawach działania narzędzia whois oraz jego dobrym działaniu jako źródle informacji pisałem nie raz. W aktualnej publikacji zajmiemy się zupełnie innym zastosowaniem tego narzędzia, a mianowicie eksfiltracją danych – znaną również jako wykradanie lub eksport danych do lokalizacji kontrolowanej przez atakującego. Słowem małego przypomnienia whois to prosty protokół żądania i odpowiedzi, powszechnie używany do przeszukiwania baz danych zawierających zarejestrowanych użytkowników obiektów internetowych, takich jak nazwy domenowe lub adresy IP. Ze względu na mnogość opcji oferowanych przez plik binarny tego narzędzia może zostać on użyty do przesłania dowolnego pliku z zaatakowanej maszyny na system atakującego za pośrednictwem jawnego połączenia TCP.
[ czytaj całość… ]

W

iększość użytkowników tego systemu nie ma pojęcia, co naprawdę oznacza średnie obciążenie systemu Linux. Bardzo często jest ono kojarzone tylko z wartością obciążenia procesora (CPU), a niestety tak nie jest. W rzeczywistości wartość ta reprezentuje średnią liczbę procesów (wątków), które w danym momencie: 1) wykonują pracę na procesorze 2) czekają w kolejce na dostęp do procesora 3) czekają na operacje wejścia / wyjścia (I/O) i nie tylko. I to właśnie trzeci punkt jest kluczowy i odróżnia Linuksa od wielu systemów Uniksowych. Dlatego wydając na przykład polecenie uptime, gdy wyświetlą się nam trzy średnie wartości dla 1, 5 i 15 minut:

05:58:34 up 12 days,  7:56,  1 user,  load average: 4.18, 3.13, 2.04

Nie możemy jednoznacznie powiedzieć, że dla systemu z dwoma wątkami procesora system jest przeładowany zadaniami obliczeniowymi.
[ czytaj całość… ]

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

R

óżne formaty binarne (ang. Miscellaneous Binary Format) to mechanizm jądra Linuksa, który umożliwia systemowi rozpoznawanie i uruchamianie dowolnych formatów plików wykonywalnych za pomocą określonych programów w przestrzeni użytkownika, takich jak: interpretery, emulatory lub maszyny wirtualne. Głównym celem BINFMT_MISC jest rozszerzenie zdolności jądra do interpretowania, jak należy uruchomić dany plik, który nie jest natywnym formatem ELF (ang. Executable and Linkable Format) Linuksa. Użytkownik (z uprawnieniami administratora) może zarejestrować nowy format binarny w określonej ścieżce wirtualnego systemu plików procfs. Rejestracja polega na zdefiniowaniu kryteriów dopasowania plików, które mogą opierać się na: magicznych bajtach (ang. magic bytes) – sekwencji bajtów na początku pliku, które są charakterystyczne dla danego formatu; rozszerzeniu nazwy pliku – na przykład: .py, .sh, .pl itd. W ten sposób użytkownik może po prostu wpisać nazwę pliku, np. skrypt.py, a jądro automatycznie rozpozna jego format i przekaże go do odpowiedniego interpretera, tak jakby był natywnym plikiem wykonywalnym Linuksa (a skrypt nie musi nawet posiadać wewnątrz siebie definicji shebang).
[ czytaj całość… ]

S

hebang (ang. shebang line, bang path) (#!) na początku skryptu jest wymagany, ponieważ informuje jądro systemu operacyjnego (ang. kernel), jakiego interpretara należy użyć do wykonania danego pliku. Gry próbujemy uruchomić plik bezpośrednio (np. ./skrypt.sh), jądro sprawdza pierwsze bajty pliku. Jeśli znajdzie tam sekwencję #!, trakuje resztę linii jako ścieżkę do programu (interpretera), który ma zostać uruchomiony, przekazując mu nazwę skryptu jako argument. Historycznie to powłoka systemowa zajmowała się uruchamianiem skryptów, dopóki nie zostało to zmienione na jądro systemu przez Dennisa Ritche w 1980 roku. Kluczowy jest fakt, że jądro systemu nie przeszukuje zmiennej środowiskowej $PATH podczas obsługi shebang:

agresor@darkstar:~$ echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

Zmienna $PATH jest używana przez powłokę (np. bash / dash), gdy wpisujemy dane polecenie (np. ls ), aby znaleźć odpowiedni plik wykonywalny. Uruchamiając polecenie śledzące konkretne wywołanie systemowe np. strace możemy zobaczyć jak wykonywane jest polecenie:

root@darkstar:~# strace -e execve cat /etc/hostname
execve("/usr/bin/cat", ["cat", "/etc/hostname"], 0x7ffdae655db8 /* 15 vars */) = 0
darkstar
+++ exited with 0 +++

Jądro systemu ma już pełną ścieżkę (/usr/bin/cat). Z kolei jeśli spojrzymy na kod źródłowy powłoki dash to w pliku exec.c znajdziemy informację o przeszukiwaniu zmiennej $PATH:

/*
 * Do a path search.  The variable path (passed by reference) should be
 * set to the start of the path before the first call; padvance will update
 * this value as it proceeds.  Successive calls to padvance will return
 * the possible path expansions in sequence.  If an option (indicated by
 * a percent sign) appears in the path entry then the global variable
 * pathopt will be set to point to it; otherwise pathopt will be set to
 * NULL.
 *
 * If magic is 0 then pathopt recognition will be disabled.  If magic is
 * 1 we shall recognise %builtin/%func.  Otherwise we shall accept any
 * pathopt.
 */

const char *pathopt;

int padvance_magic(const char **path, const char *name, int magic)

Dlatego jądro systemu, które aktualnie jako pierwsze obsługuje próbę uruchomienia pliku, działa na niższym poziomie i wymaga dokładnej, bezwzględnej (absolutnej) ścieżki do pliku wykonywalnego interpretera (np. /bin/bash, /usr/bin/python3). On, czyli interpreter dalej zajmuje się znalezieniem odpowiedniej ścieżki do programu. Gdybyśmy podali tylko #!bash jako shebang, jądro nie wiedziałoby, gdzie szukać pliku bash (czy jest w /bin, /usr/bin, /usr/local/bin, czy jeszcze gdzieś indziej). W wielu przypadkach możemy także zobaczyć shebang w formie:

#!/usr/bin/env bash

Tutaj pełną ścieżką jest /usr/bin/env. Program env również przeszukuje zmienną $PATH, aby znaleźć pierwszy argument, który mu podano (w tym przypadku: bash). Następnie env uruchamia znaleziony interpreter bash, przekazując mu resztę skryptu. Użycie programu env sprawia również, że skrypt jest bardziej przenośny między różnymi systemami (np. Linux, Unix), na których interpreter bash (lub python itp.) może znajdować się w różnych katalogach, ale program env jest prawie zawsze dostępny pod standardową ścieżką /usr/bin/env.

Więcej informacji: Shebang, env, PATH isn’t real on Linux

A

ge to proste, nowoczesne i bezpieczne narzędzie do szyfrowania plików oraz biblioteka języka Go. Charakteryzuje się małymi, jawnymi kluczami, brakiem opcji konfiguracyjnych i możliwościami kompozycji poleceń w stylu Unix. Program ten tworzy asymetryczną parę kluczy: publiczny i prywatny. Wersja publiczna jest używana do szyfrowania, a prywatna do odszyfrowania (plików, katalogów i wiadomości). Dla wygody age obsługuje również szyfrowanie za pomocą publicznych kluczy SSH oraz odszyfrowywaniu przy użyciu odpowiedniego pliku klucza prywatnego. Kilka przykładów zastosowania:

agresor@darkstar:~$ sudo apt install -y age
agresor@darkstar:~$ age-keygen | age -p > age-private.key
Public key: age1vvdj5yvk0psrz6vs5lrgqjew7h5vaep6rdtg9lwyt62x69ltu5esmpl2ad
Enter passphrase (leave empty to autogenerate a secure one):
age: using autogenerated passphrase "borrow-journey-define-exile-earth-win-cigar-yard-urge"

Tworzymy parę kluczy, z czego klucz prywatny będzie dodatkowo zaszyfrowany hasełem. Teraz możemy zaszyfrować plik nfsec_pl.txt otrzymanym kluczem publicznym:

agresor@darkstar:~$ age -o nfsec_pl.txt.age -r age1vvdj5yvk0...69ltu5esmpl2ad nfsec_pl.txt
agresor@darkstar:~$ head -3 nfsec_pl.txt.age
age-encryption.org/v1
-> X25519 Tlw8RQmWEXu7mjpBUJ1GNV2ZRuM5c0lc7++OT4Y+j24
xzwZGjRDJVQywki6tOmSaXIKjFXrg1+ycPVjtljF1es

Tak zaszyfrowany plik możemy odszyfrować za pomocą polecenia:

agresor@darkstar:~$ age -d -i age-private.key -o nfsec_pl.txt nfsec_pl.txt.age
Enter passphrase for identity file "age-private.key":

Ten sam proces (szyfrowania) możemy przeprowadzić za pomocą publicznego klucza SSH:

agresor@darkstar:~ $ age -R .ssh/id_rsa.pub nfsec_pl.txt > nfsec_pl.txt.age
agresor@darkstar:~ $ head -3 nfsec_pl.txt.age
age-encryption.org/v1
-> ssh-rsa x4o9pQ
2VKd5t82j0zjoO7PMt+xZKTxPEVAJSH/fvWWJYfHy+Q0jZkw01k6oGOXfq1BbDDE

A następnie odszyfrować go kluczem prywatnym SSH:

agresor@darkstar:~ $ age -d -i .ssh/id_rsa nfsec_pl.txt.age > nfsec_pl.txt

W ten sposób możemy bardzo prosto i szybko szyfrować wiadomości i pliki dla użytkowników, którzy zdecydowali się opublikować swoje klucza na profilu GitHub:

curl -s https://github.com/$login.keys | age -R - nfsec_pl.txt > nfsec_pl.txt.age

Więcej informacji: age encryption

U

sługa SSH od wersji 9.0 (kwiecień 2022 roku) wprowadziła algorytm wymiany kluczy (KEX), między klientem a serwerem, który uważany jest za bezpieczny przed atakami ze strony komputerów kwantowych. Głównie chodzi o atak „zbieraj teraz, odszyfruj później” (ang. harvest now, decrypt later), w którym atakujący może złamać proces wymiany kluczy, aby odszyfrować i wyświetlić całą sesję połączenia SSH. Atak ten nie musi być przeprowadzany w czasie rzeczywistym; może opierać się na nagrywaniu ruchu sieciowego podatnych, zaszyfrowanych sesji SSH, a następnie ich odszyfrowaniu w późniejszym czasie (po uzyskaniu dostępu do komputera kwantowego). Algorytm, o którym mowa to sntrup761x25519-sha512@openssh.com – jest on oparty na NTRU Prime, połączony z tradycyjnym X25519. Daje to hybrydowe podejście: system jest bezpieczny, dopóki chociaż jeden z tych algorytmów pozostaje nie do złamania.
[ czytaj całość… ]

P

akiet TCP Wrappers jest instalowany domyślnie we wszystkich głównych dystrybucjach systemu Linux. Zapewnia on kontrolę dostępu do usług sieciowych na poziomie hosta. Najważniejszym komponentem tego pakietu jest biblioteka libwrap.so, z obsługą której kompilowane są inne programy. Dzięki temu podczas próby połączenia z danym programem TCP Wrappers na początku odwołuje się do swoich plików dostępu (tj. /etc/hosts.allow i /etc/hosts.deny), aby ustalić, czy klient ma prawo połączyć się z daną usługą. Jeśli klient otrzyma zgodę na połączenie, TCP Wrappers zwalnia kontrolę nad połączeniem z żądaną usługą i nie bierze już udziału w komunikacji między klientem, a serwerem. Oprócz kontroli dostępu i rejestrowania połączeń, TCP Wrappers może wykonywać polecenia w celu interakcji z klientem przed zablokowaniem lub zwolnieniem kontroli nad połączeniem z żądaną usługą sieciową. I tutaj pojawia się przestrzeń na mechanizm utrzymania trwałego dostępu do systemu.
[ czytaj całość… ]