NFsec Logo

Znajdowanie złośliwych pakietów PyPI

11/12/2024 w Bezpieczeństwo Możliwość komentowania Znajdowanie złośliwych pakietów PyPI została wyłączona

P

rzez ostatni rok branża odnotowała wzrost ataków wymierzonych w łańcuch dostaw oprogramowania (ang. supply chain threats). Złośliwa modyfikacja w tym ataku obejmuje narzędzia, kod i infrastrukturę potrzebną do wdrożenia aplikacji (często z wykorzystaniem komponentów open source lub zewnętrznych dostawców). Jednym z powszechnych sposobów przeprowadzania tych ataków przez cyberprzestępców jest kompromitacja lub przesyłanie złośliwych zależności do repozytoriów pakietów języka Python – Python Package Index (PyPI). W ramach PyPI, które jest szanowanym oraz akceptowanym repozytorium i hostuje oszałamiającą liczbę pakietów języka Python, wyłoniła się niepokojąca rzeczywistość. Niezrównana popularność repozytorium nieumyślnie przyciągnęła uwagę nieuczciwych podmiotów, które żarliwie starają się wykorzystać jego ogromną bazę użytkowników, potajemnie rozpowszechniając złośliwe pakiety.
[ 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ść… ]

Używanie xattr w macOS jak rasowe APT

28/11/2024 w Bezpieczeństwo Możliwość komentowania Używanie xattr w macOS jak rasowe APT została wyłączona

X

