Как я взломал систему отслеживания ошибок Google и получил $15 600 в качестве вознаграждения
Прим.: статья является переводом
Вы когда-нибудь слышали о системе отслеживания ошибок Google Issue Tracker? Вероятно, нет, если вы не являетесь сотрудником Google или разработчиком, который недавно сообщал об ошибках в инструментах Google. И я тоже не знал о ней, пока не заметил, что мои отчеты о уязвимостях теперь обрабатываются именно там через создание новой ветки, в дополнение к обычным уведомлениям по электронной почте.
Так что я сразу же решил попробовать ее взломать.
Итак, что именно представляет собой этот веб-сайт? Согласно документации, Issue Tracker (внутреннее название - Buganizer System) - это инструмент, используемый внутри компании Google для отслеживания ошибок и запросов на добавление функциональности в процессе разработки продуктов. Он также доступен внешним пользователям и партнерам, которым необходимо сотрудничать с командами Google по конкретным проектам. Другими словами, когда у кого-то возникает проблема с продуктом Google, она попадает в систему отслеживания ошибок. Все логично, не так ли? Мы, как внешние пользователи, видим только верхушку айсберга: небольшой набор предварительно утвержденных категорий и проблем, к которым кто-то из Google явно добавил внешний аккаунт, например, “Vulnerability reporting”. Но сколько информации находится под поверхностью?
Наблюдая за числовыми идентификаторами, присвоенными последним открытым общедоступным темам, мы легко можем оценить, насколько интенсивно используется этот инструмент внутри компании. В течение рабочего дня в Маунтин-Вью открывается примерно 2000–3000 проблем в час, и только 0,1% из них являются общедоступными. Утечка данных из этой системы будет довольно серьезной проблемой. Давайте взломаем ее!
Попытка №1: Получение аккаунта сотрудника Google
Одной из первых вещей, которые я заметил, когда увидел эту систему — была возможность участвовать в дискуссиях, отправляя электронные письма на специальный адрес, который выглядит так:
buganizer-system+componentID+issueID@google.com
(где componentID - это число, представляющее категорию, а issueID - уникальный идентификатор для темы, на которую вы отвечаете)
Это напомнило мне о недавнем открытии, называемом "Ticket Trick", который позволял хакерам проникать в системные чаты организаций, используя такой шаблон электронной почты. Учитывая, что это адрес электронной почты с доменом @google.com, я попробовал зарегистрироваться в команде Slack Google, используя его, и страница подтверждения, на которую я попал, выглядела очень многообещающе:
К сожалению, ни одно письмо от Slack так и не поступило.
Следующая идея, которая пришла мне в голову, заключалась в получении учетной записи Google с основным электронным адресом @google.com, что, надеюсь, даст мне дополнительные привилегии в Buganizer. Регистрация такой учетной записи извне Google оказалась невозможной:
Однако, я нашел способ обойти этот фильтр: если я зарегистрировался с фиктивным адресом электронной почты, но не подтвердил учетную запись, перейдя по ссылке, полученной по электронной почте, то я мог изменить адрес электронной почты без каких-либо ограничений. Используя этот метод, я изменил адрес электронной почты новой учетной записи Google на buganizer-system+123123+67111111@google.com.
Вскоре после этого я получил письмо с подтверждением :
Отлично! Я нажал на ссылку подтверждения, вошел в систему отслеживания ошибок и...
Я был перенаправлен на страницу корпоративной авторизации. И нет, мои учетные данные Google не работали там. А жаль.
Тем не менее, эта учетная запись дала мне много дополнительных преимуществ на других платформах в интернете, включая возможность путешествовать (возможно, бесплатно), поэтому это все еще была проблема безопасности, которая открывала множество дверей для злоумышленников.
Затрачено: 11 часов | Вознаграждение: $3,133.7 | Приоритет: P1
Попытка №2: Получение уведомлений о внутренних заявках
Еще одна функция системы отслеживания ошибок, которая привлекла мое внимание при изучении пользовательского интерфейса, - это возможность добавлять элементы в избранное. Если вы добавляете проблему в избранное, это означает, что вас интересует обсуждаемая проблема и вы хотите получать уведомления по электронной почте, когда кто-то добавляет комментарий.
Интересным моментом, который я заметил при использовании этой функциональности на проблемах, к которым у меня не было доступа, было отсутствие ошибок. Правила контроля доступа, кажется, не применялись к этой конечной точке, поэтому я вошел в свою вторую учетную запись и попытался добавить в избранное отчет об уязвимости из своей основной учетной записи, заменив идентификатор проблемы в запросе. Затем я увидел это сообщение, что означает успешное выполнение действия:
1 человек добавил эту проблему в избранное.
Может быть, это настолько просто шпионить за открытыми уязвимостями Google? Я быстро оставил комментарий к проблеме, чтобы проверить, получит ли моя вымышленная атакующая учетная запись уведомление о нем.
Однако, снова ни одного письма не появилось.
По какой-то причине, которую я искренне не помню, я решил провести дополнительное тестирование. Я взял последний номер проблемы и предположил, что идентификаторы в этом диапазоне будут соответствовать другим недавним проблемам в базе данных. Затем я добавил все эти номера в избранное.
В течение нескольких минут моя почта выглядела так:
Когда я открыл свою почту, моя первая мысль была: "Джекпот!".
Однако, более внимательно рассмотрев эти сообщения, я не обнаружил ничего интересного. Похоже, что я мог просто просматривать разговоры, связанные с переводом, где люди обсуждали лучшие способы объяснения значения фразы на разных языках.
Я даже подумал не сообщать об этой уязвимости в течение нескольких часов, надеясь, что найду способ повысить ее значимость. В конце концов, я осознал, что команда по безопасности Google, вероятно, будет заинтересована в поиске возможных методов и вариантов эксплуатации, поэтому я отправил им подробности.
Затрачено: 5 часов | Вознаграждение: $5,000 | Приоритет: P0
Попытка №3: Конец игры
Когда вы посещаете Issue Tracker в качестве внешнего пользователя, большая часть его функциональности урезается, оставляя вас с крайне ограниченными привилегиями. Если вы хотите увидеть все интересные возможности, которые доступны сотрудникам Google, вы можете искать конечные точки API в файлах JavaScript. Некоторые из этих функций полностью отключены, другие просто скрыты в интерфейсе.
При разработке этой упрощенной версии системы кто-то был достаточно любезен, чтобы оставить возможность для удаления себя из списка участников (CCs), если мы потеряли интерес к проблеме или больше не хотим получать электронные письма по этому поводу. Это можно сделать, отправив POST-запрос вот так:
Однако я заметил здесь несколько упущений, которые привели к серьезной проблеме:
- Не было явной проверки того, имел ли текущий пользователь доступ к указанным проблемам (issueIds) перед попыткой выполнить указанное действие.
- Если вы указывали адрес электронной почты, который в данный момент не находился в списке участников (CCs), точка доступа возвращала сообщение о успешном удалении этого адреса.
- Если при выполнении действия не возникало ошибок, другая часть системы предполагала, что пользователь имеет соответствующие разрешения. Таким образом, каждая деталь о заданном идентификаторе проблемы возвращалась в теле HTTP-ответа.
Теперь я мог видеть детали о каждой проблеме в базе данных, заменяя issueIds в вышеприведенном запросе. Бинго! Я попробовал только просмотреть несколько последовательных идентификаторов, затем проверил на себе из другой учетной записи, чтобы подтвердить серьезность этой проблемы.
Да, я мог видеть детали о баг-репортах, а также всем остальном, что находилось на Buganizer. Что еще хуже, я мог выводить данные о нескольких тикетах в одном запросе.
Я незамедлительно отправил подробности об эксплойте в Google, и их команда по безопасности отключила затронутую точку доступа через час. Впечатляющее время реакции!
Затрачено: 1 час | Вознаграждение: $7,500 | Приоритет: P0
Если вам понравилась данная статья, жду вас в своем телеграм-канале Итак, далее!