Взлом сервера через эксполит на сайте

Очевидно, что если у сайта есть уязвимости, то его можно взломать с помощью веб-атак. Но даже если сайт защищен техническими средствами, работает на надежной CMS, его все равно могут скомпрометировать. Каким образом это происходит и как защищать сайт от различных вариантов взлома не через веб-уязвимости — oб этом рассказал на

«1С-Битрикс» Григорий Земсков, руководитель компании «

».

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

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

Увы, все эти «мифы» — про использование лишь веб-атак для взлома сайтов, про защищенность CMS и достаточность технических мер, приводят к новым массовым взломам сайтов. Что же делать, чтобы этого не происходило? Необходим комплексный подход к вопросу безопасности сайта. Далее мы рассмотрим, почему нужно уделять постоянное и пристальное внимание как техническим средствам защиты, так и организационным мерам. Это важно хотя бы потому, что существует много вариантов взлома сайтов, которые выполняются нетехническими методами и без использования веб-уязвимостей.

Варианты взлома сайтов

Все варианты взлома сайтов можно условно разделить на три большие группы (выделены жёлтым, голубым и серым цветом):

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

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

Итак, рассмотрим варианты по-порядку. Начнем с самой многочисленной группы, взлом сайта посредством веб-атак:

• В большинстве случаев это становится возможным в результате эксплуатации уязвимостей
  • в скриптах CMS, в плагинах и модулях. Разработчики допускают ошибки: недостаточно фильтруются входные параметры, не проверяются размещаемые в базе данные, информация выводится на странице «как есть», без безопасных преобразований.
  • в доработках. Можно поставить безопасную CMS, но при этом позвать неопытного разработчика. Он допишет плагин, в который внесет иногда не одну критическую уязвимость и через них взломают сайт. Веб-программист должен быть знаком с принципами безопасной разработки, а владельцу сайта следует обращаться к опытным подрядчикам.
• Второй вариант взлома сайта возможен благодаря брутфорсу панелей администрирования, то есть подбору логинов/паролей. Это очень распространённый тип атаки, особенно на защищенные CMS. По-прежнему пользователи устанавливают короткие или словарные пароли, которые с легкостью перебираются злоумышленниками и могут быть подобраны за конечное время. В результате доступ к админ-панели можно получить буквально за несколько минут. Ситуация усугубляется тем, что доступ в панель администратора обычно не ограничивается дополнительными средствами, такими как двухфакторная аутентификация, разрешенным списком IP-адресов, а число неверных попыток входа не ограничено.

Защита от веб-атак

Избавиться от веб-атак нельзя, но им можно противодействовать. Ниже представлен список мер против взлома через веб.

1. Необходимо обновлять CMS и скрипты. С каждой новой версией выходят патчи безопасности: закрываются уязвимости, исправляются ошибки. Всё это позволяет снизить вероятность взлома через веб, хотя и не защищает от него на 100%, потому что и в новых апдейтах, к сожалению, могут появиться новые «дыры».
2. Необходимо минимизировать объем плагинов в CMS. Чем больше плагинов, тем больше вероятность наличия уязвимостей. В идеале, использовать решение «из коробки», с примененными патчами и критическими обновлениями, которые закрывают все известные публичные уязвимости в ядре CMS. Но, поскольку, функциональности не всегда хватает, то перед установкой плагинов нужно обязательно проверять, насколько они защищены и безопасны.
3. Доработки нужно отдавать опытным веб-разработчикам, которые имеют представление о безопасности сайтов и источниках проблем, то есть понимают необходимость фильтрации входных и выходных параметров, безопасных алгоритмов аутентификации и авторизации, безопасного хранения данных и т.п.
4. Трафик необходимо фильтровать. По статистике сервисов проксирования трафика, около 50% всех запросов идут от ботов, причем примерно четверть тех запросов – это атаки на веб-ресурс. Фильтрация запросов к сайту блокирует атаки, паразитный трафик и снижает нагрузку при DDOS- и брутфорс-атаках. Фильтровать можно как с помощью внешнего сервиса (Web Application Firewall/AntiDDOS), так и модуля веб-сервера (naxsi/mod_security). Еще одна полезная функция WAF – это виртуальный патчинг уязвимостей. Необязательно (да и не всегда возможно) ставить «заплатки» на скрипты, но WAF может выполнять виртуальный патчинг, то есть на лету блокировать опасные запросы, не давая эксплуатировать уязвимость. Кроме сервиса и модуля веб-сервера, файрвол бывает встроен в CMS. Он, конечно, не может быть полноценной заменой внешних сервисов WAF или AntiDDOS, но частично снижает вероятность взлома в результате веб-атак.
5. Необходимо использовать плагины и сервисы для защиты от брутфорса. Скажем, установленный на VPS Fail2ban через несколько неудачных попыток авторизации на некоторое время блокирует клиента. Это существенно затрудняет и растягивает во времени подбор пароля.

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