attr, czyli rozszerzone atrybuty (ang. e[x]tended [attr]ibutes) to polecenie, które pozwala w systemach typu Unix, takich jak macOS przechowywać dodatkowe metadane plików w systemie. Podobnie jak w przypadku ADS (ang. Alternate Data Streams) dla systemu Windows funkcjonalność ta umożliwia atakującym ukrywanie danych w systemie plików bez widocznej zmiany zawartości plików. Ostatnia analiza arsenału grupy APT Lazarus pokazuje, że używanie narzędzi tego typu jest często pomijanym wektorem w współczesnych cyberatakach. W systemie macOS xattr jest często używany do przechowywania danych, takich jak tagi menedżera Finder, informacje o kwarantannie plików i metadane wyszukiwania Spotlight. Chociaż atrybuty te są zazwyczaj nieszkodliwe i pomagają poprawić funkcjonalność systemu, atakujący mogą je wykorzystać do ukrycia złośliwych danych na widoku.
[ 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?

Zawieszone rekordy DNS

20/10/2024 w Bezpieczeństwo Możliwość komentowania Zawieszone rekordy DNS została wyłączona

W

celu zrozumienia jak powstają zawieszone rekordy DNS (ang. dangling DNS records) należy posiadać podstawową widzę na temat działania usługi DNS, która tłumaczy przyjazne dla użytkowników nazwy domen, takie jak nfsec.pl (łatwe do zapamiętania i rozpoznania) na numeryczne adresy IP. Adresy IP dla każdej domeny są przechowywane na autorytatywnych serwerach DNS, które można porównać do książek telefonicznych w internecie. Po wpisaniu adresu strony internetowej w przeglądarce, przeglądarka na początku łączy się z rekurencyjnym serwerem DNS i zadaje pytanie: „Jaki jest adres IP nfsec.pl?”. Rekursywny serwer DNS wysyła zapytanie do serwera autorytatywnego w celu uzyskania odpowiedzi (oczywiście to trochę bardziej skomplikowane).
[ czytaj całość… ]

TELFHASH – Trend Micro ELF Hash

29/09/2024 w Bezpieczeństwo Możliwość komentowania TELFHASH – Trend Micro ELF Hash została wyłączona

Telfhash to funkcja haszująca używanych symboli dla plików ELF w systemie *nix, tak jak imphash to funkcja haszująca importowanych bibliotek dla plików PE w systemie Windows. Za jej pomocą możemy grupować pliki ELF według podobieństwa na podstawie ich tabeli symboli. Pozwala to na byciu na bieżąco ze wszystkimi wariantami szkodliwego oprogramowania (ang. malware), które są stale rozwijane i dokładne grupowanie zgodnie z ich rzeczywistą rodziną pochodzenia np. Tsunami, Gafgyt, czy Mirai. Telfhash do swoich obliczeń używa TLSH, co umożliwia mu rozpoznawanie oryginalnych próbek, nawet gdy zostały dodane do nich nowe funkcje importujące nowe biblioteki. Jeśli rozebrany i statycznie skompilowany plik binarny nie ma symboli, telfhash emuluje je poprzez uzyskanie i stworzenie listy z adresów docelowych dla wywołań funkcji.
[ czytaj całość… ]

Uciekając z sudo – część szósta

24/09/2024 w Bezpieczeństwo Możliwość komentowania Uciekając z sudo – część szósta została wyłączona

P

oprzez wykorzystanie dowolnych komentarzy zawierających specjalny znak nowej linii: „\n” i za pośrednictwem poleceń iptables oraz iptables-save możemy nadpisać dowolny plik z prawami administratora i częściowo kontrolować zapisane wiersze – częściowo, ponieważ moduł komentarzy w iptables pozwala na umieszczenie 256 znaków, a zapis pliku poprzez iptables-save wprowadza pewne dane z utworzonych reguł zapory ogniowej (ang. firewall), które są dodawane przed i po wstrzykniętym komentarzu. W systemie Linux jest przynajmniej jeden plik, który nie przejmuje się niepotrzebnymi wierszami i je ignoruje, a jest nim (nie)sławny plik /etc/passwd.
[ czytaj całość… ]

Atak, wykrywanie i informatyka śledcza na żywo w systemie Linux

18/07/2024 w Bezpieczeństwo, Pen Test, Techblog Możliwość komentowania Atak, wykrywanie i informatyka śledcza na żywo w systemie Linux została wyłączona

O

statnio miałem okazję wziąć udział w szkoleniu, które przygotował Leszek Miś pt. „Linux Attack, Detection and Live Forensics + 90 Days PurpleLabs Access” (całość jest w języku angielskim) – jest to jedno z niewielu dostępnych szkoleń, które jest w 100% skupione na systemie operacyjnym Linux. Po otrzymaniu dostępu do platformy szkoleniowej oraz laboratorium czekało na mnie 225 tematów do opracowania – kilka z nich można oczywiście odjąć z technicznego punktu widzenia, ponieważ są to tematy wprowadzające / wyjaśniające zasady pracy z kursem i maszynami do testów. Niemniej dobór materiału jest naprawdę spory i stanowi solidny fundament do nauki technik atakowania i obrony systemu Linux. Przy pierwszej styczności z mapą zagadnień od razu przypomniała mi się pierwsza, kupiona książka w tym temacie, czyli „Linux. Agresja i Ochrona” wydawnictwa Robomatic (ISBN: 838715041X) – tylko tym razem materiał można od razu przećwiczyć na gotowych scenariuszach i nie użyjemy już do tego SATANa.

Ponieważ dostęp do materiałów jest nieograniczony, ale dostęp do infrastruktury labów trwa aż 90 dni – podzieliłem sobie cały material od 3 do 5 zagadnień dziennie, aby mieć wolne niektóre weekendy oraz zapas czasu w przypadku braku możliwości wieczornej nauki w tygodniu. Pierwsze dni zostały poświęcone na sprawdzenie wszystkich dostępów oraz przygotowanego ekosystemu. Na początku „skakanie” po infrastrukturze może wydawać się trochę uciążliwe, ale posiadając do dyspozycji agregator adresów i dostępów z czasem nabiera się wprawy. Kolejne kroki to już intensywne wgryzanie się w przedstawione scenariusze, opisy i narzędzia, z których można wynieść wiele wartościowych wniosków. To, co najbardziej spodobało mi się w szkoleniu to różnorodne podejście do całości. Podczas nauki poszczególnych rozdziałów otrzymujemy możliwość zapoznania się z technikami, taktykami i strukturami narzędzi ofensywnych używanych w atakowaniu Linuksa; polecenia i ekosystem pozwalający na przeprowadzanie polowań na poznane zagrożenia oraz zestaw stabilnych, darmowych rozwiązań, które możemy od razu przetestować jako warstwy do ochrony i wykrywania ataków na systemie Linux i jego komponentach. Wszystko to robimy na różnych poziomach (przestrzeni użytkownika / jądra) oraz warstwach (aplikacyjnych / sieciowych) systemu.

Listę poruszanych tematów możemy znaleźć na oficjalnej stronie szkolenia (prowadzony jest nawet jego changelog). Wiele z nich jest poruszone w sposób wyczerpujący, a niektóre dają bardzo mocne podstawy do dalszej eksploracji tematu czy zagadnień przewijających się w nich przy okazji. Jeśli znajdziemy jakieś błędy lub dezaktualizację to możemy je zgłaszać na adres e-mail lub jako komentarz pod konkretnym zadaniem. Mi przy okazji paru znajdek udało się zamienić kilka zdań z autorem, a ponieważ wpis ten nie jest w żaden sposób sponsorowany – Leszek był tak miły, że dla 20’stu zainteresowanych czytelników NF.sec przygotował kod dający 20% zniżki, który można wykorzystać do 15.08.2024 r. Jeśli zakres materiału Was przekonuje to ze swojej strony mogę polecić tę pozycję na ścieżce doskonalenia swojego warsztatu z bezpieczeństwa systemu Linux.

Możliwe zdalne wykonanie kodu w OpenSSH – CVE-2024-6387 aka regreSSHion

10/07/2024 w Bezpieczeństwo 1 komentarz.

J

ednostka badawcza firmy Qualys (ang. Qualys Threat Research Unit – TRU) opublikowała szczegóły krytycznej luki w kodzie OpenSSH (sshd) umożliwiającej zdalne wykonanie kodu bez uwierzytelniania w systemach Linux opartych na glibc. CVE powiązane z tą luką to CVE-2006-5051 i CVE-2024-6387. Powodem zastosowania dwóch numerów CVE w tym wykorzystania tego z 2006 roku jest regresja, czyli powrót starego błędu. Niestety zdarza się to dość regularnie (nie w przypadku OpenSSH, ale ogólnie różnego rodzaju oprogramowania), że programiści nie dodają testów, aby upewniać się, że luki odkryte wcześniej w cyklu życia programu są pokryte łatami w przyszłych wersjach. Wersje OpenSSH starsze niż 4.4p1 są podatne na CVE-2006-5051 oraz CVE-2008-4109, z kolei OpenSSH w wersji 8.5p1 (tutaj w październiku 2020 pojawiła się regresja) do 9.8p1 (ale nie włącznie – to jest wersja poprawiona) są podatne na CVE-2024-6387 z powodu przypadkowego usunięcia krytycznego komponentu w funkcji. Ten błąd nie dotyczy systemów OpenBSD, ponieważ w 2001 roku OpenBSD opracowało bezpieczny mechanizm, który zapobiega tej luce.

Należy jednak pamiętać, że wiele dystrybucji Linuksa nie większy numerów wersji, jeśli naniosą łatkę na aktualnie używany pakiet – tylko podniesie swój wewnętrzny patchset np. z 8.9p1-3ubuntu0.7 do 8.9p1-3ubuntu0.10. Jakie dystrybucje są podatne?

Warto zaznaczyć, że luka ta opiera się na wygraniu wyścigu, czyli występuje tutaj problem z synchronizacją czasową wielu operacji, a samo wykorzystanie luki nie jest łatwe do odtworzenia – autorzy luki musieli wykonać około 10.000 prób na platformie x86 (32-bitowej), gdzie większość systemów Linux działa obecnie na architekturach 64-bitowych i ich eksploitacja wydaje się obecnie niepraktyczna. Luka może mieć jednak znaczenie w przypadku starszych systemów IoT, szczególnie jeśli nie są już dla nich dostępne poprawki bezpieczeństwa.

Mitygacja zagrożenia:

Proces sshd można chronić przed tym atakiem ustawiając odpowiedni parametr LoginGraceTime. Serwer OpenSSH nadal będzie podatny na ataki typu DoS (ang. Denial of Service), poprzez wyczerpanie wszystkich połączeń przez osobę atakującą, ale nie pozwoli na zdalne wykonanie kodu. Jako użytkownik root powinniśmy edytować plik /etc/sshd_config oraz dodać lub edytować wspomnianą opcję ustawiając jej wartość na zero:

LoginGraceTime 0

Po zapisaniu pliku należy zrestartować serwer OpenSSH:

systemctl restart sshd.service || /etc/init.d/sshd restart

Powyższe ustawienie wyłącza zdolność serwera sshd do zrywania połączeń, jeśli uwierzytelnianie nie zostanie zakończone w określonym czasie. Dlatego może to prowadzić do skutecznych ataków typu odmowa usługi (DoS). Jeśli zdecydowaliśmy się na to rozwiązanie to najlepiej połączyć je z narzędziem typu fail2ban lub zaporą ogniową *tables (a nawet techniką pukania w porty) w celu monitorowania logów i odpowiedniego limitowania połączeń na port SSH.

Upakowane ELFy – czerwona flaga dla pliku binarnego w Linuksie

21/06/2024 w Bezpieczeństwo, Debug Możliwość komentowania Upakowane ELFy – czerwona flaga dla pliku binarnego w Linuksie została wyłączona

U

ltimate Packer for Executables (UPX) to program pakujący dla kilku formatów wykonywalnych, takich jak biblioteki DLL systemu Windows, aplikacji macOS oraz Linux ELF. Jak możemy przeczytać na oficjalnej stronie programu UPX: „potrafi zazwyczaj zmniejszyć rozmiar plików programów i bibliotek DDL o około 50% – 70%, redukując w ten sposób miejsce na dysku, czas ładowania w sieci, czas pobierania oraz inne koszty dystrybucji i przechowywania”. Programy pakujące zasadniczo biorą oryginalny plik wykonywalny i dodają mały fragment kodu zwany „odgałęzieniem” (ang. stub) do nowo utworzonego wykonywalnego pliku. Kod pośredniczący zostanie następnie użyty do rozpakowania pliku i „przywrócenia” pliku wykonywalnego do jego pierwotnego stanu. Podczas, gdy niektóre programu pakujące, takie jak wspomniany UPX, tylko kompresują pliki, inne mogą je również szyfrować. Atakujący często używają kompresji, aby ukrywać złośliwe oprogramowanie jako pozornie nieszkodliwe i legalne pliki, co może oszukać silniki antywirusowe oparte na sygnaturach.
[ czytaj całość… ]