Jak mogę zresetować błąd Heartbleed w OpenSSL?

CVE-2014-0160 alias Heartbleed jest podatnością w OpenSSL. Wygląda przerażająco.

Jak ustalić, czy mam na to wpływ?

Jeśli mnie to dotknie, co muszę zrobić? Najwyraźniej aktualizacja nie wystarczy.

Ta luka ma duży potencjalny wpływ, ponieważ jeśli twój system został zaatakowany, pozostanie podatny nawet po łataniu, a ataki mogą nie pozostawić żadnych śladów w logach. Szanse, że jeśli szybko załatałeś łatę i nie jesteś głośnym celem, nikt nie zdoła cię zaatakować, ale trudno być pewnym.

Czy jestem wrażliwy?

Błędna wersja OpenSSL

Błędne oprogramowanie to biblioteka OpenSSL od 1.0.1 do 1.0.1f oraz OpenSSL 1.0.2 do beta1. Nie ma to wpływu na starsze wersje (0.9.x, 1.0.0) i wersje, w których błąd został naprawiony (1.0.1g i nowsze, 1.0.2 beta 2 i nowsze). Jest to błąd implementacyjny, a nie usterka protokołu, więc dotyczy to tylko programów korzystających z biblioteki OpenSSL.

Możesz użyć narzędzia wiersza poleceń, openssl version -aaby wyświetlić numer wersji OpenSSL. Zauważ, że niektóre dystrybucje przenoszą poprawkę do wcześniejszych wydań; jeśli dziennik zmian twojego pakietu wspomina o naprawie błędu Heartbleed, to w porządku, nawet jeśli widzisz wersję taką jak 1.0.1f. Jeśli openssl version -awspomina się datę kompilacji (nie datę w pierwszym wierszu) z dnia 2014-04-07 około wieczora UTC lub później, wszystko powinno być w porządku. Zauważ, że pakiet OpenSSL może mieć 1.0.0w nazwie, mimo że wersja to 1.0.1 ( 1.0.0odnosi się do kompatybilności binarnej).

Dotknięte aplikacje

Eksploracja odbywa się za pośrednictwem aplikacji korzystającej z biblioteki OpenSSL do implementacji połączeń SSL . Wiele aplikacji używa OpenSSL do innych usług kryptograficznych, i to dobrze: błąd polega na implementacji określonej funkcji protokołu SSL, „bicia serca”.

Możesz sprawdzić, które programy są połączone z biblioteką w twoim systemie. W systemach korzystających z dpkg i apt (Debian, Ubuntu, Mint,…) następujące polecenie wyświetla listę zainstalowanych pakietów innych niż biblioteki, które z nich korzystają libssl1.0.0(pakiet, którego dotyczy problem):

apt-cache rdepends libssl1.0.0 | tail -n +3 |
xargs dpkg -l 2>/dev/null | grep '^ii' | grep -v '^ii  lib'

Jeśli uruchomisz oprogramowanie serwera znajdujące się na tej liście i nasłuchuje połączeń SSL, prawdopodobnie masz na to wpływ. Dotyczy to serwerów WWW, serwerów e-mail, serwerów VPN itp. Będziesz wiedział, że włączyłeś protokół SSL, ponieważ musiałeś wygenerować certyfikat, przesyłając żądanie podpisania certyfikatu do urzędu certyfikacji lub składając własny podpis certyfikat. (Możliwe, że niektóre procedury instalacji wygenerowały samopodpisany certyfikat bez powiadomienia, ale generalnie dzieje się tak tylko w przypadku serwerów wewnętrznych, a nie serwerów narażonych na działanie Internetu). Jeśli korzystałeś z serwera narażonego na atak z Internetu, możesz uznać go za zagrożony chyba że twoje logi nie pokazują żadnego połączenia od ogłoszenia w dniu 2014-04-07. (Zakłada się, że luka nie została wykorzystana przed ogłoszeniem.) Jeśli serwer został ujawniony tylko wewnętrznie,

Wpływ na oprogramowanie klienckie ma tylko sytuacja, gdy użyłeś go do połączenia ze złośliwym serwerem. Więc jeśli łączysz się ze swoim dostawcą poczty e-mail za pomocą IMAPS, nie musisz się martwić (chyba że dostawca został zaatakowany - ale w takim przypadku powinni cię powiadomić), ale jeśli przeglądałeś przypadkowe witryny za pomocą podatnej przeglądarki, możesz potrzebować martwić się. Do tej pory wydaje się, że luka nie była wykorzystywana przed jej wykryciem, więc musisz się martwić, jeśli łączysz się ze złośliwymi serwerami od 08.04.2014.

Poniższe programy pozostają nienaruszone, ponieważ nie używają OpenSSL do implementacji SSL:

