To jest kanoniczne pytanie dotyczące zrozumienia i rozwiązania problemu bezpieczeństwa Heartbleed.

Czym dokładnie jest CVE-2014-0160 AKA „Heartbleed”? Jaka jest przyczyna, jakie systemy operacyjne i wersje OpenSSL są podatne na zagrożenia, jakie są objawy, czy istnieją metody wykrywania udanego wykorzystania?

Jak mogę sprawdzić, czy problem dotyczy mojego systemu? W jaki sposób można zmniejszyć tę podatność? Czy powinienem się martwić, że moje klucze lub inne prywatne dane zostały naruszone? Jakie inne działania niepożądane powinny mnie martwić?

Po pierwsze , zanim wystraszysz się, upewnij się, że rozumiesz, czy ta luka faktycznie dotyczy Ciebie. Jeśli masz serwer, ale nigdy nie miałeś żadnych aplikacji korzystających z TLS, to nie jest to priorytetowe rozwiązanie. Z drugiej strony, jeśli kiedykolwiek miałeś aplikacje obsługujące TLS , to czeka cię gratka. Czytaj:

Czym dokładnie jest CVE-2014-0160 aka „Heartbleed”?

To wielki, cholerny bałagan, oto co. Krótko mówiąc, w OpenSSL w wersjach od 1.0.1 do 1.0.1f została odkryta podatna na zdalne wykorzystanie luka, dzięki której osoba atakująca może odczytać niektóre części pamięci systemowej. Części te zawierają między innymi poufne dane, takie jak klucze prywatne, klucze wstępne, hasła i cenne dane korporacyjne.

Błąd został niezależnie wykryty przez Neel Mehta z Google Security (21 marca 2014 r.) I fińską firmę testującą bezpieczeństwo IT Codenomicon (2 kwietnia 2014 r.).

Jaka jest przyczyna?

Błędny kod w OpenSSL. Oto zatwierdzenie, które wprowadziło lukę, a oto zatwierdzenie, które naprawiło lukę. Błąd pojawił się w grudniu 2011 roku i został załatany dzisiaj, 7 kwietnia 2014.

Błąd można również postrzegać jako objaw większego problemu. Dwa powiązane problemy to (1) jaki proces istnieje, aby zapewnić, że błędny kod nie zostanie wprowadzony do bazy kodu, oraz (2) dlaczego protokoły i rozszerzenia są tak złożone i trudne do przetestowania. Punkt (1) to problem zarządzania i procesu w OpenSSL i wielu innych projektach. Wielu programistów po prostu opiera się praktykom, takim jak przeglądanie kodu, analiza i skanowanie. Punkt (2) jest omawiany w TLS WG IETF. Zobacz złożoność Heartbleed / protokołu .

Czy błędny kod został złośliwie wstawiony?

Nie będę spekulować, czy to naprawdę pomyłka, czy może trochę kodu wślizgnął się w imieniu złego aktora. Jednak osoba, która opracowała kod dla OpenSSL, twierdzi, że był on niezamierzony. Zobacz Człowiek, który wprowadził poważną lukę w zabezpieczeniach „Heartbleed”, zaprzecza, że ​​umieścił ją celowo .

Jakie systemy operacyjne i wersje OpenSSL są wrażliwe?

Jak wspomniano powyżej, każdy używany system operacyjny lub aplikacja połączona z OpenSSL od 1.0.1 do 1.0.1f.

Jakie są objawy, czy są jakieś metody wykrywania udanego wykorzystania?

To jest straszna część. O ile nam wiadomo, nie jest znany sposób wykrycia, czy ta luka została wykorzystana. Teoretycznie możliwe jest, że wkrótce zostaną wydane sygnatury IDS, które mogą wykryć ten exploit, ale w chwili pisania tego tekstu nie są one dostępne.

Istnieją dowody na to, że Heartbleed była aktywnie wykorzystywana na wolności już w listopadzie 2013 r. Zobacz: Dzikość serca EFF : czy agencje wywiadowcze korzystały z Heartbleed w listopadzie 2013 r.? Bloomberg donosi, że NSA zbroiła exploita wkrótce po wprowadzeniu podatności. Zobacz NSA Said to Exploit Heartbleed Bug for Intelligence od lat . Jednak amerykańska społeczność wywiadowcza zaprzecza twierdzeniom Bloomberga. Zobacz IC NA REJESTRZE .

