В составе BIG-IP есть разные модули, которые работают под управлением операционной системы TMOS. Один из них — Local Traffic Manager (LTM) — обрабатывает трафик приложений, обеспечивает безопасность сетевой инфраструктуры и локальную балансировку нагрузки. LTM можно гибко настраивать, в том числе при помощи веб-интерфейса TMUI (Traffic Management User Interface). В нем и нашли уязвимость.

Точнее, нашел Михаил Ключников из Positive Technologies. Баг существует из-за некорректной нормализации URI при обработке запросов. Злоумышленник может обойти аутентификацию в Traffic Management User Interface и использовать функции системы, которые предназначены только для администратора. В результате этого атакующий может выполнять произвольные команды на целевой системе от суперпользователя, а это означает полную компрометацию сервера.

Баг получил номер CVE-2020-5902 и 10 из 10 баллов критичности по CVSS. Уязвимость присутствует в BIG-IP версий с 15.0.0 по 15.1.0.3, с 14.1.0 по 14.1.2.5, 13.1.0–13.1.3.3, 12.1.0–12.1.5.1 и 11.6.1–11.6.5.1.

Тестовый стенд

Так как продукт коммерческий, простого докер-контейнера в этот раз не будет. Самый легкий способ поднять стенд — это скачать тридцатидневную пробную версию BIG-IP VE (Virtual Edition). Для этого нужен аккаунт, который можно создать на сайте F5. После подтверждения можно будет переходить в раздел загрузок.

Нам нужна последняя уязвимая версия, это — 15.1.0.3. BIG-IP распространяется в нескольких вариантах, нас интересует образ виртуальной машины в формате OVA. Перед загрузкой предложат выбрать удобное зеркало.

Также можешь попробовать воспользоваться моей ссылкой для скачивания образа. Не могу сказать, сколько она проживет, но пока отлично работает.

После этого импортируем скачанный образ в свою программу виртуализации. Я буду использовать VMware, но и VirtualBox отлично с этим справится.

После успешного импорта загружаем виртуалку. Через некоторое время видим приглашение для авторизации.

По дефолту пароль для суперпользователя — default (тебе сразу предложат его сменить). Теперь можно посмотреть IP-адрес виртуалки.

Открываем браузер и переходим на этот IP. Видим форму авторизации Traffic Management User Interface.

Стенд готов.

Детали уязвимости

Вернемся в консоль. Посмотрим, что за веб-сервер слушает 443-й порт.

netstat -lnpe | grep 443

Это обычный демон httpd, РЅРѕ очевидно, что РѕРЅ используется просто как фронтенд для проксирования запросов РєСѓРґР°-то дальше. Поищем среди конфигурационных файлов директивы ProxyPass.

grep -iR ProxyPass /etc/httpd

Нашлось много интересного в файле /etc/httpd/conf.d/proxy_ajp.conf.

/etc/httpd/conf.d/proxy_ajp.conf

...
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
...
[/code]

И название, и содержимое файла наводят на мысль, что запросы переправляются к веб-серверу Tomcat по протоколу AJP. О нем я уже писал в статье про уязвимость в Tomcat.

Но сейчас проблема не в этом. Нам нужно посмотреть на то, как передается URI к Tomcat. Здесь стоит обратиться к большому исследованию Оранжа Цая о нормализации путей в различных приложениях, которое он представил на Black Hat USA 2018 и DEF CON 26 (PDF). Там есть раздел о Tomcat, где конструкция /..;/ используется для выхода РёР· директории, РѕР±С…РѕРґР° некоторых правил Рё получения доступа Рє файлам СЃ важной информацией. Это возможно потому, что веб-сервер воспринимает конструкцию /..;/ как имя папки, а Tomcat интерпретирует его в качестве относительного пути — вверх по дереву в родительскую директорию.

Чтобы проверить, работает ли этот баг в нашем случае, попробуем прочитать какой-нибудь файл, доступ к которому в обычных условиях запрещен. Список таких можно посмотреть, например, в конфиге TMUI — /usr/local/www/tmui/WEB-INF/web.xml.

/usr/local/www/tmui/WEB-INF/web.xml

<servlet-mapping>
    <servlet-name>org.apache.jsp.dashboard.viewset_jsp</servlet-name>
    <url-pattern>/dashboard/viewset.jsp</url-pattern>
</servlet-mapping>

Попробуем его просмотреть простым запросом.

curl -k "https://192.168.31.140/tmui/dashboard/viewset.jsp" -is

В ответ получаем редирект на страницу авторизации. А теперь сделаем это при помощи конструкции /..;/.

curl -k "https://192.168.31.140/tmui/login.jsp/..;/dashboard/viewset.jsp" -is

Скрипт viewset.jsp отрабатывает успешно, Рё сервер возвращает результат.

Теперь мы можем читать любые страницы и выполнять сервлеты, которые не проверяют сессию пользователя внутри себя.

Давай посмотрим, что можно откопать РІ дебрях TMUI. Р’СЃРµ самое интересное лежит РІ директории /usr/local/www/tmui/WEB-INF/. Здесь же находятся и сами сервлеты, в откомпилированном виде. В связи с этим мне понадобится JD-GUI. Чтобы было проще, советую просто заархивировать директорию /usr/local/www/tmui/WEB-INF/ РІ формате ZIP Рё открыть РІ JD-GUI.

Рђ СЃРїРёСЃРѕРє эндпойнтов, как РјС‹ уже выяснили, можно найти РІ файле /usr/local/www/tmui/WEB-INF/web.xml. Их очень много, поэтому приведу здесь несколько наиболее интересных, которые были найдены после релиза уязвимости в паблик.

Теги: CSS