Как я получил 50000 + 0 долларов за уязвимость в Zendesk

Привет, меня зовут Дэниел, мне пятнадцать лет, я имею опыт программирования, в свободное время занимаюсь поиском багов. В посте я расскажу безумную историю о том, как обнаружил один баг, затронувший больше половины компаний из списка Fortune 500.

Поприветствуйте Zendesk

Возможно, вы уже сталкивались с Zendesk. Это инструмент службы поддержки, используемый одними из самых богатых компаний мира. Он прост в настройке: достаточно указать ссылку на электронную почту технической поддержки компании (вида support@company.com), и Zendesk сразу начнёт обрабатывать входящие письма и создавать тикеты. Вы можете работать с этими тикетами самостоятельно или передавать их команде службы поддержки. Компания Zendesk стоит несколько миллиардов долларов, ей доверяют такие крупные игроки, как Cloudflare.

Лично мне всегда казалось удивительным, что такие огромные компании, стоящие миллиарды долларов, используют сторонние инструменты наподобие Zendesk, а не создают собственные инструменты для работы с тикетами.

Ваше самое слабое звено

Как гласит поговорка, «где тонко, там и рвётся». Так как Zendesk считается базовым инструментом обработки тикетов, компании часто настраивают его, особо не задумываясь. Чаще всего я встречал такую систему: все электронные письма с support@company.com перенаправляются в Zendesk.

Почему это опасно? Многие компании используют свой домен company.com для единого входа (Single Sign-On, SSO), позволяющего сотрудникам быстро выполнять вход во внутренние инструменты. Связывая Zendesk с тем же доменом, компании неосознанно создают потенциальную брешь в защите. Zendesk обрабатывает все письма домена, для которого он был сконфигурирован, поэтому если ваша система SSO не валидирует надлежащим образом адреса электронной почты, то любой, получивший доступ к вашему Zendesk, потенциально может воспользоваться этим для доступа к вашим внутренним системам (подробнее я расскажу об этом ниже).

Спуфинг электронной почты

В начале этого года я обнаружил в Zendesk серьёзную уязвимость, позволявшую нападающим читать тикеты системы клиентской техподдержки любой компании, пользующейся Zendesk. Для этого достаточно составить специальное письмо и отправить его на адрес почты техподдержки, обрабатываемой Zendesk. Самое ужасное заключалось в том, что Zendesk, похоже, это ни капли не волновало.

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

Вот, как это работало: при отправке письма на портал Zendesk техподдержки компании (например, support@company.com) Zendesk создаёт новый тикет техподдержки. Чтобы отслеживать цепочку писем, Zendesk автоматически генерирует адрес reply-to, который выглядит так: support+id{id}@company.com, где {id} — это уникальный номер тикета. Благодаря этому адресу все будущие ответы будут отправляться напрямую на тот же тикет.

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

Эксплойт было реализовать легко: если нападающий знает адрес почты техподдержки и ID тикета (который достаточно просто подобрать, потому что ID тикетов увеличиваются инкрементально), он может применить спуфинг почты, чтобы выдать себя за исходного отправителя. Если отправить поддельное письмо на support+id{id}@company.com с почтового адреса пользователя и добавив в CC своё собственное письмо, то Zendesk подумает, что письмо подлинное. Затем он добавит почтовый адрес нападающего к тикету, давая ему полный доступ ко всей истории тикета.

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

Требования для использования бага:

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

«Out of scope»: такого не скажет ни один злоумышленник

Сразу после обнаружения уязвимости я сообщил о нём через программу баг-баунти Zendesk в полной уверенности, что её воспримут серьёзно и быстро устранят. Неделю спустя я получил неутешительный ответ:

Так как в моём баге использовался спуфинг почты, его посчитали не входящим в рамки («out of scope») программы компании на HackerOne, а мой отчёт был отклонён. Невероятно.

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

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

Эскалация бага до полного захвата Slack

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

В то время я обнаружил пост TICKETTRICK, написанный в 2017 году. В нём исследователь безопасности Инти Де Сёклер подробно описал, как он воспользовался Zendesk для внедрения в приватные рабочие пространства Slack сотен компаний. Так как многие компании использовали Slack SSO на том же домене, что и Zendesk, исследователь догадался, что можно выполнить почтовые верификации через почтовый адрес support@company.com и получить доступ к приватным каналам Slack. В те годы Zendesk ещё не была такой большой и существовали другие баги, позволявшие любому, кто знает ваш адрес почты, просматривать тикеты.

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

▍ На сцене появляется OAuth

После раскрытия хакером уязвимости (это было несколько лет назад) Slack поменял свою систему верификации через почту, добавив в адреса почты случайный токен.

В эксплойте Инти (как и в моём) требовалось, чтобы нападающий знал адрес почты отправителей кода верификации. Чтобы предотвратить подобные атаки, Slack добавил в их адреса почты случайные токены. Было невозможно узнать, с какого адреса будет отправлено письмо верификации (это одно из требований для использования моего эксплойта), потому что каждый раз генерировался случайный токен. Однако…

Хотя при отправке почтовой верификации Slack использовал случайный токен почты, этого не делали ни Google, ни Apple. Slack поддерживал оба этих способа для логина через OAuth.

Это был самый простой способ обхода защиты. Slack добавил логин через OAuth всего несколько лет назад и, вероятно, совершенно забыл о своей защите от таких типов атак.

