КИБЕРБЕЗОПАСНОСТЬ

Полиция Нидерландов задержала подозреваемого по делу о взломе Ajax

35-летнего жителя Бюрена задержали по делу о взломе Ajax: инцидент показал, как уязвимости в API и ключах открывают доступ к билетам и данным фанатов.

✍️ Редакция iTech News | 28.05.2026 | ⏱ 4 мин | Источник: BleepingComputer
Полиция Нидерландов задержала подозреваемого по делу о взломе Ajax

Полиция Нидерландов задержала 35-летнего мужчину по делу о взломе Ajax Amsterdam, и эта история интересна не только футбольным болельщикам. Если уязвимость позволяет не просто читать данные, а менять запреты на посещение стадиона, перекидывать билеты и трогать десятки тысяч учетных записей, это уже не локальный инцидент клуба, а вполне показательный кейс для любой цифровой платформы с личными кабинетами, правами доступа и API.

Как пишет BleepingComputer, утром 26 мая нидерландская полиция задержала жителя муниципалитета Бюрен, которого подозревают в неоднократном незаконном доступе к системам Ajax. По данным полиции, клуб столкнулся с компрометацией в начале 2026 года: подозреваемый сам предоставил себе доступ к внутренним системам, после чего началось расследование. После задержания силовики обыскали его дом и изъяли несколько носителей данных для дальнейшей экспертизы. Формулировка сухая, но для службы безопасности любой компании звучит знакомо: злоумышленник не просто «постучался в дверь», а заходил в систему несколько раз.

Сам Ajax публично раскрыл инцидент в конце марта. Тогда клуб сообщил, что атакующий использовал уязвимости в IT-системах и получил доступ к данным нескольких сотен человек. Это уже неприятно, но дальше история становится заметно хуже. Та же уязвимость позволяла изменять стадионные запреты менее чем для 20 человек и передавать купленные билеты другим пользователям. Иными словами, речь шла не только о персональных данных, но и о вмешательстве в бизнес-логику сервиса: кто может попасть на матч, кто не может и кому в итоге принадлежит билет.

Самые неприятные детали пришли из публикации RTL, на которую ссылается BleepingComputer. По этим данным, слабое место было связано с API и общими ключами доступа, а сам хакер показал, что VIP-абонемент можно перепривязать за считаные секунды. Там же утверждается, что через этот дефект можно было манипулировать 538 запретами для болельщиков, затронуть 42 тысячи сезонных абонементов и просматривать сведения более чем о 300 тысячах учетных записей. Для любого IT-директора это уже не «инцидент вокруг фанатского кабинета», а очень дорогой разговор о сегментации доступа, управлении секретами и о том, почему общий ключ в API однажды превращается в универсальный пропуск туда, куда ему ходить не положено.

Взлом Ajax хорошо показывает разницу между утечкой и управленческим провалом в цифровом продукте. Когда злоумышленник видит список имен и e-mail, это одна категория проблем. Когда он может переприсвоить билет, изменить запрет на вход или получить доступ к массовому набору аккаунтов, вопрос уже не только в compliance и уведомлении регулятора. Это сбой в модели авторизации, в проверках на уровне бизнес-операций и, возможно, в базовой гигиене разработки. Если API доверяет shared key больше, чем контексту конкретного пользователя и его правам, сервис рано или поздно начинает обслуживать не того клиента.

Для разработчиков и продуктовых команд здесь мало романтики и много практики. Инцидент вокруг Ajax напоминает, что самые болезненные уязвимости часто живут не в экзотических zero-day, а в привычных связках: плохо изолированные API, переиспользуемые ключи, избыточные права сервисных учеток, слабые проверки на объектном уровне и операции, которые технически доступны, хотя логически не должны быть доступны почти никому. Особенно это касается платформ с билетами, подписками, программами лояльности, CRM-модулями и любыми системами, где пользовательская запись связана с денежной ценностью или ограничениями доступа. Если через один маршрут можно и посмотреть профиль, и переназначить актив, и обойти санкцию, значит, продукт давно просит не только pentest, но и нормальный пересмотр архитектуры доверия.

Ajax после инцидента устранил уязвимости и уведомил нидерландский орган по защите данных и полицию. Это правильный минимум, но в таких историях важнее другое: насколько быстро компания понимает, что взлом затронул не витринный слой, а механику самого сервиса. Спортивный клуб здесь просто удобная декорация. Тот же набор ошибок легко представить в банке с бонусной программой, у авиаперевозчика с милями, у маркетплейса с сертификатами или у SaaS-платформы с корпоративными ролями. Разница только в том, кто именно потом объясняет клиентам, почему «это был единичный случай» и почему у злоумышленника внезапно оказалось слишком много возможностей.

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

Поделиться: Telegram X LinkedIn