Twitter: перехват управления взглядами и мыслями

в 6:30, , рубрики: bugbounty, twitter, vulnerability, web security, безопасность, Блог компании «Digital Security», информационная безопасность, уязвимость, метки:

image

А что бы сделали вы, если бы могли публиковать записи в Twitter от имени
любого пользователя социально сети? Представили? Тогда прошу вас под кат за деталями.

Предисловие

В ходе исследования безопасности социальной сети Twitter в рамках BugBounty-программы мной была обнаружена уязвимость, которая позволяла злоумышленнику размещать записи в Твиттере от имени любого пользователя сервиса, не имея при этом доступ к аккаунту жертвы. Данная бага представляет особую опасность в связи с тем, что огромное количество как представителей СМИ, так и других известных личностей, имеет аккаунты в Твиттере и использует их для публикации различных новостей. А обнаруженная проблема безопасности позволяет разместить заведомо ложную информацию не в одном, а сразу в нескольких крупных аккаунтах (например, новостных изданий), и публика с большой долей вероятности поверит в неё. Имеются реальные примеры, когда с помощью дезинформации злоумышленники серьёзно влияли на цену акций определённых компаний ради собственной выгоды. Подробнее о таких прецедентах можно прочитать тут: (https://habrahabr.ru/company/itinvest/blog/270487/).
Данная уязвимость была обнаружена 26 февраля 2017 года и исправлена 28 февраля 2017 года.

Перейдём к техническим подробностям уязвимости.

Введение

В Твиттере есть такой сервис, как ads.twitter.com, в нем расположена медиа-библиотека с возможностью загружать медиа-файлы (видео, картинки, gif-ки), а также смотреть ранее загруженные медиа-файлы, которые были использованы при публикации твита. Библиотека доступна по ссылке вида: ads.twitter.com/accounts/ид_вашего_аккаунта/media. Теперь к делу.

Осматриваемся

Перейдя в библиотеку, мы видим функцию загрузки медиа-файлов:

image

После того, как мы нажимаем на кнопку «Загрузить медиа-файл» и выбираем его, нам будет видна следующая картина:

image

По нажатию на загруженное изображение мы видим следующее:

image

  1. Возможность твитнуть наш медиа-файл.
  2. Возможность поделиться медиафайлом с любым пользователем.

Так, хорошо, посмотрим на функцию твита поближе:

image

Что мы видим? Предположительно, следующее:

  • account_id — id аккаунта конкретно в библиотеке
  • owner_id — id владельца изображения
  • user_id — id юзера, которому, собственно, и опубликуется твит
  • media_key — id нашего медиафайла (на скриншоте №3, в адресной строке, он отображен)

Введём некоторые обозначения:

  • аккаунт №1 — первый мой аккаунт
  • аккаунт №2 — второй мой аккаунт

Поскольку я не помню точные формулировки выдаваемых ошибок, будем называть их
«ошибка №1» и «ошибка №2».

Пробуем

Что было сделано мной для обнаружения уязвимости:
Сначала я перехватил запрос на публикацию твитта и подменил параметры owner_id и user_id в GET и в json-е, который отправлялся методом POST, с id аккаунта №1 на соответствующие id аккаунта №2, но ожидаемого результата я не получил, лишь ошибку №1.

После этого я решил заменить owner_id и user_id только в POST, на что получил ошибку №2, насколько я помню, текст был примерно таким: «Пользователь с owner_id *тот id на который я заменял* не является владельцем медиа *тут media_key*».

«Хорошо», — подумал я, и сделал следующее:
Я воспользовался аккаунтом №2, зашёл в сервис ads.twitter.com, в библиотеку, и загрузил изображение для того, чтобы заранее знать media_key.

Пошло-поехало

Возвращаемся на аккаунт №1:

Перехватываем запрос на твит и подменяем owner_id, user_id в GET и POST на соответствующие данные аккаунта №2 и media_key на тот, который мы узнали, загрузив изображение на аккаунте №2. Иииии… видим ошибку №1. Грусть, печаль, тоска, хотя подождите. Когда мы ранее заменяли owner_id и user_id в GET и POST, ошибка была одна (ошибка №1), а в случае замены owner_id и user_id только в POST, ошибка была другая (ошибка №2). Попробуем?

Заменяем в запросе owner_id, user_id и media_key в POST, ииии… видим response, сообщающий, что публикация твита прошла успешно! Перейдя на аккаунт №2, мы видим, что был размещен твит с ранее загруженной картинкой аккаунта №2, хотя сам аккаунт №2 ничего не публиковал.

Пробуем усерднее

Итак, на данный момент мы имеем возможность публиковать твиты от имени любого пользователя, но у нас есть жёсткое ограничение, которое серьезно снижает impact(критичность уязвимости), а именно, нам нужно, чтобы у пользователя, от имени которого мы собираемся делать публикацию, был загружен медиа-файл. Более того, необходимо знать media_key этого файла, который подобрать не получится, поскольку он состоит из 18 цифр. Что ж, будем искать возможность узнать media_key. В процессе поисков я не обнаружил 100%-ного способа узнать этот media_key, всегда были какие-то ограничения в виде определённых обстоятельств, при которых, возможно, удалось бы получить тот самый media_key. Всё кончено? Выхода нет? Репортить, как есть? Ну уж нет! Внутреннее чувство мне подсказало, что эту уязвимость можно довести до апогея критичности! Помните возможность делиться загруженным медиа-файлом? Мне пришла в голову мысль, что, возможно, когда мы поделимся нашим медиа-файлом с пользователем, от имени которого мы хотим сделать публикацию, он будет также считаться владельцем медиа-файла, ошибка №2 не возникнет и твит успешно опубликуется. И именно так и произошло:)

Для успешной эксплуатации уязвимости нам не хватало media_key, но в случае, когда мы являемся владельцем файла, мы можем видеть его media_key (скриншот №3).

Теперь сценарий выглядит следующим образом:

  1. Мы загружаем наш медиа-файл.
  2. Делимся этим файлом с пользователем, от имени которого хотим опубликовать запись.
  3. Перехватываем запрос публикации твита и просто подменяем в POST owner_id и user_id на id twitter аккаунта жертвы (узнать его просто, есть много онлайн сервисов).
  4. Получаем сообщение об успешной публикации твита.

Вот теперь можно со спокойной душой репортить об уязвимости.

Выводы:

RCE, SQLi, XSS — это всё конечно очень здорово и опасно, но порой логические уязвимости несут не меньшую угрозу для безопасности и зачастую гораздо более просты в эксплуатации нежели вышеперечисленные. На это стоит обращать пристальное внимание и при этом внимание живых специалистов, ведь автоматизированные сканеры не способны на такое. А что касается Twitter, то еще не известно сколько подобных уязвимостей в нем сейчас есть и может появиться по мере его развития и добавления функциональности. Удачного всем bughunting'а!

Автор: Digital Security

Источник


* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js