Так что теперь реализовать эксплойт было легко: создаём аккаунт Google с почтой support@company.com, запрашиваем код верификации, используем мой баг для доступа к тикету, который Zendesk создаёт автоматически после его поступления, верифицируем аккаунт Google, выполняем логин в Slack при помощи Google.

Идеальное решение… Но, увы, с Google оно не сработало. Google отправил письмо с верификацией с noreply@google.com, а Zendesk начал блокировать автоматическое создание адресов почты с noreply@ в качестве тикетов (вероятно, также после раскрытия TICKETTRICK), поэтому мы не смогли бы его получить.

Однако Apple этого не сделала: Apple отправляет письма с верификацией с адреса appleid@. Джекпот!

Этапы воссоздания Apple -> Zendesk -> Slack

Теперь этапы проведения атаки стали очень простыми:

• 1. Создаём аккаунт Apple с почтой support@company.com и запрашиваем код верификации. Apple отправляет код верификации с appleid@id.apple.com на support@company.com и Zendesk автоматически создаёт тикет.
• 2. В то же самое время создаём тикет на портале техподдержки company.com с моего собственного адреса почты, что позволяет мне отслеживать диапазон значений ID.
• 3. Используем баг со спуфингом почты, чтобы попытаться добавить себя во все тикеты в рамках определённого выше диапазона.

const sendmail = require('sendmail')();

// Допустим, тикету, созданному на этапе 2, был назначен ID 453
// Значит, письмо с верификацией придётся примерно на этот диапазон
const range = [448, 457];
for (let i = range[0]; i < range[1]; i++) {
    // Отправляем созданные спуфингом письма от Apple Zendesk
    sendmail({
        from: 'appleid@id.apple.com',
        to: `support+id${i}@company.com`,
        cc: 'daniel@wearehackerone.com',
        subject: '',
        html: 'comment body',
    }, function (err, reply) {
        console.log(err && err.stack)
        console.dir(reply)
    });
};

• Выполняем логин в портал техподдержки company.com (обычно на support.company.com) со своего аккаунта (daniel@wearehackerone.com) и просматриваем тикеты, включённые в CC.

• 5. Вводим код верификации в Apple
• 6. Используем функцию Slack «Login with Apple» и выполняем вход с аккаунтом Apple, связанным с почтой company.com

Я воспроизвёл эти шесть этапов на сотнях уязвимых инстансов Zendesk и Slack. Подготовившись, я начал по отдельности сообщать о баге компаниям, пользующимся Zendesk.

Последствия

Я примерно неделю сообщал об уязвимости компаниям; некоторые из них незамедлительно предприняли действия и пропатчили свои инстансы, а другие заявили, что это проблема Zendesk. Затем случилось нечто интересное — под моим исходным отчётом на HackerOne появился комментарий:

Меня он очень изумил — теперь они просят меня сделать отчёт конфиденциальным, хотя изначально отклонили его, как out of scope.

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

Я предоставил proof of concept уязвимости Slack, и они подтвердили наличие проблемы. Хотя компания заявила, что «начала работу» над исправлением, для её устранения им понадобилось более двух месяцев.

Баунти

Когда компании, подверженные этой проблеме, были уведомлены о ней, многие из них для защиты своих инстансов быстро отключили функцию Zendesk совместной работы по электронной почте. В процессе отправки отчётов я получил более 50000 долларов баг-баунти от отдельных компаний на HackerOne и других платформах.

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

Исправление Zendesk (и моя баунти в 0 долларов)

2 июля 2024 года, спустя два месяца после отправки отчёта, Zendesk наконец-то подтвердила, что устранила проблему. Вот заявление от руководителя её отдела Offensive Security:

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

Для выявления подозрительных характеристик в сообщениях мы используем два спам-фильтра: Cloudmark и Rspamd EAP. При получении определённой оценки от этих инструментов сообщения могут быть переведены в состояние ожидания. Мы опубликовали полный список причин перевода тикетов в состояние ожидания. В описанном здесь сценарии атаки Cloudmark имеет очень низкие показатели спама, а RSpamD — очень высокие; к сожалению, мы не использовали оценку RSpamD в этом случае, потому что в противном случае многие из почтовых адресов были бы переведены в состояние ожидания, полностью ограничивая возможность добавления CC. Первое реализованное нами исправление заключается в том, что мы автоматически переключаемся на анализ спама RSPAMD, когда:

1. Наша функция автоматического добавления в цепочки тикетов сработала для добавления нового почтового адреса в цепочку уже существующего тикета и
2. Мы ранее не переводили сообщение в состояние ожидания из-за оценки Cloudmark. Кроме того, мы также реализовали фильтры для автоматического перевода в состояние ожидания следующих классов писем:

   Письма верификации пользователей, отправляемые Apple, что определяется по значениям заголовков Reply-To и Message-Id

   Нетранзакционные письма с googleworkspace-noreply@google.com

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

Несмотря на устранение проблемы, Zendesk в конечном итоге решила не выплачивать баунти за мой отчёт. Как они это мотивировали? Я нарушил инструкции HackerOne по раскрытию и поделился уязвимостью с компаниями, которые она затронула. Я даже не стал заморачиваться и что-то доказывать.

Заключение

То, что поначалу было небольшим багом с электронной почтой, превратилось в эксплойт, позволивший мне проникнуть во внутренние системы крупнейших компаний мира. Хотя Zendesk в конечном итоге устранила уязвимость, путь к этому состоял из отказов, медленного реагирования и в конечном итоге полного отказа от признания ценности отчёта. Но такова реальность баг-хантинта: иногда ты выигрываешь, иногда нет.