Уязвимость Microsoft Titan позволила 16-летнему исследователю Faav получить права администратора во внутреннем аналитическом сервисе Microsoft и запускать SQL-запросы без валидных учетных данных. По данным The Register, потенциальная зона доступа включала аналитические базы, где метаданные указывали примерно на 17,3 трлн сохраненных строк. Для разработчиков и команд безопасности это не история про везучего школьника, а неприятное напоминание: если JWT не проверяется по подписи, остальная красота auth-логики превращается в декорацию.
Titan, судя по описанию, является внутренней аналитической платформой Microsoft: веб-интерфейс закрыт для сотрудников компании, но API оказался доступен через хост Azure Cloud Services. Faav использовал собственного AI-бота для поиска уязвимостей Antares. 25 августа тот нашел публичный API Titan, после чего исследователь около десяти дней разбирался с ошибками аутентификации, JWT и user principal name. Прорыв случился рано утром 5 сентября: вместо email-идентификатора Faav подставил в неподписанный токен значение admin. Titan принял его как локальное имя пользователя, сопоставил с локальным ID 1, где была роль администратора, и разрешил выполнять SQL.
Ключевая ошибка звучит почти буднично: сервис проверял содержимое токена — tenant, audience, app ID и пользователя, — но не проверял подпись. Именно подпись в JWT отвечает за то, что токен действительно выпущен доверенной стороной и не был изменен по дороге. Если этот шаг пропущен, злоумышленник может собрать внешне убедительный токен сам. В случае Titan это открыло путь к локальному поиску пользователей и, в итоге, к админской роли. Никакой магии, только один пропущенный контроль в самом чувствительном месте.
Сначала исследователь получил доступ к metadata database платформы. Там, по его данным, были около 25 тыс. учетных и email-записей, 17 990 email сотрудников, 15 001 запись об организационной структуре, 355 конфигураций баз данных, 20 979 SQL-описаний виртуальных датасетов, 24 569 дашбордов, 425 891 график и 27 347 определений датасетов. Отдельно Faav указал, что каталог пользователей и использования содержал должности, отделы и управленческую иерархию сотрудников. Это не парольная база, но для фишинга и социальной инженерии такой справочник был бы подарком с бантом.
Дальше масштаб стал совсем корпоративным. Faav проверил 56 routing values из архивной конфигурации и обнаружил, что 30 из них все еще активны. Эти значения вели к 24 конфигурациям и 17 подключенным аналитическим базам, охватывающим 9 863 уникальных имени таблиц. Оценка в 17,3 трлн строк, по словам исследователя, получена из метаданных и, вероятно, включает исторические, дублированные и производные данные. То есть это не обязательно 17,3 трлн строк уникальной пользовательской информации, но число все равно достаточно большое, чтобы у любого владельца data platform дернулся глаз.
В источнике также упоминается Bing analytics sample: Faav проверил две строки, где были поисковые данные, идентификаторы и высокоуровневая география вроде страны или штата. Он отдельно уточнил, что точных пользовательских локаций там не было. Это важная оговорка: громкая цифра про триллионы строк не равна доказанному массовому доступу к чувствительным данным пользователей. Но сам факт, что подросток с исследовательским ботом дошел до таких связей во внутренней аналитике крупного облачного вендора, выглядит достаточно серьезно без лишнего драматизма.
Microsoft отреагировала по процедуре coordinated vulnerability disclosure. Между 6 и 8 сентября компания попросила Faav остановить тестирование и предоставить IP-адрес, чтобы подтвердить отсутствие действий за пределами bug bounty-исследования. Затем endpoint был закрыт, а 17 сентября исследователь получил выплату в 5 тыс. долларов. В заявлении для публикации Microsoft поблагодарила Faav за отчет и сообщила, что его находка помогла усилить защиту сервисов. Еще один любопытный штрих: перед публикацией Microsoft попросила исследователя переписать часть блога, убрать отдельные секции и числа, а также смягчить описание влияния.
Для команд разработки мораль довольно прямая: уязвимость Microsoft Titan возникла не из-за экзотического zero-day, а из-за ошибки в базовой проверке доверия. Проверка claims без проверки подписи — это почти как бейдж с любым именем на входе в дата-центр: выглядит официально, но ничего не доказывает. В production-коде такие вещи должны ловиться библиотеками, тестами, threat modeling и ревью auth-flow, а не ночным экспериментом исследователя после школьных заданий.
Эта история еще раз показывает, куда движется безопасность больших платформ: все чаще находки рождаются на стыке человеческого упорства и автоматизированных помощников, которые быстро перебирают поверхности атаки. Уязвимость Microsoft Titan закрыта, bounty выплачен, но вопрос остается шире одного сервиса: сколько внутренних API в крупных компаниях выглядят закрытыми только потому, что никто снаружи еще не нашел правильную дверь?
