1-Клік Охорона OAuth Токенів через Google Apps Script – Ігнорована помилка в дизайні? | Bug Bounty

Під час роботи з налаштуваннями Google Apps Script я виявив серйозну, але приховану уразливість безпеки — OAuth токени можна ексфільтрувати та зловживати ними тихо в межах одного і того ж проєкту скриптів.

Основна проблема полягала в можливості ексфільтрації OAuth токенів у межах Google Apps Script Web Apps. Ця уразливість дозволяє зловмисникам отримати доступ до чутливих OAuth токенів, коли вони мають доступ до проєкту, що може бути використано для маніпуляцій з важливими сервісами Google. Хоча Google Apps Script не дозволяє повністю захопити користувацькі акаунти, ексфільтрація OAuth токенів з широкими правами доступу (наприклад, до Google Drive або Gmail) може призвести до серйозних наслідків для безпеки.

Доказ концепції

Сценарії експлуатації:

• Доступ до файлів на Google Drive: Зловмисники можуть отримати доступ до файлів користувача на Google Drive та змінювати їх, якщо OAuth токен має такий доступ.
• Надсилання електронних листів: Ексфільтровані токени, що надають доступ до Gmail, можуть дозволити зловмисникам надсилати несанкціоновані електронні листи від зламаного акаунту.
• Несанкціоновані дії: Викрадений OAuth токен дозволяє зловмисникам виконувати дії від імені користувача, залежно від наданих прав, що може включати доступ до чутливих даних і виконання шкідливих дій.

Проєкт

Конвертер файлів Google Drive

Простий проєкт Google Apps Script, що дозволяє користувачам перетворювати файли з Google Drive в PDF та надсилати їх електронною поштою.

OAuth права доступу проєкту:

• https://www.googleapis.com/auth/drive
• https://www.googleapis.com/auth/userinfo.email
• https://www.googleapis.com/auth/script.send_mail

Початкові налаштування:

Власник:

• Створює та розгортає легітимний проєкт із оригінальним скриптом.
• Власник вносить зміни до Code.gs та index.html, після чого розгортає Web App:
  • Назва: Google File Converter WebApp
  • Виконувати як: Користувач, який отримує доступ до вебсайту
  • Хто має доступ: Будь-хто з обліковим записом Google
  • Посилання для розгортання:
    https://script.google.com/macros/s//exec

Редактор:

• Вносить виправлення до проєкту Google Apps Script (Google Drive File Converter) та перевіряє, чи працює все коректно.

Клієнт:

• Користувач використовує проєкт “Google Drive File Converter”, який був розгорнутий власником і виправлений редактором.

Жертва (власник, редактор чи клієнт):

• Надає OAuth дозволи для проєкту, зв'язуючи свої акаунти з третім додатком (Google Drive File Converter), який має доступ до:
  • Переглядати, редагувати, створювати і видаляти всі файли на Google Drive
  • Надсилати електронні листи від вашого імені

Сценарій атаки

Крок 1: Редактор розгортає шкідливий Web App

Шкідливий редактор додає новий скрипт (Malicious.gs) і розгортає його як Web App без змін в оригінальному скрипті.
Це запобігає виявленню в історії проєкту за допомогою таких налаштувань:

• Виконувати як: Користувач, який отримує доступ до вебсайту
• Хто має доступ: Будь-хто з обліковим записом Google
• Посилання для розгортання:
  https://script.google.com/macros/s//exec

function doGet() {
Session.getActiveUser(); // Отримати інформацію про користувача
var token = ScriptApp.getOAuthToken(); // Отримати OAuth токен
var html = HtmlService.createHtmlOutput(`

OAuth Token Exfiltration via Google Apps Script Web App
Your OAuth Token:
${token} `);
return html.setSandboxMode(HtmlService.SandboxMode.NONE);
}

Крок 2: Зловмисник видаляє скрипт Malicious.gs

• Зловмисник видаляє Malicious.gs після розгортання.
• Шкідливий Web App залишається активним і пов’язаний з проєктом.
• Власник не в курсі про розгорнутий Web App.

Крок 3: Зловмисник використовує 1-клік захоплення акаунта

• Зловмисник надсилає шкідливе посилання Web App жертві (власнику, редактору або клієнту).
• Як тільки жертва переходить за посиланням, її OAuth токен автоматично ексфільтрується і відправляється на сервер зловмисника.
• Зловмисник тепер має доступ до Google Drive, Gmail і особистих даних жертви без подальшої взаємодії з користувачем.

Хронологія обговорень з командою безпеки Google та Trust & Safety

