NowościOprogramowanieRTV

Hakerzy mogą zepsuć połączenia HTTPS, wysyłając dane na Twój serwer poczty e-mail

Wysoce stylizowany wizerunek kłódki.

Gdy odwiedzasz witrynę chronioną protokołem HTTPS, przeglądarka nie wymienia danych z serwerem sieciowym, dopóki nie upewni się, że certyfikat cyfrowy witryny jest ważny. Uniemożliwia to hakerom, którzy mają możliwość monitorowania lub modyfikowania danych przesyłanych między Tobą a witryną, uzyskanie uwierzytelniających plików cookie lub wykonanie złośliwego kodu na urządzeniu odwiedzającym.

Ale co by się stało, gdyby osoba atakująca typu man-in-the-middle mogła nakłonić przeglądarkę do przypadkowego połączenia się z serwerem pocztowym lub serwerem FTP, który używa certyfikatu zgodnego z certyfikatem używanym przez witrynę?

Niebezpieczeństwa związane z komunikacją HTTPS z serwerem poczty e-mail

Ponieważ nazwa domeny witryny odpowiada nazwie domeny w certyfikacie serwera poczty e-mail lub serwera FTP, w wielu przypadkach przeglądarka nawiąże połączenie Transport Layer Security z jednym z tych serwerów, a nie z witryną, którą użytkownik zamierzał odwiedzić.

Ponieważ przeglądarka komunikuje się za pomocą protokołu HTTPS, a serwer poczty e-mail lub FTP korzysta z protokołu SMTP, SFTP lub innego, istnieje możliwość, że coś pójdzie nie tak — na przykład do atakującego może zostać wysłany odszyfrowany plik cookie uwierzytelniania może wykonać złośliwy kod na maszynie odwiedzającej.

Scenariusz nie jest tak naciągany, jak niektórzy mogą sądzić. Nowe badania wykazały, że około 14,4 miliona serwerów WWW używa nazwy domeny, która jest zgodna z danymi uwierzytelniającymi kryptograficzny serwer pocztowy lub FTP należący do tej samej organizacji. Spośród tych witryn około 114 000 uważa się za nadające się do wykorzystania, ponieważ serwer poczty e-mail lub FTP korzysta z oprogramowania, o którym wiadomo, że jest podatne na takie ataki.

Takie ataki są możliwe, ponieważ protokół TLS nie chroni integralności samego połączenia TCP, a nie integralności samego serwera obsługującego protokół HTTP, SMTP lub inny język internetowy. Osoby atakujące typu man-in-the-middle mogą wykorzystać tę słabość, aby przekierować ruch TLS z zamierzonego serwera i protokołu do innego, zastępującego punkt końcowy i protokół.

„Podstawową zasadą jest to, że atakujący może przekierować ruch przeznaczony dla jednej usługi do innej, ponieważ protokół TLS nie chroni adresu IP ani numeru portu” – powiedział mi Marcus Brinkmann, badacz z Ruhr University Bochum w Niemczech. „W przeszłości ludzie rozważali ataki, w których atakujący MitM przekierowuje przeglądarkę na inny serwer WWW, ale rozważamy przypadek, w którym atakujący przekierowuje przeglądarkę z serwera WWW na inny serwer aplikacji, taki jak FTP lub e-mail”.

Pęknięcia w kamieniu węgielnym

Zwykle w skrócie TLS, Transport Layer Security używa silnego szyfrowania, aby udowodnić, że użytkownik końcowy jest połączony z autentycznym serwerem należącym do określonej usługi (takiej jak Google lub Bank of America), a nie z oszustem podszywającym się pod tę usługę. TLS szyfruje również dane przesyłane między użytkownikiem końcowym a serwerem, aby zapewnić, że osoby, które mogą monitorować połączenie, nie będą mogły czytać ani manipulować zawartością. Ponieważ opierają się na nim miliony serwerów, TLS jest podstawą bezpieczeństwa online.

W artykule badawczym opublikowanym w środę Brinkmann i siedmiu innych badaczy zbadali wykonalność użycia tak zwanych ataków międzyprotokołowych w celu ominięcia zabezpieczeń TLS. Technika polega na tym, że atakujący MitM przekierowuje żądania HTTP między źródłami do serwerów, które komunikują się przez SMTP, IMAP, POP3 lub FTP lub inny protokół komunikacyjny.

Głównymi elementami ataku są (1) aplikacja kliencka używana przez docelowego użytkownika końcowego, oznaczona jako C; (2) serwer, do którego cel zamierzał odwiedzić, oznaczony jako Sint; oraz (3) serwer zastępczy, komputer, który łączy się za pomocą SMTP, FTP lub innego protokołu, który różni się od jednego serweraint używa, ale z tą samą domeną wymienioną w jego certyfikacie TLS.

Badacze zidentyfikowali trzy metody ataku, których adwersarze MitM mogliby użyć, aby zagrozić bezpiecznemu przeglądaniu celu w tym scenariuszu. Oni są:

