sarpantkeltiek/cve-2024-37010Эксплойт для CVE-2024-37010: доступ к внешнему хранилищу другого пользователя и латеральное перемещение
Эксплойт для CVE-2024-37010: доступ к внешнему хранилищу другого пользователя и латеральное перемещение:
https://www.cert.ssi.gouv.fr/avis/CERTFR-2024-AVI-0753/
https://owncloud.com/security-advisories/insecure-direct-object-reference-in-external-storage
Owncloud превращает сервер в облако для хранения файлов, подобно Google Drive. Это позволяет компаниям, например, предоставлять облако для сотрудников, не управляемое третьей стороной.
Если администраторы настроили это таким образом, пользователи также могут подключать внешние хранилища, такие как другие облака, FTP или Google Drive, чтобы централизовать файлы в едином облаке и тем самым упростить жизнь пользователям.
После создания внешнего хранилища мы можем обновить эту форму, чтобы изменить, например, поле "Имя папки". При обновлении формы отправляется запрос со всей формой в формате JSON. В этой форме поле 'ID', являющееся целым числом, является идентификатором нашего внешнего хранилища, сгенерированным сервером при создании хранилища.
Представим, что другой пользователь Owncloud, например администратор, также имеет внешнее хранилище с ID "18".
Теперь давайте повторно выполним запрос на обновление формы от имени пользователя "normal_user", не имеющего особых прав, но изменим ID на 18 — ID внешнего хранилища администратора.
![[images/req.png]](images/req.png)
После отправки запроса сервер возвращает ошибку 404 (4) и сообщает, что не нашел хранилища с указанным ID (5).
Однако, когда мы заходим в учетную запись администратора, мы видим следующее:
![[pwned_article.png]](images/pwned_article.png)
Хранилище администратора было обновлено.
Если мы снова войдем как "normal_user", мы увидим, что теперь у нас есть доступ к "storage_pwned" — хранилищу администратора.
![[access.png]](images/access.png)
Пользователь A смог обновить хранилище пользователя B и получить к нему права доступа. Напоминаем, что пользователь A НЕ ДОЛЖЕН изменять хост при запросе на обновление, чтобы не нарушить конфигурацию пользователя B и затем иметь доступ к его файлам.
Вот код, используемый для обновления внешнего хранилища.
![[Pasted image 20241016114714.png]](images/2.png)
Прежде всего, мы видим, что отсутствует проверка прав пользователя, выполнившего запрос. Код не проверяет, принадлежит ли хранилище пользователю, выполняющему запрос. Это объясняет, почему "normal_user" смог обновить хранилище администратора.
Во-вторых, мы видим, что при каждом обновлении код добавляет пользователя, выполнившего запрос, в список авторизованных для подключения к хранилищу, что объясняет, почему "normal_user" магическим образом получил доступ к хранилищу администратора после обновления.
В этом примере мы увидели, как один пользователь может получить полный доступ к внешнему хранилищу другого пользователя и, таким образом, получить доступ к его личным файлам. Это уже делает уязвимость весьма критической.
На этом этапе, как вы видите, эта IDOR (Insecure Direct Object Reference) уже является серьезной уязвимостью. Но давайте попробуем продолжить ее эксплуатацию, чтобы увеличить потенциальное воздействие.
Для этого давайте разберемся в процессе аутентификации, выполняемом сервером Owncloud для внешних хранилищ при получении файлов. Для систем базовой аутентификации с использованием простой пары логин/пароль облачный сервер просто ...
![[Pasted image 20241017162909.png]](images/20241017162909.png)
Теперь представим, что злоумышленник может обновить эту конфигурацию, изменив хост на адрес, который он контролирует. Это означает, что сервер Owncloud теперь будет отправлять учетные данные на этот новый адрес, контролируемый злоумышленником.
![[Pasted image 20241017163143.png]](images/20241017163143.png)
Именно это мы и можем сделать благодаря нашей уязвимости.
Когда мы повторяем запрос на обновление, указав ID хранилища другого пользователя, нам просто нужно изменить хост, указав, например, наш Burp collaborator.
![[Pasted image 20241017163326.png]](images/20241017163326.png)
Таким образом, при повторном подключении пользователя сервер Owncloud пытается аутентифицироваться на нашем collaborator, отправляя ему учетные данные пользователя.
![[Pasted image 20241017163644.png]](images/20241017163644.png)
Магическим образом collaborator получает запрос аутентификации от сервера Owncloud с учетными данными, закодированными в Base64.
![[Pasted image 20241017163945.png]](images/20241017163945.png)
Таким образом, мы только что получили учетные данные в открытом виде из внешнего хранилища администратора.
Для аутентификации во внешнем хранилище можно использовать собственные учетные данные Owncloud для входа, если, например, используется тот же пароль. При запросе на обновление внешнего хранилища можно указать "password::sessioncredentials" в поле "authMechanism".
Затем сервер Owncloud сохранит наши учетные данные в открытом виде при следующем подключении и передаст их на наше устройство внешнего хранилища для аутентификации.
Итак, вы понимаете, к чему это ведет...
Это означает, что злоумышленник также может активировать этот механизм для внешнего хранилища другого пользователя и таким образом передать учетные данные сессии Owncloud жертвы в открытом виде на контролируемый им хост, как мы только что сделали.
CVE-2024-37010, таким образом, позволяет злоумышленнику с учетной записью на сервере Owncloud:
