Вы когда-нибудь слышали о Google Issue Tracker? Вероятно нет, если только вы не являетесь сотрудником Google или разработчиком, который недавно сообщил об ошибках в продуктах Google. Я тоже не слышал, пока не заметил, что мои отчеты об уязвимостях теперь обрабатываются путем открытия новой темы в дополнение к обычным уведомлениям по электронной почте.

Я немедленно попытался сломать его.

Что же это за сайт? Согласно документации, Issue Tracker (между собой его называют Buganizer System) — это служебный инструмент, используемый компанией Google для отслеживания ошибок и запросов во время разработки продукта. Он доступен и вне Google для использования внешними партнерами, которые сотрудничают с Google по конкретным проектам.

Другими словами, когда у кого-то возникают проблемы при использовании продуктов Google, они идут в баг-трекер. Разумно, не так ли? Мы, как внешние пользователи, видим только верхушку айсберга: небольшой набор заранее согласованных категорий и проблемы, когда кто-то из Google добавит внешний аккаунт, например, отчеты об уязвимостях. Но сколько информации скрыто под покровом?

Наблюдая за числовыми ID последних публичных тем, мы можем легко оценить как часто используется этот инструмент внутри. Около 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.

Вскоре после этого я получил письмо с подтверждением в виде сообщения:

Прекрасно! Я нажал на ссылку подтверждения, вошел в Issue Tracker и…

Меня перенаправили на страницу для корпоративного входа. И нет, мои учетные данные Google-аккаунта там не работали. Облом.

Тем не менее, этот аккаунт дал мне много преимуществ в Интернете, включая возможность корпоративной развозки, поэтому это все еще было проблемой, открывавшей много возможностей для злоумышленников.

Затрачено: 11 часов | Вознаграждение: $3,133.7 | Приоритет: Р1

Попытка №2. Получение уведомлений о внутренних тикетах

Еще одна функция Issue Tracker, которая привлекла мое внимание во время знакомства с пользовательским интерфейсом — это добавление в избранное. Отметка звездочкой означает, что вас интересует обсуждаемая проблема, и вы хотите получать уведомления по электронной почте, когда кто-то добавляет комментарий.

Интересная вещь, которую я заметил применительно к этой функции заключалась в том, что наблюдалось хорошо заметное отсутствие ошибок при попытке использовать ее для тех тем, к которым у меня не было доступа. Видимо, правила контроля доступа никогда не применялись к этому показателю, поэтому я вошел в свой второй аккаунт и попытался отметить отчет об уязвимости из моего главного аккаунта, заменив в запросе Issue ID. После этого я увидел это сообщение, которое означало, что действие было успешным:

1 person has starred this issue.

Означало ли это, что можно легко отслеживать открытые уязвимости Google? Я быстро опубликовал комментарий по этому вопросу, чтобы увидеть – придет ли уведомление на мой фиктивный аккаунт?

Но вновь, не появилось никаких писем.

По какой-то причине, которую я уже и не помню, я решил провести еще один тест. Так как у меня были номера последних ID с запросами, то я экстраполировал несколько тысяч ID, которые должны были совпадать с последними обращениями в базе данных. Я отметил их все.

Через несколько минут мой почтовый ящик выглядел так:

Когда я открыл почтовый ящик, моя первая мысль была – «джекпот!».

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

Я даже подумывал не сообщать об этом, надеясь найти способ усилить степень опасности. В конце концов я понял, что команда безопасности Google будет заинтересована в поиске возможных методов и вариантов, поэтому я отправил им все детали.

Затрачено: 5 часов | Вознаграждение: $5,000 | Приоритет: Р0

Попытка №3. Игра окончена

Когда вы посещаете баг-трекер в качестве внешнего пользователя, многие его функции недоступны, что существенно ограничивает ваши возможности. Если вы хотите увидеть все те классные вещи, которые доступны сотрудникам Google, то вы можете поискать конечные точки API в файлах JavaScript. Некоторые из этих функций полностью отключены, другие же просто скрыты в интерфейсе.

Когда разрабатывали эту ограниченную версию системы, кто-то был достаточно мил, чтобы отойти от метода, в соответствии с которым нас удаляют из списка вторичных адресатов (CC), в случае, если мы потеряли интерес к проблеме или не хотим получать электронные письма о ней. Этого можно добиться, отправив запрос следующим образом:

POST /action/issues/bulk_edit HTTP/1.1

{
"issueIds":[
67111111,
67111112
],
"actions":[
{
"fieldName":"ccs",
"value":"test@example.com",
"actionType":"REMOVE"
}
]
}

Однако я заметил некоторые упущения, которые привели к огромной проблеме:

1. Контроль несанкционированного доступа: нет четкой проверки, что текущий пользователь действительно имеет доступ к обращениям, указанным в issueIds, перед попыткой выполнить заданное действие;
2. Безмолвный отказ: если вы указали адрес электронной почты, который не был включен в список CC, то конечная точка вернет сообщение о том, что письмо было успешно удалено;
3. Детальная информация об обращении в ответе: если не было обнаружено ошибок во время совершения действия, то другая часть системы предполагает наличие у пользователя соответствующего разрешения. Поэтому каждая деталь для заданного issueID будет возвращена в теле HTTP ответа.

Теперь я могу просмотреть подробности о каждом обращении в базе данных, заменив issueIds в запросе. Бинго!

Я только попробовал просмотреть несколько последовательных ID, а затем атаковал самого себя со стороннего аккаунта, чтобы подтвердить серьезность этой проблемы.

Да, я смог увидеть подробности в отчетах об уязвимостях, как и много другое, размещенное в Buganizer.

Хуже того, я мог бы извлечь данные о нескольких тикетах одним запросом, значит мониторинг всей внутренней активности в реальном времени не привел бы к наложению каких-то ограничений.

Я быстро отправил информацию об уязвимости в Google, и их команда безопасности отключила поврежденную конечную точку в течение часа. Впечатляющее время реакции!

Затрачено: 1 час | Вознаграждение: $7,500 | Приоритет: Р0

Когда я впервые начал искать утечку информации, я предположил, что настоящей чашей Грааля будут баги в системе Google, потому что они позволяют найти информацию обо всех других багах (например, HackerOne платит минимум 10 000 долларов за нечто похожее).

Но обнаружив их, я быстро понял, что воздействие будет минимизировано, так как критические уязвимости в любом случае будут нейтрализованы в течение часа.

Я очень рад, что получил дополнительные средства, и с нетерпением стремлюсь к нахождению ошибок в других продуктах Google.

Заглядывайте на VPS.today — сайт для поиска виртуальных серверов. 1500 тарифов от 130 хостеров, удобный интерфейс и большое число критериев для поиска самого лучшего виртуального сервера.