m3m0o/portabilis-ieducar-user-type-privilege-escalationДоказательство концепции эксплуатации уязвимости, описанной в CVE-2025-11554, которая касается возможности повышения привилегий через произвольные запросы к конечной точке изменения типов пользователей в программном обеспечении i-Educar.
Доказательство концепции эксплуатации уязвимости, описанной в CVE-2025-11554, которая касается возможности повышения привилегий при произвольных запросах к конечным точкам типов пользователей в программном обеспечении i-Educar.
Пользователи, не имеющие необходимых привилегий для изменения типов пользователей, могут изменять права зарегистрированных типов пользователей через произвольный запрос к конечной точке, отвечающей за это действие. Это позволяет пользователям с низкими привилегиями повышать свои привилегии, предоставляя максимальные права типу пользователя, с которым они связаны, что ставит под угрозу все разделы приложения.
Чтобы продемонстрировать уязвимость, мы смоделируем путь атаки, который можно использовать в реальном сценарии эксплуатации. Во-первых, у нас есть пользователь Usuário sem Privilégios, который связан с типом пользователя Baixíssimo.
Тип пользователя Baixíssimo не имеет связанных привилегий и ему назначен самый низкий уровень доступа — Biblioteca, который имеет уровень 8.
Для целей данной демонстрации мы видим, что права на редактирование типов пользователей отключены для этой роли, что означает, что пользователи, связанные с ней, не должны иметь возможности просматривать, создавать/редактировать или удалять типы пользователей.
При входе в систему под именем Usuário sem Privilégios мы можем подтвердить, что никакие права не назначены, поскольку ему недоступны никакие разделы.
Первым шагом в процессе повышения привилегий является определение типа пользователя, назначенного пользователю. В различных ответах на запросы, возвращающих отрисованные HTML-документы из приложения, эту информацию можно найти в переменной dataLayer, расположенной внутри первого элемента script документа. Мы можем проверить эту информацию, обратившись, например, к домашней странице приложения. В этой демонстрации для анализа и манипуляции запросами будет использоваться Burp Suite.
После определения типа пользователя, связанного с текущим пользователем, следующим шагом является определение его идентификатора, хранящегося в базе данных. Для этого следует использовать конечную точку /usuarios/tipos/<cod_tipo_usuario>. Поскольку идентификаторы типов пользователей являются числовыми и последовательными, можно перечислить все сохранённые типы пользователей, пока не будет найден тот, который связан с текущим пользователем.
Тип пользователя с идентификатором 1, например, по умолчанию является административным типом пользователя — Administrador.
В ответе приложения мы можем увидеть права, связанные с типом пользователя, в объекте processes. Каждый конкретный раздел идентифицируется уникальным числовым идентификатором, а уровень доступа типа пользователя к этому разделу определяется числами 0, 1, 2 или 3:
Мы можем наблюдать, что административный тип пользователя имеет уровень доступа 3 для всех разделов.
При запросе типа пользователя с идентификатором 2 мы видим, что он соответствует типу пользователя, связанному с текущим пользователем. Этот тип пользователя имеет уровень доступа 0 для всех разделов.
Учитывая всё это, мы можем приступить к повышению привилегий. Для этого необходимо отправить POST-запрос на ту же конечную точку, содержащий идентификатор типа пользователя, соответствующий идентификатору типа пользователя, связанного с текущим пользователем. Тело запроса должно включать параметры _method, name, level, description и processes. Не все обязательные значения сразу понятны, но поскольку это проект с открытым исходным кодом, правильную структуру запроса можно легко обнаружить путём анализа кода или ручного тестирования на локальном экземпляре.
В приведённом ниже запросе мы изменяем уровень доступа для всех разделов на максимальный (3) и меняем тип пользователя с Biblioteca на Poli-institucional (параметр level установлен в значение 1). Это означает, что пользователь получит доступ ко всем зарегистрированным учреждениям, а не только к тому, с которым он был связан при создании.
После этого при перезагрузке домашней страницы мы можем подтвердить, что ранее не имевший привилегий пользователь теперь обладает всеми доступными привилегиями в контексте приложения, предоставленными произвольно.
Маршруты для уязвимых конечных точек можно найти в файле routes/web.php.
Уязвимые методы, используемые этими маршрутами, можно найти в файле app/Http/Controllers/AccessLevelController.php. Эти методы не выполняют проверку прав запрашивающего пользователя перед выполнением запрошенных действий над типами пользователей.
Это программное обеспечение используется в качестве решения для управления школами в различных государственных учреждениях. Каждый экземпляр потенциально содержит различные виды конфиденциальной информации о зарегистрированных пользователях и учениках, такие как удостоверяющие личность документы и медицинские записи (состояния здоровья). В сценарии, где злоумышленник с низкими привилегиями или учётная запись, контролируемая атакующим, эксплуатирует эту уязвимость, конфиденциальность, целостность и доступность этих записей окажутся под угрозой. Быстрая оценка безопасности проекта выявила бы эту слабость.
