J

akiś czas czemu firma Elastic weszła w rozwiązania typu SIEM (ang. Security Information and Event Management oraz EDR (ang. Endpoint Detection and Response). Jako, że jej rozwiązania od dawna wywodzą się z korzeni open source – firma udostępniła otwarte repozytorium reguł wykrywania różnych ataków i technik. Reguły w tym repozytorium są uporządkowane według rozwiązania lub platformy zachowując spłaszczoną strukturę. Każdy katalog zawiera od kilku do kilkunastu plików .toml, a w nich opisane reguły detekcyjne wraz z referencjami i taktykami ATT&CK. W drugim repozytorium znajdziemy artefakty zawierające logikę ochrony wykorzystywaną do zatrzymywania zagrożeń w systemach operacyjnych Windows, macOS i Linux. Obejmuje to reguły ochrony przed złośliwym oprogramowaniem napisane w EQL (ang. Event Query Language), a także sygnatury YARA stosowane zarówno do zawartości plików, jak i pamięci. Repozytoria te stanowią bardzo dużą bazę wiedzy odnośnie procesu proaktywnej detekcji zagrożeń (ang. threat hunting), którą możemy przełożyć na reguły dedykowane we własnych rozwiązaniach. Jeśli za ich pomocą nauczymy się wykrywania nowych technik i zagrożeń to świetnie! Ale jeszcze lepiej podzielić się także własną logiką wykrywania ze światem i pomóc innym podnieść poprzeczkę we własnych systemach detekcyjnych.

Więcej informacji: Continued leadership in open and transparent security

T

imestomping jest powszechną techniką, która odnosi się do zmiany sygnatur czasowych plików (czasu modyfikacji, dostępu, utworzenia i ostatniej zmiany) na systemie plików. Taktyka ta jest powszechnie wykorzystywana przez cyberprzestępców do ukrywania swoich narzędzi w systemie plików ofiary. Osiąga się to, sprawiając wrażenie, że pliki zostały utworzone poza ramami czasowymi incydentu (znacznie wcześniej niż nastąpiło naruszenie systemu) lub naśladowania plików znajdujących się w tym samym folderze, gdzie nastąpiła infekcja. W ten sposób takie obce pliki będą trudniejsze do znalezienia lub całkowicie pominięte przez śledczych lub przez różne narzędzia do analizy.
[ czytaj całość… ]

J

ak zauważył Chris Siebenmann prawie każdy system Linux (a tak naprawdę, każdy system Unix) posiada systemowy “schowek” dla głównych certyfikatów CA. Możemy przez to rozumieć katalog, w którym przechowywana jest lista wszystkich certyfikatów CA, które są domyślnie zaufane przez większość oprogramowania wykorzystującego TLS. Z różnych rozsądnych powodów, wiele dystrybucji Linuksa wykorzystuje magazyn CA Mozilli jako swój systemowy czasami wprowadzając pewne zmiany. Na czym polega więc problem? Sednem jest fakt, że Mozilla oraz Microsoft właśnie przestały ufać głównym certyfikatom TrustCor w swoich przeglądarkach. Oznacza to, że certyfikaty wydane od 1 grudnia przez tego CA nie będą zaufane, a główne certyfikaty zostaną usunięte z przeglądarek po wygaśnięciu. O ile zmiana w przeglądarkach zadziała się dość szybko to należy zauważyć, że w systemach takich jak Linux, które bazują na głównym magazynie certyfikatów Mozilli będą w pełni ufać TrustCor przez co najmniej kolejny rok lub dłużej ze względu na opóźnienia w wydaniu i instalacji aktualizacji paczki ca-certificates. Możemy być zdezorientowani dlaczego systemy Linuksowe tak długo będą ufać certyfikatom TrustCor. Mniej istotnym powodem są opóźnienia jakie wynikną z aktualizacji spakowanych kopii magazynu Mozilli (powstała nawet na ten temat praca naukowa pt. Tracing Your Roots: Exploring the TLS Trust Anchor Ecosystem), a później skłonienie użytkownika do zastosowania tej aktualizacji. Dość znamiennym przykładem mogą tutaj być dystrybucje Ubuntu oraz Debian, które same cofnęły usunięcie certyfikatu Symantec z pakietu Mozilli, ponieważ program nuget używał jeszcze certyfikatów, które nie zostały odnowione, więc tymczasowo przywrócono te od Symantec. Ważniejszym problemem może wydawać się ograniczony model tradycyjnego przechowywania certyfikatów CA w systemach *nix.
[ czytaj całość… ]

W

raz z wersją git 2.34.0 każdy nasz commit do kodu lub jego tag będzie mógł zostać podpisany kluczem SSH. Możliwość podpisywania dowolnych danych za pomocą SSH została dodana już w 2019 roku z wydaniem OpenSSH 8.0. Jednak, aby używać tej funkcjonalności bez żadnego problemu najlepiej używać OpenSSH w wersji 8.8. Nasz proces zaczynamy od instalacji i konfiguracji klienta git i SSH:

sudo apt install -y git

Kolejnym krokiem jest wygenerowanie klucza SSH, który będzie używany do podpisywania:

ssh-keygen -t ed25519 -C "agresor@nfsek.pl" -f ~/.ssh/code_commit_signing

Odpowiadamy na pytania i upewniamy się, że wpisaliśmy silne i unikalne hasło do klucza. Klucz ten będzie domyślnie przechowywany w naszym katalogu domowym pod katalogiem .ssh:

agresor@darkstar:~$ cat .ssh/code_commit_signing.pub
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIMzu8wjcnyAorVVtEjddoG2gaYjmRnHiZHvElYFcl/s/ 
agresor@nfsek.pl

[ czytaj całość… ]

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

Z

narzędziem utmpdump spotkaliśmy się pierwszy razy przy okazji ściągawki z informatyki śledczej w wykrywaniu włamań za pomocą linii poleceń Linuksa. W tym wpisie rozwinę trochę użycie tego narzędzia i pokażę jak można go użyć od strony defensywnej, jak i ofensywnej. Pozornie nieznane przez wielu polecenie utmpdump jest doskonałym narzędziem do wykrywania manipulacji na plikach logowań. Jeśli chodzi o system Linux to często możemy polegać na następujących trzech artefaktach w celu określenia czynności logowania i wylogowywania użytkowników:

• /var/run/utmp – plik utmp pozwala odkryć informacje o tym, kto aktualnie korzysta z systemu.
• /var/log/wtmp – plik wtmp rejestruje wszystkie logowania i wylogowania. Jego format jest dokładnie taki jak utmp, z tą różnicą, że pusta nazwa użytkownika wskazuje na wylogowanie z powiązanego terminala. Co więcej, nazwa terminala “~” z nazwą użytkownika “shutdown” lub “reboot” wskazuje na zamknięcie lub ponowne uruchomienie systemu.
• /var/log/btmp – plik btmp zawiera wszystkie złe próby logowania do systemu.

Ponieważ pliki utmp, wtmp i btmp zawierają dane logowania wszystkich użytkowników, są one głównym celem modyfikacji lub usuwania wpisów przez intruzów i złośliwe oprogramowanie. Wiele rodzajów malware dla systemu Linux po prostu usunie te pliki i zastąpi je plikami o zerowej długości bajtów. Bardziej wyrafinowani napastnicy podejmują próbę wyczyszczenia poszczególnych wpisów jednak jest to trudniejszy sposób na zacieranie śladów i łatwo go zauważyć.
[ czytaj całość… ]

K

olejnym pakietem (obok base-files), który wysyła informacje o naszym serwerze do firmy Ubuntu jest pollinate. Jest to klient, który łączy się z conajmniej jednym serwerem Pollen (entropia-jako-usułga) za pośrednictwem zaszyfrowanego (HTTPS) lub nie (HTTP) protokołu i pobiera losowe ziarno. Jest to szczególnie przydatne przy pierwszym uruchomieniu obrazów w chmurze i na maszynach wirtualnych, aby zainicjować systemowy generator liczb losowych. Może być również używany na fizycznych maszynach, aby uzupełniać nastawienie pseudogeneratora liczb losowych. Sprawdźmy, co jest wysyłane do serwerów entropy.ubuntu.com, które są wpisane w standardowej konfiguracji tego programu:

sudo su - pollinate -s /bin/bash
pollinate --print-user-agent

[ czytaj całość… ]

M

inimalizacja QNAME (RFC 7816), czyli Query Name zmienia zapytania DNS pochodzące z resolwera rekurencyjnego, aby w każdym zapytaniu zawierał tylko tyle szczegółów, ile jest to wymagane dla tego kroku w procesie rozwiązywania danej domeny. Internet Engineering Task Force opisuje to jako technikę, “w której resolwer DNS nie wysyła już pełnej oryginalnej nazwy QNAME do nadrzędnego serwera nazw”. Powiedzmy, że chcemy odwiedzić stronę: stardust.nfsec.pl. W celu określenia adresu IP, z którym chce się połączyć przeglądarka, system wysyła zapytania do resolwera dostawcy usług internetowych (ISP) lub innego ustawionego przez konfigurację systemu. Prosi on o pełną nazwę – stardust.nfsec.pl – w tym przypadku. ISP (lub inny serwer DNS przydzielony przez zarządce sieci, z której korzystasz) zapyta root DNS, a następnie domenę najwyższego poziomu (.pl), a następnie domenę drugorzędną (nfsec.pl) o pełną nazwę domeny. W rzeczywistości wszystko, czego się dowiadujesz od głównego serwera DNS to odpowiedź na pytanie “kto odpowiada za .pl?”, a jedyne, o co pytasz serwer .pl, to “kto odpowiada za .nfsec.pl?”. Żadne z tych żądań nie musi zawierać informacji o pełnej nazwie strony internetowej, którą chcesz odwiedzić, aby odpowiedzieć na wcześniejsze pytania, ale niestety oba te serwery taką informacje otrzymują. Tak zawsze działał DNS, ale obecnie nie ma ku temu praktycznego powodu.
[ 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

G

ootloader, czyli usługa wstępnego dostępu do (firmowych) sieci dla cyberprzestępców ostatnio rozszerzyła swój zakres działalności o różne cele na całym świecie. Przypomnijmy: w 2014 roku po raz pierwszy został zauważony trojan bankowy o nazwie Gootkit. Od tego czasu ewoluował, aby stać się bardziej złodziejem poufnych informacji obsługiwanym przez grupę aktorów. Nazwa ‘Gootkit’ jest często używana zamiennie – zarówno w odniesieniu do złośliwego oprogramowania, jak i do samej grupy. W marcu 2021 roku firma Sophos jako pierwsza zidentyfikowała szersze możliwości tego oprogramowania i nazwała go GootLoader. Ten oparty o Javascript framework pierwotnie przeznaczony do infekcji Gootkitem w coraz większym stopniu zaczął dostarczać szerszą gamę złośliwego oprogramowania (w tym ransomware). Wczesna aktywność kampanii platformy Gootloader została po raz pierwszy zauważona przez analityka zagrożeń z firmy Proofpoint pod koniec 2020 roku, a następnie zbadana i opisana przez ASEC, Malwarebytes i TrendMicro.
[ czytaj całość… ]