Обнаружена уязвимость в панели управления хостингом Vesta CP

    В некоторых своих предыдущих статьях мы уже рассказывали о бесплатной панели управления Vesta CP. Сегодня утром мы получили тревожную информацию — в панели есть критическая уязвимость, позволяющая злоумышленникам получить доступ к серверу и производить с него DDoS атаки либо рассылать спам, что часто приводит к перерасходу трафика. Известные на текущий момент подробности, а также советы по защите чистого и очистке взломанного сервера, под катом.



    Первые уведомления о возможной уязвимости в Vesta 0.9.8-19 появились 7 апреля как в английской, так и в русской ветках форума панели. Симптомы у всех были схожими: резкий рост трафика и паразитической нагрузки на сервер. И по утверждениям людей, обслуживающих множество клиентских серверов, общее у них было только одно — Vesta CP.

    Вскоре последовали превентивные меры со стороны отдельных провайдеров — блокировка стандартного порта Весты (8083) на уровне сети провайдера, отключение провинившихся. Тем временем разработчики самой панели пытались связать взломы со своим продуктом. И нельзя сказать, что успешно.

    По утверждениям самих разработчиков, им не удалось достоверно установить и воспроизвести вектор атаки, однако они выпустили хотфикс, закрывающий некоторые прорехи, которые могли послужить причиной. А именно, поправили авторизацию и сделали проверку паролей более строгой. Пока что не поступало информации об успешных взломах обновлённой Vesta 0.9.8-20, однако тот факт, что разработчики не смогли достоверно установить сам вектор атаки, держит пользователей в некоторой напряжённости. Ниже мы приводим некоторые рекомендации из сети по предотвращению взлома и по борьбе с последствиями.

    Что делать, если Ваш сервер ещё не взломали?


    Большинство приведённых ниже рекомендаций относятся не только к серверам с Vesta CP, но и к любому другому Linux серверу.

    • Первым делом, обновите панель, выполнив команду:

      v-update-sys-vesta-all
      
    • Смените в /usr/local/vesta/nginx/conf/nginx.conf стандартный порт 8083 на какой-либо другой по Вашему усмотрению.
    • Используйте нестандартный порт SSH. По возможности используйте вход по ключам.
      Также желательно отключить вход под root из мира.
    • Скачайте и запустите Linux Environment Security.
    • Скачайте и установите Linux malware detect. После установки запустите первичный анализ системы на уже существующие проблемы: maldet -a / (и проанализируйте отчёт). Если всё в порядке, запустите мониторинг: maldet --monitor /. Не забудьте указать свою электронную почту для получения отчётов в /usr/local/maldet.conf.
    • Ещё один очень полезный инструмент, который стоит установить — Config Server Firewall. Внимательно изучите файл конфигурации и обязательно включите отслеживание изменений директорий и файлов.
    • Если у Вас не ожидается пользователей, клиентов или посетителей из Китая — заблокируйте его весь на уровне фаервола.
    • Установите приложение для мониторинга трафика. Например, ntopng.

    А если уже взломали?


    Пятна Последствия от данной атаки устраняются достаточно непросто, потому, если у Вас есть такая возможность, советуем использовать Vanish слить бэкапы (о необходимости их делать мы напоминали не раз) и переустановить сервер. Сложность заключается в том, что Trojan.DDoS_XOR-1 (он же Chinese Chicken Multiplatform DoS botnets Trojan), которым было заражено большинство скомпрометированных машин, очень эффективно самовосстанавливается, и для его удаления нужны определённые танцы с бубном (описаны ниже). Другая сложность — возможна банальная перегрузка сервера паразитическими процессами, что существенно усложнит Вашу работу с сервером вне rescue mode (которого может и не существовать в принципе, если Вы используете VPS).

    Если же возможности просто переустановить всё нет, попробуйте проделать следующее.

    1. Проверьте, есть ли симптомы заражения Trojan.DDoS_XOR. Проявляется он в выводе top как файл со случайным именем вида H8wuaqwiu, S01wefiouh8 и т.п. либо как системная команда, порой даже не предполагающая длительного исполнения: ls, ifconfig, pwd, ping, awk, telnet…

      Второй симптом — наличие .sh файла в папке ежечасного крона. Проверить можно командой ls -la /etc/cron.hourly/. Файл часто называется gcc.sh, cron.sh, но возможны и другие имена.
    2. Посмотрите содержимое .sh файла. Например, командой cat /etc/cron.hourly/gcc.sh. Для файла характерно примерно следующее содержимое:
      #!/bin/sh
      PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin:/usr/X11R6/bin
      for i in `cat /proc/net/dev | grep: | awk -F: {'print $ 1'}`; do ifconfig $ i up & done
      cp /lib/libudev.so /lib/libudev.so.6
      /lib/libudev.so.6
    3. Вляпались? Не спешите суетиться, троян восстанавливает свои файлы быстрее, чем вы успеете их все удалить. Но он будет пытаться использовать те же самые имена файлов, так что блокировка должна помочь:

      chmod 0 /etc/cron.hourly/gcc.sh; chattr +ia /etc/cron.hourly/gcc.sh;  chattr + i /etc/crontab
    4. И процесс полностью убивать тоже бесполезно, рекомендуется сначала его остановить,
      чтобы троян не пытался его перезапустить. В выводе команды top найдите процесс, вызвавший подозрение (к примеру, S01wefiouh8), и выполните:

      kill -STOP 16621
    5. Найдите исполняемые файлы и заблокируйте их. Для поиска используйте команду find /etc -name '* S01wefiouh8 *'. Для найденных файлов выполните chmod 0 /имя/файла; chattr +ia /имя/файла.
    6. Удалите исполняемые файлы, найденные в /usr/bin (с помощью ls -lt /usr/bin | head можете поискать другие, вызывающие подозрение):

      rm -f /usr/bin/S01wefiouh8
    7. Теперь можно добить остановленный процесс:

      pkill mtyxkeaofa
    8. И наконец, удалите тело вируса:

      rm -f /lib/libudev*.so

    Если Вы — хостер или сисадмин, и Вам нужно оставить доказательство для клиента, остальные файлы можете пока не трогать. Если нет — удалите все остальные «примороженные» файлы. Также, если Вам не удалось самим определить вредоносные файлы, воспользуйтесь ClamAV или RKHunter и посмотрите их отчёт.

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

    Спасибо, что остаётесь с нами. Вам нравятся наши статьи? Хотите видеть больше интересных материалов? Поддержите нас оформив заказ или порекомендовав знакомым, 30% скидка для пользователей Хабра на уникальный аналог entry-level серверов, который был придуман нами для Вас: Вся правда о VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps от $20 или как правильно делить сервер? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40GB DDR4).

    Dell R730xd в 2 раза дешевле? Только у нас 2 х Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 ТВ от $249 в Нидерландах и США! Читайте о том Как построить инфраструктуру корп. класса c применением серверов Dell R730xd Е5-2650 v4 стоимостью 9000 евро за копейки?
    • +15
    • 6,5k
    • 5
    ua-hosting.company
    667,00
    Хостинг-провайдер: серверы в NL / US до 100 Гбит/с
    Поделиться публикацией

    Комментарии 5

      0
      Правильно ли я понял, что ограничив доступ на VPS в панель по IP, я тем самым предотвратил возможность использования уязвимости?
        0
        Не обязательно, так как были случаи, когда пользователи разрешали доступ только для их IP, либо вовсе закрывали порт 8083, и все равно были взломаны. Боюсь панель тут может быть ни при чем…
          0
          Т.е. дело не в VestaSP? Тогда только shh::non_root, но это тоже реализовано. Не святым же духом проникают на сервера?
            0
            Точно сказать пока сложно, нужно больше времени для тестов и исследований
          0
          Судя по некоторым сообщениям с форума
          i got hacked on debian 9 with blocked port 8083 -> only available to my ip via iptables
          этого может быть недостаточно.

        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

        Самое читаемое