O

d wersji jądra 5.14 został wprowadzony zestaw poprawek dający systemowi Linux opcjonalną blokadę jądra mającą na celu wzmocnienie granicy między prawami administracyjnymi, a jądrem. Po jej włączeniu różne elementy funkcjonalności jądra (w tym nisko poziomowy dostęp do sprzętu) są ograniczone dla różnych programów. Większość głównych dystrybucji Linuksa zawiera już zestaw tych poprawek pod postacią zaczepu (ang. hook) do Linux Security Modules (LSM), czyli programowalnego szkieletu do implementacji polityk bezpieczeństwa (ang. security policies) i obowiązkowej kontroli dostępu (ang. Mandatory Access Control) w jądrze systemu. Lockdown LSM zapewnia prostą implementację poziomu blokady jądra za pomocą wiersza poleceń jądra lub pseudo systemowi plików sysfs. Listę aktywnych modułów bezpieczeństwa w LSM można znaleźć odczytując plik: /sys/kernel/security/lsm. Jest to lista rozdzielona przecinkami, odzwierciedlająca kolejność, w jakiej przeprowadzane są sprawdzenia modułów.
[ czytaj całość… ]

Powrównując różne dane w języku Python, ze względu na wydajność najlepiej użyć do tego zbiorów. Zbiory są zaimplementowane przy użyciu tablic mieszających. Za każdym razem, gdy dodajemy obiekt do zbioru, pozycja w pamięci obiektu zbioru jest określana przy użyciu funkcji skrótu obiektu, który ma zostać dodany. Podczas testowania przynależności obiektu, wszystko co należy zrobić, to sprawdzić, czy obiekt znajduje się na pozycji określonej przez jego funkcję skrótu (ang. hash) – dlatego szybkość tej operacji nie zależy od rozmiaru zestawu danych. W przypadku list jest odwrotnie – cała lista musi zostać przeszukana, co stanie się wolniejsze wraz ze wzrostem tej listy. Przykładem może być szukanie unikalnych linii występujących w pierwszym pliku w porównaniu z drugim plikiem:

#!/usr/bin/env python3

import argparse

def uniq_lines(file1, file2, file3):
    try:
        with open(file1, 'r') as f1, open(file2, 'r') as f2, open(file3, 'w') as f3:
            file2_lines = set(line.strip() for line in f2)
            print(file2_lines)
            for line in f1:
                if line.strip() not in file2_lines:
                    f3.write(line)
    except FileNotFoundError:
        print('Error: One of the files was not found.')
    except IOError:
        print('Error: An I/O error occurred while reading the files.')
    print(f'Unique lines from {file1} compared with {file2} written to {file3}.')

if __name__ == "__main__":
    parser = argparse.ArgumentParser(
        prog='UniqLines.py',
        description='Compare two files and write unique lines to a third file.')
    parser.add_argument('file1', help='The first file.')
    parser.add_argument('file2', help='The second file.')
    parser.add_argument('file3', help='The third file to write unique lines to.')
    args = parser.parse_args()
    uniq_lines(args.file1, args.file2, args.file3)

Wszystkie unikalne linie zapisywane są do trzeciego pliku.

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

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

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

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

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

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

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

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 input – stdin). Gdy dane są wyświetlane na terminalu, używane jest standardowe wyjście (ang. standard output – stdout).
[ czytaj całość… ]