Поделиться
В ERP-системе JD Edwards Enterprise One закрыта уязвимость спустя 3 года с момента обнаружения
Компания Digital Security оказала содействие корпорации Oracle в устранении опасной уязвимости в ERP-системе JD Edwards Enterprise One — в части использования толстого клиента на рабочих станциях. Уязвимость была закрыта в январском обновлении от Oracle (CVE-2012-1678).
Как рассказали CNews в Digital Security, детали уязвимости были частично раскрыты ещё 2 года назад на конференции BlackHat в Вашингтоне, где Александр Поляков, технический директор Digital Security, рассматривал архитектурные проблемы разных бизнес-приложений. При этом сама уязвимость была обнаружена ещё годом ранее в рамках одного из проектов по аудиту защищённости ERP-системы JD Edwards.
Проблема заключается в том, что файл конфигураций JDE.INI, в котором, кроме всего прочего, хранятся аутентификационные данные пользователей для подключения к СУБД, зачастую присутствует на рабочих станциях пользователей, что позволяет любому легитимному пользователю при желании получить полный доступ к ERP-системе, пояснили в компании.
«По непонятным причинам Oracle занизила CVSS-рейтинг опасности данной уязвимости. В то время как для стандартных уязвимостей этот рейтинг показывает адекватные результаты, для некоторых нетипичных уязвимостей он оказывается не совсем точным. Учитывая, что разработчик может сжульничать, например, указав частичное влияние на КЦД вместо полного, критичной уязвимости в итоге присваивается рейтинг 3.5 (низкая критичность), — возмутился Александр Поляков. — В действительности же уязвимость, позволяющую любому пользователю ERP-системы получить доступ ко всем данным и присвоить себе любые права, сложно назвать низкой».
По информации Digital Security, процесс аутентификации в системе JD Edwards реализован следующим образом: пользователь вводит своё имя (например, appuser) и пароль (например, appassword) в клиентском приложении, после чего приложение пытается подключиться напрямую к СУБД JD Edwards, используя имя пользователя JDE (по умолчанию) и пароль для этого пользователя, который читается с конфигурационного файла клиентской рабочей станции JDE.INI (пароль хранится в поле “Security” и по умолчанию имеет значение JDE). Получив прямой доступ к СУБД, клиентское приложение проверяет пароль пользователя appuser в таблице F98OWSEC, и если пароль подходит, то отрисовывает интерфейс пользователя на основе его ролей из таблицы appusers.
По мнению специалистов Digital Security, такого рода аутентификация не выдерживает никакой критики, так как реализуется, по сути, на клиенте. «Если злоумышленник получил доступ к рабочей станции пользователя, сам является инсайдером или может перехватывать трафик между клиентом и сервером (например, в старых версиях MS SQL пароль элементарно расшифровывается при помощи утилиты Cain & Abel), то он получит аутентификационные данные пользователя JDE, который имеет административные права в СУБД. Дальнейшие его действия ограничены только фантазией», — подчеркнули в компании.
Поделиться
Короткая ссылка
