Захватываем полный контроль над чужим облаком Digital Ocean
Как и многие хабрапользователи, я пользуюсь «облачными» технологиями, в т.ч. арендую VPS (виртуальные сервера) в разных странах мира. Порядка двух лет я пользовался Амазоном и не сказать, чтобы был доволен, но хватало.В сентябре прошлого года я наткнулся на очень агрессивную PR компанию от Digital Ocean (DO) и решил воспользоваться их услугами. С того момента я забросил Амазон (ни разу не реклама) и полностью перешел на DO.
И чем больше пользуешься каким-либо сервисом и чем больше доверяешь ему своих данных, тем более пристально смотришь как он работает :)
Веб DO написан на RoR, также повсеместно используется GO/Perl, БД — MariaDB / PostgreSQL (весьма странно что оба вместе в одном продукте, ну да ладно). И из нескольких security-репортов хотелось бы выделить один, уже исправленный, с самой простейшей багой и самым большим импактом — захват контроля над чужим аккаунтом.
Как-то давно я писал статью про безопасность API и что смотреть уязвимости лучше именно там. Осмотрев свой аккаунт и функционал заметил — что здесь он как раз есть. Можно создавать «developer applications».
Окно создания приложения
Почитав документы — developers.digitalocean.com/, изучив запуск новой версии API понял, что могу создать приложение, после на него мне дается ссылка вида — cloud.digitalocean.com/v1/oauth/authorize? client_id=34fc7d56883b7e33b2f305642acb5ec6e5a14271ba83084dc6a0ca2b22d29555&redirect_uri=https%3A%2F%2Fsergeybelove.ru%2Fexploits%2F&response_type=code
Пример запроса доступа к аккаунту
В url можно задать параметр scope. Вместо типичного решения разделения прав по модулям (например, как в соц. сетях — доступ к друзьям, фотоальбомам и т.п.) ребята из DO решили сделать по-другому, можно запросить доступные операции — read|write (без явного указания параметра выставляется только read), при этом выдавая доступ сразу ко всем модулям. Далеко не лучшее решение.
Если юзер нажмет на «Authorize Application» его автоматически перекинет по callback url с специальным токеном. Этот токен можно использовать уже на своей стороне (разработчика) для запроса следующего токена, который нужен непосредственно для вызовов самих методов API (информация об аккаунте, управление дроплетами и т.п.).Вся их ошибка сводилась к тому, что можно провести CSRF атаку на установку приложения (создать на своей стороне форму, идентичную запросу выше на картинке, поменять action формы на DO и выполнить submit). CSRF токен они используют, но не проверяют на серверной стороне.
Как итог, мы просто размещаем где-либо нужный html/js код, помещаем его в скрытый фрейм и, незаметно для пользователя, устанавливаем ему свое «злобное» приложение, попутно отлавливая access_token, который юзер передаст по callback_url на наш сервер.
Для наглядности приведу свой PoC. При посещении кода с такой страницей — устанавливалось приложение, отлавливался access_token, запрашивался следующий и выводились некоторые данные аккаунта