LSR / Взлом сервера glee.c4b / 13.09.23

Описание

// вкратце что произошло//

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

Описание будет построено следующим образом:

  • таймлайн событий взлома
  • анализ логов и происходящего на сервере
  • диагностика, графики и показательные скриншоты
  • меры предотвращения

Предпринятые действия

// таймлайн с описанием //

  • 11.09.23 - первый взлом системы. Выглядел он таким образом: злоумышленник пытался получить доступ к серверу, однако у него ничего не получилось (скриншот 1), а затем зашел в личный кабинет нашего провайдера услуг (скриншот 2)

Скриншот 1

Скриншот 2

  • 11.09.23 - первый запрос в техническую поддержку провайдера. Из сообщений следует, что злоумышленник пытался получить доступ к серверу по ssh, однако у него ничего не получилось. Так как тикет в поддержке удален, но остались ответы поддержки на почте, то можно предположить следующий алгоритм действий - злоумышленник написал запрос в систему с просьбой предоставить ему ssh-доступ. Когда поддержка сообщила, что сделать этого не может, он спросил, если система будет переустановлена, что произойдет в таком случае?

Cкриншот 3

  • 11.09.23 - по логам и сохраненным данным самого сервера можно видеть, что злоумышленник 11 сентября пыталяся поставить графическую оболочку на серверную систему - Sep 11 12:01:54 sudo apt install xfce4, а также выполнил ряд других безопасных для пользовательских данных команд

  • 11.09.23-13.09.23 - в этот промежуток времени последовало несколько перезагрузок серверов lumina, aurora, glee и cult. Вероятнее всего, злоумышленник просто "тыкал" по кнопкам в панели управления, однако аудит безопасности показал, что данные и сервера lumina, aurora, cult не были скомпроментированы

  • 13.09.23 20:15 - злоумышленник создает новый тикет в панели управления с просьбой предоставить KVM-доступ на сервер (KVM доступ позволяет получить доступ к "экрану" сервера даже в случае, если он выключен или не подключен к интернету)

  • 13.09.23 21:22 - злоумышленник выполняет команду sudo poweroff (судя по логам) на сервере. В этот момент сервер выключается

Cкриншот 4

  • 14.09.23 00:14 - начинаем длительное общение с поддержкой. Предоставленный KVM-доступ не работал. Вероятнее всего, это произошло из-за того что злоумышленник "держал" KVM, и мы не могли одновременно с ним использовать одну сессию, которая предоставляет доступ к серверу. С нашей стороны ошибка выглядела довольно примитивно - network error

  • 14.09.23 00:30 - общение с поддержкой продолжалось, а вместе с ним попытки получить KVM доступ различными способами - использование VPN соединений, других компьютеров (windows, macos), однако никакого успеха это не дало. Параллельно с этим мы анализировали доступные нам логи, о которых напишем ниже

  • 14.09.23 01:07 - мы начали получать первые уведомления от системы алертинга, которые касались восстановления работы сервера glee. Также мы получили скриншот от поддержки из KVM, на нем видна графическая оболочка - в этот момент мы окончательно подтвердили свою гипотезу о взломе и готовились к худшему

Скриншот 5

Анализ

// анализ описания //

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

  1. злоумышленник не имел достаточно технических знаний, чтобы причинить серьёзный ущерб инфраструктуре хостинга и данным клиентов;
  2. всё произошедшее - чистое стечение обстоятельств.

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

Первые ip-адреса и упоминание нашего злоумышленника появились в нашей системе superhub.host уже после взлома сервера. То есть человек мог фактически не знать о том, что glee - нода хостинга. Он мог перебором (брутфорсом) подобрать пароль к нашей панели управления и затем получить доступ к самому серверу. Возможно, изучая систему, он нашел упоминание superhub, однако если первый взлом был в 12:01 11 сентября, то первые логи с его ip-адресом появились примерно через несколько часов.

Скриншот 6

Так как никакие данные не были удалены или даже не было оставлено никакого "сообщения" нам (мы рассматривали также вопрос конкуренции), то мы можем сделать однозначный вывод - слитые базы клиентов с паролями одного из наших провайдеров, брутфорс по системе и мы - первая цель этого кулхацкера.

Однако очевидно, что это было безумно страшно и в какой-то мере опасно, но после детального (а мы действительно логируем всё, что происходит) анализа всех систем (даже удаленно, да-да) мы пришли к выводу, что пользовательские сервера не были затронуты. И даже сервер не пришлось переустанавливать.

Какие же выводы мы делаем из этого?

Что мы уже успели сделать:

  1. мы превентивно поменяли все пароли во всех используемых нами системах
  2. провели аудит безопасности и журналы посещения тех или иных личных кабинетов
  3. еще раз проверили нашу систему на алертинг при логине через ssh - всё работает

Что еще планируем:

  • добавить некоторую аналитическую платформу на анализ угроз на сервере, которая в режиме реального времени будет оповещать нас о том, что происходит что-то неладное.

И напоследок - никакие пользовательские данные (почты, пароли, деньги и банковские карты) не были затронуты. Superhub не хранит такую информацию на нодах хостинга. Как российский провайдер, мы соответствуем закону о защите персональных данных и осуществляем исключительно целенаправленный доступ к ним только авторизованным сотрудникам.

Какие сервисы затронуты

// список сервисов //

  • glee.c4b - выключение и недоступность ноды

Приносим свои извинения из-за недоступности ноды glee.c4b