{"id":32603,"date":"2019-10-31T21:47:55","date_gmt":"2019-10-31T18:47:55","guid":{"rendered":"https:\/\/prohoster.info\/blog\/potentsialnye-ataki-na-https-i-kak-ot-nih-zashhititsya\/"},"modified":"2019-10-31T21:47:55","modified_gmt":"2019-10-31T18:47:55","slug":"potentsialnye-ataki-na-https-i-kak-ot-nih-zashhititsya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/potentsialnye-ataki-na-https-i-kak-ot-nih-zashhititsya","title":{"rendered":"Potencjalne ataki na HTTPS i jak si\u0119 przed nimi chroni\u0107","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Po\u0142owa stron internetowych u\u017cywa HTTPS<\/a><\/noindex>, a ich liczba nieustannie ro\u015bnie. Protok\u00f3\u0142 zmniejsza ryzyko przechwycenia ruchu, ale nie eliminuje pr\u00f3b atak\u00f3w. O niekt\u00f3rych z nich \u2014 POODLE, BEAST, DROWN i innych \u2014 oraz o sposobach ochrony, opowiemy w naszym materiale.<\/p>\n

\"Potencjalne <\/a><\/noindex><\/a><\/noindex>
\n\/ Flickr \/ Sven Graeme<\/a><\/noindex> \/ CC BY-SA<\/i><\/p>\n

POODLE<\/h2>\n

\nO ataku po raz pierwszy POODLE<\/a><\/noindex> dowiedziano si\u0119 w 2014 roku. Luk\u0119 w protokole SSL 3.0 odkry\u0142 specjalista ds. bezpiecze\u0144stwa Bodo M\u00f6ller wraz z kolegami z Google.<\/p>\n

Esencja ataku jest nast\u0119puj\u0105ca: haker zmusza klienta do po\u0142\u0105czenia si\u0119 przez SSL 3.0, symuluj\u0105c przerwy w po\u0142\u0105czeniu. Nast\u0119pnie szuka w zaszyfrowanym CBC<\/a><\/noindex>-trybie ruchu specjalnych wiadomo\u015bci-cenzorek. Poprzez seri\u0119 fa\u0142szywych zapyta\u0144, przest\u0119pca ma mo\u017cliwo\u015b\u0107 rekonstrukcji zawarto\u015bci interesuj\u0105cych go danych, na przyk\u0142ad ciasteczek.<\/p>\n

SSL 3.0 to przestarza\u0142y protok\u00f3\u0142. Jednak kwestia jego bezpiecze\u0144stwa wci\u0105\u017c jest aktualna. Klienci korzystaj\u0105 z niego, aby unikn\u0105\u0107 problem\u00f3w z kompatybilno\u015bci\u0105 z serwerami. Wed\u0142ug niekt\u00f3rych danych, prawie 7% z 100 tys. najpopularniejszych stron internetowych nadal wspiera SSL 3.0<\/a><\/noindex>. R\u00f3wnie\u017c istniej\u0105<\/a><\/noindex> modyfikacje POODLE, kt\u00f3re celuj\u0105 w nowocze\u015bniejsze TLS 1.0 i TLS 1.1. W tym roku pojawi\u0142y si\u0119<\/a><\/noindex> nowe ataki Zombie POODLE i GOLDENDOODLE, kt\u00f3re omijaj\u0105 ochron\u0119 TLS 1.2 (s\u0105 one nadal zwi\u0105zane z szyfrowaniem CBC).<\/p>\n

Jak si\u0119 chroni\u0107.<\/b> W przypadku oryginalnego POODLE nale\u017cy wy\u0142\u0105czy\u0107 obs\u0142ug\u0119 SSL 3.0. Jednak w takim przypadku istnieje ryzyko problem\u00f3w z kompatybilno\u015bci\u0105. Alternatywnym rozwi\u0105zaniem mo\u017ce by\u0107 mechanizm TLS_FALLBACK_SCSV \u2014 gwarantuje, \u017ce wymiana danych przez SSL 3.0 b\u0119dzie odbywa\u0142a si\u0119 tylko z przestarza\u0142ymi systemami. Przest\u0119pcy nie b\u0119d\u0105 mogli ju\u017c zainicjowa\u0107 obni\u017cenia wersji protoko\u0142u. Sposobem ochrony przed Zombie POODLE i GOLDENDOODLE jest wy\u0142\u0105czenie obs\u0142ugi CBC w aplikacjach opartych na TLS 1.2. Drastycznym rozwi\u0105zaniem b\u0119dzie przej\u015bcie na TLS 1.3 \u2014 w nowej wersji protoko\u0142u nie u\u017cywa si\u0119 szyfrowania CBC. Zamiast tego stosuje si\u0119 bardziej odporne metody AES i ChaCha20.<\/p>\n

BEAST<\/h2>\n

\nTo jeden z pierwszych atak\u00f3w na SSL i TLS 1.0, odkryty w 2011 roku. Podobnie jak POODLE, BEAST u\u017cywa<\/a><\/noindex> cechy szyfrowania CBC. Napastnicy wprowadzaj\u0105 na komputerze klienta agenta JavaScript lub aplet Java, kt\u00f3ry zmienia wiadomo\u015bci podczas transmisji danych przez TLS lub SSL. Poniewa\u017c napastnicy znaj\u0105 tre\u015b\u0107 \"fa\u0142szywych\" pakiet\u00f3w, mog\u0105 z ich pomoc\u0105 odszyfrowa\u0107 wektor inicjalizacji i przeczyta\u0107 inne wiadomo\u015bci do serwera, na przyk\u0142ad pliki cookie do autoryzacji.<\/p>\n

Obecnie podatno\u015bci BEAST wci\u0105\u017c dotycz\u0105 wielu narz\u0119dzi sieciowych<\/a><\/noindex>: serwer\u00f3w proxy i aplikacji do ochrony lokalnych bram internetowych.<\/p>\n

Jak si\u0119 chroni\u0107.<\/b> Aby napastnik m\u00f3g\u0142 odszyfrowa\u0107 dane, musi regularnie wysy\u0142a\u0107 \u017c\u0105dania. W VMware zaleca si\u0119<\/a><\/noindex> skr\u00f3t czasu SSLSessionCacheTimeout \u2014 z pi\u0119ciu minut (zalecenie domy\u015blne) do 30 sekund. Takie podej\u015bcie utrudni realizacj\u0119 plan\u00f3w napastnikom, chocia\u017c wp\u0142ynie negatywnie na wydajno\u015b\u0107. Trzeba te\u017c pami\u0119ta\u0107, \u017ce wkr\u00f3tce podatno\u015b\u0107 BEAST mo\u017ce sama znikn\u0105\u0107 \u2014 od 2020 roku najwi\u0119ksze przegl\u0105darki zaprzestan\u0105<\/a><\/noindex> wsparcia dla TLS 1.0 i 1.1. W ka\u017cdym razie mniej ni\u017c 1,5% wszystkich u\u017cytkownik\u00f3w przegl\u0105darek korzysta z tych protoko\u0142\u00f3w.<\/p>\n

DROWN<\/h2>\n

\nTo atak mi\u0119dzyprotoko\u0142owy, wykorzystuj\u0105cy b\u0142\u0119dy w implementacji SSLv2 z 40-bitowymi kluczami RSA. Napastnik pods\u0142uchuje setki po\u0142\u0105cze\u0144 TLS docelowego serwera i wysy\u0142a specjalne pakiety do serwera z SSLv2, u\u017cywaj\u0105c tego samego klucza prywatnego. Wykorzystuj\u0105c atak Bleichenbachera<\/a><\/noindex>, haker mo\u017ce odszyfrowa\u0107 jedn\u0105 z oko\u0142o tysi\u0105ca sesji TLS klienta.<\/p>\n

O DROWN po raz pierwszy dowiedziano si\u0119 w 2016 roku \u2014 wtedy okaza\u0142o si\u0119, \u017ce podatnych jest jedna trzecia serwer\u00f3w<\/a><\/noindex> na \u015bwiecie. Do dzi\u015b nie straci\u0142a na znaczeniu. Spo\u015br\u00f3d 150 tysi\u0119cy najpopularniejszych stron internetowych 2% wci\u0105\u017c wspieraj\u0105<\/a><\/noindex> u\u017cywa SSLv2 i podatnych mechanizm\u00f3w szyfrowania.<\/p>\n

Jak si\u0119 chroni\u0107.<\/b> Nale\u017cy zainstalowa\u0107 poprawki dostarczone przez tw\u00f3rc\u00f3w bibliotek kryptograficznych, wy\u0142\u0105czaj\u0105ce wsparcie dla SSLv2. Na przyk\u0142ad dwie takie \u0142atki zosta\u0142y zaprezentowane dla OpenSSL (w 2016 roku by\u0142y to aktualizacje<\/a><\/noindex> 1.0.1s i 1.0.2g). Ponadto aktualizacje i instrukcje dotycz\u0105ce wy\u0142\u0105czania podatnego protoko\u0142u opublikowano w Red Hat<\/a><\/noindex>, Apache<\/a><\/noindex>, Debian<\/a><\/noindex>.<\/p>\n

\u201eZas\u00f3b mo\u017ce by\u0107 podatny na DROWN, je\u015bli korzysta z kluczy u\u017cywanych przez zewn\u0119trzny serwer z SSLv2, na przyk\u0142ad pocztowy\u201d, zauwa\u017ca szef dzia\u0142u rozwoju dostawcy us\u0142ug IaaS 1cloud.ru<\/a><\/noindex> Siergiej Be\u0142kin. \u2014 Taka sytuacja wyst\u0119puje, je\u015bli kilka serwer\u00f3w korzysta ze wsp\u00f3lnego certyfikatu SSL. W takim przypadku wsparcie dla SSLv2 nale\u017cy wy\u0142\u0105czy\u0107 na wszystkich maszynach.<\/i><\/p><\/blockquote>\n

\nMo\u017cna sprawdzi\u0107, czy konieczna jest aktualizacja systemu, za pomoc\u0105 specjalnego narz\u0119dzia<\/a><\/noindex> \u2014 zosta\u0142 opracowany przez specjalist\u00f3w ds. bezpiecze\u0144stwa, kt\u00f3rzy odkryli DROWN. Wi\u0119cej o zaleceniach dotycz\u0105cych ochrony przed tym typem atak\u00f3w mo\u017cna przeczyta\u0107 w po\u015bcie na stronie OpenSSL<\/a><\/noindex>.<\/p>\n

Heartbleed<\/h2>\n

\nJedna z najwi\u0119kszych luk w oprogramowaniu \u2014 Heartbleed<\/a><\/noindex>. Zosta\u0142a odkryta w 2014 roku w bibliotece OpenSSL. W momencie og\u0142oszenia o b\u0142\u0119dzie liczba podatnych stron internetowych szacowano na p\u00f3\u0142 miliona<\/a><\/noindex> \u2014 to oko\u0142o 17% zabezpieczonych zasob\u00f3w w sieci.<\/p>\n

Atak realizowany jest poprzez ma\u0142y modu\u0142 Heartbeat rozszerzenia TLS. Protok\u00f3\u0142 TLS wymaga, aby dane by\u0142y przesy\u0142ane nieprzerwanie. W przypadku d\u0142ugiego bezczynno\u015bci nast\u0119puje roz\u0142\u0105czenie i konieczne jest ponowne nawi\u0105zanie po\u0142\u0105czenia. Aby poradzi\u0107 sobie z problemem, serwery i klienci sztucznie \u00abszumiaj\u0105\u00bb kana\u0142 (RFC 6520, str.5<\/a><\/noindex>), przesy\u0142aj\u0105c pakiet losowej d\u0142ugo\u015bci. Je\u015bli okazywa\u0142 si\u0119 wi\u0119kszy ni\u017c to, co powinno, podatne wersje OpenSSL odczytywa\u0142y pami\u0119\u0107 poza przydzielonym buforem. W tej przestrzeni mog\u0142y znajdowa\u0107 si\u0119 jakiekolwiek dane, w tym klucze szyfrowania i informacje o innych po\u0142\u0105czeniach.<\/p>\n

Luka by\u0142a obecna we wszystkich wersjach biblioteki mi\u0119dzy 1.0.1 a 1.0.1f w\u0142\u0105cznie, a tak\u017ce w kilku systemach operacyjnych \u2014 Ubuntu do 12.04.4, CentOS starszym ni\u017c 6.5, OpenBSD 5.3 i innych. Pe\u0142na lista jest na stronie po\u015bwi\u0119conej Heartbleed<\/a><\/noindex>. Chocia\u017c \u0142aty przeciwko tej luce zosta\u0142y wydane praktycznie zaraz po jej odkryciu, problem wci\u0105\u017c pozostaje aktualny. Jeszcze w 2017 roku pracowa\u0142o prawie 200 tys. stron<\/a><\/noindex>, nara\u017conych na Heartbleed.<\/p>\n

Jak si\u0119 chroni\u0107.<\/b> Nale\u017cy zaktualizowa\u0107 OpenSSL<\/a><\/noindex> do wersji 1.0.1g lub wy\u017cszej. Mo\u017cna tak\u017ce r\u0119cznie wy\u0142\u0105czy\u0107 zapytania Heartbeat za pomoc\u0105 opcji DOPENSSL_NO_HEARTBEATS. Po aktualizacji specjali\u015bci ds. bezpiecze\u0144stwa zaleca si\u0119<\/a><\/noindex> powinni ponownie wyda\u0107 certyfikaty SSL. Wymiana jest konieczna na wypadek, gdyby dane o kluczach szyfrowania jednak trafi\u0142y w r\u0119ce haker\u00f3w.<\/p>\n

Podmiana certyfikatu<\/h2>\n

\nMi\u0119dzy u\u017cytkownikiem a serwerem ustawia si\u0119 kontrolowany w\u0119ze\u0142 z legalnym certyfikatem SSL, aktywnie przechwytuj\u0105cy ruch. Ten w\u0119ze\u0142 podaje si\u0119 za legalny serwer, przedstawiaj\u0105c wa\u017cny certyfikat, co umo\u017cliwia przeprowadzenie ataku MITM.<\/p>\n

Zgodnie z badaniem<\/a><\/noindex> Badania przeprowadzone przez Mozilla, Google oraz kilka uniwersytet\u00f3w pokazuj\u0105, \u017ce oko\u0142o 11% zabezpieczonych po\u0142\u0105cze\u0144 w sieci jest \"pods\u0142uchiwanych\". To wynik zainstalowania podejrzanych certyfikat\u00f3w root na komputerach u\u017cytkownik\u00f3w.<\/p>\n

Jak si\u0119 chroni\u0107.<\/b> Korzystaj z us\u0142ug zaufanych dostawc\u00f3w SSL<\/a><\/noindex>. Jako\u015b\u0107 certyfikat\u00f3w mo\u017cna sprawdzi\u0107 za pomoc\u0105 serwisu Certificate Transparency<\/a><\/noindex> (CT). Wykrywanie \"pods\u0142uchu\" mog\u0105 wspiera\u0107 r\u00f3wnie\u017c dostawcy chmurowi \u2014 ju\u017c dzi\u015b niekt\u00f3re du\u017ce firmy oferuj\u0105 specjalistyczne narz\u0119dzia do monitorowania po\u0142\u0105cze\u0144 TLS.<\/p>\n

Innym sposobem na zabezpieczenie b\u0119dzie nowy standard<\/a><\/noindex> ACME, kt\u00f3ry automatyzuje proces uzyskiwania certyfikat\u00f3w SSL. Doda on dodatkowe mechanizmy do weryfikacji w\u0142a\u015bciciela strony. Wi\u0119cej na ten temat pisali\u015bmy w jednym z naszych wcze\u015bniejszych materia\u0142\u00f3w<\/a><\/noindex>.<\/p>\n

\"Potencjalne
\n\/ Flickr \/ Yuri Samoilov<\/a><\/noindex> \/ CC BY<\/i><\/p>\n

Perspektywy HTTPS<\/h2>\n

\nPomimo wielu luk, giganci IT i eksperci ds. bezpiecze\u0144stwa s\u0105 przekonani o przysz\u0142o\u015bci tego protoko\u0142u. Za aktywne wdra\u017canie HTTPS jest<\/a><\/noindex> odpowiada tw\u00f3rca WWW, Tim Berners-Lee. Jego zdaniem, z biegiem czasu TLS b\u0119dzie stawa\u0142 si\u0119 coraz bardziej zabezpieczony, co znacz\u0105co zwi\u0119kszy bezpiecze\u0144stwo po\u0142\u0105cze\u0144. Berners-Lee nawet zasugerowa\u0142, \u017ce w przysz\u0142o\u015bci pojawi\u0105 si\u0119<\/a><\/noindex> certyfikaty klienckie do uwierzytelniania to\u017csamo\u015bci. Pomo\u017ce to w poprawie ochrony serwer\u00f3w przed cyberprzest\u0119pcami.<\/p>\n

Rozw\u00f3j technologii SSL\/TLS planuje si\u0119 r\u00f3wnie\u017c przy wykorzystaniu uczenia maszynowego \u2014 inteligentne algorytmy b\u0119d\u0105 odpowiada\u0142y za filtrowanie z\u0142o\u015bliwego ruchu. W po\u0142\u0105czeniach HTTPS administratorzy nie maj\u0105 mo\u017cliwo\u015bci poznania tre\u015bci zaszyfrowanych wiadomo\u015bci \u2014 w tym tak\u017ce wykrycia zapyta\u0144 od z\u0142o\u015bliwego oprogramowania. Ju\u017c dzi\u015b sieci neuronowe s\u0105 w stanie filtrowa\u0107 potencjalnie niebezpieczne pakiety z dok\u0142adno\u015bci\u0105 90%. (slajd 23 prezentacji<\/a><\/noindex>).<\/p>\n

Wnioski<\/h2>\n

\nAtaki na HTTPS w przewa\u017caj\u0105cej mierze zwi\u0105zane s\u0105 nie z samymi problemami protoko\u0142u, ale z obs\u0142ug\u0105 przestarza\u0142ych mechanizm\u00f3w szyfrowania. Przemys\u0142 IT zaczyna stopniowo rezygnowa\u0107 z protoko\u0142\u00f3w poprzedniej generacji i oferowa\u0107 nowe narz\u0119dzia do wykrywania luk. W przysz\u0142o\u015bci te narz\u0119dzia b\u0119d\u0105 stawa\u0142y si\u0119 coraz bardziej inteligentne.<\/p>\n

Dodatkowe linki w temacie:<\/h5>\n

<\/p>\n