Podsumowanie bezpieczeństwa w styczniu 2020 r

Szczęśliwego Nowego Roku od SSL.com! Witamy w tym wydaniu podsumowania bezpieczeństwa SSL.com, które przedstawia wybór styczniowych zmian w SSL /TLS, certyfikaty cyfrowe i bezpieczeństwo sieci. W tym wydaniu omówimy:

SHA-1: Kolizja Chosen-Prefix

Nie jest to ostatnia wiadomość, że algorytm szyfrujący SHA-1 jest podatny na ataki. Około trzy lata temu badacze Google wygenerowali kolizja ze stałym prefiksem z algorytmem, wysyłając go do śmierci w zwolnionym tempie do poważnego wykorzystania kryptograficznego. W rezultacie został on prawie porzucony na rzecz mniej podatnego na uszkodzenia SHA-2. W tym miesiącu sytuacja pogorszyła się z wybrany prefiks kolizja, jak donosi Ars Technica:

Nowa kolizja daje atakującym więcej opcji i elastyczności niż w przypadku poprzedniej techniki. Praktyczne jest tworzenie kluczy szyfrowania PGP, które po cyfrowym podpisaniu przy użyciu algorytmu SHA1 podszywają się pod wybrany cel. Mówiąc bardziej ogólnie, tworzy ten sam skrót dla dwóch lub więcej danych wybranych przez atakującego, dołączając dane do każdego z nich. Przeprowadzony we wtorek atak kosztuje również zaledwie 45,000 2017 USD. Z kolei atak ujawniony w 110,000 r. Nie pozwolił na fałszowanie określonych z góry określonych prefiksów dokumentów i został oceniony na koszt od 560,000 XNUMX do XNUMX XNUMX USD na platformie usług internetowych Amazon, w zależności od tego, jak szybko przeciwnicy chcieli to zrobić.

Ten atak jest znaczący. Chociaż wielu porzuciło algorytm SHA-1, nie jest on jeszcze w pełni przestarzały (na przykład pozostaje w użyciu do certyfikacji kluczy PGP w starszej gałęzi 1.4 GnuPG). To sprawia, że ​​naruszenie to jest poważnym biznesem, a eksperci ponoszą prośby o zaprzestanie używania SHA-1 do certyfikatów lub uwierzytelniania.

Na wynos SSL.com: SHA1 był przez długi czas niezabezpieczony, a renomowane urzędy certyfikacji (w tym SSL.com) nie wystawiały certyfikatów SHA-1 od kilku lat. Ta kolizja oznacza nowy, niepokojący niski poziom niepewności SHA-1 i zgadzamy się z badaczami, którzy stwierdzają, że „zdecydowanie zalecają użytkownikom usunięcie obsługi SHA1, aby uniknąć obniżenie ataków".

Dostawca sprzętu nie wierzy w prywatne klucze

As odkryty przez Nick Starke i Tom Pohl i zgłoszone przez Shaun Nichols w Rejestr, Netgear miał ostatnio dość zawstydzające naruszenie bezpieczeństwa. Prawidłowe, podpisane certyfikaty - wraz z kluczami prywatnymi - zostały osadzone w oprogramowaniu układowym routera dostępnym do publicznego pobrania i dostarczane z urządzeniami. Są to informacje, które można wykorzystać do przejęcia połączeń HTTPS użytkowników z ich routerami, i wydaje się, że była to próba ułatwienia swoim klientom, kosztem bezpieczeństwa. Jak donosi Shaun Nichols:

Błąd jest wynikiem podejścia Netgear do bezpieczeństwa i wygody użytkownika. Podczas konfigurowania zestawu właściciele sprzętu Netgear powinni odwiedzić https://routerlogin.net lub https://routerlogin.com. Router sieci próbuje zapewnić, że te nazwy domen są rozwiązywane z adresem IP urządzenia w sieci lokalnej… Aby ustanowić połączenie HTTPS i uniknąć skarg przeglądarek dotyczących korzystania z niezabezpieczonego protokołu HTTP i niezaufanych certyfikatów, router musi wygenerować ważny certyfikat HTTPS do logowania przez router .net lub routerlogin.com, któremu ufają przeglądarki. Aby kryptograficznie udowodnić, że certyfikat jest prawidłowy podczas nawiązywania połączenia, router musi użyć klucza prywatnego certyfikatu. Ten klucz jest niezabezpieczony w oprogramowaniu sprzętowym, umożliwiając każdemu jego wyodrębnienie i nadużycie.

