Программная ошибка позволила баг-хантеру удалить живое видео на Facebook

Программная ошибка позволила баг-хантеру удалить живое видео на Facebook

Программная ошибка позволила баг-хантеру удалить живое видео на Facebook

ИБ-исследователь Ахмад Талахмех (Ahmad Talahmeh) опубликовал подробности уязвимости в службе видеотрансляции на Facebook, а также созданный им PoC-эксплойт. Разработчики платформы исправили ошибку, позволявшую удалить контент без согласия владельца, а баг-хантеру выплатили суммарно $14,5 тыс. за находку.

Сервис Facebook Live позволяет создавать видеоконтент в реальном времени, публиковать его, а также общаться с аудиторией в прямом эфире. По завершении трансляции пользователь может вырезать лишние кадры онлайн, руководствуясь временными метками начала и конца записи.

Как оказалось, при подаче через API запроса на сокращение видео до пяти миллисекунд система воспримет длительность видеозаписи как 0 секунд, и развернуть ее вновь не удастся. Заполучив ID документа и его автора, злоумышленник сможет скопировать его POST-запрос на загрузку, изменить конечное значение времени, чтобы вызвать сброс до нуля, и подать его снова. Система вернет ошибку, но команду выполнит.

За обнаружение этой проблемы Талахмеху выплатили $11 тыс. в ходе конференции BountyCon 2020. Еще две премии он получил позднее от Facebook — $1150 и $2300.

Выступая на BountyCon, исследователь также продемонстрировал способ восстановления обрезанной видеозаписи на Facebook от имени ее владельца. Эта находка принесла Талахмеху дополнительно $2875.

Баг-хантер также обнаружил возможность подмены информационных сообщений в бизнес-лентах Facebook — она появилась в связи с необходимостью мониторинга ситуации с COVID-19. Обновление страниц умышленно тормозится в ожидании новостей с этого фронта, и такие сообщения, как оказалось, можно вставлять в ленту вместе со ссылкой на сторонний ресурс. Для обновления нужны лишь ID страницы и полномочия аналитика (обычно таким пользователям разрешен доступ только на чтение). Эту находку Facebook оценила в $750.

Все проблемы, обнаруженные исследователем в соцсети, уже решены.

Расширения Chrome могут слить секреты URL через атаку по стороннему каналу

Как оказалось, расширения Chrome можно использовать для слива кодов авторизации, сеансовых ID и других секретов из URL любой открытой вкладки. Никаких специальных разрешений для этого не понадобится, только доступ к declarativeNetRequest API.

Этот механизм, пришедший на смену webRequest API, позволяет расширениям сообщать браузеру, что следует изменить или заблокировать на загружаемой странице (заголовки, реклама, трекеры).

Правила обработки запросов при этом добавляются динамически, а фильтрация осуществляется по регулярным выражениям, соответствующим подмножествам знаков, которые могут присутствовать на определенных позициях в URL.

Исследователь Луан Эррера (Luan Herrera) обнаружил, что блокировку, диктуемую правилами, Chrome производит почти мгновенно, за 10-30 мс, а остальные запросы выполняются дольше (~50-100ms) — из-за сетевых подключений. Эту разницу во времени расширение может использовать для бинарного поиска с целью посимвольного слива URL.

// extensions/browser/api/web_request/extension_web_request_event_router.cc:1117-1127
case DNRRequestAction::Type::BLOCK:
  ClearPendingCallbacks(browser_context, *request);
  DCHECK_EQ(1u, actions.size());
  OnDNRActionMatched(browser_context, *request, action);
  return net::ERR_BLOCKED_BY_CLIENT;

Оракул для подобной тайминг-атаки строится с использованием chrome.tabs.reload для перезагрузки страницы и перехватчика chrome.tabs.onUpdated, помогающего отследить событие status === "complete". Замер времени между reload и завершением загрузки покажет, заблокирован запрос или успешно обработан.

Повторение проверок и бинарного поиска позволяет получить полный URL (с довеском после «?»), затратив на каждый знак строки несколько прогонов. Таким образом, можно незаметно для пользователя украсть включенные приложением в адрес секреты — токены OAuth и сброса пароля, API-ключи, ссылки на контент, закрытый для поисковых систем.

Проверка PoC проводилась на Windows 11 24H2 с использованием Chrome разных версий:

  • 144.0.7559.97 (Stable)
  • 145.0.7632.18 (Beta)
  • 146.0.7647.4 (Dev)
  • 146.0.7653.0 (Canary)

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

RSS: Новости на портале Anti-Malware.ru