W ostatnich dniach Internet obiegła informacja o odkryciu CVE-2014-0160. Luka ta, od dwóch lat znajdująca się w bibliotece OpenSSL w wersjach 1.0.1a-f, pozwala na odczytanie fragmentu pamięci procesu, który korzysta z tej biblioteki. Ponieważ z biblioteki OpenSSL korzystają zarówno aplikacje serwerowe (np. serwer WWW, poczty) jak i aplikacje klienckie (chociaż najpopularniejsze przeglądarki nie używają tej biblioteki), które są powszechnie używane, luka ta jest bardzo niebezpieczna. CERT Polska podjął próbę sprawdzenia jakie informacje mogą wyciec oraz jaki ta luka ma wpływ na polski Internet oraz sieć TOR. Informacje podane przez Electronic Frontier Foundation pozwalają spekulować, że ten błąd był wykorzystywany w zeszłym roku przez agencje wywiadowcze.

Czym jest CVE-2014-0160 i jak zapobiec jego wykorzystaniu?

Luka ta znajduje się w bibliotece OpenSSL, więc jej załatanie wymaga aktualizacji biblioteki OpenSSL do wersji 1.0.1g (lub nałożenia patcha na istniejącą wersję). Niektóre starsze wersje biblioteki nie są podatne. Sama aktualizacja biblioteki jednak nie wystarcza. Należy również pamiętać o zrestartowaniu usług, które korzystają z tej biblioteki, tak, aby załadowały nową wersję.

W gorszej sytuacji jesteśmy, jeśli nasze oprogramowanie zostało zlinkowane statycznie z biblioteką OpenSSL. W takiej sytuacji pozostaje nam albo ponowna kompilacja, albo czekanie na producenta, żeby wydał aktualizację.

Jak wygląda zagrożenie?

Zagrożenie polega na odczytaniu części pamięci procesu używającego biblioteki OpenSSL. Ta część pamięci może zawierać różne dane. Podczas naszych testów przeskanowaliśmy kilka różnych serwisów. Instalacja klienta WWW oprogramowania Zimbra zwracała kawałki wiadomości e-mail tak jak zaprezentowano poniżej.

Oczywiście, wiadomości takich było więcej, pokazana wyżej jest tylko przykładem. Oprócz zawartości wiadomości e-mail, również zwracana była zawartość plików Cookie (jak np. ZM_AUTH_TOKEN). Polecamy wszystkim sprawdzić ich systemy pocztowe, szczególnie jeśli są dostępne z zewnątrz.

Oprócz tego bramki SSL-VPN są również narażone i udało nam się wykorzystać ten błąd do wyciągnięcia danych do logowania. Szczególną uwagę muszą zwrócić na to firmy, które korzystają z takich rozwiązań. Należy również pamiętać o aktualizacji oprogramowania klienckiego. My przetestowaliśmy Fortigate z oprogramowaniem FortiOS w wersji 5.0 B0252 (GA Patch 5). Znaleziona podatność pozwała uzyskać dane logowania. Fortinet wydał już aktualizację oprogramowania do wersji FortiOS 5.0.7 B3608. Wcyiągnięte dane zaprezentowane są poniżej.

Kolejnym przykładem są serwery będące częścią sieci TOR. Jedno z najprostszych przykładów wycieku informacji to serwery, które zwracają fragmenty swojej konfiguracji takie jak np. klucze publiczne czy kontakt do administratora. Oczywiście są to informacje dostępne publicznie, więc nie jest to de facto wyciek. Są jednak też informacje takie jak np. adresy IP, którym ma być odmawiane połączenie (reject 192.168.0.0/16) czy linijki plików logowania:

Adresy domenowe stron, kawałki kodu HTML czy części niektórych żądań HTTP również są dostępne w ten sposób. To są przykładowe dane, nie można jednak wykluczyć, że, ze względu na losowość zwracanych danych, w niektórych przypadkach serwer może zwrócić np. klucz prywatny.

Co więcej, w przypadku sieci TOR łatwo wytypować potencjalne cele. Ze względu na konieczność restartu serwera oraz fakt, że listy (części) serwerów sieci TOR są publicznie dostępne, wraz z ich uptime, wystarczy wybrać te, które nie było długo restartowane.

Z przeskanowanych przez nas 9 kwietnia 5174 serwerów sieci TOR:

• 1088 było podatnych,
• 2916 nie było podatnych.

Reszta serwerów nie odpowiadała bądź zgłaszała błąd.
Z kolei 10 kwietnia na 4960 serwerów sieci TOR:

• 970 było podatnych,
• 2926 nie było podatnych.

Reszta serwerów nie odpowiadała bądź zgłaszała błąd.

Oprócz tych dwóch przykładów docierają do nas informacje z różnych źródeł mówiące o wycieku:

• danych logowania (nazwa użytkownika oraz hasło),
• konfiguracja serwera WWW, np. pliki .htaccess.

W jakim stopniu polskie serwisy są zagrożone?

Ze skanowania polskiej przestrzeni adresów IP (a przynajmniej jej przybliżonej, publicznej wersji) oraz portu 443 wynika iż:

• 15737 było podatnych co stanowi 1.8% wszystkich adresów IPv4, które miały otwarty port 443,
• 675478 nie było podatnych, co stanowi 76.8% jak wyżej.

Pozostałe adresy albo nie odpowiadały albo zgłaszały błąd połączenia. Jedną z najczęściej występujących domen, były domeny zakończone na edu.pl.

Z 13490 najpopularniejszych (według alexa.com) adresów w domenie .pl 765 (5.7%) jest podatnych, w tym kilkanaście dużych sklepów internetowych.

W systemie ARAKIS również zaobserwowaliśmy wzrost aktywności na portach TCP, które są najczęściej związane z SSL: 443 (HTTPS), 465 (SMTPS), 993 (IMAP), 995 (POP3). Wykresy prezentujące ostatni tydzień znajdują się poniżej.

Zalecenia

Zalecamy oczywiście aktualizację biblioteki OpenSSL oraz restart wszystkich serwisów. W celu zapewnienia większego bezpieczeństwa radzimy też wymianę certyfikatów SSL używanych zarówno do szyfrowania jak i do uwierzytelniania użytkowników. Użytkownicy, aby zapewnić sobie pewność, że ich dane nie wyciekły, powinni zmienić wszystkie hasła, których używali.

Podsumowanie

We wpisie koncentrowaliśmy się tylko na podatnych serwerach. Jednak aplikacje klienckie również mogą być podatne, jeśli korzystają z biblioteki OpenSSL. Atakujący jest w stanie wyciągnąć informacje z aplikacji klienta. Wystarczy, że skłoni aplikację do połączenia się z jego serwerem.

Błąd ten oczywiście jest znaczący, ale wciąż nie wiemy o istnieniu narzędzi, które potrafią w łatwy sposób wyciągnąć nielosowe informacje z pamięci procesu. Przede wszystkim należy zaktualizować bibliotekę i zrestartować wszystkie usługi i programy, które mogą z niej korzystać.

Adresy IP i domeny, które są w Twojej sieci i wciąż są podatne można już uzyskać za darmo zapisując się do n6. Szczegóły dostępne są na stronie n6.cert.pl. Swoją stronę możesz też przetestować tutaj