NFsec Logo

/bin/sh: Największa luka w zabezpieczeniach Uniksa

19/02/2025 (3 tygodnie temu) w Hackultura Możliwość komentowania /bin/sh: Największa luka w zabezpieczeniach Uniksa została wyłączona

T

owarzystwo Historyczne Uniksa (ang. Unix Historical Society) niedawno otrzymało i udostępniło kopię raportu technicznego Bell Labs z 1984 roku autorstwa Jamesa Allena zatytułowanego: “/bin/sh: Największa luka w zabezpieczeniach Uniksa” (ang. /bin/sh: The Biggest Unix Security Loophole). W czasach, gdy powstawał ten raport Unix był jeszcze znakiem towarowym AT&T Bell Laboratories. Z samego abstraktu możemy dowiedzieć się, że wówczas osoby zajmujące się łamaniem zabezpieczeń określało się terminem “crackerzy”. Mieli oni mieć wiele sposobów, aby stać się superużytkownikami w systemie Unix. Jednak autor wyodrębnił dwie główne klasy luk. Klasa pierwsza składała się z wielu tajemnych i trudnych do wykonania “sztuczek”. Druga klasa to jeden, łatwy sposób, z którego każdy mógł skorzystać bez problemu. Cały raport skupił się w głównej mierze na drugiej klasie. W szczególności na prawowitych poleceniach systemu (takich jak: mail, troff itp.), działających z uprawnieniami superużytkownika, które mogły zostać zmuszone do nieumyślnego wykonywania poleceń w powłoce systemowej. W praktyce raport pokazał, jak wiele programów posiadających bit setuid było napisanych w niedbały sposób zapewniając wspomnianemu crackerowi luki, których potrzebował, aby eskalować swoje uprawnienia. Poniżej znajduje się wolne tłumaczenie:
[ czytaj całość… ]

Przejmowanie ulotnych danych skracarek

05/02/2025 w Ataki Internetowe Możliwość komentowania Przejmowanie ulotnych danych skracarek została wyłączona

O

skracarkach adresów URL (ang. shorturls) mówiliśmy nie raz, nie dwa. Ogólnie rzecz biorąc ich używanie ich jako przekierowanie prowadzące do wrażliwych danych wiążę się z dużym ryzykiem. Oprócz tego, że tego typu adresy są łamane w celu odgadywania i katalogowania obiektów do których prowadzą to jeszcze posiadają inną wadę – mogą zostać przejęte. Gdy użytkownik tworzy krótki link w danej skracarce, zazwyczaj wygląda on tak: “skrót.pl/“, po którym następuje losowy ciąg cyfr i liter stworzony przez usługę np. 2TeiuwH, co daje nam: https://skrót.pl/2TeiuwH. Jednak w wielu tego typu serwisach użytkownicy mogą również dostosowywać tylną część, która pojawia się po ukośniku (“/”). Jeśli taki niestandardowy, ostatni człon adresu URL (2TeiuwH) jest już gdzieś używany, serwis informuje użytkownika, że dana fraza jest już zajęta i musi wybrać inną. Jednak mogą zdarzyć się błędy związane z weryfikacją ulotnych danych takich skracarek. Na przykład ze względu na niechęć wyczerpania się możliwych kombinacji adresów URL o określonej długości – serwisy mogą umożliwiać użytkownikom tworzenie niestandardowych części tych adresów, które były już wcześniej używane – ale oryginalny link lub konto odpowiedzialne za jego stworzenie w danym serwisie zostało usunięte lub dezaktywowane. Wówczas dochodzi do reużycia lub rotacji właściciela tego samego adresu URL, który może tym razem kierować w inne miejsce niż pierwotnie to robił oryginał. Jak możemy się domyślić – w zależności gdzie historycznie został użyty i opublikowany skrócony adres URL: czy to na profilu społecznościowym kogoś ważnego / popularnego, czy to w bardzo poczytnym serwisie / artykule – jego przejęcie i przekierowanie w szkodliwe miejsce może mieć negatywne konsekwencje zarówno dla autora wpisu, jak i czytelnika.

Atakujący tak banalną metodą może doprowadzić np. do uwiarygodnienia szkodliwej strony, która będzie wyłudzała dane uwierzytelniające lub środki finansowe tworząc ją w taki sposób, aby wpisywała się w kontekst w jakim został użyty skrócony adres URL. To samo może tyczyć się już docelowych adresów URL, do których prowadzą skrócone adresy URL. Jeśli skrócony adres jest nadal aktywny, ale docelowa domena już wygasła i jest wolna – może zostać ona ponownie zarejestrowana i zmanipulowana do serwowania szkodliwej treści lub bycia kolejnym przekierowaniem do takowej.

