remote code execution что это

RCE в Android-приложениях через сторонние сервисы

Совсем недавно компания MWR опубликовала интересную запись «WebView addJavascriptInterface Remote Code Execution» в своем блоге. Запись касается безопасности мобильных приложений. Не хочется полностью пересказывать исследование наших английских коллег — советуем обратиться к первоисточнику. Но если коротко, то при использовании сторонней библиотеки в своем мобильном приложении под Android можно легко поймать RCE (remote code execution) атаку. Произвольное выполнение кода в Android-приложении возможно благодаря рефлексии Java-объекта, который вставляется в WebView.

Итак, для того чтобы данный вектор работал:

1) Во-первых, код должен быть собран с помощью SDK старше 17 версии.
2) Во-вторых, в приложении должно быть разрешено выполнение JavaScript-кода. То есть должен присутствовать метод setJavaScriptEnabled() с параметром true – по умолчанию он отключен.
3) В-третьих, должна использоваться функция addJavascriptInterface().
4) В-четвертых, при получении данных с сервера должен отсутствовать или некорректно использоваться HTTPS.

Вроде бы много условий, но, как показывает наша практика, все это очень часто встречается, особенно в каких-нибудь сторонних фреймворках.
Уже с начала года в наших презентациях и исследованиях безопасности мобильного банкинга говорится, что при разработке таких критичных приложений стоит руководствоваться принципом использования только нужных библиотек. Ведь в системы ДБО никто не интегрирует взаимодействие с новостями, соцсетями и другими сервисами, нужно избегать этого и в мобильном банкинге.

В российских приложениях для мобильного банкинга под Android мы видели взаимодействие с большим количеством сторонних сервисов, что повышает риск компрометации приложения при неправильном использовании. Очень часто встречается взаимодействие с новостным сервером банка, и очень часто это взаимодействие идет по HTTP. Все это значительно расширяет область атаки (attack surface) на банковское приложение.

Атака:

1) Производим MitM.
2) Инъектим в трафик вредоносный JavaScript-код, который вызывает метод Java-объекта getClass(). Например:

Можно представить вариант атаки и без MitM: например, через взлом сайта и вставку своего JavaScript-кода или через хранимую XSS на сайте. В общем, возможно и такое развитие ситуации.

А тем временем Joshua J. Drake, один из самых активных контрибьюторов Metasploit, уже написал специально под это дело модуль add_js_interface_mitm. Модуль пока не доступен и проходит бета-тестирование. На картинке – успешная атака на Fruit Ninja, использующую уязвимый MoPub.

Возможные последствия для пользователя:

1) Полная компрометация данных уязвимого приложения. Если устройство не рутовано, то наш код будет выполняться в рамках sandbox уязвимого Android-приложения, то есть делать все, что может делать это приложение.
2) Полная компрометация мобильного устройства (всех данных на телефоне). Если устройство рутовано или имеет уязвимую версию Android, то наш код может провести LPE (Local Privilege Escalation) атаку и уже работать от пользователя root. Делаем на устройстве все что хотим.

1) Отказаться от вызова Java-объекта из JavaScript, если в этом нет необходимости.
2) Использовать SDK младше 17 версии – для этого необходимо добавить аннотацию @JavaScriptInterface, так как все методы Java-объекта, начиная с версии 17, по умолчанию недоступны.
3) Вместо addJavaScriptInterface использовать другой способ вызова Java-методов через создание своей URI-схемы и использование метода shouldOverrideUrlLoading. При этом следует применить валидацию входящих данных и кодирование исходящих данных для предотвращения инъекции.

Источник

Удалённое выполнение кода в InterSystems Caché (RCE)

Введение

В том случае, если вы управляете более чем одним сервером Caché может возникнуть задача выполнения произвольного кода из одного сервера Caché на другом. Кроме того, может потребоваться выполнение произвольного кода на удалённом сервере Caché, например, для нужд сисадмина… Для решения этих задач была разработана утилита RCE.

Какие вообще есть варианты решения подобных задач, и что предлагает RCE (Remote Code Execution) – под катом.

Что уже есть?

» Локальные команды ОС

» Удалённое выполнение COS кода

Возможно с помощью класса %Net.RemoteConnection, где доступна следующая функциональность:

В данном коде происходит:

Отдельно следует упомянуть о технологии ECP, о которой писали на Хабре, и которая позволяет вызывать удаленные JOB процессы со стороны сервера приложений на сервере БД.

В результате, комбинируя два предложенных выше подхода, в принципе, возможно достижение поставленной в начале этой статьи цели, однако, мне хотелось достичь простого процесса создания нового выполняемого скрипта пользователем, что представляется затруднительным при использовании существующих подходов.

Таким образом, перед проектом были поставлены следующие цели:

Иерархия Машина – ОС – Инстанс служит для хранения информации, необходимой для доступа к удалённым серверам.
Для хранения команд служит класс RCE.Script, который содержит последовательный список – объектов класса RCE.Command, которые могут быть как командами ОС так и COS кодом.

Первый аргумент – текст команды, второй – уровень выполнения: 0 – ОС, 1 – Cache.

Пример создания нового скрипта:

Здесь на уровне ОС будут выполнены 1-я и 4-я команда, а 2-я и 3-я будут выполнены в Caché, причём процесс переключения уровня выполнения абсолютно прозрачен для пользователя.

» Механизмы выполнения

Сейчас поддерживаются следующие пути исполнения:

В том случае, если есть поддержка ssh на клиенте, сервер генерирует ssh команду и выполняет её на клиенте с помощью стандартного класса %Net.SSH.Session.

В случае же, если и сервер и клиент – под управлением ОС Windows, происходит генерация bat-файла, который потом отправляется на клиент и выполняется с помощью утилиты psexec.

» Добавление сервера

Загрузите классы из репозитория в любую область. В случае, если у вас Windows сервер и вы хотите управлять другими Windows серверами, установите значение глобала ^settings(«exec») равное пути к утилите psexec. На этом настройка завершена!

» Добавление клиента

Состоит в сохранении всех необходимых для аутентификации данных.

» Выполнение скрипта

Выводы

RCE предоставляет удобный механизм удалённого выполнения кода из InterSystems Caché. Так как скрипты хранимые, вам необходимо написать скрипт только один раз, потом он может выполнятся когда угодно и на любом числе клиентов.

Источник

Разбор: как мы нашли 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

Источник

Критическая уязвимость кода сайта. Максимальный уровень угрозы.

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 (удаленное выполнение кода на сервере)

Сканер уязвимостей сайтов онлайн Проверьте, наколько устойчив к взлому Ваш сайт

Источник

Что такое удаленное выполнение кода. Уроки хакинга — глава 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 и следите за ПО, которое используется сайтами и которое может быть устаревшим, т.к. скорее всего оно может быть уязвимым.

Источник