Kilka dni temu sieć została zaatakowana przez inwazje słabych kluczy. W skrócie chodzi o to że klucze prywatne generowane przez wersje openssl od 2006-09-17 do 2008-05-13 najprawdopodobniej są słabe.

Słabe klucze ?… mianowicie zamiast faktycznych niezliczonych kombinacji, jedynym zrodlem losowosci byl PID procesu generujacego klucz, czyli faktycznych kombinacji bylo 32768 (15 bit). Moze ta liczba wydawac sie duza, ale w dzisiejszych czasach 512 bitowy klucz jest troche slaby: 2⁵¹² = 1.34078079 × 10¹⁵⁴.
Nie uzywam zwrotu „słaby klucz” w stricte definicji, poniewaz sam problem nie dotyczy algorytmu, jedynie losowosci ziarna (random seed) generatora liczb pseudolosowych.

Ten problem mogł spotkać wszelkie rodzaje kluczy generowane przez openssl, ssh-keygen albo openvpn –keygen. Tak wiec w kazdym wypadku warto poczytac i sprawdzic czy wszystko gra.

• http://www.debian.org/security/2008/dsa-1571
• http://www.debian.org/security/key-rollover/
• http://wiki.debian.org/SSLkeys
• http://metasploit.com/users/hdm/tools/debian-openssl/
  (pomocna strona, zawiera blacklisty fingerprintow w roznych formatach i cale pakiety wygenerowanych kluczy, jak i rozne programy do testowania)

Zagrożenie

Co to znaczy dla zwyklego zjadacza chleba… zasadniczo nic
Ale jesli uzywasz bezhaslowego logowania sie na shella, dostep do konta mozna uzyskac w ok 20 minut. Drugim zagrozeniem jest to, ze ktos moze sie podszyc pod twoj komputer, przedstawiajac sie falszywym (ale takim samym jak twoj) kluczem. Jest to raczej glownie problem dotyczacy bezpiecznych certyfikatow do szyfrowania lub bezpiecznej identyfikacji serwera.

Tak wiec, w kazdym wypadku nalezy dziure zalatac.

Ratunek

Naturalnie pierwszym krokiem jak zawsze w takich sytuacjach jest zupgradowanie systemu:
apt-get update
apt-get upgrade
(dokładnie chodzi o apt-get install openssl openssh-server).

Krytycznym pakietem wymagajacym zupgradowania jest naturalnie openssl, a drugim w kolejce jest openssh-server. Zupgradowanie openssl poprawia blad blednie wygenerowanych kluczy, oraz automatycznie generuje nowy, silny klucz. Nowa wersja openssh-server natomiast, po pierwsze uniemozliwia bezhaslowe logowanie sie slabymi kluczami (zawartymi w specjalnych blacklistach), po drugie zaopatruje nas w narzedzie ssh-vulnkey, służące do sprawdzania istniejących kluczy.

Aby sprawdzic klucze pojedynczego uzytkownika, mozna po prostu uruchomic ssh-vulnkey. Mozna rowniez sprawdzic wszystkie klucze na serwerze (mieszczace sie w standardowych miejscach), wywolujac z konta roota polecenie ssh-vulnkey -a.

UWAGA: Wg autora, skrypt sie czasami moze mylic. Tzn czasami czasami ma false-positives, a czasami false-negatives.

Not blacklisted: 1024 xx:xx:[...]:xx:xx /etc/ssh/ssh_host_dsa_key
Unknown (no blacklist information): 4096 xx:xx:[...]:xx:xx /home/costam1/.ssh/id_rsa.pub
COMPROMISED: 2048 xx:xx:[...]:xx:xx /home/costam2/.ssh/authorized_keys

Ostatni klucz nalezy natychmiast wymienic/usunac, w szczegolnosci jesli jest to authorized_keys, sluzacy do logowania bezhaslowego. Pierwszy klucz jest najprawdopodobniej dobry i raczej nie trzeba go wymieniac, chyba ze jest sie pewnym ze zostal utworzony na trefnym systemie (posiadajacym wspomniany blad openssl).
Jednak co zrobic ze srodkowym, swiezo utworzonym kluczem ? Czy on jest zly czy dobry ?
Klopot w tym ze oficjalna blacklista zawiera jedynie rodzaje kluczy DSA 1024 i RSA 2048, jako że są najpopularniejsze. Jednak co jeśli mam klucz RSA 4096 ? Lub stary RSA 1024 ?
(Aby uniknać pytań wspomne, że DSA wystepuje tylko jako 1024 bitowy.)

Rozwiązanie jest niby proste… trzeba wygenerowac liste trefnych kluczy, na blednym systemie i wgrac ja do ssh-vulnkey. Nie moglem takiej listy znalezc w internecie, dlatego zdecydowalem sie na wyciagniecie fingerpintów z innych wygenerowanych list (http://metasploit.com/users/hdm/tools/debian-openssl/).

Tak więc oto blacklisty do użycia z programem ssh-vulnkey (openssh-client 1:4.7p1-9):

1. Oficjalne
   • blacklist.DSA-1024.bz2
   • blacklist.RSA-2048.bz2
2. Utworzone na architekturze x86 (utworzone z plikow metasploit)
   • blacklist.RSA-1024.bz2
     
   • blacklist.RSA-4096.bz2
3. Utworzone na architekturach x86 i amd64 (utworzone z plikow Max Bowsher) ZALECANE
   • blacklist.RSA-1023.bz2
   • blacklist.RSA-1024.bz2
   • blacklist.RSA-4096.bz2
   • RSA-8192… podobno 4096 to juz paranoja

Należy je umieścic w /etc/ssh/ obok pozostałych oficjalnych plikow. Ważne jest żeby nie zmieniać nazwy.
Po tym, program ssh-vulnkey od razu powinien odpowiednio rozpoznawac pozostale klucze.

Not blacklisted: 4096 xx:xx:[...]:xx:xx /home/costam3/.ssh/authorized_keys

Ja juz jestem zabezpieczony, przy okazji pozamienialem klucze userow i serwerow na 4kbit…

Powodzenia !

AKTUALIZACJA: Wyszla nowa wersja openssh-blacklist, o numerze 0.1.2. Mozna zaczekac az pojawi sie w pakietach, albo od razu sciagnac stad. Wyglada na to ze format list sie zmienil, zaczekam na rozwoj sytuacji i aktualizuje swoje pakiety.