Група дослідників з кількох університетів Німеччини розробила новий метод MITM-атаки на HTTPS, що дає змогу витягти Cookie з ідентифікаторами сеансу та інші конфіденційні дані, а також домогтися виконання довільного коду JavaScript у контексті іншого сайту. Атака отримала назву ALPACA і може бути застосована до TLS-серверів, які реалізують різні протоколи прикладного рівня (HTTPS, SFTP, SMTP, IMAP, POP3), але використовують загальні сертифікати TLS.
Суть атаки в тому, що за наявності контролю над мережним шлюзом або точкою бездротового доступу атакуючий може перенаправити web-трафік на інший мережевий порт і організувати встановлення з'єднання з FTP або поштовим сервером, що підтримують TLS-шифрування та використовують спільний з HTTP-сервером TLS-сертифікат , і браузер користувача буде вважати, що встановлено з'єднання із запитаним HTTP-сервером. Так як протокол TLS універсальний і не прив'язаний до протоколів прикладного рівня, встановлення шифрованого з'єднання для всіх сервісів ідентична і помилка відправки запиту не до того сервісу може бути визначена вже після встановлення шифрованого сеансу під час обробки команд відправленого запиту.
Відповідно, якщо, наприклад, перенаправити з'єднання користувача, спочатку адресоване до HTTPS, на поштовий сервер, в якому застосовується спільний сертифікат з HTTPS-сервером, TLS-з'єднання буде успішно встановлено, але поштовий сервер не зможе обробити передані HTTP-команди і поверне відповідь з кодом помилки. Ця відповідь буде оброблена браузером як відповідь запитаного сайту, передана всередині коректно встановленого шифрованого каналу зв'язку.
Запропоновано три варіанти атаки:
- "Upload" для отримання Cookie з параметрами автентифікації. Метод застосовується, якщо FTP-сервер, що охоплюється TLS-сертифікатом, дозволяє завантажити і витягти свої дані. У цьому варіанті атаки атакуючий може домогтися збереження частин початкового запиту HTTP користувача, таких як вміст заголовка Cookie, наприклад, якщо FTP-сервер інтерпретує запит як файл для збереження або повністю журналює вхідні запити. Для успішної атаки зловмиснику потрібно потім якимось чином витягти збережений вміст. Атака застосовується до Proftpd, Microsoft IIS, vsftpd, filezilla та serv-u.
- "Download" для організації міжсайтового скриптингу (XSS). Метод має на увазі, що атакуючий в результаті якихось окремих маніпуляцій може розмістити дані в сервісі, який використовує загальний TLS-сертифікат, який потім можна видати у відповідь на запит користувача. Атака застосовна до вищезазначених FTP-серверів, IMAP-серверів та POP3-серверів (courier, cyrus, kerio-connect та zimbra).
- "Reflection" для запуску JavaScript в контексті іншого сайту. Метод заснований на поверненні клієнту частини запиту, в якому міститься надісланий JavaScript-код, що атакує. Атака застосовна до вищезазначених FTP-серверів, IMAP-серверів cyrus, kerio-connect та zimbra, а також до SMTP-сервера sendmail.
Наприклад, при відкритті користувачем сторінки, підконтрольної атакуючим, з цієї сторінки може бути ініційований запит ресурсу з сайту, на якому користувач має активний обліковий запис (наприклад, bank.com). У ході MITM-атаки цей запит, адресований web-сайту bank.com, можна перенаправити на поштовий сервер, у якому використовується спільний із bank.com TLS-сертифікат. Оскільки поштовий сервер не завершує сеанс після першої помилки, службові заголовки та команди, такі як «POST/HTTP/1.1» та «Host:», будуть оброблені як невідомі команди (поштовий сервер поверне на кожен заголовок «500 unrecognized command»).
Поштовий сервер не розбирає особливості протоколу HTTP і для нього службові заголовки і блок даних запиту POST обробляються однаково, тому в тілі запиту POST можна вказати рядок з командою поштовому серверу. Наприклад, можна передати: MAIL FROM: alert(1); на що поштовий сервер поверне повідомлення про помилку 501 alert(1); : malformed address: alert(1); не може не follow
Ця відповідь отримає браузер користувача, який виконає JavaScript-код у контексті не відкритого сайту атакуючого, а сайту bank.com, на який був відправлений запит, оскільки відповідь надійшла всередині коректного TLS-сеансу, сертифікат якого підтвердив справжність відповіді bank.com.
Сканування глобальної мережі показало, що проблему в загальному вигляді схильні близько 1.4 млн web-серверів, для яких можливе здійснення атаки зі змішуванням звернень за різними протоколами. Можливість реального здійснення атаки визначена для 119 тисяч web-серверів, для яких були присутні супутні сервери TLS на базі інших прикладних протоколів.
Приклади експлоїтів підготовлені для ftp-серверів pureftpd, proftpd, microsoft-ftp, vsftpd, filezilla та serv-u, IMAP- та POP3-серверів dovecot, courier, exchange, cyrus, kerio-connect та zimbra, SMTP-серверів postfix sendmail, mailenable, mdaemon та opensmtpd. Дослідниками вивчено можливість здійснення атаки тільки у поєднанні з серверами FTP, SMTP, IMAP і POP3, при цьому не виключається, що проблема може виявлятися і для інших прикладних протоколів, які використовують TLS.
Для блокування атаки запропоновано використовувати розширення ALPN (Application Layer Protocol Negotiation) для узгодження TLS-сеансу з урахуванням прикладного протоколу та розширення SNI (Server Name Indication) для прив'язки до імені хоста у разі застосування TLS-сертифікатів, що охоплюють кілька доменних імен. На стороні програм рекомендовано обмежити ліміт на кількість помилок при обробці команд, після досягнення якого розривати з'єднання. Процес вироблення заходів щодо блокування атаки розпочався ще у жовтні минулого року. Подібні заходи для захисту вже вжито у Nginx 1.21.0 (mail proxy), Vsftpd 3.0.4, Courier 5.1.0, Sendmail, FileZill, crypto/tls (Go) та Internet Explorer.
Джерело: opennet.ru