Jak mogę sprawdzić, czy problem dotyczy mojego systemu?

Jeśli utrzymujesz OpenSSL w swoim systemie, możesz po prostu wydać openssl version:

$ openssl version
OpenSSL 1.0.1g 7 Apr 2014

Jeżeli podział jest utrzymanie OpenSSL, to prawdopodobnie nie można określić wersję OpenSSL powodu tyłu łatanie używając opensslpolecenia lub informacje pakietu (na przykład apt-get, dpkg, yumlub rpm). Proces łatania wstecznego używany przez większość (wszystkich?) Dystrybucji używa tylko podstawowego numeru wersji (na przykład „1.0.1e”); i nie obejmuje skutecznej wersji zabezpieczeń (na przykład „1.0.1g”).

Super Użytkownik ma otwarte pytanie, aby ustalić skuteczną wersję bezpieczeństwa dla OpenSSL i innych pakietów, gdy pakiety są ponownie ładowane. Niestety, nie ma przydatnych odpowiedzi (poza sprawdzeniem strony internetowej dystrybucji). Zobacz Określanie skutecznej wersji zabezpieczeń w obliczu backpatchingu ?

Ogólna zasada: jeśli kiedykolwiek zainstalowałeś jedną z wersji, której dotyczy luka, i kiedykolwiek uruchomiłeś programy lub usługi, które łączyły się z OpenSSL w celu obsługi TLS, jesteś narażony na atak.

Gdzie mogę znaleźć program do testowania podatności?

W ciągu kilku godzin od ogłoszenia Heartbleed kilka osób w Internecie opublikowało publicznie dostępne aplikacje internetowe, które rzekomo mogłyby zostać wykorzystane do sprawdzenia serwera pod kątem tej luki. W chwili pisania tego artykułu nie recenzowałem żadnych, więc nie będę dalej publikować ich wniosków. Można je znaleźć stosunkowo łatwo za pomocą preferowanej wyszukiwarki.

W jaki sposób eliminuje się tę podatność?

Uaktualnij do wersji niezabezpieczonej i zresetuj lub ponownie zabezpiecz wrażliwe dane. Jak zauważono na stronie Heartbleed , odpowiednie kroki reakcji są zasadniczo następujące:

1. Łagodzić wrażliwe systemy.
2. Regeneruj nowe klucze prywatne.
3. Prześlij nowy raport CSR do swojego urzędu certyfikacji.
4. Uzyskaj i zainstaluj nowy podpisany certyfikat.
5. Unieważnij klucze sesji i pliki cookie
6. Zresetuj hasła i wspólne sekrety
7. Odwołaj stare certyfikaty.

Aby uzyskać bardziej szczegółową analizę i odpowiedź, zobacz Co powinien zrobić operator strony internetowej w związku z exploitem Heartbleed OpenSSL? w sprawie wymiany stosów zabezpieczeń.

Czy powinienem się martwić, że moje klucze lub inne prywatne dane zostały naruszone? Jakie inne działania niepożądane powinny mnie martwić?

Absolutnie. Administratorzy systemów muszą założyć, że ich serwery, które korzystały z wrażliwych wersji OpenSSL, są rzeczywiście zagrożone i odpowiednio zareagować.

Wkrótce po ujawnieniu luki w zabezpieczeniach Cloudfare zaproponowało, czy w praktyce można odzyskać klucz prywatny serwera. Wyzwanie zostało niezależnie wygrane przez Fedora Indutnego i Ilkkę Mattilę. Zobacz Wyzwanie Heartbleed .

Gdzie mogę znaleźć więcej informacji?

Zrzut linku, dla tych, którzy szukają więcej szczegółów:

• OpenSSL SECADV 2014047
• CVE-2014-0160
• Heartbleed
• Ogłoszenie Ubuntu
• Ogłoszenie RHEL
• Oficjalne ogłoszenie OpenSSL

Dość szczegółowy harmonogram wydarzeń związanych z ujawnieniem można znaleźć na osi czasu ujawnienia Heartbleed: kto wiedział, co i kiedy .

Jeśli jesteś programistą i interesujesz się różnymi sztuczkami programistycznymi, takimi jak wykrywanie ataku Heartbleed poprzez msg_cbwywołanie zwrotne OpenSSL , zapoznaj się z Poradnikiem bezpieczeństwa OpenSSL 2014047 .

