2

października 1983 roku podczas specjalnego programu telewizjnego kręconego na żywo pt. „Making the Most of the Micro – Live!” w BBC1 (ang. British Broadcasting Corporation) doszło do incydentu związanego z bezpieczeństwem komputerowym. W trakcie programu prowadzący John Coll i Ian McMcNaught-Davis chcieli zademonstrować, jak podłączyć się z usługą poczty elektroczninej (e-mail) British Telecom Gold za pomocą zwykłego modemu. Niestety krótko przed emisją kierownik sali podał hasło do konta jednemu z prowadzących podczas, gdy jego mikrofon był włączony. Wykorzystali to goście programu, którzy znajdowali się w poczekalni. Skontaktowali się telefocznie ze znajomym hackerem i przekazali mu podsłyszane hasło. Hackerzy pod pseudonimami „Oz” i „Yug” wykorzystali tę informację, aby zalogować się szybciej na konto programu. W trakcie demonstracji przez prowadzących na ekranie komputera pojawiła się ich wiadomość, w której w zabawny sposób wytknęli błąd w zabezpieczeniach:

Computer Security error. Illegal access
I hope your Television PROGRAMME runs
as smoothly as my PROGRAM worked out
your passwords!   Nothing is secure!

    Hackers' Song.

"Put another password in,
Bomb it out and try again,
Try to get past logging in,
we're Hacking, Hacking, Hacking...

