Хакер украл изображения с сайта и шантажирует. Что делать?

1602

Представьте, у вас два процветающих интернет-магазина. Однажды утром вы заходите в один из них и понимаете, что все изображения товаров исчезли. Посещаете второй интернет-магазин и видите то же самое. Вы пытаетесь найти источник проблемы, запускаете скрипты, пробуете восстановить визуализацию страниц, но тут приходит письмо от хакера: «Ваши изображения скомпрометированы, для восстановления переведите средства на мой счет в размере...»

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

Ход работ

Поиск источника компрометации

Изначально мы воспринимали исчезновение картинок как случайность. Да, был удален бакет в S3 с картинками (отдельные контейнеры для хранения объектов в объектном хранилище S3), но такое возможно.

Мы действовали по логичному алгоритму:

получили от клиента новые ключи для бакета;
восстановили картинки;
вновь обнаружили пропажу;
проверили скрипты и убедились, что нет скрипта, который бы самостоятельно удалял бакет;
получили новые ключи; вновь заметили исчезновение картинок;
подключили свое S3-хранилище, опасаясь, что компрометация происходит на стороне клиента при создании бакета

Картинки исчезли в четвертый раз. Повторяющаяся проблема даже после смены ключей и провайдера указывала на целенаправленные действия злоумышленников и на то, что у хакеров есть доступ к системному файлу с паролями.

Поиск уязвимых мест

Стали искать возможные уязвимости, через которые хакеры могли получить те самые пароли.

Выдвинули несколько гипотез:

Злоумышленники получили доступ к серверам через подозрительные авторизации и сомнительные команды — не подтвердилась.
Злоумышленники получили доступ к gitlab клиента — не подтвердилась.
Злоумышленники получили пароли через незащищенные файлы на production-площадке — подтвердилась. Можно было получить данные, перейдя по http-адресу и далее открыть доступ к бакетам. Проблема была в конфигурации production.

Устранение уязвимости

Мы скорректировали конфигурацию nginx production-площадки и устранили уязвимость. Далее создали новый бакет и сгенерировали новые ключи. Подключили наш бакет, восстановили картинки.

Прошло более 5 дней: проблем с картинками больше нет.

Разместите
тендер бесплатно

Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.

Заполнить заявку 13201 тендер
проведено за восемь лет работы нашего сайта.

Предотвращаем последующие атаки

Несмотря на то, что проблема решена, у хакеров остался файл с доступами, скачанный до устранения уязвимости. И это дает злоумышленникам возможности для последующих маневров и получения доступа к ресурсам. Поэтому нужно было продолжать профилактические работы, чем мы и занялись.

Важно: убираем уязвимости синхронно, действуя по следующему алгоритму:

Создаем новый ключ
Меняем настройки сайта и переключаемся на новый созданный ключ
Удаляем старый ключ из сервиса.
Сторонними лицами получен apache доступ и адрес, по которому обновляется товарная номенклатура с 1С, что позволяет просматривать товары и искать уязвимости в этом сервере: Клиенту необходимо сменить apache-авторизацию — срочность высокая;
Злоумышленники имеют доступ к базе данных. Без доступа к серверу это не является угрозой, но есть сопряжённые с этим риски: Клиенту необходимо поменять логин/пароль/название базы данных — срочность средняя;
У хакеров имеется секретный ключ приложения, который участвует в шифровке сессий и куки: Необходимо перегенерировать ключ приложения — срочность высокая;
Получен доступ к Rewriter API — сервису для перевода и переписывания текстов. Злоумышленник может израсходовать лимиты, и сервисом нельзя будет пользоваться: Клиенту следует поменять API-ключ для сервиса — срочность низкая;
В руках хакеров Recaptcha, и его компрометация позволяет злоумышленнику проводить фишинг сайта и заниматься спамом: Клиенту нужно заменить recaptcha — срочность высокая;
Получен доступ к Typesense, что позволяет злоумышленнику получать индексированные данные и спамить ресурс запросами: Клиенту необходимо заменить API-ключ — срочность высокая;
Хакерам удалось получить доступ на чтение 3D-моделей первого сайта клиента (точнее, к ресурсу, на котором они расположены). Доступ хоть и на чтение, но хакер знает ресурс и может пробовать искать уязвимости на этом сервере: Клиенту необходимо заменить пароль — срочность средняя.

Нюанс: проверяем все ресурсы и меняем ключи на всех сервисах. Чтобы не была нарушена работа сайта, клиент уведомлял нас о смене ключей, и мы оперативно меняли доступы. Работали слаженно и единой командой.

Проблемы и пути решения

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

У злоумышленника есть доступ к бакету с картинками. Он может самостоятельно удалять картинки: Клиенту нужно создать новый бакет с новыми ключами — срочность средняя;
У злоумышленника есть доступ на отправку форм в CRM. Это даёт ему возможность спамить в CRM, а также удалять обращения: Для CRM-сервиса клиенту необходимо сгенерировать новый ключ. Старый ключ сразу же удалить — срочность высокая;
Хакеры могут массово отправлять сообщения с адреса почты клиента. При спаме почту могут заблокировать, и потребуется время на то, чтобы доказать отсутствие спамных намерений: Клиенту необходимо поменять пароль для почты на более надёжный — срочность высокая;
Сторонними лицами получен apache доступ и адрес, по которому обновляется товарная номенклатура с 1С, что позволяет просматривать товары и искать уязвимости в этом сервере: Клиенту необходимо сменить apache-авторизацию — срочность высокая;
Злоумышленники имеют доступ к базе данных. Без доступа к серверу это не является угрозой, но есть сопряжённые с этим риски: Клиенту необходимо поменять логин/пароль/название базы данных — срочность средняя;
У хакеров имеется секретный ключ приложения, который участвует в шифровке сессий и куки: Необходимо перегенерировать ключ приложения — срочность высокая;
Получен доступ к Rewriter API — сервису для перевода и переписывания текстов. Злоумышленник может израсходовать лимиты, и сервисом нельзя будет пользоваться: Клиенту следует поменять API-ключ для сервиса — срочность низкая;
В руках хакеров Recaptcha, и его компрометация позволяет злоумышленнику проводить фишинг сайта и заниматься спамом: Клиенту нужно заменить recaptcha — срочность высокая;
Получен доступ к Typesense, что позволяет злоумышленнику получать индексированные данные и спамить ресурс запросами: Клиенту необходимо заменить API-ключ — срочность высокая;
Хакерам удалось получить доступ на чтение 3D-моделей первого сайта клиента (точнее, к ресурсу, на котором они расположены). Доступ хоть и на чтение, но хакер знает ресурс и может пробовать искать уязвимости на этом сервере: Клиенту необходимо заменить пароль — срочность средняя.

О бэкапах

Отдельное внимание уделим бэкапированию. Чтобы в случае возникновения таких непредвиденных ситуаций иметь возможность быстро и оперативно восстановить данные, необходимо делать бэкапы и регулярно проверять их на целостность данных.

В нашем случае мы видим, что бэкап бакета S3 не выполнялся. После настройки бэкапирования для бакета сайта следует проверить выполнение бэкапов для остальных систем.

Заключение

Наши эксперты рекомендуют дополнительно:

Менять пароли к системам после увольнения сотрудников (смены подрядчика);
Проводить мониторинг доступности ключевых систем инфраструктуры;
Подключать и проверять alert-чаты.

Мы продолжаем работу над двумя сайтами клиента. Даже в случае шантажа и хакерских атак у вас всегда есть минимум два выхода. Мы сделали выбор в пользу решений, которые защитили интересы нашего клиента и позволили решить проблему без потери средств из-за шантажа.