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?

P

odczas pierwszego łączenia się z wybranym serwerem klient SSH poprosi użytkownika o weryfikację autentyczności tego serwera. Jest to zasada zwana TOFU – Trust On First Use – przy pierwszym połączeniu zakładamy lub weryfikujemy, że jest ono prawidłowe, a jeśli później coś się zmieni w łączności, będzie to podejrzane i wygeneruje ostrzeżenia. Z obserwacji zachowań użytkowników systemów *nix wynika, że wielu z nich po prostu na ślepo odpowiada: "Yes / Tak", nie biorąc pod uwagę potencjalnych zagrożeń bezpieczeństwa. Osoba, która jest w stanie przejąć sieciowo komunikację może przeprowadzić atak man-in-the-middle (MITM) prowadzący do wycieku danych uwierzytelniających lub przejęcia sesji użytkownika. Zgodnie z RFC 4251 istnieje kilka sposobów na weryfikację „odcisku palca” (ang. fingerprint) klucza serwera.
[ czytaj całość… ]

W

raz z wersją git 2.34.0 każdy nasz commit do kodu lub jego tag będzie mógł zostać podpisany kluczem SSH. Możliwość podpisywania dowolnych danych za pomocą SSH została dodana już w 2019 roku z wydaniem OpenSSH 8.0. Jednak, aby używać tej funkcjonalności bez żadnego problemu najlepiej używać OpenSSH w wersji 8.8. Nasz proces zaczynamy od instalacji i konfiguracji klienta git i SSH:

sudo apt install -y git

Kolejnym krokiem jest wygenerowanie klucza SSH, który będzie używany do podpisywania:

ssh-keygen -t ed25519 -C "agresor@nfsek.pl" -f ~/.ssh/code_commit_signing

Odpowiadamy na pytania i upewniamy się, że wpisaliśmy silne i unikalne hasło do klucza. Klucz ten będzie domyślnie przechowywany w naszym katalogu domowym pod katalogiem .ssh:

agresor@darkstar:~$ cat .ssh/code_commit_signing.pub
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIMzu8wjcnyAorVVtEjddoG2gaYjmRnHiZHvElYFcl/s/ 
agresor@nfsek.pl

[ czytaj całość… ]

P

anchan to nowy malware odkryty przez zespół Akamai, który od marca 2022 uruchomił swoją aktywność. Został napisany w języku Go, aby wykorzystać wbudowane funkcje współbieżności (goroutines) do przyśpieszenia szybkości rozprzestrzeniania się i uruchamiania złośliwych modułów. Dostaje się on do systemów Linux poprzez atak typu brute force na usługę SSH. Lista użytkowników (np. „ubuntu”, „root”, „user”, „debian”, „pi”) i haseł jest wcześniej ustalona. Oprócz „podstawowego” ataku słownikowego na SSH (który jest powszechny w większości znanych robaków) – ta odmiana przechwytuje również klucze SSH w celu rozprzestrzeniania się po innych systemach w sieciach wewnętrznych i zewnętrznych (ang. lateral movement). Szuka on konfiguracji i kluczy SSH w katalogu domowym użytkownika ($HOME). Odczytuje klucz prywatny ze ścieżki $HOME/.ssh/id_rsa i używa go do próby uwierzytelniania na dowolnym adresie IP znalezionym w pliku $HOME/.ssh/known_hosts. Jest to dość nowatorska metoda zbierania danych uwierzytelniających, która nie występowała wcześniej w złośliwych programach łamiących hasła SSH.
[ czytaj całość… ]

P

rzewiduje się, że do końca 2025 roku ponad 30 miliardów urządzeń IoT będzie podłączonych do internetu. To doskonale definiuje cele na kolejne lata dla szkodliwego oprogramowania. Aktualnie w internecie występuje wzmożona aktywność programu XorDDoS. Jest to koń trojański z funkcjami rootkita wykorzystywany do przeprowadzania ataków DDoS na dużą skalę. Jego nazwa pochodzi od szyfrowania XOR, które często jest wykorzystywane w złośliwym oprogramowaniu, jak i w komunikacji sieciowej do C&C. Inspirowany projektem rooty został stworzony dla wielu architektur systemu Linux: ARM, x86 i x64. Wykryty w 2014 roku przez grupę badawczą zajmującą się bezpieczeństwem MalwareMustDie i do dzisiaj pozostaje aktywny. De facto w 2021 roku aktywność tego malware wzrosła o 123% w porównaniu do 2020 roku. Z kolei według telemetrii firmy Microsoft XorDDoS od początku roku zwiększył swoją aktywność o 254%. Prześledźmy jego działanie.
[ czytaj całość… ]

Znalazłeś w repozytorium X prywatny klucz SSH i chciałbyś się dowiedzieć do kogo należy? Nic prostszego:

ssh -i znajda.key git@github.com

Warning: Permanently added 'github.com' (RSA) to the list of known hosts.
PTY allocation request failed on channel 0
Hi nfsec! You've successfully authenticated, but GitHub does not provide shell access.
Connection to github.com closed.