• SSH (protokół nie jest SSL)
• Chrome / Chromium ( używa NSS )
• Firefox (używa NSS) (przynajmniej z Firefox 27 na Ubuntu 12.04, ale nie ze wszystkimi kompilacjami?

Jaki jest wpływ?

Błąd pozwala każdemu klientowi, który może połączyć się z twoim serwerem SSL, jednocześnie pobierać z serwera około 64kB pamięci. Klient nie musi być w żaden sposób uwierzytelniany. Powtarzając atak, klient może zrzucić różne części pamięci podczas kolejnych prób. To potencjalnie pozwala atakującemu na odzyskanie wszelkich danych, które zostały zapisane w pamięci procesu serwera, w tym kluczy, haseł, plików cookie itp.

Jednym z kluczowych elementów danych, które osoba atakująca może uzyskać, jest prywatny klucz SSL serwera. Dzięki tym danym atakujący może podszyć się pod Twój serwer.

Błąd pozwala także każdemu serwerowi, do którego podłączony jest klient SSL, pobierać od klienta około 64kB pamięci. To zmartwienie, jeśli użyłeś podatnego klienta do manipulowania wrażliwymi danymi, a następnie podłączyłeś się do niezaufanego serwera z tym samym klientem. Scenariusze ataku po tej stronie są zatem znacznie mniej prawdopodobne niż po stronie serwera.

Należy pamiętać, że w przypadku typowych dystrybucji nie ma wpływu na bezpieczeństwo dystrybucji pakietów, ponieważ integralność pakietów zależy od podpisów GPG, a nie transportu SSL.

Jak naprawić usterkę?

Usuwanie narażonych serwerów

1. Przełącz wszystkie serwery, których dotyczy problem, do trybu offline. Tak długo, jak działają, potencjalnie wyciekają krytyczne dane.

2. Zaktualizuj pakiet biblioteki OpenSSL . Wszystkie dystrybucje powinny być już naprawione (z wersją 1.0.1g lub z łatką, która naprawia błąd bez zmiany numeru wersji). Jeśli skompilowałeś ze źródła, uaktualnij do wersji 1.0.1g lub wyższej. Upewnij się, że wszystkie serwery, których dotyczy problem, zostaną zrestartowane.
   W systemie Linux można sprawdzić, czy nadal działają procesy potencjalnie dotknięte problememgrep 'libssl.*(deleted)' /proc/*/maps

3. Wygeneruj nowe klucze . Jest to konieczne, ponieważ błąd mógł umożliwić osobie atakującej uzyskanie starego klucza prywatnego. Postępuj zgodnie z tą samą procedurą, którą użyłeś początkowo.

   • Jeśli korzystasz z certyfikatów podpisanych przez urząd certyfikacji, prześlij nowe klucze publiczne do urzędu certyfikacji. Po otrzymaniu nowego certyfikatu zainstaluj go na serwerze.
   • Jeśli korzystasz z certyfikatów z podpisem własnym, zainstaluj je na swoim serwerze.
   • Tak czy inaczej, przenieś stare klucze i certyfikaty na bok (ale nie usuwaj ich, po prostu upewnij się, że nie są już używane).

4. Teraz, gdy masz nowe bezkompromisowe klucze, możesz przywrócić serwer do trybu online .

5. Odwołaj stare certyfikaty.

6. Ocena szkód : wszelkie dane, które były w pamięci procesu obsługującego połączenia SSL, mogły zostać wyciekły. Może to obejmować hasła użytkownika i inne poufne dane. Musisz ocenić, jakie mogły być te dane.

   • Jeśli korzystasz z usługi, która umożliwia uwierzytelnianie haseł, hasła użytkowników, którzy nawiązali połączenie od czasu przed ogłoszeniem luki w zabezpieczeniach, należy uznać za zagrożone. Sprawdź swoje dzienniki i zmień hasła każdego użytkownika, którego dotyczy problem.
   • Unieważnij także wszystkie sesyjne pliki cookie, ponieważ mogły zostać naruszone.
   • Certyfikaty klienta nie są zagrożone.
   • Wszelkie dane, które zostały wymienione od czasu, zanim luka w zabezpieczeniach mogła pozostać w pamięci serwera, a więc mogły zostać wyciekły do ​​atakującego.
   • Jeśli ktoś zarejestrował stare połączenie SSL i odzyskał klucze serwera, może teraz odszyfrować transkrypcję. (Chyba że zapewniono PFS - jeśli nie wiesz, nie było.)

Środki zaradcze w innych przypadkach

Serwery, które nasłuchują tylko na hoście lokalnym lub w intranecie, należy uznać za narażone tylko wtedy, gdy niezaufani użytkownicy mogą się z nimi połączyć.

W przypadku klientów istnieją tylko rzadkie scenariusze, w których można wykorzystać błąd: exploit wymagałby użycia tego samego procesu klienta do

1. manipulować poufnymi danymi (np. hasłami, certyfikatami klientów,…);
2. a następnie w tym samym procesie połączony ze złośliwym serwerem za pośrednictwem protokołu SSL.

Na przykład klient poczty e-mail, którego używasz tylko do łączenia się z (nie całkowicie niezaufanym) dostawcą poczty, nie stanowi problemu (nie jest złośliwym serwerem). Uruchomienie programu wget w celu pobrania pliku nie stanowi problemu (brak wycieku poufnych danych).

Jeśli zrobiłeś to między 2014-04-07 wieczorem UTC a aktualizacją biblioteki OpenSSL, weź pod uwagę wszelkie dane znajdujące się w pamięci klienta.

Bibliografia

• Błąd Heartbleed (przez jedną z dwóch drużyn, które niezależnie wykryły błąd)
• Jak dokładnie działa wykorzystanie pulsu OpenSSL TLS (Heartbleed)?
• Czy Heartbleed oznacza nowe certyfikaty dla każdego serwera SSL?
• Heartbleed: co to jest i jakie są opcje jego łagodzenia?

Aby sprawdzić, czy jesteś podatny na zagrożenia, przejdź tutaj: http://filippo.io/Heartbleed/

Jeśli stwierdzisz, że jesteś wrażliwy, zaktualizuj openssli uruchom ponownie serwer WWW.

Nie ma sposobu na odzyskanie tego błędu. Po zapisaniu wszystkich dzienników będą one potrzebne na wypadek, gdyby ktoś rzeczywiście zdał sobie sprawę, że luka istniała przed ogłoszeniem