Реконструкция событий
Артемий Шохор, корреспондент ADPASS
Судя по тому, как долго не могут восстановить нормальную работу видеохостинга, резервные копии, которые обязательно должны быть, не могут быть использованы.
Процесс создания резервных копий автоматизирован, они обновляются по заданному графику. Файлы резервных копий хранятся на другом сервере. И никто не проверяет, что находится в файле rutube_backup_080522. Резервирование прошло, файлы есть, система это видит, все хорошо. То, что хранится внутри этих файлов, обычно никто не проверяет. В случае нестабильной работы основного сервера восстановить предыдущую копию очень просто и делается это парой команд.
Но для того, чтобы сделать невозможным восстановление резервной копии и чтение её файлов, данные нужно перезаписать или зашифровать. И тот, и другой процессы достаточно долгие, учитывая объем данных. Из этого можно сделать вывод, что атака произошла не 9 мая, а началась несколько раньше. Она состояла из двух частей. Сначала был уничтожен бэкапы, а 9 мая работающая версия видеохостинга.
9 мая мы были ознакомлены с «результатом».
Подтверждением этого может служить заявление в телеграмм-канале RuTube, вышедшее ночью 11 мая. В нем специалист компании Positive Technologies сообщает, что в данный момент они работают над поиском и удалением инструментария, который могли оставить за собой хакеры.
Подробно и точно о методах совершения этой атаки мы не узнаем, скорее всего, никогда.
Однако масштаб разрушений говорит о том, что уровень прав, которым воспользовались хакеры, был максимальным. Им были доступны не только административная панель RuTube, предположительные скриншоты которой сейчас можно найти в Сети, но и доступ к серверам. Это совсем не похоже на взлом с использованием возможных уязвимостей программного обеспечения.
Скорее всего, хакерами были получены необходимые логины и пароли.
Вопрос только в том, где они их взяли.
Наиболее вероятным, сходятся во мнении эксперты, является то, что хакерам совсем не нужно было что-то взламывать для получения этих логинов и паролей. Они у них просто были. А возможно, они даже разрабатывали RuTube или его часть. Над созданием проектов такого масштаба обычно работает несколько команд программистов. Подрядчик распределяет задачи субподрядчикам, те выполняют работу. Субподрядчик может находиться, где угодно: в России, в Беларуси, в Украине или на Кипре. Это не важно. После завершения работ у субподрядчика отзывались права доступа. И тут возникает вопрос: были ли эти права отозваны? Это вопрос к службе безопасности RuTube, если такая есть.
Теперь немного о последствиях. Любой сайт состоит из нескольких основных элементов: клиентской части, с которой взаимодействует пользователь (фронтэнд), панель администратора (бэкенд), файлов данных (в данном случае видеофайлов) и базы данных, которая соединяет между собой предыдущие три элемента и позволяет им взаимодействовать. Наиболее ценными, с точки зрения работоспособности сайта, являются три: фронтэнд, бекенд и базы. Судя по заявлению Rutube, файлы данных повреждены не были. Судьба остальных частей и возможность их восстановления и запуска пока не известны.
Днем 11 мая Александр Моисеев, генеральный директор Rutube в телеграмм-канале видехостинга заявил, что компания успешно завершила первый этап восстановления функционала платформы и намерена «запустить видеохостинг сегодня». По его словам, в данный момент на платформе проводится нагрузочное тестирование и дополнительная проверка на уязвимость.
Из этого заявления можно сделать вывод, что данные из резервных копий восстановлены или расшифрованы. Стоит подождать вечера и перезапуска вылеченного Rutube.