Спочатку я повідомив про проблему як “OAuth Token Exfiltration via Google Apps Script Web App Without External Request Scope.” Однак через додаткові знахідки та відсутність деталей у початковому звіті сценарій атаки став важким для відстеження, що призвело до непорозумінь. Я подав нові звіти і отримав доброзичливу відповідь від “st…@google.com”.

Однак команда Trust & Safety відмовилася виправляти проблему, оскільки вважають, що жертва (користувач) повинна довіряти будь-якому учаснику, якого вона запрошує, і запропонували деякі заходи.

Позначено як “Won’t Fix”

Але ці заходи можна обійти багатьма способами, наприклад:

Після того як я обійшов запропоновані "заходи", питання було відкрито знову, але закрите відразу, з пропозицією “Аудиторські журнали” і “Обмеження запитів за доменами сервісів”.

Однак ці запропоновані заходи (аудиторські журнали та обмеження доменів) доступні лише для корпоративних організацій, залишаючи окремих розробників і малі команди вразливими.

Команда Google Trust & Safety: “Ми вважаємо, що проблема не настільки серйозна, щоб відслідковувати її як ризик зловживання.”

Після того, як я обійшов “запропоновані заходи” і довів, що поточні рішення неефективні:
- Аудиторські журнали не надають захисту в реальному часі, що означає, що атаки можуть відбутися до того, як їх виявлять.
- Обмеження запитів за доменами сервісів не знижує ризик атаки, оскільки атака не залежить від UrlFetchApp Service.
(це можна обійти за допомогою JavaScript Fetch)
- Відсутність контролю власності дозволяє редакторам розгортати Web App без відома власника (сповіщення), що дозволяє зловмисникам впроваджувати шкідливі скрипти, які зберігаються, навіть якщо оригінальний скрипт не змінений.

Команда Google Trust & Safety: “Ми вважаємо, що проблема не настільки серйозна, щоб відслідковувати її як ризик зловживання.”

Насправді, я не маю уявлення, за якими критеріями вони оцінюють уразливість, але ось так це є.

Цього разу я все ще наполягав на вирішенні питання, але вони знову відмовилися виправляти проблему і сказали: “Кілька членів команди обговорювали цю проблему, щоб переконатися, що ваш звіт не був неправильно зрозумілий.” Цього разу я припинив наполягати на уразливості, оскільки питання вже було передано всій команді, і я хотів лише отримати відгук від іншої команди безпеки Google з їхньої точки зору.

Хронологія обговорень з командою безпеки Google та Trust & Safety

1. Перше виявлення та звіт — Проблему було вперше подано до Google VRP, в якому детально пояснювалося, як OAuth токени можна ексфільтрувати через Google Apps Script Web App. Уразливість дозволяла отримати доступ до чутливих сервісів Google та компрометувати конфіденційність і цілісність даних.
2. Пропозиції щодо виправлення від Google:

• Аудиторські журнали: Google порекомендував використовувати аудиторські журнали для відстеження дій. Однак затримка та період збереження цих журналів (кілька годин або більше) обмежують їх корисність для забезпечення безпеки в реальному часі, дозволяючи зловмисникам завершити свої шкідливі дії до виявлення.
• Обмеження запитів за доменами сервісів: Google також запропонував обмежити домени сервісів для запитів. Однак сама експлуатація не залежить від Fetch, тому це конкретне обмеження не могло б запобігти атаці.

1. Подальше обговорення та відгук — Був поданий більш детальний звіт, в якому пояснювалося, що ці заходи не є достатніми для запобігання ексфільтрації OAuth токенів. Незважаючи на доведене життєздатність атаки, команда Trust & Safety Google вирішила, що це не відповідає їхнім критеріям для підвищення ризику зловживань.
2. Остаточна позиція Google:

• Оцінка серйозності: Хоча Google визнав наявність уразливості, вони вирішили, що проблема не досягає порогу серйозності, необхідного для відслідковування як ризик зловживання. Проблему визнали важливою, але недостатньо серйозною для запуску процесів ескалації ризиків зловживань.

Остаточні думки

Цей випадок не про те, щоб звинувачувати Google. Йдеться про підкреслення розриву між зручністю платформи та реальним потенціалом зловживань.

Apps Script — це потужний інструмент, але коли токени легко доступні і важко відслідковуються, зловмисники не потребують фішингу або соціальної інженерії, щоб компрометувати акаунти. Їм просто потрібен доступ до спільного скрипту або документа.

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

Контакти:
Електронна пошта: [email protected]
Twitter: https://x.com/PhHitachi
LinkedIn: www.linkedin.com/in/phhitachi

Перекладено з: 1-CLick OAuth Token Hijacking via Google Apps Script – A Design Flaw Ignored? | Bug Bounty