Взлом Tez Tour: форма загрузки файлов, плоская сеть и бэкапы рядом с сайтом
15 сентября 2026 года группировка DataSuckers заявила о компрометации инфраструктуры туроператора Tez Tour. На главной странице компании появилось сообщение о захвате серверов. Компания факт взлома подтвердила, но оценивает последствия существенно мягче.
Разбираем, что известно, где стороны расходятся и какие системные ошибки в этой
истории повторяются из инцидента в инцидент.
---
## Что заявляют атакующие
На подменённой главной странице Tez Tour было размещено обращение к клиентам и
администраторам компании, а также перечень якобы скачанных и уничтоженных
данных:
| Категория | Заявленный объём |
|---|---|
| Записи бронирования | 45,4 млн |
| Заказы туров | 21,5 млн |
| Бронирования отелей | 52 млн |
| Финансовые транзакции | 252 млн |
| **Заявленный итог** | **более 395 млн записей** |
По версии DataSuckers, доступ к инфраструктуре был получен примерно за две
недели до публичного заявления, после чего злоумышленники постепенно
расширяли привилегии. Отдельно они утверждают, что администраторы использовали
устаревшие версии ПО с известными уязвимостями, а резервные копии хранились на
том же сервере, что и сайт.
## Что говорит компания
Tez Tour факт инцидента подтвердила «Интерфаксу», но описывает картину иначе.
По словам коммерческого директора Воскана Арзуманова, инцидент затронул работу
сайта, однако признаков утечки данных туристов и партнёров не выявлено.
Ключевые тезисы компании:
- сразу после обнаружения несанкционированной активности были приняты меры по
локализации и защите информационных систем;
- **ERP-система была своевременно изолирована и не пострадала**;
- действующие бронирования сохраняются, обязательства перед клиентами
выполняются в штатном режиме.
## Заявленная цепочка атаки
Здесь нужна важная оговорка: **все технические детали исходят исключительно от
DataSuckers**. Независимого аудита или отчёта форензики на момент публикации
нет. Ниже — реконструкция по заявлению атакующих, а не установленный факт.
**1. Точка входа — сервис загрузки файлов.** Сервис позволил загрузить файл,
который веб-сервер впоследствии обработал как PHP-код. Классическая
unrestricted file upload с последующим выполнением кода: контроль на стороне
приложения проверял то, что можно подделать (расширение, заявленный
MIME-тип), и не проверял то, что имеет значение, — фактическое содержимое и
то, как сервер будет интерпретировать файл.
**2. Выполнение команд внутри Docker-контейнера.** Атакующие получили
возможность запускать команды в контейнере, обслуживающем веб-приложение.
**3. Плоская внутренняя сеть.** Сам контейнер, по заявлению группы, был
изолирован. Но из него была доступна внутренняя сеть компании с корпоративными
сервисами. Это критическая точка всей истории, и к ней мы вернёмся отдельно.
**4. Учётные данные в исходном коде.** Из внутренней сети атакующие добрались
до SVN-репозиториев с исходным кодом и конфигурационными файлами,
содержавшими пароли от баз данных.
**5. Tomcat Manager и продакшен.** Доступ к интерфейсу Tomcat Manager дал
возможность разворачивать и выполнять код уже в продуктивной среде.
---
## Что в этой истории действительно важно
### Изоляция контейнера не равна сегментации сети
Самый ценный урок инцидента находится в пункте 3. Контейнер был изолирован —
и это не помогло совершенно.
Контейнеризация решает задачу изоляции процессов и файловой системы. Она **не
решает** задачу сетевой сегментации. Если из веб-контейнера в DMZ открыт
сетевой доступ к внутренним корпоративным сервисам, то любое выполнение кода в
этом контейнере автоматически превращается в плацдарм внутри периметра.
Практический вывод: для каждого контейнера и каждой публично доступной рабочей
нагрузки должен существовать явный, документированный список того, куда ей
разрешено ходить. Всё остальное — deny by default. Проверяется это не
архитектурной схемой, а фактическим тестом связности из контейнера.
### Пароли в конфигах в системе контроля версий
SVN-репозиторий с конфигурационными файлами, содержащими пароли от
продуктивных БД, — это не уязвимость одного дня. Это накопленный технический
долг, который превращает любой доступ к репозиторию в полную компрометацию
данных.
Здесь помогают три вещи: вынос секретов в специализированное хранилище
(HashiCorp Vault, облачные KMS, на худой конец зашифрованные переменные
окружения), автоматическое сканирование репозиториев на секреты в CI/CD, и —
обязательно — ротация всех секретов, которые когда-либо попадали в историю
коммитов. Удаление файла из HEAD не удаляет пароль из истории.
### Бэкапы на том же сервере
По заявлению атакующих, резервные копии хранились на одном сервере с сайтом.
Если это подтвердится, то компрометация веб-сервера означала одновременную
потерю и продуктива, и средств восстановления.
Правило 3-2-1 существует ровно для этого сценария: три копии данных, на двух
разных носителях, одна — вне площадки, и как минимум одна копия должна быть
логически недоступна из продуктивной среды (offline, immutable-хранилище или
WORM).
### Открытый Tomcat Manager
Интерфейс управления сервером приложений, доступный из внутренней сети без
дополнительного контроля, — прямая дорога к выполнению кода в продакшене.
Административные интерфейсы (Tomcat Manager, панели CI/CD, консоли
гипервизоров, веб-морды СУБД) должны быть доступны только из выделенного
административного сегмента, за MFA и с обязательным логированием каждой
сессии.
### Две недели присутствия
Заявленный dwell time примерно в две недели — это не про изощрённость
атакующих. Это про отсутствие детекта. Постепенное расширение привилегий,
разведка внутренней сети, обращение к SVN, деплой через Tomcat Manager —
каждый из этих шагов производит телеметрию. Проблема в том, что её никто не
собирал и не анализировал.
---
## Короткий чеклист
Если вы читаете это как руководитель ИТ или ИБ, шесть вопросов, которые стоит
задать своей команде сегодня:
1. Какие публично доступные формы принимают файлы, и проверяем ли мы
содержимое, а не расширение?
2. Куда фактически может дойти по сети наш веб-контейнер? Проверено тестом
или предполагается?
3. Есть ли пароли в наших репозиториях — включая историю коммитов?
4. Существует ли хотя бы одна копия бэкапа, недоступная из продуктивной
среды?
5. Кто и откуда может открыть Tomcat Manager, панель CI/CD, консоль
гипервизора?
6. Если злоумышленник проведёт в нашей сети две недели, какой конкретно
алерт мы увидим?
Шестой вопрос — самый неудобный и самый важный.
---
*Материал подготовлен на основе публичных заявлений сторон. Технические
детали цепочки атаки приводятся по заявлению группировки DataSuckers и не
подтверждены независимым аудитом. Позиция компании приводится по публикации
«Интерфакса»: https://www.interfax.ru/russia/1116299*