Zespół badaczy z kilku uniwersytetów w Niemczech opracował nowy atak MITM na HTTPS, który może wyodrębnić pliki cookie sesji i inne wrażliwe dane, a także wykonać dowolny kod JavaScript w kontekście innej witryny. Atak nazywa się ALPACA i można go zastosować do serwerów TLS, które implementują różne protokoły warstwy aplikacji (HTTPS, SFTP, SMTP, IMAP, POP3), ale korzystają z popularnych certyfikatów TLS.
Istota ataku polega na tym, że atakujący, jeśli posiada kontrolę nad bramą sieciową lub punktem dostępu bezprzewodowego, może przekierować ruch sieciowy na inny port sieciowy i zorganizować nawiązanie połączenia z serwerem FTP lub pocztowym, który obsługuje szyfrowanie TLS i wykorzystuje Certyfikat TLS wspólny z serwerem HTTP, a przeglądarka użytkownika przyjmie, że zostało nawiązane połączenie z żądanym serwerem HTTP. Ponieważ protokół TLS jest uniwersalny i nie jest powiązany z protokołami aplikacji, ustanowienie szyfrowanego połączenia dla wszystkich usług jest identyczne, a błąd wysłania żądania do niewłaściwej usługi można stwierdzić dopiero po nawiązaniu szyfrowanej sesji podczas przetwarzania polecenia wysłanego żądania.
W związku z tym, jeśli na przykład przekierujesz połączenie użytkownika pierwotnie adresowane do HTTPS na serwer pocztowy korzystający z certyfikatu udostępnionego serwerowi HTTPS, połączenie TLS zostanie pomyślnie nawiązane, ale serwer pocztowy nie będzie mógł przetworzyć przesłanej Polecenia HTTP i zwróci odpowiedź z kodem błędu. Odpowiedź ta będzie przetwarzana przez przeglądarkę jako odpowiedź z żądanej witryny, przesyłana w ramach poprawnie ustanowionego, zaszyfrowanego kanału komunikacji.
Proponowane są trzy opcje ataku:
- „Prześlij”, aby pobrać plik cookie z parametrami uwierzytelniającymi. Metoda ma zastosowanie w przypadku, gdy serwer FTP objęty certyfikatem TLS umożliwia przesyłanie i pobieranie swoich danych. W tym wariancie ataku osoba atakująca może zachować część pierwotnego żądania HTTP użytkownika, na przykład zawartość nagłówka Cookie, jeśli serwer FTP zinterpretuje żądanie jako plik zapisu lub całkowicie zarejestruje przychodzące żądania. Aby skutecznie zaatakować, osoba atakująca musi w jakiś sposób wyodrębnić przechowywaną zawartość. Atak dotyczy Proftpd, Microsoft IIS, vsftpd, filezilla i serv-u.
- „Pobierz” do organizowania skryptów między witrynami (XSS). Metoda zakłada, że atakujący w wyniku indywidualnych manipulacji może umieścić dane w usłudze korzystającej ze wspólnego certyfikatu TLS, który następnie może zostać wystawiony w odpowiedzi na żądanie użytkownika. Atak dotyczy ww. serwerów FTP, serwerów IMAP oraz serwerów POP3 (courier, cyrus, kerio-connect i zimbra).
- „Reflection”, aby uruchomić JavaScript w kontekście innej witryny. Metoda polega na zwróceniu klientowi części żądania, która zawiera kod JavaScript przesłany przez atakującego. Atak dotyczy wyżej wymienionych serwerów FTP, serwerów IMAP cyrus, kerio-connect i zimbra, a także serwera SMTP sendmail.
Na przykład, gdy użytkownik otworzy stronę kontrolowaną przez atakującego, strona ta może zainicjować żądanie udostępnienia zasobu z witryny, w której użytkownik ma aktywne konto (na przykład bank.com). Podczas ataku MITM to żądanie skierowane do witryny bank.com może zostać przekierowane na serwer poczty elektronicznej korzystający z certyfikatu TLS współdzielonego z bank.com. Ponieważ serwer pocztowy nie zakończy sesji po pierwszym błędzie, nagłówki usług i polecenia takie jak „POST / HTTP/1.1” i „Host:” zostaną przetworzone jako nieznane polecenia (serwer pocztowy zwróci „500 nierozpoznanych poleceń” dla każdy nagłówek).
Serwer pocztowy nie rozumie cech protokołu HTTP i dla niego nagłówki usług oraz blok danych żądania POST są przetwarzane w ten sam sposób, dlatego w treści żądania POST można podać linię z poleceniem serwer pocztowy. Na przykład możesz przekazać: MAIL OD: alert(1); do którego serwer pocztowy zwróci komunikat o błędzie 501 alert(1); : zniekształcony adres: alert(1); może nie nadążać
Odpowiedź ta zostanie odebrana przez przeglądarkę użytkownika, która wykona kod JavaScript w kontekście nie początkowo otwartej witryny atakującego, ale witryny bank.com, do której wysłano żądanie, gdyż odpowiedź nadeszła w ramach prawidłowej sesji TLS , którego certyfikat potwierdził autentyczność odpowiedzi bank.com.
Skan sieci globalnej wykazał, że ogółem problem dotyczy około 1.4 miliona serwerów WWW, na które można przeprowadzić atak poprzez mieszanie żądań przy użyciu różnych protokołów. Możliwość rzeczywistego ataku stwierdzono dla 119 tys. serwerów WWW, dla których towarzyszyły serwery TLS oparte na innych protokołach aplikacyjnych.
Przygotowano przykłady exploitów dla serwerów FTP pureftpd, proftpd, microsoft-ftp, vsftpd, filezilla i serv-u, serwerów IMAP i POP3 dovecot, kurier, Exchange, cyrus, kerio-connect i zimbra, serwerów SMTP postfix, exim, sendmail , mailenable, mdaemon i opensmtpd. Badacze zbadali możliwość przeprowadzenia ataku tylko w połączeniu z serwerami FTP, SMTP, IMAP i POP3, ale możliwe jest, że problem może wystąpić również w przypadku innych protokołów aplikacji korzystających z TLS.
Aby zablokować atak proponuje się wykorzystanie rozszerzenia ALPN (Application Layer Protocol Negotiation) do negocjowania sesji TLS z uwzględnieniem protokołu aplikacji oraz rozszerzenia SNI (Server Name Indication) do powiązania z nazwą hosta w przypadku użycia Certyfikaty TLS obejmujące kilka nazw domen. Po stronie aplikacji zaleca się ograniczenie liczby błędów przy przetwarzaniu poleceń, po czym połączenie zostaje zerwane. Proces opracowywania środków blokujących atak rozpoczął się w październiku ubiegłego roku. Podobne środki bezpieczeństwa zostały już podjęte w Nginx 1.21.0 (mail proxy), Vsftpd 3.0.4, Courier 5.1.0, Sendmail, FileZill, crypto/tls (Go) i Internet Explorer.
Źródło: opennet.ru