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

H

arry Sintonen odkrył zestaw 36-letnich w implementacji protokołu Secure Copy Protocol (SCP) wielu aplikacji klienckich. Luki te mogą zostać wykorzystane przez złośliwe serwery do nieautoryzowanego nadpisania dowolnych plików w katalogu docelowym klienta SCP. Dla przypomnienia: SCP, zwany również “bezpieczną kopią”, jest protokołem sieciowym, który umożliwia użytkownikom bezpieczne przesyłanie plików pomiędzy lokalnym, a zdalnym hostem przy użyciu protokołu RCP (ang. Remote Copy Protocol) oraz protokołu SSH (ang. Secure Shell. Innymi słowy, SCP (pochodzący z 1983 roku) jest bezpieczną wersją RCP, która wykorzystuje uwierzytelnianie i szyfrowanie protokołu SSH do przesyłania plików między serwerem, a klientem.
[ czytaj całość… ]