Jesteśmy równie zaskoczeni, jak wszyscy, informując, że minął kolejny miesiąc. I choć minęło szybko, sierpień obfitował w wiadomości dotyczące bezpieczeństwa. W tym miesiącu przyjrzymy się:
- Internet przedmiotów podatny na zagrożenia przez niezabezpieczone protokoły komunikacyjne
- Bloki Chin TLS 1.3 i ENSI
- Wykryto lukę w zabezpieczeniach wolfSSL
- Wydano trzecią wersję standardu OASIS PKCS # 11
Internet rzeczy pozostawiony otwarty przez niezabezpieczone protokoły komunikacyjne
Ponad 3.7 miliona urządzeń IoT (Internetu rzeczy) pozostało otwartych na atak za pośrednictwem dwóch niezabezpieczonych protokołów komunikacji peer-to-peer: Sieć CS2 P2P i Shenzhen Yunni iLNKP2P.
Artykuł autorstwa Shauna Nicholsa w Rejestr wpada w problemy które pozostawiły takie rzeczy jak kamery internetowe, elektroniczne nianie i inne urządzenia połączone z internetem podatne na przejęcie. Te dwa protokoły są używane przez miliony urządzeń na całym świecie, co oznacza, że dostęp do tych urządzeń może uzyskać każdy, kto chce szpiegować lub gorzej.
Błędy zostały znalezione przez Paula Marrapese, który ma całą witrynę, zhakowany.kamerapoświęcony lukom. „Według stanu na sierpień 2020 r. W Internecie znaleziono ponad 3.7 miliona urządzeń narażonych na ataki” - czytamy w witrynie, która zawiera listę urządzeń, których dotyczy problem, oraz porady, co zrobić, jeśli masz jakiś niebezpieczny sprzęt. (Podsumowanie: wyrzuć go lub spróbuj zablokować firewallem).
Oczywiście, jak zauważa Nichols, luki nie kończą się na urządzeniach, na których działają protokoły komunikacyjne.
… Pamiętaj, że te gadżety znajdują się w ludzkich sieciach Wi-Fi i LAN, więc po przejęciu kamery bezpieczeństwa lub cokolwiek to może być, możesz dotrzeć do sąsiednich maszyn w celu wykorzystania lub użyć pobliskich adresów MAC sieci bezprzewodowej, aby dokładnie określić lokalizacja sprzętu z baz danych Google i tak dalej.
Pełne „i tak dalej”, których jest całkiem sporo, zalecamy przeczytanie całego artykułu, prowadzi nas również do Dyskusja DEFCON od Paula Marrapese, który daje dogłębne spojrzenie każdemu, kto jest zainteresowany lub zaniepokojony zagrożeniami bezpieczeństwa:
Wielkie bloki zapory TLS 1.3 i ENSI
Sierpień też przyniósł aktualności że chiński Wielki Firewall jest teraz blokowany HTTPS ruch, który używa TLS 1.3 i ESNI (zaszyfrowana nazwa serwera). Obie technologie utrudniają chińskim cenzorom dostrzeżenie, z którymi witrynami próbują się łączyć obywatele, oraz cenzurze kontrolowanie dostępu do tych witryn.
Skręt raport z IYouPort, University of Maryland i Great Firewall Report potwierdziły zakaz, zgodnie z artykuł autorstwa Catalina Cimpanu z ZDNet. Zakaz, który wszedł w życie pod koniec lipca, nadal zezwala na ruch HTTPS korzystający ze starszych wersji TLS i niezaszyfrowane SNI, pozwalając rządowym cenzorom zobaczyć, do jakich domen obywatele próbują dotrzeć.
W tej chwili grupy, które wydały raport zidentyfikowali sześć sposobów obejścia zakazu po stronie klienta i cztery sposoby uniknięcia tego po stronie serwera, ale zarówno grupa, jak i artykuł ZDNet przyznają, że te obejścia nie są długoterminowym rozwiązaniem jako „gra w kotka i myszkę” między technologią a Postępuje chińska cenzura.
Odkryto luki w wolfSSL
Gérald Doussot z firmy zajmującej się bezpieczeństwem cybernetycznym Grupa NCC opublikowane doradztwo techniczne 24 sierpnia opisujący TLS 1.3 Luka w wersjach wilkSSL przed 4.5.0. Wersja 4.5.0 biblioteki wolfSSL, zawierająca poprawkę, została wydana 17 sierpnia, przed publikacją poradnika Grupy NCC, a NCC Group zaleca użytkownikom aktualizację do nowszej, bezpiecznej wersji.
Według NCC Group:
wolfSSL nieprawidłowo implementuje rozszerzenie TLS 1.3 maszyna stanu klienta. Dzięki temu osoby atakujące w uprzywilejowanej pozycji w sieci mogą całkowicie podszywać się pod dowolne pliki TLS 1.3 i czytać lub modyfikować potencjalnie wrażliwe informacje między klientami korzystającymi z biblioteki wolfSSL i tymi TLS serwerów.
Jak opisano na Witryna wolfSSL, omawiana wbudowana biblioteka wolfSSL SSL „jest lekką, przenośną, opartą na języku C SSL /TLS Biblioteka przeznaczona dla środowisk IoT, embedded i RTOS, głównie ze względu na jej rozmiar, szybkość i zestaw funkcji ”. Fakt, że luki te można znaleźć w Internecie rzeczy i że liczba „rzeczy”, które wolfSSL występuje w miliardach, sprawia, że jest to warte odnotowania. Zaleca się aktualizację do naprawionej, dostępnej wersji biblioteki.
Wydano trzecią wersję standardu OASIS PKCS # 11
19 sierpnia zapowiedź na blogu PrimeKey poinformował nas, że wersja 3 standardowego interfejsu tokena kryptograficznego PKCS # 11 OASIS została opublikowana w czerwcu 2020 roku.
PKCS # 11 istnieje od 1995 roku i, jak opisuje go sam blog, jest „niezależnym od platformy API umożliwiającym dostęp i korzystanie z funkcji kryptograficznych w sprzętowych modułach bezpieczeństwa (HSM), kartach inteligentnych, tokenach USB, modułach TPM i tym podobnych. ”
Zgodnie z Klucz Prime (dostawcy oprogramowania Centrum Certyfikacji EJBCA), standard PKCS # 11 miał pewne problemy ze standaryzacją związane z mechanizmami definiowanymi przez sprzedawcę w tokenach sprzętowych, które ograniczają jego użyteczność jako standardowego API. Poprzednia wersja standardu również miała pewne problemy z nadążaniem za szybkim tempem rozwoju kryptografii w dzisiejszych czasach, więc wersja trzecia jest pożądaną i potrzebną zmianą. Jak zauważa blog:
Ogólnie rzecz biorąc, działał zaskakująco dobrze przez lata, ale pojawiły się subtelne niuanse wymagające rozważenia przy próbie użycia nowego tokena, który twierdził, że jest zgodny z PKCS # 11, powodując problemy ze współdziałaniem między klientami a serwerami.
Dodanie nowych, ustandaryzowanych mechanizmów kryptograficznych w PKCS # 11 v3.0 (w tym podpisów SHA3 i EdDSA) umożliwi PrimeKey i innym dostawcom oprogramowania wdrożenie ich w ustandaryzowany sposób w sprzętowych modułach bezpieczeństwa i tokenach obsługujących nowy standard.
