База лежала в открытом доступе пять месяцев, и никто её не взламывал
Полные копии базы с заказами и паролями клиентов лежали в открытой части сайта пять месяцев и скачивались по прямой ссылке. Признаков взлома не было ни одного - и это самое интересное в этой истории. Разбираю, как утекают базы через рабочий мусор и как проверить свой сайт.
Собственник спросил осторожно: "У нас же не могли слить базу?" Повод был - месяцем раньше на одном из его сайтов мы уже находили открытый архив. Я проверил все сайты, до которых у него есть отношение. Результат: на соседнем сайте лежали две полные копии базы данных, доступные любому человеку в интернете, - самой старой было пять месяцев.
Признаков взлома не было ни одного. Никаких подозрительных файлов, чужого кода и следов правок. Данные просто лежали так, что взламывать ничего не требовалось.
Утечка - это чаще всего не взлом
В голове у большинства владельцев сайтов утечка выглядит как хакер в толстовке. На практике типовой сценарий скучнее и обиднее: база утекает через рабочий мусор, который оставили свои же.
Плагин резервного копирования складывает копии базы в открытую часть сайта и хранит их месяцами. Подрядчик перенёс сайт и забыл убрать архив с установщиком. Кто-то поставил панель управления базой, чтобы разово посмотреть таблицу, и она осталась. Каждый шаг по отдельности выглядит безобидно, а вместе это готовый способ скачать всё содержимое компании, зная только имя файла.
Именно так выглядели три находки на этом аудите.
Копии базы в открытой части сайта. Две штуки, от марта и апреля, плюс архивы самого сайта на 162 мегабайта. Внутри - заказы клиентов с персональными данными, пароли всех пользователей сайта (зашифрованные, но подбираются офлайн и не спеша), ключи доступа интеграций. Рядом лежала копия служебного файла с логином и паролем от базы.
Архив сайта на 876 мегабайт на копии другого сайта - со всеми файлами и базой внутри. Такой архив разворачивается в один клик где угодно: у того, кто его скачал, появляется полная рабочая копия чужого бизнеса.
Открытая панель управления базой версии 2013 года на боевом сайте. Пароль она спрашивает, но для такой старой версии публично известны способы обхода, и это удобная точка для перебора.
Отдельно неприятная деталь: формально защита стояла. В папке с копиями лежал файл-запрет на скачивание - но конкретный хостинг для таких путей его игнорировал. По конфигу всё выглядело закрытым, по факту файлы отдавались наружу. Это ровно тот случай, когда проверять надо не настройку, а поведение.
Диск - это не то же самое, что интернет
Главная методическая ошибка в таких проверках - искать файлы на сервере и по факту находки объявлять утечку. Файл может лежать на диске и не отдаваться наружу, а может лежать в неожиданном месте и прекрасно скачиваться.
Поэтому порядок такой: сначала поиск по диску (все архивы, дампы, файлы с расширениями bak, old, save, остатки установщиков), затем каждый найденный файл проверяется обычным запросом из интернета. Вывод делается только по коду ответа сервера. И отдельно - обратная проверка: типовые адреса запрашиваются снаружи вслепую, даже если на диске ничего не нашлось, потому что доступа к диску может и не быть.
Смежные векторы, про которые забывают: доступен ли сервер базы данных напрямую из интернета (на этом хостинге - да, и пользователь базы принимал подключение с любого адреса, то есть добывшему пароль сайт уже не нужен), нет ли следов веб-шелла, что лежит на соседних сайтах того же аккаунта.
Сколько это было открыто и что теперь доказывать
Копии базы лежали с начала марта - пять месяцев. Логи доступа за такой срок хостинг не хранит, поэтому доказать, скачивал кто-то эти файлы или нет, невозможно в принципе.
Это важный практический вывод, а не формальность. Если в базе есть персональные данные клиентов, невозможность доказать отсутствие утечки означает, что исходить придётся из худшего: считать данные скомпрометированными, менять ключи и пароли, оценивать обязанности по 152-ФЗ. Разница между "у нас была дыра" и "у нас была утечка" стоит дорого, и определяется она наличием логов, которых обычно нет.
Правило, которое я соблюдаю жёстко: аудит ничего не меняет
Ни одного удаления, переноса или изменения прав на сайте клиента без его отдельного согласия. Даже когда дыра очевидна, даже когда правка обратима.
Причина простая. На сайте работает не только тот, кто заказал аудит: есть SEO-подрядчик, прежние разработчики, иногда сам собственник. Той самой панелью управления базой, судя по датам, кто-то регулярно пользовался. Молча снести её - значит сломать чужой рабочий процесс, а объясняться будет заказчик.
Логика такая: находки, потом отчёт, потом решение владельца, и только потом правки - с бэкапом до изменения. Файлы, к слову, были открыты уже пять месяцев; час до ответа собственника ничего не менял.
Что было на выходе
Два документа. Технический разбор - что где лежит, каким запросом это проверяется, что предлагается сделать. И отчёт собственнику человеческим языком: что нашли, чем это грозит, как давно открыто, что делать в порядке важности и сколько это займёт (получилось около трёх часов работы).
Плюс один вопрос, на который может ответить только он: панелью пользуются подрядчики - убираем сразу или сначала предупреждаем.
Что забрать себе
- Проверьте, куда ваш плагин бэкапов кладёт копии. Если внутрь сайта - у вас уже открытая база, вопрос только в том, нашли её или нет.
- После любого переезда сайта пройдитесь по остаткам: архивы, установщики, папки с названием installation, копии конфигов.
- Панель управления базой в открытой части сайта - это не удобство, это второй вход.
- Наличие файла-запрета не равно закрытому доступу. Проверяйте запросом из интернета, а не глазами по конфигу.
- Если персональные данные клиентов могли утечь, а логов нет - юридически вы в позиции "докажите, что не утекли". Логи стоят дешевле, чем эта позиция.
Новые разборы - на почту
Разборы задач автоматизации: что автоматизировать, сколько это стоит и что даёт в цифрах. Одно письмо на статью, без рекламы чужих продуктов.
