Blog IT, Blog Marketing

Nowe zagrożenie dla połączeń szyfrowanych

Nowe zagrożenie dla połączeń szyfrowanych

Marcin Sarna , 15.06.2021 r.

Atak międzyprotokołowy pozwala wykraść pliki cookies a więc np. zalogować się na stronę.

Niebezpieczeństwa związane z komunikacją HTTPS z serwerem pocztowym

Zwykle TLS używa silnego szyfrowania, aby zapewnić, że użytkownik końcowy jest połączony z autentycznym serwerem należącym do określonej usługi 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ć przekazywaną treścią. TLS jest podstawą bezpieczeństwa online.

Gdy odwiedzasz witrynę chronioną protokołem HTTPS, przeglądarka nie wymienia danych z serwerem, dopóki nie upewni się, że certyfikat cyfrowy witryny jest ważny. Uniemożliwia to atakującym, którzy mogą monitorować lub modyfikować dane przesyłane między Tobą a witryną, uzyskać uwierzytelniające pliki cookie czy wykonać złośliwy kod na urządzeniu odwiedzającym daną stronę.

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

Jeżeli nazwa domeny strony odpowiada nazwie domeny w certyfikacie serwera poczty e-mail lub serwera FTP, w wielu przypadkach przeglądarka nawiąże połączenie TLS 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 używa protokołu SMTP czy FTPS, istnieje możliwość, że coś pójdzie nie tak. Na przykład do atakującego może zostać wysłany odszyfrowany plik cookie z danymi uwierzytelnienia albo może zostać wykonany złośliwy kod.

To nie tylko teoria

Scenariusz nie jest wcale naciągany. Nowe badania wykazały właśnie, że około 1,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 możliwe do wykorzystania, ponieważ serwer poczty e-mail lub FTP korzysta z oprogramowania, które jest podatne na takie ataki.

Czemu to się w ogóle może udać? Ano dlatego, że protokół TLS nie chroni integralności samego połączenia TCP. 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 „prawdziwy” punkt końcowy i protokół.

Marcus Brinkmann, specjalista z Uniwersytetu Ruhry w Bochum, ujmuje to tak:

Podstawową wadą 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. W przeszłości ludzie rozważali ataki, w których atakujący man-in-the-middle przekierowuje przeglądarkę na inny serwer WWW, ale teraz rozważamy jako możliwy także przypadek, w którym atakujący przekierowuje przeglądarkę z serwera WWW na inny serwer aplikacji, taki jak FTP lub e-mail.

Brinkmann i siedmiu innych badaczy zbadało wykonalność wykorzystania tak zwanych ataków międzyprotokołowych w celu ominięcia zabezpieczeń TLS. Technika polega na tym, że atakujący przekierowuje żądania HTTP do serwerów, które komunikują się przez SMTP, IMAP, POP3 lub FTP lub inny protokół komunikacyjny.

Badacze zidentyfikowali trzy metody ataku, których możnaby użyć: Upload Attack, Download Attack—Stored XSSReflection Attack—Reflected XSS. Atakujący nie może wprawdzie odszyfrować ruchu TLS, ale możliwe jest na przykład:

  • zmuszenie przeglądarki do łączenia się z serwerem poczty e-mail lub FTP zamiast zamierzonego serwera WWW a w rezultacie zapisanie pliku cookie na tym serwerze FTP
  • wykonanie ataku typu cross-site scripting, w wyniku którego przeglądarka pobierze i wykona złośliwy kod JavaScript hostowany na serwerze FTP lub serwerze poczty e-mail

Aby zapobiec atakom między protokołami naukowcy zaproponowali póki co ściślejsze egzekwowanie już istniejącego zabezpieczenia ALPN.

Najnowsze oferty pracy:

Polecane wpisy na blogu IT:

Szukasz pracownika IT?

Dostarczymy Ci najlepszych specjalistów z branży IT. Wyślij zapytanie

Wyrażam zgodę TeamQuest Sp. z o.o. na przetwarzanie moich danych osobowych w celu marketingu produktów i usług własnych TeamQuest, w tym na kontaktowanie się ze mną w formie połączenia telefonicznego lub środkami elektronicznymi.
Administratorem podanych przez Ciebie danych osobowych jest TeamQuest Sp. z o.o., z siedzibą w Warszawie (00-814), ul. Miedziana 3a/21, zwana dalej „Administratorem".
Jeśli masz jakiekolwiek pytania odnośnie przetwarzania przez nas Twoich danych, skontaktuj się z naszym Inspektorem Ochrony Danych (IOD). Do Twojej dyspozycji jest pod adresem e-mail: office@teamquest.pl.
W jakim celu i na jakiej podstawie będziemy wykorzystywać Twoje dane? Dowiedz się więcej