Proste wyjaśnienie błędu przez XKCD:

Ubuntu 12.04, 12.10 i 13.10

Ubuntu wydało USN-2165-1 , który stwierdza, że ​​zaktualizowane pakiety są teraz dostępne w archiwach. Uruchom następujące dwa polecenia, aby pobrać poprawkę.

sudo apt-get update
sudo apt-get upgrade

Ubuntu 14.04

Przesłałem pakiet Debian zawierający nową wersję (1.0.1g) do PPA, które skonfigurowałem w tym celu. Te trzy polecenia dodają mój PPA do twojego systemu, zaktualizują listę dostępnych pakietów i zaktualizują wszystko:

sudo add-apt-repository ppa:george-edison55/openssl-heartbleed-fix
sudo apt-get update
sudo apt-get upgrade

_{Uwaga: PPA zapewnia również pakiety dla Ubuntu 12.04 i 13.10, na wypadek, gdybyś wolał faktycznie uruchomić nową wersję (1.0.1g) zamiast używać tylko poprawionych wersji w archiwach.}

Ubuntu 10.04

To jest wersja LTS, wersja serwera jest nadal obsługiwana i otrzymuje aktualizacje zabezpieczeń. Luka w zabezpieczeniach nie wpłynęła jednak na pakiet openssl standardowej instalacji ubuntu 10.04, ponieważ wersja jest niższa niż 1.0.1.

Wersja komputerowa dobiegła końca i wymaga aktualizacji / ponownej instalacji.

Ubuntu 13.04 i inne nieaktualne wersje

Ubuntu 13.04 miał bardzo krótki cykl wsparcia, którego nie można się spodziewać. Osiągnął już kres eksploatacji i nie otrzymuje już aktualizacji zabezpieczeń. Od dawna powinien był zostać zaktualizowany. Jeśli nadal ktoś go używa, zaktualizuj go teraz albo od zera, albo możesz go zaktualizować w sposób nieniszczący do 13.10, wykonując tę ​​prostą procedurę: http://www.tecmint.com/upgrade-ubuntu-13-04-raring-ringtail -to-ubuntu-13-10-saucy-salamander / Po aktualizacji system otrzymuje łatkę z serca z 13.10.

W przypadku wszystkich innych nieaktualnych wersji ubuntu oznacza to, że w zasadzie konieczna jest nowa instalacja.

Sprawdź, czy łatka została zastosowana

Zasadniczo uruchom openssl version -ai upewnij się, że data kompilacji to 7 kwietnia 2014 r. Lub później, ale zobacz więcej tutaj .

Restart

Najlepszym sposobem, aby upewnić się, że wszystkie usługi zależne od OpenSSL są zrestartowane, jest ponowne uruchomienie .

RedHat 6.5 i CentOS 6.5

Są wrażliwe. Errata RHSA-2014-0376 RedHata mówi, że dostępne są łatane biblioteki, a każda osoba dotknięta problemem powinna dokonać aktualizacji przy najbliższej okazji.

W momencie pisania tego tekstu CentOS nie miał jeszcze ustalonej wersji, ale post Karanbira Singha w CentOS-announce mówi, że stworzyli zaktualizowaną wersję openssl ( openssl-1.0.1e-16.el6_5.4.0.1zwróć uwagę na ostatnie cztery ważne cyfry), która ma nadający się do wykorzystania TLS polecenie wyłączone, które można bezpiecznie zastosować, ponieważ zostanie nadpisane przez stałą wersję, gdy zostanie ostatecznie wydane.

Wydaje się, że tymczasowo naprawiona wersja nie dotarła jeszcze do wszystkich serwerów lustrzanych, ale znajduje się w głównym repozytorium pod adresem http://mirror.centos.org/centos/6/updates/x86_64/Packages/ (i podobnie dla i686).

Edycja : jak mówi Iain, wydaje się, że jest teraz w pełni załatana wersja dla C6.5 i wydaje się, że w pośpiechu została wypchnięta wokół luster. Prosto yum updatemam to dla moich serwerów; to jest openssl-1.0.1e-16.el6_5.7.

Wersje RH6 i C6 przed 6.5

Nie są wrażliwe. Zgodnie z niniejszym poradniku z Red Hata ,

