[Перевод] Как я нашел уязвимости в системе баг-трекинга Google и получил $15,60006.11.2017 15:18

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

Поэтому я сразу начал пытаться взломать его.

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

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

Наблюдая за ID, назначенных на последние опубликованные баги, мы можем легко оценить, сколько применения этот инструмент получает изнутри. В рабочие часы в Mountain View открывается около 2000–3000 проблем за час. Похоже, утечка данных из этой системы будет иметь большую ценность. Давайте взломаем ее!

Перевод выполнен при поддержке компании EDISON Software, которая профессионально занимается разработкой сервисов видеонаблюдения, приложения для виртуального сотового оператора и разработкой программ на C и C++ (IPTV-плеер).

Уязвимость № 1: Получение учетной записи сотрудника Google

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

buganizer-system+componentID+issueID@google.com

(в котором componentID — это число, представляющее категорию, а issueID — уникальный идентификатор для обсуждения, в котором вы отвечаете)

Это напомнило мне недавнее открытие под названием Ticket Trick, которое позволило хакерам проникнуть в систему чатов организаций, используя такую систему электронной почты.

Учитывая, что это адрес электронной почты @ google.com, я пытался зарегистрироваться в Google Slack, используя его. Страница подтверждения входа, которую я увидел, выглядела очень многообещающе:

Увы, ни одного письма от Slack не пришло.

Следующая вещь о которой я мог подумать — это получить учетную запись Google с доменом google.com, который, надеюсь, предоставит мне дополнительные привилегии в Buganizer. Зарегистрировать такую учетную запись извне Google не получалось:

Тем не менее, я нашел метод обхода этого фильтра: если я зарегистрировался на любом другом поддельном адресе электронной почты, но не смог подтвердить учетную запись, нажав на ссылку, полученную по электронной почте, мне было разрешено менять свой адрес электронной почты без каких-либо ограничений. Используя этот метод, я изменил электронную почту новой учетной записи Google на buganizer-system+123123+67111111@google.com.

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

Отлично! Я щелкнул на ссылку подтверждения и вошел в систему Tracker Issue и …

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

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

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

Уязвимость № 2: Получение уведомления о внутренних тикетах

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

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

1 человек отметил эту проблему.

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

Но опять же, ни одно сообщение не появилось.

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

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

Моя первая мысль при открытии папки «Входящие» была «Джекпот!».

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

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

Итого: 5 часов | Вознаграждение: $5000 | Приоритет: P0

Уязвимость №3: Game over

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

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

POST /action/issues/bulk_edit HTTP/1.1

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

Тем не менее, я заметил некоторые недочеты здесь, что могло бы привести к огромной проблеме:

Неправильное управление доступом: не было явной проверки того, что у текущего пользователя действительно был доступ к проблемам, указанным в issueIds, прежде чем пытаться выполнить данное действие.
Скрытый отказ (Silent failure): если вы указали адрес электронной почты, который в настоящее время не был включен в список CCs, конечная точка вернет сообщение о том, что письмо было успешно удалено.
Подробное описание проблемы в ответе: если во время действия не было ошибок, другая часть системы решила, что у пользователя есть соответствующие права доступа. Таким образом, каждая деталь о данном ID бага будет возвращена в теле ответа HTTP.

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

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

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

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

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

Итог: 1 час | Вознаграждение: $7500 | Приоритет: P0

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

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

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

Перевод: Вячеслав Букатов