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.

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

O

penSSH – Secure Shell Server zapewnia bezpieczny, szyfrowany zdalny dostęp do systemów *niksowych. Po stronie serwera znajduje się plik authorized_keys w katalogu .ssh (głównym folderze użytkownika), w którym można skonfigurować uwierzytelnianie za pomocą klucza publicznego. Przy normalnej konfiguracji użytkownik uzyskuje pełny dostęp do systemu, w którym skonfigurowano uwierzytelnianie. Jednak w niektórych przypadkach, takich jak automatyczne operacje na zdalnych serwerach (np. wdrażanie kodu, tworzenie kopii zapasowych, uruchamianie konkretnych skryptów), sensowne jest ograniczanie dostępu do kilku lub nawet jednego polecenia. Oprócz ograniczenia poleceń dla danego użytkownika zapobiegamy również kompromitacji zdalnego serwera w przypadku przejęcia klucza prywatnego.
[ 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ść… ]

O

d wersji 5.4 (wypuszczonej w marcu 2010 roku), klient OpenSSH obsługuje nieudokumentowaną funkcjonalność o nazwie “roaming“: jeśli połączenie do serwera SSH zostanie nieoczekiwanie przerwane i jeśli serwer wspiera tą funkcjonalność – klient jest w stanie odnowić połączenie i odzyskać zawieszoną sesję SSH. Chociaż roaming nie jest jeszcze wspierany po stronie serwera OpenSSH jest standardowo włączony w kliencie i posiada dwie podatności, które mogą zostać wykorzystane przez szkodliwy (lub zaufany ale skompromitowany) serwer SSH: wyciek informacji (poprzez ujawnienie danych z pamięci) oraz przepełnienie bufora (z wykorzystaniem stosu).
[ czytaj całość… ]

U

żytkownicy OpenSSH podczas nawiązywania lub nawiązanych sesji mają do dyspozycji kilka sekwencji, które mogą ułatwić zarządzanie połączeniem. W celu ich wylistowania (dostępne są różne opcje dla normalnych i multipleksowanych sesji) wystarczy użyć kombinacji: "~" oraz "?" podczas wykony. Powinniśmy otrzymać mniej więcej listing:
[ czytaj całość… ]