Rce уязвимость что это
Критическая уязвимость кода сайта. Максимальный уровень угрозы.
RCE (Remote code execution) является максимальной угрозой класса А1 по классификации OWASP
В нашей практике встречались случаи, когда RCE эксплуатировали боевые скрипты, размещенные на хакерских серверах, которые отслеживали наличие вредоносной составляющей, вирусов шеллов и т.п. на сайте. Когда программисты сайта пытались удалить вредоносные скрипты с своих сайтов, они появлялись заново, в течении секунд!
Фактически программисты атакуемых сайтов не успевали «отпустить клавишу» DELETE, как заражение сайта повторялось в удвоенном размере.
Обычным удалением вирусов троянов и шеллов в таком случае не обойтись. Первоначально нужно найти и устранить уязвимость в коде, позволяющую эксплуатировать RCE (Remote code execution).
Поступило обращение от одной организации с следующими проблемами:
1. Резко возросшая нагрузка на сервер, угрозы от хостера отключить сайт, из-за критической нагрузки на ЦП сервера.
2. На сайте кем-то создается форум (черная SEO) в десятки тысяч постов, рекламирующий сомнительные услуги, код которого обнаружить не удается.
То есть сам форум присутствует, индексируется поисковыми системами, в т.ч. Яндексом, а кода форума на сервере нет.
В процессе проведения аудита безопасности сайта, нашими специалистами была обнаружена уязвимость в коде сайта, позволяющая эксплуатировать RCE. С помощью RCE злоумышленники запускали свой хакерский форум (черная SEO) на атакуемом сайте, тем самым увеличивая нагрузку на сервер. Кроме этого поисковые системы оказались «заспамлены» сообщениями с этого форума, предложениями сомнительных услуг и товаров, что привело к репутационным и имиджевым, и соответственно финансовым потерям компании.
По результатам аудита безопасности сайта, были выявлены и устранены все уязвимости исследуемого сайта.
Проблемы с хакерскими атаками и взломами сайта для этой компании закончились.
Возможность эксплуатации RCE возникает из за грубейших ошибок разработки сайта, отсутствия фильтрации передающих параметров, использование небезопасных функций и приемов программирования.
Вызов скрипта:
http://vulnserver.com/ vuln.php?code=phpinfo();
Результат:
Выполнение PHP кода, а именно команды phpinfo();
Защита от RCE (удаленное выполнение кода на сервере)
Сканер уязвимостей сайтов онлайн Проверьте, наколько устойчив к взлому Ваш сайт
90 уязвимостей класса Remote Code Execution в майском «вторнике обновлений»
«Мир. Труд. Май» — это не только про приятную работу на даче, но и про установку обновлений, тем более что в этом месяце производители офисного программного обеспечения потрудились на славу и закрыли в сумме 162 уязвимости, из которых 90 позволяют выполнить произвольный код в системе.
Сразу 2 уязвимости, которые можно эксплуатировать удаленно, исправили в Windows. О самой опасной мы оповестили еще вчера вечером – уязвимость CVE-2019-070 в службе удаленного рабочего стола позволяет обладателю эксплойта выполнить код с правами SYSTEM. Рекомендуем как можно быстрее обновить все терминальные серверы, доступные извне. Также не забудьте обновить DHCP сервера от уязвимости CVE-2019-0725, так как ее тоже можно эксплуатировать удаленно.
Заслуживают внимания еще две уязвимости: CVE-2019-0863 и CVE-2019-0903. Первая позволяет повысить привилегии в системе, и экссплойт уже гуляет по сети. Вторая же находится в графическом компоненте Windows GDI и может быть эксплуатирована через разные векторы — как через браузер, так и с помощью файла, присланного, например, по почте.
Май принес нам еще четыре хардварных уязвимости спекулятивного исполнения в процессорах Intel, одна из которых уже имеет собственный сайт с красивым названием Zombieload. Рекомендации по противодействию такому типу уязвимостей стандартные: обновляйтесь и отключайте Hyper-Threading в процессоре. При этом проверить настройки спекулятивного исполнения можно с помощью этого Powershell-скрипта.
Кроме того, Microsoft и Adobe устранили еще 87 уязвимостей, позволяющих выполнить произвольный код в системе:
Разбор: как мы нашли RCE-уязвимость в контроллере доставки приложений F5 Big-IP
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»:
Содержимое файла /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 в конфигурационном файле:
Фрагмент конфигурационного файла /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, но теперь давайте попробуем найти что-нибудь более полезное:
Фрагмент файла /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 может заработать с такими дефолтными данными для логина:
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:
Пытаемся вызвать этот метод с произвольными данными:
Запрос: 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-запрос, если сервер уязвим:
И получим 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
Что такое удаленное выполнение кода. Уроки хакинга — глава 12.
Удаленное выполнение кода возникает из-за внедренного кода, который интерпретируется и выполняется уязвимым приложением. Причиной данной уязвимости является пользовательский ввод, который приложение использует без надлежащей фильтрации и обработки.
Это может выглядить следующим образом:
Здесь уязвимое приложение может использовать url index.php?page=1, однако, если пользователь введёт index.php?page=1;phpinfo(), приложение выполнит функцию phpinfo() и вернёт приложению её результат.
Также RCE иногда используется для обозначения Command Injection, которые OWASP различает. С помощью Command Injection, в соответствии с OWASP, уязвимое приложение выполняет произвольные команды в принимающей их операционной системе. Опять же, это становится возможным благодаря недостаточной обработке и проверки пользовательского ввода, что приводит к тому, что пользовательский ввод выпоняется операционной системой, как команда.
В PHP, к примеру, это может быть из-за того, что пользовательский ввод будет вставлен в функцию system().
Примеры удаленного выполнения кода.
1. Polyvore ImageMagick
Сложность: Высокая
Ссылка на отчёт: http://nahamsec.com/exploiting-imagemagick-on-yahoo/46
Дата отчёта: Май 5, 2016
Описание:
ImageMagick представляет собой программный пакет, обычно используемый для обработки изображений, например кадрирование, масштабирование, и так далее. Imagick в PHP, rmagick и paperclip в Ruby, а также imagemagick в NodeJS используют этот пакет, и в апреле 2016 в нем было обнаружено множество уязвимостей, одна из которых могла быть использована атакующими, чтобы выполнить удаленный код, на чём я и сосредоточился.
В двух словах, ImageMagick не фильтровал надлежащим образом получаемые имена файлов и в результате использовался для выполнения системного вызова system(). В итоге атакующий мог вставлять команды вроде https://example.com”|ls “-la, и при получении они были исполнены. Пример с ImageMagick будет выглядеть так:
Что интересно, ImageMagick определяет свой собственный синтаксис для файлов Magick Vector Graphics (MVG), а значит, атакующий мог создать файл exploit.mvg со следующим кодом:
Потом это будет передано библиотеке и, если сайт уязвим, код выполнится и отобразит перечень файлов в директории.
Зная это, Бен Садежепур протестировал купленный Yahoo сервис Polyvore на эту уязвимость. Как сказано в его блоге, Бен сначала протестировал уязвимость на локальной машине к которой он имел доступ, чтобы подтвердить, что mvg файл работает правильно. Вот код, который он использовал:
Здесь вы можете видеть, что он использовал библиотеку cURL, чтобы сделать обратиться к SOMEIPADDRESS (измените это на IP адрес уязвимого сервера). В случае успеха, вы должны получить следующий ответ:
Далее Бен посетил Polyvore, загрузил изображение в качестве аватара и получил следующий ответ от сервера:
Ben Sadeghipour Polyvore ImageMagick response
Выводы
Итоги
Удаленное выполнение кода, как и остальные уязвимости, возникает в результате неправильной фильтрации и обработки пользовательского ввода. В предоставленом примере ImageMagick неправильно обрабатывал контент, который мог быть зловредным. Это, вместе с знанием Бена о уязвимости, позволило ему найти и протестировать те зоны, которые могли быть уязвимыми. Что касается поиска подобных уязвимостей, быстрого ответа не существует. Будьте в курсе вышедших CVE и следите за ПО, которое используется сайтами и которое может быть устаревшим, т.к. скорее всего оно может быть уязвимым.
Кот-призрак. Как эксплуатировать новую RCE-уязвимость в веб-сервере Apache Tomcat
Содержание статьи
Tomcat — это контейнер сервлетов с открытым исходным кодом. Он написан на языке Java и реализует такие спецификации, как JavaServer Pages (JSP) и JavaServer Faces (JSF). Это один из наиболее популярных веб-серверов, особенно часто он используется в корпоративной среде. Его ставят как самостоятельное решение или в качестве контейнера сервлетов в различных серверах приложений, например GlassFish или JBoss.
Баг нашел исследователь из Chaitin Tech в начале этого года. Уязвимость получила статус критической. Как сейчас стало модно, она обзавелась собственным названием — Ghostcat — и логотипом в виде кота-призрака.
Тестовый стенд
Начнем со стенда для тестирования уязвимости. Для этого достаточно запустить контейнер Docker из официального репозитория Tomcat.
Очень важно расшарить порт 8009, это AJP-протокол, в котором и была найдена уязвимость.
Если хочется вместе со мной возиться с отладкой приложения, то нужно действовать немного по-другому. Для дебага я буду использовать IntelliJ IDEA. Сначала скачаем уязвимую версию Apache Tomcat. Я взял 9.0.30. Распакуем и откроем проект в IDEA. Теперь создадим новую конфигурацию отладки с шаблоном Remote.
Создание шаблона Remote в IDEA
Здесь в поле Command line arguments строка с параметрами, которые нужно указать при запуске сервера. Рекомендую выбрать версию JDK 1.4.x.
Конфигурация отладки. Аргументы для запуска Tomcat в режиме удаленной отладки
Запускаем контейнер. Не забывай пробрасывать порт, который указал для удаленной отладки.
Запущенный сервер Tomcat 9.0.30
После этого обновляем страницу и видим приветствие сервера Tomcat.
Приветственная страница стенда Tomcat
Tomcat работает, теперь дело за фронтендом, который поможет нам в исследовании AJP. Я создам еще один контейнер на основе Debian.
Понятно из названия, какой веб-сервер я буду использовать в качестве фронта, — Apache. Устанавливаем.
Я выбрал его, так как он проще в настройке прокси до Tomcat. Ты можешь использовать любой другой веб-сервер по желанию.
Включаем модуль для работы прокси с протоколом AJP.
Теперь редактируем стандартный конфиг виртуального хоста ( /etc/apache2/sites-enabled/000-default.conf ) и указываем адрес Tomcat.
И перезагружаем Apache.
Проксируем трафик через Apache к Tomcat по протоколу AJP
Помимо веб-сервера, нам также понадобится какой-нибудь сниффер. Я буду использовать Wireshark. На этом стенд готов. Кстати, если ты не любишь Docker, то есть вариант скачать с сайта разработчика версию с готовыми бинарниками. Все версии можно найти в разделе с архивами.
Теперь можно переходить к разбору уязвимости.
Детали уязвимости. Чтение произвольных файлов на сервере
Apache JServ Protocol (AJP) — это бинарный протокол, созданный ради избавления от избыточности HTTP. AJP гораздо более эффективен, обладает высокой производительностью благодаря значительной оптимизации и отлично масштабируется.
AJP обычно используется для балансировки нагрузки, когда один или несколько внешних веб-серверов (front-end) отправляют запросы на сервер (или серверы) приложений. Сессии направляются к нужному благодаря механизмам роута, где каждый сервер приложений получает свое имя.
В современных Tomcat используется AJP 1.3 (AJP13). Поскольку это двоичный протокол, браузер напрямую не может отправлять запросы AJP13. Поэтому в качестве фронтенда выступает любой популярный веб-сервер — nginx, Apache, IIS.
Вариант взаимодействия с сервером Tomcat через связку веб-сервер — AJP
По дефолту Tomcat принимает запросы AJP на порте 8009.
/tomcat9.0.30/conf/server.xml
Видим, что директива address отсутствует, поэтому AJP доступен на всех IPv4-адресах локальной машины.
По дефолту Tomcat слушает AJP-порт на всех адресах IPv4
Такая настройка крайне небезопасна, и сейчас ты поймешь почему.
Для начала нам нужно разобраться в формате пакетов AJP. Запустим Wireshark и сгенерируем любой легитимный запрос к серверу по AJP. В этом как раз поможет фронтенд в виде веб-сервера Apache.
Снифаем трафик от Apache к Tomcat по протоколу AJP13 через Wireshark
Следующие два байта — это размер тела пакета. Это обычное числовое значение типа integer. Далее идет байт, который в большинстве случаев указывает на тип сообщения. С него начинается подсчет длины тела пакета.
Существуют следующие типы сообщений от веб-сервера к Tomcat.
Типы пакетов к контейнеру Tomcat
Сразу привлекает внимание пакет с кодом 0x7 (Shutdown), который выключает сервер. Спешу тебя разочаровать — пакет такого плана обработается только в том случае, если он отправлен с хоста, на котором запущен Tomcat.
За кодом идет метод. Список соотношения базовых методов с их байт-кодами выглядит таким образом.
/tomcat9.0.30/java/org/apache/coyote/ajp/Constants.java
В пакете AJP используется метод GET
Далее все содержимое пакета довольно привычно и похоже на обычный HTTP-запрос. После параметра is_ssl начинается блок заголовков запроса ( request_headers ). Следующие два байта ( num_headers ) отвечают за общее количество заголовков в запросе. Следом за ним перечисляются сами хидеры. Каждый заголовок имеет следующий формат:
Коды для стандартных заголовков определены в коде.
Коды стандартных HTTP-заголовков в протоколе AJP
/tomcat9.0.30/java/org/apache/coyote/ajp/Constants.java
Некоторые заголовки крайне важны, например если content-length (0xA008) ненулевой, то Tomcat будет предполагать, что запрос имеет тело (как, например, POST-запрос), и попытается прочитать отдельный пакет.
За блоком хидеров следует блок атрибутов. Его использование опционально, но это самая важная часть для понимания уязвимости.
Существует несколько типов основных атрибутов, каждый из них имеет код, а структура идентична структуре хидеров.
/tomcat9.0.30/java/org/apache/coyote/ajp/Constants.java
Однако любое количество других атрибутов может быть передано и через тип req_attribute (0x0A). Пара имя:значение атрибута передается сразу же после указания этого кода. В этом случае структура примет следующий вид:
Например, так передаются переменные окружения. После перечисления необходимых атрибутов отправляется байт-терминатор (0xFF), который означает не только конец списка атрибутов, но и окончание всего пакета. Именно до него считается длина тела пакета.
Продолжение доступно только участникам
Вариант 1. Присоединись к сообществу «Xakep.ru», чтобы читать все материалы на сайте
Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», позволит скачивать выпуски в PDF, отключит рекламу на сайте и увеличит личную накопительную скидку! Подробнее
Вариант 2. Открой один материал
Заинтересовала статья, но нет возможности стать членом клуба «Xakep.ru»? Тогда этот вариант для тебя! Обрати внимание: этот способ подходит только для статей, опубликованных более двух месяцев назад.
Специалист по информационной безопасности в ONsec. Research, ethical hacking and Photoshop.