Хакер сообщил, что «тема закрыта», а напоследок выложил подробный технический разбор атаки - от первоначальной точки входа до доступа к внутренним базам и инфраструктуре.
Началось все 15 сентября. По словам хакера, к этому моменту он уже около двух недель находился внутри инфраструктуры TEZ TOUR, постепенно расширяя доступ. После публичного заявления о взломе началась своеобразная борьба с администраторами: сайт переводили в режим техработ, атакующий утверждал, что возвращал его обратно, после чего компания начала последовательно отключать внутренние ресурсы. Примерно через шесть часов публичной фазы серверы были остановлены, а использовавшийся для доступа SSH-ключ удален.
Причиной взлома, судя по опубликованному разбору, стала не какая-то «суперуязвимость», а целая цепочка достаточно банальных проблем. Точкой входа оказался забытый сервис upload.tez-tour.com: загрузчик запрещал
.php, но пропускал .pht, который Apache также мог выполнить как PHP. Это дало RCE внутри Docker-контейнера. Дальше - Squid без нормальной авторизации, доступ во внутреннюю сеть, Jenkins без логина и пароля, единый конфигурационный файл с паролями и ключами, а затем SSH-ключ без passphrase, который, как утверждается в разборе, подходил сразу к 46 серверам.Масштаб доступных данных автор оценивает достаточно внушительно. В основной Oracle-базе он заявляет о 45,4 млн записей о туристах, 252 млн финансовых транзакций, 21,5 млн заказов, 13,7 млн страховых полисов, 1,8 млн визовых заявок и 1,69 млн платежей. Отдельно упоминаются 182 тыс. пользователей ERP, причем, по его утверждению, практически у всех пароли хранились в открытом виде.
При этом полную базу в открытый доступ хакер не выкладывал, но утверждает что продал ее в один из сервисов пробива. В первые часы публиковался небольшой пример данных, который довольно быстро удалили, а позднее автор отдельно заявил, что полного публичного слива не будет. Поэтому все цифры о масштабах компрометации сейчас фактически основаны на заявлениях самого атакующего и опубликованном им техническом разборе.
Интересно и то, что позиции сторон до сих пор расходятся. TEZ TOUR подтверждает сам факт кибератаки, но заявляет, что признаков компрометации персональных данных туристов и партнеров не зафиксировано, а ключевой ERP-контур был изолирован.
В итоге история выглядит не столько как эксплуатация одной критической уязвимости, сколько как классическая цепочка: забытый сервис → RCE → плохо изолированная внутренняя сеть → открытый Jenkins → пароли в конфигах → доступ к БД и серверам. И вот такая цепочка уже действительно способна превратить один старый загрузчик файлов в проблему всей инфраструктуры.
В открытых источниках не удалось обнаружить сведения о последнем проведенном пентесте TEZ TOUR или компании, которая его выполняла.
#утечка #teztour