W tym momencie firma ma do dyspozycji kilka rozwiązań, które są oczywiście obecnie debatowane online.

Na wynos SSL.com: Dostawcy sprzętu powinni przechowywać swoje klucze prywatne w innym miejscu niż oprogramowanie układowe do pobrania (i możemy pomoc z tym). W międzyczasie certyfikaty te będą musiały zostać odwołane.

NSA odkrywa krytyczną lukę w zabezpieczeniach kryptograficznych w systemie Windows 10

Agencja Bezpieczeństwa Narodowego odkryła, że ​​nazywają „krytyczną luką” w systemie Windows 10, która wpływa na jego funkcjonalność kryptograficzną. Luka dotyczy w szczególności połączeń HTTPS, podpisanych plików i wiadomości e-mail oraz niektórych podpisanych kodów. W związku z tym agencja radzi, aby użytkownicy zminimalizowali tę lukę, instalując wszystkie łatki we wtorek łatki ze stycznia 2020 r. Jak najszybciej. Możesz przeczytać więcej z NSA na swojej stronie internetowej.

Luka, którą opisano jako „szeroką”, niepokoi badaczy. Jak Dan Goodin w Ars Technica wyjaśnialuka wykorzystuje lukę, która przerywa łańcuch zaufania:

Luka polega na sposobie, w jaki nowe wersje systemu Windows sprawdzają ważność certyfikatów wykorzystujących kryptografię krzywych eliptycznych. Podczas gdy podatne na ataki wersje systemu Windows sprawdzają trzy parametry ECC, nie sprawdzają czwartego, kluczowego, który jest znany jako generator punktów bazowych i jest często reprezentowany w algorytmach jako „G.”. Ta awaria jest wynikiem implementacji ECC przez Microsoft, a nie wadą lub słabością samych algorytmów ECC.

Atakujący mogą wykorzystać tę lukę, wyodrębniając klucz publiczny certyfikatu głównego, który jest domyślnie wysyłany w systemie Windows. Certyfikaty te są określane jako root, ponieważ należą do dużych urzędów certyfikacji, które same wydają własne TLS certyfikatów lub walidacji pośrednich urzędów certyfikacji, które sprzedają certyfikaty w imieniu głównego urzędu certyfikacji. Każdy certyfikat główny będzie działał, o ile jest podpisany algorytmem ECC… Osoba atakująca sprawdza określony algorytm ECC używany do generowania klucza publicznego certyfikatu głównego i przystępuje do tworzenia klucza prywatnego, który kopiuje wszystkie parametry certyfikatu dla tego algorytmu, z wyjątkiem dla generatora punktów. Ponieważ podatne wersje systemu Windows nie sprawdzają tego parametru, akceptują klucz prywatny jako ważny. W ten sposób osoba atakująca sfałszowała certyfikat główny zaufany w systemie Windows, którego można użyć do wybicia dowolnego certyfikatu używanego do uwierzytelniania witryn internetowych, oprogramowania i innych poufnych właściwości.

Krótko mówiąc, ten błąd może zostać wykorzystany przez złych facetów, aby wyglądało na to, że złośliwe pliki wykonywalne pochodzą z zaufanych, zweryfikowanych źródeł i fałszywych certyfikatów cyfrowych. Zmartwiony? Oto link do przetestowania jeśli jesteś podatny na atak.

Na wynos SSL.com: To świetna okazja, aby postępować zgodnie z radami NSA i zainstalować Microsoft łata to rozwiąże problem. Jak zauważają, „Szybkie przyjęcie łatki jest obecnie jedynym znanym środkiem łagodzącym i powinno być głównym celem wszystkich właścicieli sieci”. Zgadzamy się z Catalin Cimpanu z ZD Net że ten jest „tak zły, jak to tylko możliwe”. Oto link do poprawki.
Dziękujemy za wybranie SSL.com! W razie jakichkolwiek pytań prosimy o kontakt mailowy pod adresem Support@SSL.com, połączenie 1-877-SSL-SECURElub po prostu kliknij link czatu w prawym dolnym rogu tej strony.


Subskrybuj biuletyn SSL.com

Nie przegap nowych artykułów i aktualizacji z SSL.com

Będziemy wdzięczni za Twoją opinię

Weź udział w naszej ankiecie i daj nam znać, co myślisz o swoim ostatnim zakupie.