Ten problem nie wpłynął na wersje openssl dostarczane z Red Hat Enterprise Linux 5 i Red Hat Enterprise Linux 6.4 i wcześniejszymi wersjami.

Wiadomość Karanbira Singha do ogłoszenia CentOS-a jest równie jasna na temat wersjonowania:

Wcześniej tego samego dnia dowiedzieliśmy się o poważnym problemie z openssl w wersji CentOS-6.5

Debian Wheezy

Debian przeanalizował DSA-2896-1, a łatane biblioteki są dostępne tutaj . Skrypt powłoki jest dostępny tutaj .

1. Łatka

Repozytorium Apt-get zostało zaktualizowane, więc teraz załatane biblioteki są dostępne za pośrednictwem apt-get update && apt-get upgrade

apt-get upgrade libssl1.0.0 openssl

Alternatywnie (niezalecane) pakiety można zaktualizować ręcznie:

wget http://security.debian.org/pool/updates/main/o/openssl/libssl1.0.0-dbg_1.0.1e-2+deb7u5_amd64.deb
wget http://security.debian.org/pool/updates/main/o/openssl/openssl_1.0.1e-2+deb7u5_amd64.deb
wget http://security.debian.org/pool/updates/main/o/openssl/libssl1.0.0_1.0.1e-2+deb7u5_amd64.deb
wget http://security.debian.org/pool/updates/main/o/openssl/libssl-dev_1.0.1e-2+deb7u5_amd64.deb

dpkg -i openssl_1.0.1e-2+deb7u5_amd64.deb
dpkg -i libssl1.0.0_1.0.1e-2+deb7u5_amd64.deb
dpkg -i libssl1.0.0-dbg_1.0.1e-2+deb7u5_amd64.deb
dpkg -i libssl-dev_1.0.1e-2+deb7u5_amd64.deb

2. Uruchom ponownie serwer / usługi

Aby uzyskać najlepszą ochronę, zrestartuj cały serwer lub jeśli serwer nie może być offline, zrestartuj potrzebne usługi.

3. Sprawdź wersję OpenSSL

love@server:~$ openssl version
OpenSSL 1.0.1e 11 Feb 2013
love@server:~$ dpkg -l libssl1.0.0
||/ Name                    Version          Architecture     Description
+++-=======================-================-================-====================================================
ii  libssl1.0.0                 1.0.1e-2+deb7u6  amd64            SSL shared libraries

Chciałbym zauważyć, że klucze prywatne nie są jedynymi zasobami, które należy uznać za zagrożone. Błąd ma potencjał wycieku dowolnej pamięci działającej w tej samej przestrzeni adresowej (tj. W tym samym procesie) co OpenSSL. Dlatego jeśli prowadzisz proces serwera, na którym podatna wersja OpenSSL jest połączona statycznie lub dynamicznie, wszelkie informacje, które ten proces kiedykolwiek przetwarzał , w tym hasła, numery kart kredytowych i inne dane osobowe, należy uznać za potencjalnie zagrożone.

FreeBSD 10.0 lub openssl z portów

Zespół bezpieczeństwa FreeBSD wydał poradę dotyczącą CVE-2014-0160 (alias „Heartbleed”) oraz: FreeBSD-SA-14: 06.openssl

1. Aktualizacja FreeBSD

   • Aktualizacja FreeBSD poprzez łatkę binarną

     Systemy działające w wersji RELEASE FreeBSD na platformach i386 lub amd64 można aktualizować za pomocą narzędzia freebsd-update (8):

     # freebsd-update fetch
     # freebsd-update install
     

   • Aktualizacja FreeBSD ze źródeł

     1. Pobierz odpowiednią łatkę z poniższej lokalizacji i sprawdź odłączony podpis PGP za pomocą narzędzia PGP.

        # fetch http://security.FreeBSD.org/patches/SA-14:06/openssl-10.patch
        # fetch http://security.FreeBSD.org/patches/SA-14:06/openssl-10.patch.asc
        # gpg --verify openssl-10.patch.asc
        

     2. Wykonaj następujące polecenia jako root:

        # cd /usr/src
        # patch < /path/to/patch
        

     3. Ponownie skompiluj system operacyjny

        stosując buildworld i installworld , jak opisano w podręczniku FreeBSD .

2. Zaktualizuj port openssl do wersji minimalnej 1.0.1_10

3. Zrestartuj wszystkie demony za pomocą biblioteki lub uruchom ponownie system

