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.
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.
Odpowiedzi:
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.
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 -a
aby 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 -a
wspomina 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.0
w nazwie, mimo że wersja to 1.0.1 ( 1.0.0
odnosi się do kompatybilności binarnej).
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:
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.
Przełącz wszystkie serwery, których dotyczy problem, do trybu offline. Tak długo, jak działają, potencjalnie wyciekają krytyczne dane.
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
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.
Teraz, gdy masz nowe bezkompromisowe klucze, możesz przywrócić serwer do trybu online .
Odwołaj stare certyfikaty.
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.
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
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.
lsof -c firefox | grep 'ssl\|crypto'
, dostanę /usr/lib64/libssl.so.1.0.0, /usr/lib64/libcrypto.so.1.0.0, /lib64/libk5crypto.so.3.1 i /opt/firefox/libssl3.so .
Aby sprawdzić, czy jesteś podatny na zagrożenia, przejdź tutaj: http://filippo.io/Heartbleed/
Jeśli stwierdzisz, że jesteś wrażliwy, zaktualizuj openssl
i uruchom ponownie serwer WWW.