Если CMS неуязвима

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

• Из нашей практике, самый популярный вариант — это взлом через «соседей» по аккаунту. Например, на виртуальном хостинге размещен сайт, безопасности которого уделяется большое внимание: он работает на обновленной версии CMS, к нему применены технические средства защиты. Но на том же shared-аккаунте может быть размещено еще два десятка сайтов с уязвимыми версиями CMS, или размещаться старая тестовая версия сайта, про которую все давно забыли, а в ней может быть открыт загрузчик файлов или доступна без аутентификации админ-панель. Подобные незащищенные сайты и являются источниками проблем безопасности. Через их уязвимости можно внедрить администратора сайта в базу данных, загрузить веб-шелл или бэкдор, а затем получить полный контроль над аккаунтом хостинга. Почему это возможно? На shared-аккаунтах, где нет физической изоляции сайтов друг от друга, все данные расположены внутри общего файлового пространства (у файлов аккаунта общий пользователь операционной системы), то есть скрипты одного сайта могут читать, изменять, удалять скрипты, шаблоны и базу данных другого сайта на том же аккаунте. Это является причиной массовых взломов сайтов на аккаунте, когда однотипное заражение наблюдается на всех ресурсах виртуальной площадки.

  Это касается не только виртуальных хостингов, но и VPS-серверов. Часто, даже при технической возможности и абсолютной дешевизне, на выделенном сервере создается один административный аккаунт (пользователь admin), и внутри него размещается несколько десятков сайтов на различных CMS. А для взлома всего аккаунта достаточно иметь одну единственную критическую уязвимость на любом из этих сайтов. За пару секунд на каждый сайт будет загружено несколько десятков вредоносных скриптов, а процесс лечения будет напоминать вычерпывание воды из дырявой лодки: с одного сайта убрали вредоносный код, а он с другого опять «перешел» на вылеченный. Поэтому одно из базовых правил безопасности сайтов – изолированное размещение сайтов.

• Следующий вариант взлома защищённого сайта — брутфорс SFTP/FTP-аккаунтов или SSH-доступов. Для своего удобства и к радости злоумышленников веб-мастера устанавливают слабые словарные пароли, которые попадают в ТОП-100, ТОП-1000 популярных и подбираются за пару часов.
• Третий вариант — взлом через phpMyAdmin (а также другие инструменты, которыми пользуются веб-разработчики и администраторы). PhpMyAdmin — это средство администрирования базы данных. Распространяется по open source-лицензии, удобный, простой, доступный, его ставят на все хостинги и выделенные сервера под управлением популярных панелей. Самое интересное, что адрес у него почти всегда фиксированный. То есть можно набрать или /phpmyadmin, и откроется форма авторизации phpmyadmin. Если туда ввести пароль и логин от базы данных, которые можно узнать различными методами, вы получите доступ к базе данных. А дальше с помощью SQL-запроса можно внедрять вредоносный код в шаблоны, читать или создавать файлы на диске. А это уже могут быть бэкдоры, позволяющие загружать произвольные файлы и выполнять произвольный код. Многие хакеры напрямую внедряют код в базу данных, и при этом не оставляют никаких следов в файловой системе. То есть владелец сайта или веб-мастер просто не поймет, каким образом вирус появляется в коде страницы.

  На самом деле, он, порой, даже не знает о существовании phpMyAdmin, его публичной доступности и возможности взлома сайта через него.

  У читателя может возникнуть вопрос: каким образом злоумышленник узнает логины и пароли от базы данных, ведь для этого нужно получить доступ к файлу конфигурации CMS? На самом деле, получить данные для подключения к БД намного проще, чем кажется. Иногда запрос в поисковую систему Google позволяет найти очень много проиндексированных файлов, содержащий различную «чувствительную» информацию. Например, бэкапы сайтов с файлом настроек, или ошибочно проиндексированные файлы конфигурации. В качестве примера можно взять один старый запрос из Google Hacking Database – хакерской базы данных, содержащей запросы к Google для поиска проиндексированных уязвимых скриптов и чувствительных файлов.

  

  Вводим его в строку поиска и получаем примерно 288 тыс. файлов, которые содержат открытый логин, пароль, хост. Остается просто взять их оттуда, зайти на страницу /myadmin (или аналогичную для конкретного хостинга) и авторизоваться для проведения операций с базой данных.

  Второй вариант простого получения пароля от базы данных — это поиск бэкапов. Злоумышленник может получить несанкционированный доступ к резервным копиям сайта, если они лежат в корневом каталоге сайта (часто их называют backup.zip, backup.tar.g и т.п.) или в случае небезопасной настройки веб-сервера, когда каталог backup открыт для чтения по прямой ссылке (а иногда его даже индексирует поисковик). То есть злоумышленники по каким-то фиксированным путям (в WordPress это wp-content/uploads или /backups) могут перебрать различные имена файлов и выгрузить бэкап сайта. В этом архиве находится конфигурационный файл, в котором хранятся необходимые доступы к базе данных.