4. Zachowuj się tak, jakby Twój system został naruszony, ponownie wystaw wszystkie klucze ssl i / lub certyfikaty oraz potencjalnie wyciek informacji (zobacz bardziej ogólną odpowiedź EEAA ).

FreeBSD 9.x i FreeBSD 8.x

Te systemy nie są domyślnie narażone na problem Heartbleed , ponieważ polegają na starszej wersji biblioteki openssl w wersji 0.9.x , chyba że zainstalowałeś openssl z portów (patrz na górze).

Jeśli te systemy nie są podatne na problem z Heartbleed , rozsądne może być uaktualnienie systemu raczej wcześniej niż później z powodu innej lokalnej luki (patrz FreeBSD-SA-14: 06.openssl i sekcja „FreeBSD 10.0” na górze):

Lokalny atakujący może być w stanie podsłuchać proces podpisywania i odzyskać z niego klucz podpisu. [CVE-2014-0076]

Uwaga :

Oryginalny poradnik Heartbleed wymienia FreeBSD 8.4 i 9.1 jako potencjalnie podatne na atak. Nie jest to prawdą z powodu braku rozszerzenia pulsu (domyślna biblioteka OpenBS dla FreeBSD w wersji 0.9.x).

Stwierdziłem, że określenie wersji SSL używanej na kilku urządzeniach, z którymi pracuję, jest prawie niemożliwe. Chociaż technicznie nie jest to łatwe, identyfikacja aktualnie zagrożonych hostów była na szczycie mojej listy.

Złożyłem małą maszynę wirtualną, która będzie przeprowadzać kontrole względem dowolnych hostów i portów za pomocą modułu testowego FiloSottile . Na pierwszy rzut oka kod wygląda na dobry.

Wersja ukończonej maszyny wirtualnej jest tutaj . Jest w formacie VMX.

Słowa ostrzeżenia

Ten skrypt i maszyna wirtualna pokażą tylko bieżący stan twoich systemów. Jest całkiem możliwe, że w pewnym momencie w przeszłości twoje systemy były podatne na ataki i mogły zostać wykorzystane.

Coś, co się tu pojawia, jest zdecydowanie priorytetem do naprawienia, ale nie przeszkadza w stosowaniu aktualizacji i zmianie wszystkich kluczy.

Amazon Linux (dystrybucja Linuksa używana w Amazon EC2)

https://aws.amazon.com/amazon-linux-ami/security-bulletins/ALAS-2014-320/

Omówienie problemu: Znaleziono sposób sprawdzenia brakujących granic w sposobie, w jaki OpenSSL obsługiwał pakiety rozszerzeń pulsu TLS. Tę lukę można wykorzystać do ujawnienia do 64 KB pamięci od podłączonego klienta lub serwera.

Wersje, których dotyczy problem: Dowolna wersja Amazon Linux AMI, na której jest zainstalowany openssl 1.0.1, czyli dowolna wersja Amazon Linux AMI 2013.03 lub nowsza oraz dowolna wersja Amazon Linux AMI, która została zaktualizowana do wersji 2013.03 lub nowszej. OpenSSL jest instalowany domyślnie na Amazon Linux AMI.

Dotknięte pakiety: openssl

Korekta problemu: Uruchom aktualizację yum openssl, aby zaktualizować system. Po zainstalowaniu nowego pakietu wymagane jest ręczne ponowne uruchomienie wszystkich usług korzystających z openssl lub ponowne uruchomienie instancji. Chociaż nowy pakiet nadal ma nazwę openssl-1.0.1e, zawiera poprawkę dla CVE-2014-0160.

Nowe pakiety: i686:

openssl-1.0.1e-37.66.amzn1.i686

openssl-static-1.0.1e-37.66.amzn1.i686

openssl-perl-1.0.1e-37.66.amzn1.i686

openssl-devel-1.0.1e-37.66.amzn1.i686

openssl-debuginfo-1.0.1e-37.66.amzn1.i686

x86_64:

openssl-devel-1.0.1e-37.66.amzn1.x86_64

openssl-1.0.1e-37.66.amzn1.x86_64

openssl-debuginfo-1.0.1e-37.66.amzn1.x86_64

openssl-perl-1.0.1e-37.66.amzn1.x86_64

openssl-static-1.0.1e-37.66.amzn1.x86_64