|
| Группа исследователей из нескольких университетов Германии разработала новый метод MITM-атаки на HTTPS, дающий возможность извлечь Cookie с идентификаторами сеанса и другие конфиденциальные данные, а также добиться выполнения произвольного кода JavaScript в контексте другого сайта. Атака получила название ALPACA и может быть применена к TLS-серверам, реализующим разные протоколы прикладного уровня (HTTPS, FTPS, SMTP, IMAP, POP3), но использующим общие TLS-сертификаты. Суть атаки в том, что при наличии контроля над сетевым шлюзом или точкой беспроводного доступа атакующий может перенаправить web-трафик на другой сетевой порт и организовать установку соединения с FTP или почтовым сервером, поддерживающими TLS-шифрование и использующими общий с HTTP-сервером TLS-сертификат, и браузер пользователя будет считать, что установлено соединение с запрошенным HTTP-сервером. Так как протокол TLS универсален и не привязан к протоколам прикладного уровня, установка шифрованного соединения для всех сервисов идентична и ошибка отправки запроса не к тому сервису может быть определена только уже после установки шифрованного сеанса во время обработки команд отправленного запроса. Соответственно, если, например, перенаправить соединение пользователя, изначально адресованное к HTTPS, на почтовый сервер, в котором применяется общий с HTTPS-сервером сертификат, TLS-соединение будет успешно установлено, но почтовый сервер не сможет обработать переданные HTTP-команды и вернёт ответ с кодом ошибки. Данный ответ будет обработан браузером как ответ запрошенного сайта, переданный внутри корректно установленного шифрованного канала связи. Предложено три варианта атаки:
Например, при открытии пользователем страницы, подконтрольной атакующим, с этой страницы может быть инициирован запрос ресурса с сайта, на котором у пользователя имеется активная учётная запись (например, bank.com). В ходе MITM-атаки этот запрос, адресованный web-сайту bank.com, можно перенаправить на почтовый сервер, в котором используется общий с bank.com TLS-сертификат. Так как почтовый сервер не завершает сеанс после первой ошибки, служебные заголовки и команды, такие как "POST / HTTP/1.1" и "Host:", будут обработаны как неизвестные команды (почтовый сервер вернёт на каждый заголовок "500 unrecognized command"). Почтовый сервер не разбирает особенности протокола HTTP и для него служебные заголовки и блок данных POST-запроса обрабатываются одинаково, поэтому в теле POST-запроса можно указать строку с командой почтовому серверу. Например, можно передать: MAIL FROM: <script>alert(1);</script> на что почтовый сервер вернёт сообщение об ошибке 501 <script>alert(1);</script>: malformed address: alert(1);</script> may not follow <script> Этот ответ получит браузер пользователя, который выполнит JavaScript-код в контексте не изначально открытого сайта атакующего, а сайта bank.com, на который был отправлен запрос, так как ответ поступил внутри корректного TLS-сеанса, сертификат которого подтвердил подлинность ответа bank.com. Из браузеров подобная манипуляция сработает только в Internet Explorer и в старом Microsoft Edge (выпуски до перехода на движок Chromium), которые определяют наличие HTML/JavaScript в выдаваемом потоке, даже если ответ сервера не содержит корректного заголовка ("HTTP/1.1 200 OK"). Для того, чтобы заставить выполнить JavaScript в остальных браузерах необходимо обеспечить вывод корректного HTTP-ответа, например, это можно сделать при наличии доступа на запись на FTP-сервер при возможности вернуть содержимое сохранённого файла в ответ на запрос из браузера пользователя. 
Сканирование глобальной сети показало, что проблеме в общем виде подвержены около 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, exim, 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, FileZilla, crypto/tls (Go) и Internet Explorer. Opennet |