• Еще один вариант заражения сайта – когда веб-мастер добровольно устанавливает зараженный компонент. Например, вместо покупки плагина или шаблона для сайта, он скачивает этот же архив с «варезных» сайтов или каталога тем. А в этом плагине уже «вшит» бэкдор или вредоносный код. Естественно, через некоторое время такой сайт взламывают.
• И последний вариант, редко встречающийся у крупных хостеров, но периодически возникающий среди владельцев выделенных серверов – это «рутование» сервера (взлом сервера и получение административных полномочий). Это возможно в том случае, если программное обеспечение, компоненты операционной системы и сервисы содержат уязвимости или ошибки настройки. Если VPS-сервер не администрируется специалистом, то его достаточно быстро взламывают через известные уязвимости, а затем уже, как следствие, взламывают и все находящиеся на нем сайты.

Подытожу способы взлома не через веб:

1. Перехват или кража доступов, то есть компрометация доступов к сайту.
2. Брутфорс-атака на сервисы: SFTP, FTP, SSH или административную панель хостинга.
3. Взлом сайтов через «соседей».
4. Компрометация сервера хостинга, то есть получение несанкционированного доступа через уязвимости или ошибки настройки.

Защита от взлома

Как от этого защищаться?

1. Нужно правильно подбирать хостера, обращать внимание на используемые технические средства и сервисы, на наличие изоляции сайтов внутри аккаунтов. Всё это значительно снижает вероятность взлома.
2. Размещайте сайты изолированно. Не экономьте на безопасности, не ленитесь создавать для сайтов отдельные аккаунты. В идеале нужно размещать каждый сайт на отдельном аккаунте. Если это сервер, также создавайте для каждого сайта отдельный пользовательский аккаунт. Сейчас даже можно найти хостинг-компанию, у которой сайты размещаются изолированно внутри shared-аккаунта. Таких не много, но они есть.
3. Используйте ограничение по IP или двухфакторную аутентификацию при входе в панель управления, при работе с FTP и SSH. Нужно обязательно устанавливать дополнительную защиту, то есть ограничивать доступ только для доверенного круга лиц.
4. Регулярно меняйте пароли. Очевидный совет, которому следуют единицы. Это защищает во многих случаях, даже при компрометации доступов. Если злоумышленник не успел ими воспользоваться, то регулярная смена паролей позволяет сохранить свой доступ к сайтам. Дело в том, что вы не знаете, был ли факт компрометации и исходить нужно из пессимистичного сценария. Поэтому в качестве превентивной меры необходимо регулярно устанавливать новые пароли.

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

5. При работе с сайтом по FTP/в админке используйте VPN для предотвращения перехвата доступов, чувствительных и конфиденциальных данных.
6. Забудьте про FTP и заблокируйте его на хостинге, так как он небезопасен. Если на аккаунте есть такая возможность, подключите SFTP — это надстройка над SSH-протоколом для работы с файлами. В настоящий момент он поддерживается практически на всех хостингах. С точки зрения работы с файлами, разницы с FTP вы не заметите, а с точки зрения безопасности – разница колоссальная.
7. Если вы очень часто пользуетесь какими-то функциями в панели управления, то создайте отдельный аккаунт с ограниченной функциональностью и вынесите эти популярные функции в этот аккаунт. Если у вас его и взломают, то получат только ограниченный доступ к управлению сайтами.

Когда виноват подрядчик или сотрудник

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

