Критическая уязвимость кода сайта. Максимальный уровень угрозы.
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 (удаленное выполнение кода на сервере)
Сканер уязвимостей сайтов онлайн Проверьте, наколько устойчив к взлому Ваш сайт
Разбор: как мы нашли 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
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 уязвимостей, позволяющих выполнить произвольный код в системе:
CVE-2020-0796: новая уязвимость в SMB-протоколе
Компания Microsoft выпустила патч для критической уязвимости CVE-2020-0796 в сетевом протоколе SMB 3.1.1.
Обновлено 12 марта.
В сети появилась информация об RCE-уязвимости CVE-2020-0796 в операционных системах Windows 10 и Windows Server, затрагивающей протокол Microsoft Server Message Block 3.1.1 (SMBv3). По информации компании Microsoft, потенциальный атакующий может использовать эту уязвимость для того, чтобы исполнить произвольный код на стороне SMB-сервера или SMB-клиента. Однако если для атаки на сервер достаточно послать на него специально созданный пакет, то для атаки на клиент злоумышленникам придется сконфигурировать вредоносный SMBv3-сервер и как-то убедить пользоваться подключиться к нему.
Специалисты по информационной безопасности считают, что данная уязвимость может быть использована для запуска червя, аналогичного WannaCry. Microsoft присваивает уязвимости критический рейтинг, то есть озаботиться ее закрытием стоит максимально срочно.
Для кого опасна CVE-2020-0796?
SMB — сетевой протокол для удалённого доступа к файлам, принтерам и прочим сетевым ресурсам. Он используется для реализации «Сети Microsoft Windows» и «Совместного использования файлов и принтеров». Если в вашей компании эти функции используются — это повод побеспокоиться.
Поскольку Microsoft Server Message Block 3.1.1 — сравнительно свежий протокол, он используется только в новых операционных системах:
То есть Windows 7, 8, 8.1 и более старые уязвимость не затрагивает. Однако поскольку большинство современных компьютеров работает под управлением Windows 10 с автоматической установкой обновлений, то, вероятно, уязвимости подвержено очень много компьютеров по всему миру – как домашних, так и корпоративных.
Эксплуатируют ли CVE-2020-0796 злоумышленники?
По данным Microsoft, уязвимость CVE-2020-0796 пока что не используется для атак – по крайней мере, таких атак пока никто не наблюдал.
Но проблема в том, что информация об уязвимости находится в общем доступе с 10 марта, так что эксплойты могут появиться с минуты на минуту, если еще не появились.
Что делать?
Обновление от 12 марта: компания Microsoft выпустила обновление безопасности, которое должно закрыть эту уязвимость. Скачать патч можно вот здесь.
Пока патча не существовало, приходилось использовать обходные пути. Компания Microsoft предлагала временное решение, блокирующее возможность эксплуатации этой уязвимости.
Для SMB-сервера:
Для SMB-клиентов:
Также обязательно используйте надежное защитное решение, например такое, как Kaspersky Endpoint Security для бизнеса. Помимо прочих технологий, в нем работает подсистема Exploit Prevention, которая поможет защититься даже от неизвестных уязвимостей.
Что такое удаленное выполнение кода. Уроки хакинга — глава 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 и следите за ПО, которое используется сайтами и которое может быть устаревшим, т.к. скорее всего оно может быть уязвимым.