Try his fist wife's maiden name,
This is more than just a game.
It's real fun, but just the same,
It's Hacking, Hacking, Hacking!"

    -   The NutCracker.
       ( Hackers' U.K. )

<
*** ACN019 (41) on SYS81  12:08
HI THERE OWLETS, FROM OZ AND YUG (OLIVER AND GUY)!

Pomimo włamania do systemu nie zostały wyrządzone żadne szkody i demonstracja mogła być kontynuowana bez zakłóceń. Celem tego incydentu było jedynie pokazanie, że żadne systemy nie są w pełni bezpieczne. Sam program „na żywo” był dwurazowym wydarzeniem zorganizowanym w odpowiedzi na „masowe zainteresowanie” widzów po pierwszych seriach cyklicznego programu „Making the Most of the Micro” (będącego częścią większego projektu edukacyjnego Computer Literacy Project działającego w latach 1980-1989 w Wielkiej Brytanii). Dlatego wydarzenie z pierwszej części odbiło się bardzo szerokim echem i przyczyniło się do wzrostu zainteresowania tematyką hackerów i bezpieczeństwa komputerowego. W drugiej części tego specjalnego programu Live nie omieszkano poruszyć zagadnień bezpieczeństwa haseł, a nawet pokazano jak hacker 'David’ włamuje się na żywo do innego komputera. Choć incydent na antenie BBC nie był wynikiem skomplikowanego ataku technicznego, lecz prostego błędu ludzkiego (i słabego, dwuliterowego hasła) to przeszedł do historii jako jeden z pierwszych transmitowanych na żywo przykładów hackingu.

Więcej informacji: The NutCracker Song, 1983: The BBC is HACKED Live On Air | Micro Live | Retro Tech | BBC Archive, Micro Live, MTMOTM Live Special

O

programownie typu rootkit stanowi klasę złośliwego oprogramowania (ang. malware), które zostało zaprojektowane w celu zapewnienia ukrytego, trwałego i uprzywilejowanego dostępu do skompromitowanego systemu. Jako post-eksploatacyjne narzędzie (stanowiące końcowy wektor ataku) zazwyczaj uzbrojone jest w funkcje umożliwiające: persystencję działania; eksfiltrację danych; eskalację uprawnień; ukrywanie swoich złośliwych komponentów pod postacią procesów, połączeń sieciowych, a przede wszystkim plików i katalogów. Ukrywanie plików i katalogów odbywa się poprzez modyfikację funkcji jądra systemu odpowiedzialnych za wyświetlanie listy plików i informacji o nich. Zamiast tworzyć i usuwać pliki (co byłoby łatwe do wykrycia) rootkit zmienia sposób, w jaki system „widzi” i raportuje posiadane pliki.
[ czytaj całość… ]

N

ie tak dawno omawialiśmy używanie xattr w macOS. Tym razem czeka nas mała demonstracja, jak podobny scenariusz może zostać wykorzystany w systemie Linux za pomocą pakietu attr. Odpowiada on za dostarczenie narzędzi (setfattr / getfattr) służących do manipulowania rozszerzonymi atrybutami systemu plików typu XFS, EXT4 oraz BTRFS. Umożliwiają one tworzenie własnych, dowolnych atrybutów plików, które możemy traktować jako „tagi” w podobny sposób, w jaki używamy metadanych EXIF dla zdjęć. Podczas gdy programiści mogą używać rozszerzonych atrybutów do rozwijania niestandardowych funkcji aplikacji, atakujący mogą je wykorzystywać do ukrywania szkodliwych ładunków.
[ czytaj całość… ]

N

aszym zadaniem jest wystawienie usługi SSH do internetu, ale nie chcemy by ktoś oprócz naszej wiedzy tajemnej mógł się do niej połączyć. Nie będziemy używali rozwiązań typu VPN, port knocking, czy zmiany portu nasłuchu z 22 na inny. Secure Shell będzie nasłuchiwać na standardowym porcie i umożliwiała połączenie z dowolnego adresu IP. Jedynym warunkiem, jaki musi spełnić klient SSH to nawiązanie połączenia z konkretnego, tylko nam znanego portu źródłowego – w przeciwnym wypadku firewall nie dopuści do połączenia:

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp --dport 22 --sport 31337 -m state --state NEW -j ACCEPT
iptables -A INPUT -j DROP

Jeśli spróbujemy teraz połączyć się ze standardowej puli źródłowych portów (1024:65535) klientem SSH – nasze połączenie zostanie odrzucone:

heavyarms:~ agresor$ ssh 192.168.254.2 -v
OpenSSH_9.9p2, LibreSSL 3.3.6
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 21: include /etc/ssh/ssh_config.d/* matched no files
debug1: /etc/ssh/ssh_config line 54: Applying options for *
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling
debug1: Connecting to 192.168.254.2 [192.168.254.2] port 22.

Zupełnie inaczej będzie to wyglądało kiedy wykorzystamy opcję klienta SSH o nazwie ProxyCommand, która wykorzysta pośrednie połączenie przez program netcat, który będzie miał ustawiony port źródłowy połączenia na stały numer 31337:

heavyarms:~ agresor$ ssh -o ProxyCommand="nc -p 31337 %h %p" 192.168.254.2 -v
OpenSSH_9.9p2, LibreSSL 3.3.6
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 21: include /etc/ssh/ssh_config.d/* matched no files
debug1: /etc/ssh/ssh_config line 54: Applying options for *
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling
debug1: Executing proxy command: exec nc -p 31337 192.168.254.2 22
debug1: Next authentication method: password
agresor@192.168.254.2's password:

Ten prosty mechanizm Security Through Obscurity pozwala nam na zdalny dostęp do serwera z dowolnego adresu IP jednocześnie trzymając zautomatyzowane boty atakujące SSH z daleka.

Więcej informacji: How can I set the source port for an SSH command-line client?, How does SSH’s ProxyCommand actually work?

M

oduły dostarczane przez dystrybucyjne jądra pochodzą z ich kodu źródłowego. Powstają one podczas procesu kompilacji jądra, a narzędzia towarzyszące przy tej operacji tworzą parę autowygenerowanych kluczy (prywatny / publiczny) i podpisują każdy moduł powstający z drzewa kodu źródłowego jądra (używając klucza prywatnego). Klucz publiczny jest zapisywany w samym jądrze systemu. Gdy moduł dostarczony z jądrem jest ładowany w systemie, klucz publiczny może zostać użyty do sprawdzenia, czy moduł pozostał niezmieniony i pochodzi z pierwotnego drzewa kodu źródłowego. Podczas uruchamiania systemu możemy poinstruować jądro, aby zawsze weryfikowało moduły i raportowało wszelkie niepowodzenia ładowania modułów „spoza drzewa” do logów, ponieważ gdy „wymusimy” obsługę tylko podpisanych modułów jądra – system Linux będzie ładować tylko moduły podpisane cyfrowo wcześniej autowygenerowanym kluczem.
[ czytaj całość… ]

P

lik lastlog, znajdujący się w ścieżce /var/log/lastlog, jest plikiem typu „niegęstego” (ang. sparse file), który próbuje wykorzystać przestrzeń systemu plików bardziej efektywnie, gdy sam plik jest częściowo pusty. Osiąga się to poprzez zapisywanie krótkich informacji (metadanych) reprezentujących puste bloki na nośniku danych zamiast rzeczywistej „pustej” przestrzeni, która tworzy blok, zużywając w ten sposób mniej miejsca. Pełny blok jest zapisywany na nośniku jako rzeczywisty rozmiar tylko wtedy, gdy blok zawiera „rzeczywiste” (niepuste) dane. Dla codziennego użytkowania systemu Linux oznacza to, że jego zgłaszany rozmiar (np. przez polecenie ls) może być znacznie większy niż rzeczywista przestrzeń, jaką zajmuje na dysku.
[ czytaj całość… ]

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