1. Недобросовестный подрядчик. Часто бывают ситуации, когда сайты отдаются на обслуживание фрилансерам, которые не всегда добросовестны. Например, есть вероятность, что в результате сотрудничества ему что-то не понравится, покажется мало денег, он обидится на критику и начнет шантажировать владельца сайта доступами. Или он просто использует свои полномочия администратора и повредит сайт. Поскольку у подрядчика есть полный контроль над сайтом, он может внедрить на страницы вредоносный код, может начать продавать на нем ссылки с биржи Sape.ru/Trustlink/и пр., размещать несанкционированную рекламу. И порой владелец сайта или менеджер проекта не догадываются, что бывший веб-мастер «паразитирует» на веб-ресурсе, оставив на нем свои «закладки».
2. Бывает, что подрядчик устанавливает плагины, которые содержат уязвимости или бэкдоры. Например, владелец сайта находит красивый плагин галереи для сайта и просит фрилансера купить и настроить этот модуль. Фрилансер находит такой же плагин на «варезном» сайте, берет деньги с заказчика на покупку, но на самом деле скачивает бесплатно. В «нулленом» варианте будет присутствовать некая «полезная» нагрузка в виде бэкдора или «черных» seo-ссылок. Владелец сайта об этом скорее всего никогда не узнает, потому что не будет проверять то, что установил фрилансер.
3. Утечка доступов — тоже очень серьезный момент, потому что часто подрядчики не задумываются о безопасности клиентских доступов и сайтов, и небрежно ими распоряжаются. Например, крупное диджитал-агентство обычно работает по различным задачам с партнерами (субподрядчиками), которым передаются клиентские доступы, и что с ними делают партнеры, никто не знает. Эти доступы могут передаваться открыто через мессенджеры по небезопасному сетевому подключению, сохраняться в текстовых файлах, храниться в различных незащищенных CRM и т.п. В итоге шансов раскрытия данных доступов масса, и достаточно сложно будет найти причину компрометации.

   Самый живой пример — это когда такой партнер крупного диджитал-агентства сидит в кафе, обновляет сайт по FTP, а где-нибудь рядом с ним устроился хакер, который перехватывает трафик в той же WIFI сети. Или роутер, через который работает специалист в коворкинг-кафе, заражен трояном. Вредоносное ПО собирает все эти доступы и передает злоумышленникам. Сейчас подобное уже не редкость, перехват траффика в открытых сетях – операция очень простая и эффективная. Поэтому работать в публичном месте без активного VPN – это почти преступление.

4. И последний вариант — использование социальной инженерии. Скажем, подрядчику, приходит фишинговое письмо: «Ваш сайт взломали! Пожалуйста, срочно смените пароль!» и ссылка. Напуганный исполнитель в замешательстве кликает по ссылке, ему открывается знакомая форма авторизации CMS, но он не замечает, что страница загружена с подставного сайта злоумышленника. Вводит пароль и последний благополучно отсылается хакеру.

Что делать? Как защититься?

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

1. Управлять доступами. Владелец должен знать, когда и как их менять, у кого они есть, кому их передавать и в каком объеме. Это защитит от многих проблем.
2. Проводить аудит безопасности после выполнения работ подрядчиком. Файлы, базу и страницы сайта можно проверить самостоятельно с помощью доступных сканеров или инструментов для контроля целостности, а можно обратиться к соответствующим специалистам по безопасности.
3. Инструктировать подрядчиков. Обязательно нужно составить руководство по безопасной работе с сайтом для сотрудников и подрядчиков и проинструктировать по нему. Многие специалисты могут отлично выполнять свои задачи, но не задумываться о безопасности сайта.
4. Работать по договору и с проверенными компаниями. Сотрудничество с фрилансерами часто оборачивается проблемами безопасности с сайтом.

В заключение

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

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

Хостинг MskHost начал свою работу в 2022 году. Компания позиционировала себя, как «надёжный современный хостинг-провайдер, у которого можно приобрести виртуальный облачный сервер, выделенный сервер, виртуальный хостинг и зарегистрировать свой домен». Последнее время клиенты хостинга оставляли все больше негативных отзывов о его работе.

Судя по данным аптайма серверов хостинга, проблемы с доступом к MskHost начались сегодня после 7 утра.

На странице, куда сейчас ведет ссылка с сайта MskHost указано, что вся инфраструктура хостинга была взломана, был получен доступ к пользовательским серверам и данным, а большая часть серверов была безвозвратно удалена. Также хакеры пообещали выложить в открытый доступ всю информацию с абьюз ящика хостинга (abuse@msk.host). Как оказалось, там было более 100 непрочитанных электронных писем с жалобами от клиентов.

В обращении на заглушке сайта, которая ведет в телеграм-канал пользователя mskhostohoh указано:

Мы вместе ведущими пентестерами СНГ, вынуждены нанести удар по инфраструктуре этого хостинг-проекта, и очистить Рунет от такого масштабного хостера черни.

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

Дорогие причастные лица к деятельности данного хостинг проекта, ваши данные у нас тоже уже есть. IP каждого входа и многое другое. Эти данные также как и с клиентскими, будут в скором времени переданы в правоохранительные органы.

В 13:00 мск администрация хостинга

пояснила

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

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