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

leer en español

7930
Сначала пряник, потом кнут: почему Google передумала платить багхантеру за критическую уязвимость

В облаке нашли дыру, а в правилах вознаграждений внезапно выявилась лазейка.

image

В облачных сервисах всё чаще возникают споры не только об уязвимостях, но и о том, считать ли найденную проблему уязвимостью. Именно в такую ситуацию попал багхантер Джастин О’Лири, который заявил о критическом недостатке в Google Cloud и получил от Google два взаимоисключающих ответа.

По словам О’Лири, проблема затрагивает открытый компонент Config Connector, который позволяет управлять ресурсами Google Cloud через Kubernetes. Специалист обнаружил механизм, получивший название ConfigConfusion. Согласно его описанию, пользователь с доступом лишь к одному пространству имён Kubernetes мог повысить привилегии до уровня владельца всей облачной организации и получить контроль над проектами, секретами, биллингом и другими ресурсами.

После получения отчёта сотрудники Google первоначально признали находку серьёзной. Заявка получила максимальные уровни приоритета и критичности P1/S1, а команде продукта поручили разобраться с проблемой. Исследователю также сообщили, что вопрос вознаграждения будет рассмотрен в рамках программы Bug Bounty.

Однако спустя несколько дней позиция компании изменилась. Google заявила, что программное обеспечение работает так, как задумано, и не содержит уязвимости. В компании пояснили, что для атаки злоумышленнику сначала необходимо получить доступ к инфраструктуре организации, а также воспользоваться сервисной учётной записью Config Connector с расширенными правами. Такой уровень полномочий, по мнению Google, противоречит принципу минимально необходимых привилегий и рекомендациям самой компании.

О’Лири не согласился с такой трактовкой. Специалист утверждает, что проблема заключается не в наличии привилегированной учётной записи, а в отсутствии проверки полномочий пользователя перед выполнением действий от её имени. В опубликованной демонстрации для получения административного контроля над организацией потребовалось всего несколько строк конфигурации Kubernetes.

Дополнительные вопросы вызывает статус самой заявки. Несмотря на отказ в выплате и заявление об отсутствии уязвимости, отчёт до сих пор остаётся со статусом «принята, в работе». Google не объяснила, почему заявка не была закрыта окончательно, а также не выпустила исправление и не присвоила проблеме идентификатор CVE.

О’Лири отметил, что сталкивался с похожей ситуацией и ранее. В начале года Microsoft отклонила его сообщение о повышении привилегий в Azure Backup for AKS, после чего устранила проблему без публикации отдельного уведомления безопасности.

Кроме того, ситуация перекликается с недавним конфликтом между AMD и исследователем под ником MrBruh. Тогда компания тоже отказалась выплачивать вознаграждение за найденную проблему, несмотря на её последующее исправление. Подобные случаи всё чаще вызывают споры о прозрачности программ Bug Bounty и о том, насколько последовательно крупные технологические компании оценивают сообщения о потенциально опасных ошибках.