Хакер нашёл способ бесплатно питаться в McDonalds и множество других уязвимостей — исправлять их компания не спешила

Почему McDonald's три месяца не замечал дыру в своей системе: разбор уязвимостей от баг-хантера

Исследователь под псевдонимом BobDaHacker нашел в инфраструктуре McDonald's целый веер уязвимостей. И не просто нашел — он смог создать учетную запись на внутренней платформе, поменяв одно слово в адресной строке. Компания на это реагировала кварталами. Разбираемся, как так вышло и почему это не шутка.

Все началось с бесплатных наггетсов. BobDaHacker заметил, что мобильное приложение McDonald's проверяет бонусные баллы только на стороне клиента. То есть — любой мог запросить еду, не имея баллов вообще. Ошибка детская, но для безопасности — тревожный звонок.

Как дизайн-центр стал проходным двором

Попытка сообщить о проблеме провалилась — заявка ушла в никуда. Тогда исследователь полез глубже. Он наткнулся на портал Feel-Good Design Hub — внутреннюю платформу для сотрудников. И тут началось самое интересное.

Портал требовал авторизации. Но стоило заменить в URL login на register — как система любезно предлагала создать новую учетку. Никаких подтверждений от администратора, никаких invite-only ограничений. Просто форма регистрации.

«Требовалось всего лишь одно изменение в URL — и я получал доступ к сервису, который не предназначался для посторонних. Компания потратила три месяца, чтобы внедрить систему с разными путями входа. Но дыра оставалась», — рассказал BobDaHacker.

Мало того: при регистрации платформа отправляла пароль в открытом виде. Никакого шифрования, никакой защиты. В 2025 году такое — дикость. Даже небольшие стартапы перестали так делать лет пять назад.

API-ключи в JavaScript и уволенный помощник

BobDaHacker нашел и встроенные в JavaScript-код API-ключи и секреты. Это позволяло отправлять уведомления от имени McDonald's или запускать фишинговые кампании — прямо через официальную инфраструктуру.

Список найденных проблем:

• отсутствие серверной проверки бонусных баллов
• возможность неавторизованной регистрации на внутренней платформе
• отправка пароля в открытом виде
• API-ключи в клиентском коде
• отсутствие нормального канала связи для баг-репортов

Когда исследователь попытался снова сообщить об уязвимостях, ему пришлось звонить в штаб-квартиру, называть случайные имена из LinkedIn и надеяться, что кто-то свяжет его с нужным человеком. Это — не шутка. Именно так выглядит безопасность глобального бренда.

Как это работает: один шаг к взлому

Возьмем самый вопиющий пример — смену login на register. Обычно внутренние порталы закрыты для посторонних. Но разработчики не отключили маршрут регистрации для публичной сети. Злоумышленнику достаточно: 1) узнать URL портала (часто он публичный или утекает); 2) подставить /register в адрес; 3) заполнить форму — и система сама пришлет пароль. Все.

Личное наблюдение

Недавно я заметил, что крупные компании часто экономят на баг-баунти программах. Они считают: «мы большие, нас не взломают». А потом какой-то энтузиаст за бесплатные наггетсы находит дыры, которые могут стоить миллионы. McDonald's — не исключение. У них до сих пор нет нормального канала для сообщений об уязвимостях. Сотрудник, который помогал расследовать проблему, был уволен. Вместо благодарности — увольнение.

Таблица: что было и что должно было быть

Итог: исправления есть, доверия нет

McDonald's заявил, что «большинство уязвимостей» устранено. Но факт увольнения сотрудника, который помогал разбираться, и отсутствие нормального канала для исследователей говорят о культуре безопасности. Такое отношение — прямая дорога к следующему инциденту. И тогда наггетсами уже не отделаться.