mcorybillington/suitecrm-rceРазбор уязвимости CVE-2020-28328: удаленное выполнение кода через файл журнала SuiteCRM и дополнительный межсайтовый скриптинг
Я недавно обнаружил две уязвимости в SuiteCRM, которые предоставляют цепочку атак для пользователя с низкими привилегиями для выполнения кода на базовой операционной системе. Цепочка атак включает межсайтовый скриптинг (XSS), который можно использовать для подделки межсайтовых запросов (CSRF), что приводит к удаленному выполнению кода путем изменения конфигурации приложения и отравления файла журнала. Все это достигается загрузкой файла, содержащего вредоносный JavaScript, который пользователь с низкими привилегиями может обманом заставить выполнить пользователя с правами администратора. Прилагаемые файлы Proof-Of-Concept и видео демонстрируют, как пользователь с низкими привилегиями выполняет эту атаку и получает обратную оболочку на системе, на которой размещен SuiteCRM.
Это было исправлено в версии 7.11.17 SuiteCRM.
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Я не полностью согласен с этой оценкой, поскольку эксплойт требует административного доступа, что изменило бы PR:L на PR:H, скорректировав итоговый балл с 8.8 до 7.2.
Я бы оценил это как: CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H
Ссылка: https://nvd.nist.gov/vuln/detail/CVE-2020-28328
SuiteCRM версия 7.11.15
Постоянный межсайтовый скриптинг существует в загрузке файлов 'Create Documents'. Пользователь с низкими привилегиями может загрузить файл с любым содержимым. Затем пользователь может просмотреть ссылку, предоставленную для загрузки этого документа, и определить местоположение файла в файловой системе по параметру id. Это длинное случайное значение является именем файла внутри каталога /uploads/. Пользователь может поместить произвольный JavaScript в этот файл, а затем отправить ссылку другому пользователю. Это может быть использовано для перехвата сессии другого пользователя и/или выполнения действий от его имени, что будет показано в PoC-видео.
После того как я обнаружил, что могу стать администратором через перехват сессии с помощью межсайтового скриптинга, я выяснил, что могу управлять системными свойствами в разделе 'Admin → System Settings', а именно свойством файла журнала. Расширения файлов журнала были хорошо заблокированы, но я смог использовать BurpSuite, чтобы изменить значение 'Log File Name' на любое произвольное значение, включая расширения .php. Я сделал это, отправив запрос без изменений и перехватив POST-запрос, который фактически обновляет значения. Я изменил имя файла через параметр logger_file_name на shell.php и просто сделал поле 'Extension' пустым. Это дало php-файл, к которому я мог получить доступ в браузере в корне веб-сервера, но мне нужно было поместить немного php-кода внутрь файла для выполнения.
Затем я исследовал вывод в файл и заметил, что могу контролировать ввод в файл через свойства пользователя, если обновлю пользователя (например, имя или фамилию), при условии что журналирование установлено на info (кажется, это значение по умолчанию...). Итак, я перехватил запрос в Burp и вставил некоторый php-код <?php $id =`id`; echo $id; ?> в поле формы last_name. Это привело к выводу команды id в Linux в контексте пользователя веб-сервера www-data. Единственные символы, которые, как я могу сказать, экранируются в файле журнала - это одинарные кавычки, двойные кавычки и обратные слеши. Вы можете проверить это с помощью tail'ирования файла sql-журнала на бэкенде.
Я смог выполнить все это от имени администратора, потому что смог получить куки сессии. Однако для рабочей цепочки мне нужно было, чтобы это выполнялось через JavaScript в контексте администратора. Я смог запрограммировать это с помощью нескольких fetch-запросов для выполнения каждого из этих POST-запросов. Первый обновил системные свойства, второй обновил поле 'Last Name' администратора, а последний выполнил GET-запрос к вновь созданному файлу журнала с вредоносным php-кодом. Вредоносный php-код выполнял curl-запрос к моей машине, загружал bash-обратную оболочку и затем передавал вывод этого curl-запроса напрямую в bash, выполняя код. Затем я загрузил это с помощью того же метода, который описал в разделе XSS, и заново перешел по новой ссылке как администратор. С запущенным веб-сервером, размещающим мой bash-файл, и работающим netcat-слушателем, я смог получить обратную оболочку.
Убедитесь, что в Apache установлено AllowOveride All. В nginx такого параметра нет, и я не тестировал его на nginx.
Обновитесь до последней версии SuiteCRM или хотя бы до версии 7.11.17.
Это конкретное исправление. Коммит 1618af16eaa494c4551bac961e5ac8fc3d87ab8c
SuiteCRM был очень отзывчивым на протяжении всего процесса отчетности. Они подтвердили RCE, которое было исправлено. XSS был результатом конфигурации веб-сервера, поэтому они не признали его уязвимостью. Однако они отметили, что обновят документацию в связи с этим.
06 АВГ 2020 -> Обе проблемы сообщены на [email protected]
07 АВГ 2020 <- SuiteCRM подтверждает получение отчета и поднимает вопрос перед внутренней командой безопасности
21 АВГ 2020 -> Я связался с [email protected] для последующего уведомления
25 АВГ 2020 <- SuiteCRM отвечает относительно конфигурации веб-сервера/XSS
26 АВГ 2020 -> Я отвечаю, что предложение AllowOveride All смягчает XSS
16 СЕН 2020 -> Я связался с [email protected] для последующего уведомления
17 СЕН 2020 <- SuiteCRM отвечает, чтобы подтвердить проблему как частичную
29 ОКТ 2020 Выпущено обновление
03 НОЯ 2020 -> Я связываюсь с [email protected], чтобы убедиться, что с их стороны больше ничего не требуется перед публикацией статьи
05 НОЯ 2020 <- SuiteCRM отвечает
Теперь мы выпустили патч для этой проблемы, и она находится в публичном доступе, с нашей стороны нет проблем, если вы напишете блог-пост об уязвимостях.
05 НОЯ 2020 -> CVE запрошен мной
06 НОЯ 2020 <- CVE-2020-28328 выдан
https://www.exploit-db.com/exploits/49001
С ними было очень легко работать, и я определенно планирую продолжать искать и сообщать об уязвимостях в этом программном обеспечении!
