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:
- Łagodzić wrażliwe systemy.
- Regeneruj nowe klucze prywatne.
- Prześlij nowy raport CSR do swojego urzędu certyfikacji.
- Uzyskaj i zainstaluj nowy podpisany certyfikat.
- Unieważnij klucze sesji i pliki cookie
- Zresetuj hasła i wspólne sekrety
- 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:
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 .
