Группа исследователей из нескольких университетов Германии разработала новый метод 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.
Источник статьи: https://www.opennet.ru/opennews/art.shtml?num=55307
Суть атаки в том, что при наличии контроля над сетевым шлюзом или точкой беспроводного доступа атакующий может перенаправить web-трафик на другой сетевой порт и организовать установку соединения с FTP или почтовым сервером, поддерживающими TLS-шифрование и использующими общий с HTTP-сервером TLS-сертификат, и браузер пользователя будет считать, что установлено соединение с запрошенным HTTP-сервером. Так как протокол TLS универсален и не привязан к протоколам прикладного уровня, установка шифрованного соединения для всех сервисов идентична и ошибка отправки запроса не к тому сервису может быть определена только уже после установки шифрованного сеанса во время обработки команд отправленного запроса.
Соответственно, если, например, перенаправить соединение пользователя, изначально адресованное к HTTPS, на почтовый сервер, в котором применяется общий с HTTPS-сервером сертификат, TLS-соединение будет успешно установлено, но почтовый сервер не сможет обработать переданные HTTP-команды и вернёт ответ с кодом ошибки. Данный ответ будет обработан браузером как ответ запрошенного сайта, переданный внутри корректно установленного шифрованного канала связи.
Предложено три варианта атаки:
- "Upload" для извлечения Cookie с параметрами аутентификации. Метод применим, если охватываемый TLS-сертификатом FTP-сервер позволяет загрузить и извлечь свои данные. В данном варианте атаки атакующий может добиться сохранения частей изначального HTTP-запроса пользователя, таких как содержимое заголовка Cookie, например, если FTP-сервер интерпретирует запрос как файл для сохранения или полностью журналирует входящие запросы. Для успешной атаки злоумышленнику требуется затем каким-то образом извлечь сохранённое содержимое. Атака применима к Proftpd, Microsoft IIS, vsftpd, filezilla и serv-u.
- "Download" для организации межсайтового скриптинга (XSS). Метод подразумевает, что атакующий в результате каких-то отдельных манипуляций может разместить данные в сервисе, использующем общий TLS-сертификат, которые затем можно выдать в ответ на запрос пользователя. Атака затрагивает вышеотмеченные FTP-серверы и IMAP/POP3-серверы (courier, cyrus, kerio-connect и zimbra). Например, подобный вариант атаки может быть применим к почтовым сервисам, предоставляющим доступ к сообщениям через web-интерфейс и через POP3/IMAP поверх TLS.
- "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: <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.
Источник статьи: https://www.opennet.ru/opennews/art.shtml?num=55307