Działa również z gitlab.com, bitbucket.org i zapewne innymi.

Więcej informacji: GNU/JUSTIN

ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -T agresor@192.168.1.1 \
"bash -i"

Jeśli w ten sposób połączymy się z wybranym serwerem przez SSH, to nasz użytkownik nie zostanie dodany do pliku /var/log/utmp i nie pojawi się w poleceniu who (zalogowanych użytkowników). Pominie również takie pliki, jak .profile oraz .bash_profile, a po stronie klienta nie zarejestruje nazwy hosta zapisując go do pliku ~/.ssh/known_hosts:

agresor@darkstar:~$ w
w
 22:44:35 up 11 min,  1 user,  load average: 0.05, 0.03, 0.00
USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU WHAT
root     tty1     -                22:37    5:15   0.04s  0.03s -bash
agresor@darkstar:~$ who
who
root    tty1         2021-02-25 22:37

Prawie niewidzialne SSH, ponieważ połączenie sieciowe nadal widnieje w systemie:

agresor@darkstar:~$ ss -t
ss -t
State   Recv-Q   Send-Q     Local Address:Port     Peer Address:Port   Process
ESTAB   0        0           192.168.56.2:ssh      192.168.56.1:49998

Plus możemy zacząć szukać sesji, które nie mają zaalokowanego terminala:

agresor@darkstar:~$ loginctl | grep -v pts
SESSION  UID USER    SEAT TTY
      3 1000 agresor

3 sessions listed.

agresor@darkstar:~$ loginctl session-status 3
3 - agresor (1000)
           Since: Mon 2022-11-21 22:01:48 UTC; 37min ago
          Leader: 1880 (sshd)
          Remote: 127.0.0.1
         Service: sshd; type tty; class user
           State: active
            Unit: session-3.scope
                  ├─1880 "sshd: agresor [priv]"
                  ├─1927 "sshd: agresor@notty" ""
                  └─1928 bash -i

Nov 21 22:01:48 darkstar systemd[1]: Started Session 3 of User agresor.

agresor@darkstar:~$ pstree `ps -eo pid,cmd | grep sshd\:.*@notty \
                    | grep -v grep | awk '{ print $1 }'` -ap
sshd,1927
  └─bash,1928 -i

Więcej informacji: man ssh

D

ocker jako jedno z rozwiązań dla tworzenia kontenerów zyskał ogromną popularność w ciągu kilku ostatnich lat i stał się nowym sposobem pakowania, dostarczania i wdrażania aplikacji. Niestety, jeśli dana technologia się szybko rozwija i jest szeroko adoptowana przez społeczność, staje się również cennym celem dla adwersarzy. Na początku pojawiły się złośliwe obrazy. Były one umieszczane w publicznych rejestrach. Jeśli użytkownik sam lub za namową cyberprzestępcy skłonił się do skorzystania z takiego obrazu w rzeczywistości pobierał i wykonywał złośliwe ładunki (np. koparki kryptowalut), umożliwiał wejście przez tylną furtkę (ang. backdoor), przeszukiwanie logów dla poufnych informacji, czy dostęp do systemu plików hosta z kontenera.
[ czytaj całość… ]

J

eśli używasz SSH to Twój klient przechowuje w katalogu domowym listę mapującą nazwy hostów i adresy IP każdego zdalnego hosta, z którym się połączyłeś. Ta „baza danych”, znana jako plik known_hosts może zostać wykorzystana przez atakujących, którzy naruszyli konta użytkowników. Rezultatem odczytania tego pliku jest „obraz” sieci, ujawniający, do których systemów mamy jeszcze połączenie. Może ułatwić to szkodliwemu oprogramowaniu i innym szkodliwym skryptom w rozprzestrzenianiu się na inne systemy, gdy tylko jeden system w sieci został skompromitowany. Plik ten jest dostępny w katalogu ~/.ssh każdego użytkownika, który chociaż raz łączył się jako klient SSH z zdalnym systemem. Jest on na tyle użyteczny, że w przypadku zmiany podpisu serwera – klient SSH będzie chronić użytkownika, powiadamiając go o tej sytuacji komunikatem typu:
[ czytaj całość… ]

B

rezent (ang. tarpit), czyli płachta na usługę. Jest usługą sieciową, która celowo wprowadza opóźnienia w obsługiwanym protokole spowalniając w ten sposób klientów i zmuszając ich do oczekiwania przez określony czas. Zachowanie to spowalnia lub zatrzymuje sondowanie i atakowanie systemów / usług. Skanery, skrypty i inne narzędzia atakującego są związywane z konkretną usługą / portem i nie mają możliwości ruszyć dalej (zazwyczaj działają synchronicznie wykonując pracę host po hoście / port po porcie). Nakłada to na atakującego większy koszt pod względem czasu i zasobów niż ponosi go obrońca.
[ czytaj całość… ]