S

hebang (ang. shebang line, bang path) (#!) na początku skryptu jest wymagany, ponieważ informuje jądro systemu operacyjnego (ang. kernel), jakiego interpretara należy użyć do wykonania danego pliku. Gry próbujemy uruchomić plik bezpośrednio (np. ./skrypt.sh), jądro sprawdza pierwsze bajty pliku. Jeśli znajdzie tam sekwencję #!, trakuje resztę linii jako ścieżkę do programu (interpretera), który ma zostać uruchomiony, przekazując mu nazwę skryptu jako argument. Historycznie to powłoka systemowa zajmowała się uruchamianiem skryptów, dopóki nie zostało to zmienione na jądro systemu przez Dennisa Ritche w 1980 roku. Kluczowy jest fakt, że jądro systemu nie przeszukuje zmiennej środowiskowej $PATH podczas obsługi shebang:

agresor@darkstar:~$ echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

Zmienna $PATH jest używana przez powłokę (np. bash / dash), gdy wpisujemy dane polecenie (np. ls ), aby znaleźć odpowiedni plik wykonywalny. Uruchamiając polecenie śledzące konkretne wywołanie systemowe np. strace możemy zobaczyć jak wykonywane jest polecenie:

root@darkstar:~# strace -e execve cat /etc/hostname
execve("/usr/bin/cat", ["cat", "/etc/hostname"], 0x7ffdae655db8 /* 15 vars */) = 0
darkstar
+++ exited with 0 +++

Jądro systemu ma już pełną ścieżkę (/usr/bin/cat). Z kolei jeśli spojrzymy na kod źródłowy powłoki dash to w pliku exec.c znajdziemy informację o przeszukiwaniu zmiennej $PATH:

/*
 * Do a path search.  The variable path (passed by reference) should be
 * set to the start of the path before the first call; padvance will update
 * this value as it proceeds.  Successive calls to padvance will return
 * the possible path expansions in sequence.  If an option (indicated by
 * a percent sign) appears in the path entry then the global variable
 * pathopt will be set to point to it; otherwise pathopt will be set to
 * NULL.
 *
 * If magic is 0 then pathopt recognition will be disabled.  If magic is
 * 1 we shall recognise %builtin/%func.  Otherwise we shall accept any
 * pathopt.
 */

const char *pathopt;

int padvance_magic(const char **path, const char *name, int magic)

Dlatego jądro systemu, które aktualnie jako pierwsze obsługuje próbę uruchomienia pliku, działa na niższym poziomie i wymaga dokładnej, bezwzględnej (absolutnej) ścieżki do pliku wykonywalnego interpretera (np. /bin/bash, /usr/bin/python3). On, czyli interpreter dalej zajmuje się znalezieniem odpowiedniej ścieżki do programu. Gdybyśmy podali tylko #!bash jako shebang, jądro nie wiedziałoby, gdzie szukać pliku bash (czy jest w /bin, /usr/bin, /usr/local/bin, czy jeszcze gdzieś indziej). W wielu przypadkach możemy także zobaczyć shebang w formie:

#!/usr/bin/env bash

Tutaj pełną ścieżką jest /usr/bin/env. Program env również przeszukuje zmienną $PATH, aby znaleźć pierwszy argument, który mu podano (w tym przypadku: bash). Następnie env uruchamia znaleziony interpreter bash, przekazując mu resztę skryptu. Użycie programu env sprawia również, że skrypt jest bardziej przenośny między różnymi systemami (np. Linux, Unix), na których interpreter bash (lub python itp.) może znajdować się w różnych katalogach, ale program env jest prawie zawsze dostępny pod standardową ścieżką /usr/bin/env.

Więcej informacji: Shebang, env, PATH isn’t real on Linux

A

ge to proste, nowoczesne i bezpieczne narzędzie do szyfrowania plików oraz biblioteka języka Go. Charakteryzuje się małymi, jawnymi kluczami, brakiem opcji konfiguracyjnych i możliwościami kompozycji poleceń w stylu Unix. Program ten tworzy asymetryczną parę kluczy: publiczny i prywatny. Wersja publiczna jest używana do szyfrowania, a prywatna do odszyfrowania (plików, katalogów i wiadomości). Dla wygody age obsługuje również szyfrowanie za pomocą publicznych kluczy SSH oraz odszyfrowywaniu przy użyciu odpowiedniego pliku klucza prywatnego. Kilka przykładów zastosowania:

agresor@darkstar:~$ sudo apt install -y age
agresor@darkstar:~$ age-keygen | age -p > age-private.key
Public key: age1vvdj5yvk0psrz6vs5lrgqjew7h5vaep6rdtg9lwyt62x69ltu5esmpl2ad
Enter passphrase (leave empty to autogenerate a secure one):
age: using autogenerated passphrase "borrow-journey-define-exile-earth-win-cigar-yard-urge"

Tworzymy parę kluczy, z czego klucz prywatny będzie dodatkowo zaszyfrowany hasełem. Teraz możemy zaszyfrować plik nfsec_pl.txt otrzymanym kluczem publicznym:

agresor@darkstar:~$ age -o nfsec_pl.txt.age -r age1vvdj5yvk0...69ltu5esmpl2ad nfsec_pl.txt
agresor@darkstar:~$ head -3 nfsec_pl.txt.age
age-encryption.org/v1
-> X25519 Tlw8RQmWEXu7mjpBUJ1GNV2ZRuM5c0lc7++OT4Y+j24
xzwZGjRDJVQywki6tOmSaXIKjFXrg1+ycPVjtljF1es

Tak zaszyfrowany plik możemy odszyfrować za pomocą polecenia:

agresor@darkstar:~$ age -d -i age-private.key -o nfsec_pl.txt nfsec_pl.txt.age
Enter passphrase for identity file "age-private.key":

Ten sam proces (szyfrowania) możemy przeprowadzić za pomocą publicznego klucza SSH:

agresor@darkstar:~ $ age -R .ssh/id_rsa.pub nfsec_pl.txt > nfsec_pl.txt.age
agresor@darkstar:~ $ head -3 nfsec_pl.txt.age
age-encryption.org/v1
-> ssh-rsa x4o9pQ
2VKd5t82j0zjoO7PMt+xZKTxPEVAJSH/fvWWJYfHy+Q0jZkw01k6oGOXfq1BbDDE

A następnie odszyfrować go kluczem prywatnym SSH:

agresor@darkstar:~ $ age -d -i .ssh/id_rsa nfsec_pl.txt.age > nfsec_pl.txt

W ten sposób możemy bardzo prosto i szybko szyfrować wiadomości i pliki dla użytkowników, którzy zdecydowali się opublikować swoje klucza na profilu GitHub:

curl -s https://github.com/$login.keys | age -R - nfsec_pl.txt > nfsec_pl.txt.age

Więcej informacji: age encryption

U

sługa SSH od wersji 9.0 (kwiecień 2022 roku) wprowadziła algorytm wymiany kluczy (KEX), między klientem a serwerem, który uważany jest za bezpieczny przed atakami ze strony komputerów kwantowych. Głównie chodzi o atak „zbieraj teraz, odszyfruj później” (ang. harvest now, decrypt later), w którym atakujący może złamać proces wymiany kluczy, aby odszyfrować i wyświetlić całą sesję połączenia SSH. Atak ten nie musi być przeprowadzany w czasie rzeczywistym; może opierać się na nagrywaniu ruchu sieciowego podatnych, zaszyfrowanych sesji SSH, a następnie ich odszyfrowaniu w późniejszym czasie (po uzyskaniu dostępu do komputera kwantowego). Algorytm, o którym mowa to sntrup761x25519-sha512@openssh.com – jest on oparty na NTRU Prime, połączony z tradycyjnym X25519. Daje to hybrydowe podejście: system jest bezpieczny, dopóki chociaż jeden z tych algorytmów pozostaje nie do złamania.
[ czytaj całość… ]

P

akiet TCP Wrappers jest instalowany domyślnie we wszystkich głównych dystrybucjach systemu Linux. Zapewnia on kontrolę dostępu do usług sieciowych na poziomie hosta. Najważniejszym komponentem tego pakietu jest biblioteka libwrap.so, z obsługą której kompilowane są inne programy. Dzięki temu podczas próby połączenia z danym programem TCP Wrappers na początku odwołuje się do swoich plików dostępu (tj. /etc/hosts.allow i /etc/hosts.deny), aby ustalić, czy klient ma prawo połączyć się z daną usługą. Jeśli klient otrzyma zgodę na połączenie, TCP Wrappers zwalnia kontrolę nad połączeniem z żądaną usługą i nie bierze już udziału w komunikacji między klientem, a serwerem. Oprócz kontroli dostępu i rejestrowania połączeń, TCP Wrappers może wykonywać polecenia w celu interakcji z klientem przed zablokowaniem lub zwolnieniem kontroli nad połączeniem z żądaną usługą sieciową. I tutaj pojawia się przestrzeń na mechanizm utrzymania trwałego dostępu do systemu.
[ czytaj całość… ]

P

odsłuchiwanie ruchu sieciowego najczęściej kojarzy się nam z systemami typu: IDS/IPS lub narzędziami takimi, jak: tcpdump. Głównie programy te wykorzystywane są z różnych uzasadnionych powodów np. ochrona sieci lub rozwiązywanie problemów sieciowych. Czasami jednak proces ten może zostać użyty przez złośliwe oprogramowanie lub atakującego w celu kradzieży informacji, czy też aktywacji uśpionych tylnych wejść do systemu. Na szczęście za pomocą bezpośredniego dostępu do pliku /proc/net/packet możemy szybko zidentyfikować procesy powiązane z gniazdami pakietów. Tego typu gniazda (ang. sockets) służą do odbierania lub wysyłania surowych pakietów na poziomie sterownika urządzenia sieciowego (warstwa 2 OSI ; najczęściej karty sieciowej) pozwalając na bardziej bezpośrednią interakcję ze stosem sieciowym niż standardowe gniazda Berkeley w warstwie 4’tej (np. AF_INET / AF_INET6 + SOCK_STREAM / SOCK_DGRAM). Nas będzie interesować typ gniazda albo SOCK_RAW (dla surowych pakietów zawierających nagłówek warstwy łącza), albo SOCK_DGRAM (dla pakietów przetworzonych z usuniętym nagłówkiem warstwy łącza):

root@darkstar:~# cat /proc/net/packet
sk               RefCnt Type Proto  Iface R Rmem   User   Inode
ffff8f34c7d7d000 3      3    88cc   2     1 0      998    6666
ffff8f34c7d7c000 3      3    88cc   3     1 0      998    6685
ffff8f34c0b80000 3      3    0003   0     1 0      0      8767
ffff8f34c5243800 3      2    0003   0     1 0      0      9350

Nas będzie interesować ostatnia kolumna, czyli Inode, która pozwoli nam na identyfikację procesów i ich właścicieli. Pozostaje nam przeszukanie procfs pod numerach ze wspomnianej kolumny, aby otrzymać numery identyfikacyjne procesów odpowiedzialnych za otwarte gniazda pakietów:

root@darkstar:~# ls -al /proc/*/fd/* 2> /dev/null | egrep '(6666|6685|8767|9350)'
lrwx------ 1 root            root            64 Sep 1 19:44 /proc/1053/fd/3 -> socket:[8767]
lrwx------ 1 root            root            64 Sep 1 19:44 /proc/1067/fd/5 -> socket:[9350]
lrwx------ 1 systemd-network systemd-network 64 Sep 1 19:44 /proc/404/fd/18 -> socket:[6666]
lrwx------ 1 systemd-network systemd-network 64 Sep 1 19:44 /proc/404/fd/19 -> socket:[6685]

Powyżej widzimy dwa procesy (ID: 404) systemd przechwytujące ruch sieciowy (często są to protokoły wykrywania sieci i urządzeń sieciowych – tutaj LLDP [88cc]). Mamy również dwa kolejne podejrzane procesy (ID: 1053 oraz 1067), które wymagają zbadania – tym bardziej, że ich właścicielem jest administrator systemu i mają wartość protokołu 0003, który reprezentuje ETH_P_ALL. Oznacza to, że tego typu gniazdo pakietów skonfigurowane jest do przechwytywania każdego pakietu przechodzącego przez dany interfejs sieciowy (tryb promiscuous). Kiedy program tworzy gniazdo pakietów z protokołem ETH_P_ALL, w zasadzie mówi jądru systemu: „- Daj mi kopię wszystkich surowych ramek danych, które widzisz na tej karcie sieciowej”. Jest to podstawowa funkcja wykorzystywana przez narzędzia do analizy sieci:

root@darkstar:~# ls -al /proc/1053/cwd
lrwxrwxrwx 1 root root 0 Sep 16 19:57 /proc/1053/cwd -> /root

root@darkstar:~# ls -al /proc/1053/exe
lrwxrwxrwx 1 root root 0 Sep 16 19:57 /proc/1053/exe -> /usr/sbin/netsniff-ng

root@darkstar:~# cat /proc/1053/comm
netsniff-ng

root@darkstar:~# cat /proc/1053/cmdline
netsniff-ng--inany--filterport 80--jumbo-support--ascii-V

root@darkstar:~# cat /proc/1053/maps
62484cd10000-62484cd15000 r--p 00000000 08:02 533368  /usr/sbin/netsniff-ng
75fc96400000-75fc966c5000 r--p 00000000 08:02 683102  /usr/share/GeoIP/GeoIP.dat
75fc91c00000-75fc95c00000 rw-s 00000000 00:08 8767    socket:[8767]

root@darkstar:~# ls -al /proc/1067/cwd
lrwxrwxrwx 1 root root 0 Sep 16 20:10 /proc/1067/cwd -> /root

root@darkstar:~# ls -al /proc/1067/exe
lrwxrwxrwx 1 root root 0 Sep 16 20:10 /proc/1067/exe -> /usr/bin/tcpflow

root@darkstar:~# cat /proc/1067/comm
tcpflow

root@darkstar:~# cat /proc/1067/cmdline
tcpflow-iany-cport80

root@darkstar:~# cat /proc/1067/maps
60590f0bd000-60590f0c5000 r--p 00000000 08:02 531829  /usr/bin/tcpflow
7c0bf2b0a000-7c0bf2d0a000 rw-s 00000000 00:08 9350    socket:[9350]

Oczywiście, aby przyśpieszyć ten proces, możemy użyć takich poleceń jak lsof oraz ss. Programy te są przydatne, jeśli są już zainstalowane w systemie, ale istnieją pewne zastrzeżenia. Po pierwsze – jeśli ich nie ma w systemie nie możemy ich zainstalować, ponieważ zmienimy stan badanego systemu i możemy nadpisać dowody kompromitacji systemu. Po drugie niektóre warianty złośliwego oprogramowania często przechwytują wywołania systemowe i filtrują wyniki programów, aby ukryć się przed takimi narzędziami, więc istnieje ryzyko, że nic nie ustalimy. Niemniej warto znać ich zastosowanie:

root@darkstar:~# lsof -p 1053
COMMAND    PID USER   FD   TYPE DEVICE SIZE/OFF   NODE NAME
netsniff- 1053 root  cwd    DIR    8,2     4096 655362 /root
netsniff- 1053 root  txt    REG    8,2   250136 533368 /usr/sbin/netsniff-ng
netsniff- 1053 root  mem    REG    0,8            8767 socket:[8767]
netsniff- 1053 root    3u  pack   8767      0t0    ALL type=SOCK_RAW

root@darkstar:~# lsof -p 1067
tcpflow 1067 root  cwd       DIR    8,2     4096 655362 /root
tcpflow 1067 root  txt       REG    8,2   581064 531829 /usr/bin/tcpflow
tcpflow 1067 root  mem       REG    0,8            9350 socket:[9350]
tcpflow 1067 root    5u     pack   9350      0t0    ALL type=SOCK_DGRAM

root@darkstar:~# ss -0 -p
Netid  Recv-Q  Send-Q  Local Address:Port  Peer Address:Port  Process
p_raw  0       0              LLDP:enp0s3              *      users:(("systemd-network",
                                                                       pid=404,fd=18))
p_raw  0       0              LLDP:enp0s8              *      users:(("systemd-network",
                                                                       pid=404,fd=19))
p_raw  0       0                 *:*                   *      users:(("netsniff-ng",
                                                                       pid=1053,fd=3))
p_dgr  0       0                 *:*                   *      users:(("tcpflow",
                                                                       pid=1067,fd=5))

Teraz już wiemy, jak /proc/net/packet może pomóc nam ujawnić podsłuchujące ruch sieciowy procesy, a nawet może ujawnić rozbieżność z tym, co widzimy w wynikach ze standardowych narzędzi.

Więcej informacji: Detecting Packet Sniffing Malware on Linux, List packet sniffers

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

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

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