Prześlij atak. W przypadku tego ataku zakładamy, że atakujący ma pewną możliwość przesyłania danych do Spod i odzyskaj go później. W ataku typu upload osoba atakująca próbuje przechowywać części żądania HTTP przeglądarki (w szczególności nagłówek Cookie) na Spod. Może to na przykład wystąpić, jeśli serwer zinterpretuje żądanie jako przesłanie pliku lub jeśli serwer szczegółowo rejestruje przychodzące żądania. Po udanym ataku atakujący może pobrać zawartość na serwerze niezależnie od połączenia z C do Spod i pobrać plik cookie sesji HTTPS.

Pobierz atak — przechowywany XSS. W przypadku tego ataku zakładamy, że atakujący ma pewną zdolność do przygotowania przechowywanych danych na Spod i pobierz go. W ataku polegającym na pobieraniu atakujący wykorzystuje łagodne funkcje protokołu, aby „pobrać” wcześniej zapisane (i specjalnie spreparowane) dane z S.pod do C. Jest to podobne do przechowywanej luki XSS. Ponieważ jednak używany jest inny protokół niż HTTP, nawet wyrafinowane mechanizmy obrony przed XSS, takie jak Content-Security-Policy
(CSP), można obejść. Bardzo prawdopodobne, Spod sam nie wyśle ​​żadnego CSP, a duża część odpowiedzi jest pod kontrolą napastnika.

Atak odbicia — odbity XSS. W ataku odbicia atakujący próbuje oszukać serwer Spod do odzwierciedlenia części żądania C w odpowiedzi do C. Jeśli się powiedzie, atakujący wysyła złośliwy kod JavaScript w żądaniu, które zostaje odzwierciedlone przez Spod. Klient przeanalizuje następnie odpowiedź z serwera, co z kolei może doprowadzić do wykonania kodu JavaScript w kontekście docelowego serwera WWW.

Przeciwnik MitM nie może odszyfrować ruchu TLS, ale przeciwnik może zrobić jeszcze inne rzeczy. Na przykład zmuszenie przeglądarki docelowej do łączenia się z serwerem poczty e-mail lub FTP zamiast zamierzonego serwera WWW może spowodować, że przeglądarka zapisze plik cookie uwierzytelniania na serwerze FTP. Może też umożliwić ataki typu cross-site scripting, które powodują, że przeglądarka pobiera i wykonuje złośliwy kod JavaScript hostowany na serwerze FTP lub serwerze poczty e-mail.

Egzekwowanie zabezpieczeń ALPN i SNI

Aby zapobiec atakom między protokołami, naukowcy zaproponowali ściślejsze egzekwowanie dwóch istniejących zabezpieczeń. Pierwszy znany jest jako negocjacja protokołu warstwy aplikacji, rozszerzenie TLS, które pozwala warstwie aplikacji, takiej jak przeglądarka, negocjować, jaki protokół powinien być używany w bezpiecznym połączeniu. ALPN, jak to zwykle jest skracane, służy do nawiązywania połączeń przy użyciu wydajniejszego protokołu HTTP/2 bez dodatkowych podróży w obie strony.

Dzięki ścisłemu egzekwowaniu ALPN zgodnie z definicją w standardzie formalnym połączenia tworzone przez przeglądarki lub inne warstwy aplikacji, które wysyłają rozszerzenie, nie są podatne na ataki międzyprotokołowe.

Podobnie użycie oddzielnego rozszerzenia TLS zwanego wskazaniem nazwy serwera może chronić przed atakami obejmującymi wiele nazw hostów, jeśli zostało skonfigurowane do kończenia połączenia, gdy nie zostanie znaleziony pasujący host. „Może to chronić przed atakami międzyprotokołowymi, w których zamierzony i zastępczy serwer ma różne nazwy hostów, ale także przed niektórymi atakami opartymi na tym samym protokole, takimi jak dezorientacja hosta wirtualnego HTTPS lub ataki z dezorientacją kontekstu” – napisali naukowcy.

Naukowcy nazywają swoje ataki międzyprotokołowe ALPACA, skrótem od „protokołów warstwy aplikacji umożliwiających ataki międzyprotokołowe”. W tej chwili ALPACA nie stanowi większego zagrożenia dla większości ludzi. Jednak ryzyko może wzrosnąć wraz z odkryciem nowych ataków i luk w zabezpieczeniach lub użyciem protokołu TLS do ochrony dodatkowych kanałów komunikacyjnych.

„Ogólnie rzecz biorąc, atak jest bardzo sytuacyjny i jest wymierzony w indywidualnych użytkowników” – powiedział Brinkmann. „Tak więc indywidualne ryzyko dla użytkowników prawdopodobnie nie jest bardzo wysokie. Jednak z biegiem czasu coraz więcej usług i protokołów jest chronionych za pomocą TLS i pojawia się więcej okazji do nowych ataków zgodnych z tym samym wzorcem. Uważamy, że łagodzenie skutków jest na czas i ważne te kwestie na poziomie normalizacji, zanim staną się większym problemem”.

Zostaw komentarz

Maciek Luboński
Z wykształcenia jestem kucharzem , ale to nie przeszkadza mi pisać dla Was tekstów z wielu ciekawych dziedzin , których sam jestem fanem.Piszę dużo i często nie na tak jak trzeba , ale co z tego skoro tak naprawdę liczy się pasja.

Najlepsze recenzje

Video

gallery

Facebook