1

4 marca 2025 roku po raz kolejny mogliśmy przekonać się jak łatwo można przeprowadzić atak na łańcuch dostaw (ang. supply chain attack). Wystarczy uderzyć w kruchość ludzkiej weryfikacji w danym projekcie, którego popularność jest na tyle duża (lub specyficzna), aby spowodować dość duże spustoszenie, problemy i zaangażowanie dużej ilości ludzi do naprawy przepuszczonego błędu. Ale od początku. Dzisiejszy model rozwoju oprogramowania opiera się na używaniu popularnych platform typu Github, czy Gitlab itp. Oczywiście ma to swoje plusy dodatnie oraz plusy ujemne – szczególnie, gdy tego typu platformy mają swoje problemy bezpieczeństwa, które dziedziczymy razem z ich adopcją. W dodatku oferują funkcjonalności, które są najczęściej uzupełnianie przez zewnętrzne (często lepsze) rozwiązania. Takim przykładem są klocki, z których budowane są przepływy zadań / pracy (ang. workflows). Oferują one zautomatyzowane procesy uruchamiające jedno lub więcej zadań do obsługi cyklu życia oprogramowania. W przypadku GitHub są definiowane przez pliki YAML zaewidencjonowane w repozytorium projektu i zostają uruchomione automatycznie przez konkretne zdarzenie w repozytorium (np. dodanie pliku, zmianę wersji itd.). Mogą być też wyzwalane ręcznie, a także według zdefiniowanego harmonogramu czasowego (ala cron).
[ 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

P

ierwszy raz z truflową świnką ryjącą za poszukiwaniem kluczy mogliśmy spotkać się w Oh Shit, Git?!. Najnowsza, trzecia wersja została zupełnie przepisana w języku Go. Dodano do niej obsługę ponad 600 typów kluczy zwiększając tym samym zdolność tego narzędzia do polowania na wycieki danych uwierzytelniających. W dodatku detektory te obsługują aktywną weryfikację z odpowiednimi interfejsami API. Ujawnione dane uwierzytelniające, w tym pary tajnych kluczy, stanowią poważny problem cyberbezpieczeństwa. Klucze mogą być nadużywane do włamywania się do sieci korporacyjnych, często bardziej potajemnie i przez dłuższy czas niż wykorzystywanie luk w popularnym oprogramowaniu.
[ czytaj całość… ]

P

rojekt LOTS jest zestawieniem serwisów, które mogą posłużyć w zupełnie innym celu niż zostały stworzone. Obok takich projektów, jak: Living Off The Land Binaries (Żyjąc Z Wbudowanych Binarek) oraz GTFOBins pokazuje, jak można użyć “popularnych” i o “dobrej reputacji” serwisów do przeprowadzenia wybranych ataków przez cyberprzestępców. Mogą one zostać użyte do przeprowadzenia phishingu, hostowania C&C, eksfiltracji danych oraz pobierania własnych, szkodliwych narzędzi z poziomu sieci wewnętrznej w celu uniknięcia wykrycia swojej obecności.

Przykład: Analizując wpisy DNS określonej firmy atakujący zauważył, że aktywnie korzysta ona z ekosystemu usług firmy Microsoft (Office 365). Posiadając tą wiedzę tworzy on kampanię phishingu wymierzoną w tą firmę, a jako link do kliknięcia wykorzystuje usługę OneDrive: https://*.files.1drv.(com|ms). Ze względu na fakt, że pracownicy tej firmy zapewne bardzo często spotykają z tego typu linkami współdzieląc między sobą różnego rodzaju dokumenty i pliki to istnieje większe prawdopodobieństwo, że ktoś kliknie w ten link i pobierze złośliwe oprogramowanie.

Przy pozytywnej infekcji komputera narzędzia umożliwiające dalsze poruszanie się w głąb sieci firmowej w poszukiwaniu poufnych danych lub zasobów o wysokiej wartości (ang. lateral movement) mogą zostać ściągnięte poprzez stworzenie wiadomości e-mail; dodanie skompresowanego, binarnego załącznika, który będzie miał fałszywe rozszerzenie .txt); kliknięcie na załącznik w celu pobrania jego linku (link jest ważny przez 15 minut) i ściągnięcia narzędzia z mało podejrzanego adresu: attachment.outlook.live.net lub attachments.office.net.

Po zdobyciu interesujących artefaktów dane mogą zostać wyprowadzone z firmy poprzez stworzenie webaplikacji w domenie *.azurewebsites.net lub *.cloudapp.azure.com i za pomocą protokołu HTTPS przesyłane do niej POST-porcjami.

Więcej informacji: LOTS Project

B

ardzo wiele firm utrzymuje repozytoria publicznych projektów na popularnych serwisach takich jak Github oraz Gitlab. Na przykład listę loginów poszczególnych użytkowników w serwisie Github można uzyskać bardzo łatwo – wystarczy odwiedzić adres: https://github.com/orgs/$firma/people.

Plus iterując po poszczególnych projektach: https://github.com/$firma/$projekt/graphs/contributors można zebrać dość dużą ilość unikatowych użytkowników. Gdzie następuje wyciek? Otóż Github używa adresów e-mail powiązanych z kontem Github (można mieć ich więcej niż jeden – a często na jednym koncie łączy się prywatne i firmowe adresy) przy zatwierdzaniu kodu (ang. commit) oraz innych aktywnościach w profilu użytkownika. Kiedy użytkownik zatwierdza kod w publicznym repozytorium jego adres e-mail jest publikowany i staje się publicznie dostępny.
[ czytaj całość… ]

Znalazłeś w repozytorium X prywatny klucz SSH i chciałbyś się dowiedzieć do kogo należy? Nic prostszego:

ssh -i znajda.key git@github.com

Warning: Permanently added 'github.com' (RSA) to the list of known hosts.
PTY allocation request failed on channel 0
Hi nfsec! You've successfully authenticated, but GitHub does not provide shell access.
Connection to github.com closed.

Działa również z gitlab.com, bitbucket.org i zapewne innymi.

Więcej informacji: GNU/JUSTIN

K

iedy wykonujemy program Python to w tle wykonuje się najpierw kompilacja kodu źródłowego (instrukcje znajdujące się w danym pliku .py) do formatu zwanego jako kod bajtowy. Kompilacja to proces tłumaczenia kodu na inny format, a w tym wypadku kod bajtowy jest niskopoziomową, niezależną od platformy reprezentacją kodu źródłowego. Język programowania Python przekłada każdą z instrukcji źródłowych na grupę instrukcji kodu bajtowego poprzez podzielenie ich na pojedyncze kroki. Proces przekładania kodu źródłowego na kod bajtowy odbywa się z myślą o szybkości wykonania – kod bajtowy może działać o wiele szybciej od oryginalnych instrukcji z kodu źródłowego zawartego w pliku tekstowym.
[ czytaj całość… ]

I

nernet to wodospad cieknących danych. W mojej pierwszej serii Necronomicon ( część I oraz II) mogliśmy się o tym przekonać na przykładzie skracarek adresów URL. Dzisiaj zajmiemy się serwisami oferującymi miejsce na repozytoria kodu. Ale od początku. Jakieś dziesięć lat temu powstał ruch DevOps – przechodząc przez różne etapy rozwoju dołączono do niego kolejny człon – DevSecOps. Upraszczając: jest to ruch, który osadza w cykl życia oprogramowania procesy bezpieczeństwa. Jego braki lub luki proceduralne są częstym i w dużej mierze niedocenianym wektorem zagrożeń dla wielu firm i organizacji.
[ czytaj całość… ]