Więcej informacji: Crypto scammers hacked Trump’s tweets via a bug

Obchodzenie flagi montowania noexec za pomocą ddexec

27/01/2025 w Bezpieczeństwo Możliwość komentowania Obchodzenie flagi montowania noexec za pomocą ddexec została wyłączona

W

systemie Linux wszystko jest plikiem. W celu uruchomienia programu w tym systemie musi on istnieć jako plik i być dostępny w jakiś sposób przez hierarchię systemu plików (tak właśnie działa execve() wykonując program, do którego odnosi się ścieżka dostępu). Plik ten może znajdować się na dysku lub w pamięci (tmpfs), ale nadal potrzebujemy ścieżki do pliku. Dzięki temu bardzo łatwo jest kontrolować, co jest uruchamiane w systemie Linux i ułatwia to wykrywanie zagrożeń oraz narzędzi atakujących. Pomaga to też w nakładaniu opowiednich praw dostępu i polityk kontroli dostępu zapobiegając nieuprzywilejowanym użytkownikom umieszczać i wykonywać pliki gdziekolwiek. Jednak technika użyta w DDexec nie uruchamia nowego procesu w danej ścieżce, ale przejmuje już istniejący.
[ czytaj całość… ]

RapidFuzz i CharMap jako pomoc przy sprawdzaniu phishingu

15/01/2025 w Bezpieczeństwo Możliwość komentowania RapidFuzz i CharMap jako pomoc przy sprawdzaniu phishingu została wyłączona

R

apidFuzz jest cenioną za uniwersalność i szybkość biblioteką języka Python, która oferuje zestaw funkcji pomagających w obliczaniu różnic między ciągami znaków oraz dopasowywania rozmytego (ang. fuzzy matching). W swojej implementacji posiada algorytmy obliczające odległość (miarę różnicy między dwoma ciągami znaków) takie jak: Levenshteina, Damerau-Levenshteina, Hamminga, czy Jaro-Winklera oraz algorytmy obliczające współczynnik podobieństwa ciągów znaków (np. porównujące liczby pasujących do siebie znaków na tle całkowitej liczby znaków w obu ciągach). Możemy wykorzystać ją w swoim procesie przetwarzania danych, aby automatycznie identyfikować: dopasowania, duplikaty, literówki; usprawniać oczyszczanie danych lub szukać w innych bazach danych podobnych wzorców.
[ czytaj całość… ]

Podsumowanie systemu plików proc dla analityków bezpieczeństwa

03/01/2025 w Bezpieczeństwo Możliwość komentowania Podsumowanie systemu plików proc dla analityków bezpieczeństwa została wyłączona

P

odczas konferencji BSides w Monachium Stephan Berger oraz Asger Strunk przedstawili prelekcję pt. “/proc Dla Analityków Bezpieczeństwa: Ujawnianie Ukrytych Zagrożeń i Skarbów dla Informatyki Śledczej” (ang. “/proc For Security Analysts: Unveiling Hidden Threats And Forensic Treasures”), której agenda oraz poruszane tematy idealnie pasują, aby przeprowadzić małe podsumowanie tego zestawu tematów na przykładach poruszanych w szerszym zakresie na łamach NF.sec. Dlatego pozwolę sobie na małą transkrypcję owej prelekcji wraz z odsyłaniem do bardziej obszernych publikacji zagłębiających się w poruszane tematy. Oprócz dobrze już nam znanych zagadnień autorzy dodali również klika nowych smaczków, z których możemy dowiedzieć się nowych rzeczy i uzupełnić swój warsztat.
[ czytaj całość… ]

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?

Lets Encrypt najpopularniejszym dostawcą TLS w top 750.000 popularnych domen

17/11/2024 w Techblog Możliwość komentowania Lets Encrypt najpopularniejszym dostawcą TLS w top 750.000 popularnych domen została wyłączona

C

loudflare udostępnił publicznie usługę Radar, w której są zawarte dane o rankingu domen: Domian Rankings Worldwide. Tutaj należy mieć świadomość, że dane pochodzą z ich publicznego serwera DNS, z którego nie koniecznie musi korzystać cały internet. Niemniej jednak jest to dobra próbka, aby przeprowadzić eksperyment podobny do analiz nagłówka HTTP. W pliku pobranym 28.09.2024 znalazło się 1.008.856 domen. Finalnie udało połączyć się z 750.892 domenami w celu pobrania informacji o ich certyfikacie TLS. Aby szybko pozyskać te dane został zmodyfikowany kod skryptu httpsrvreaper na bazie którego powstał sslsrvreaper. Jest on na tyle prosty, że czyta z pliku tekstowego domains.txt adresy, z jakimi ma się połączyć i zapisać ich metadane TLS w formacie JSON, na przykład:
[ czytaj całość… ]