Содержание статьи
info
Полный текст этой статьи доступен без подписки благодаря спонсору — компании RUVDS, одному из самых передовых хостинг‑провайдеров VPS/VDS-серверов. RUVDS предлагает виртуальные серверы в десяти дата‑центрах уровня TIER3 и выше по всему миру, низкие цены от 30 рублей в месяц, удобный маркетплейс и установку популярных образов в один клик.
Фишинг
Выпив традиционный утренний кофе, ты запускаешь почтовый клиент и неожиданно получаешь письмо от своего провайдера с напоминанием о том, что пришло время в очередной раз оплатить хостинг. Кстати, прямо сейчас можно пополнить баланс со значительной скидкой в честь годовщины освобождения Изенгарда от засилья урук‑хаев.
Издав радостный боевой клич, ты переходишь по ссылке и только тут, если повезет, замечаешь что‑то неладное. Да, письмо выглядит безобидно: оно оформлено в точности так же, как официальные сообщения от твоего хостера, текст набран тем же шрифтом, адрес отправителя — верный. И даже в «подвале» на своем законном месте расположены ссылки на политику конфиденциальности, правила обработки персональных данных и прочую лабуду, которую никто никогда не читает. Только вот URL страницы авторизации в администраторской панели немного отличается от настоящего, да и SSL-сертификат на сайте вызывает подозрения и у тебя, и у антивируса. Ой, а не фишинг ли это?
Подобные атаки, нацеленные на перехват учетных данных от админки популярных хостингов, в последнее время участились. Можно, конечно, заподозрить провайдера в утечке базы клиентов, но не торопись с выводами. Раздобыть нужную информацию об администраторах сайтов, хостящихся у той или иной компании, не так сложно, как кажется.
Чтобы получить образец корпоративного письма, достаточно зарегистрироваться на сайте провайдера или заказать тестовый хостинг, который многие компании бесплатно предлагают на ограниченный срок. Дальше такое письмо можно обработать в любом HTML-редакторе, поменяв содержимое. Нетрудно найти и все используемые провайдером диапазоны IP-адресов: для этой цели создано множество сервисов, например xseo.in. Ну а затем можно получить список сайтов на каждом из IP-адресов shared-хостинга, например здесь, здесь или тут. Проблемы могут возникнуть только с провайдерами, которые прячутся за Cloudflare, но на каждый хитрый винт, как известно, найдется гайка с левой резьбой.
Останется только пройтись по сайтам и собрать адреса email или сгенерировать список рассылки подстановкой значений admin, administrator, contact, info к каждому domain. — куда‑нибудь да попадем. Потом этот список можно почистить, исключив из него несуществующие адреса. Причем весь процесс нетрудно автоматизировать с помощью несложного скрипта на питоне либо воспользоваться одной из программ автоматического сбора email, которым скармливают список URL для последующего парсинга (не станем рекламировать их в этой статье, поскольку практически весь подобный софт платный). Ну а счастливые юзеры Kali могут использовать для этих целей theHarvester, слегка повозившись с настройками.
Похожие «письма счастья» зачастую прилетают администраторам доменов, особенно если их данные не скрыты за анонимайзером Private Person. Здесь для парсинга адресов электронной почты используются публичные базы Whois.
Существует и целый ассортимент утилит, позволяющих выяснить не только контактный адрес электропочты админа, но и наименование компании — регистратора домена, а потом собрать из них базу для фишинговой рассылки. В этом случае администратору обычно предлагают оплатить продление делегирования доменного имени, перенаправив его на страницу платежной системы с левым номером кошелька или счета. Конечно, подвох заметить нетрудно, но с бодуна если ты устал или на работе аврал, то есть шанс ненароком и лохануться.
Методы борьбы с подобными явлениями просты: по возможности выбирать провайдера, использующего двухфакторную авторизацию для входа в панель управления хостингом, и, разумеется, всегда быть внимательным, чтобы не попасться на удочку прохиндеев.
Самый цимес
Кто в наше время не использует CMS? Все используют CMS! Многие провайдеры предлагают услугу быстрого развертывания наиболее популярных движков, вроде WordPress, Joomla, Drupal, Bitrix, из контейнера: нажал кнопку в панели управления хостингом, и готово. Но некоторые уникумы пользователи предпочитают ставить CMS вручную, скачав дистрибутив с сайта разработчика и залив его на сервер через FTP — потому что так привычнее, надежнее и по фэншую. При этом они иногда забывают удалить инсталляционные скрипты и служебные папки.
О Google Dorks мы уже неоднократно рассказывали, но актуальность описанных приемов от этого не уменьшается. Например, всем известно, что инсталляционный скрипт WordPress при установке движка располагается по адресу wp-admin/. Давай посмотрим, сколько результатов с таким URL найдет для нас великий Гуголь при использовании команды inurl.
Безусловно, выдача будет сильно замусоренной, ведь среди линков отображается много ссылок на форумы с обсуждением глюков WordPress. Но, хорошенько покопавшись в этой куче, можно отыскать и рабочие варианты, позволяющие нам поменять настройки сайта, — один из них показан на картинке выше. Фокус удастся, если, конечно, взломщик сумеет подобрать валидные данные базы. Можно, например, попытать счастья с использованием команды intext:, указав второй директивой интересующий нас URL, или использовать традиционный брутфорс.
Посмотреть структуру скриптов в WordPress можно с помощью запроса inurl:. Еще есть шанс узнать много интересного, поискав забытые скрипты phpinfo( запросом inurl:.
Отыскать рабочие скрипты инсталляции популярного движка Joomla можно, например, с использованием характерного заголовка веб‑страницы: для этого подойдет команда вроде intitle:. Один из результатов поиска по такому запросу показан на иллюстрации ниже.
В общем, если грамотно использовать специальные режимы поиска, можно найти залитые на хостинг дистрибутивы систем управления контентом с незавершенной инсталляцией или забытыми служебными скриптами и помочь незадачливому владельцу закончить установку. Заодно зарегистрировав в CMS нового админа. Бороться с подобным несложно: нужно всего лишь прибирать за собой в папках на сервере или использовать контейнеризацию — обычно она более безопасна.
Мисконфигурейшн
Из предыдущего раздела логично вытекает еще одна возможность поиска уязвимостей на виртуальных хостах с предустановленной CMS: изъяны в настройке и использование конфигурации по умолчанию. И в WordPress, и в Joomla, и в других движках обычно присутствует огромное количество плагинов, имеющих известные уязвимости с настройками по умолчанию.
В первую очередь атакующие обычно пытаются выяснить версию CMS, установленную на хосте, — в случае с WordPress это можно сделать, например, посмотрев в код веб‑страницы и поискав там метатеги вроде <. Версию шаблона подскажут строчки наподобие https://.
Затем можно поискать версии интересующих взломщика плагинов: многие из них имеют в своем составе текстовые файлы readme, доступные по адресу вроде https://. Подобные файлы лучше прибивать сразу после установки плагинов, не оставляя их на хостинге для любопытных исследователей. Выяснив версии ядра движка, шаблона и плагинов, хакер может попытаться заюзать известные уязвимости.
Кроме этого, на некоторых сайтах с WordPress можно попытаться выяснить имя администратора, добавив к URL строку вида /. С настройками по умолчанию движок вернет в URL валидное наименование учетки первого пользователя, зачастую имеющего права админа. Останется только сбрутить пароль. Эта возможность зависит от нескольких факторов — используемой темы, установленных плагинов, настроек веб‑сервера. Если перечисление пользователей не отключено, можно перебрать ID всех юзеров WordPress и собрать таким нехитрым способом список логинов для брута. Отключить возможность перебора пользователей можно, отредактировав соответствующим образом functions. или .. Например, так:
functions.php
if ( ! is_admin() ) { if ( preg_match('/author=([0-9]*)/i', $_SERVER['QUERY_STRING']) ) die(); add_filter( 'redirect_canonical', 'check', 10, 2 );}function check( $redirect, $request ) { if ( preg_match('/\?author=([0-9]*)(\/*)/i', $request) ) die(); else return $redirect;}.htaccess
<IfModule mod_rewrite.c> RewriteCond %{QUERY_STRING} ^author=([0-9]*)
RewriteRule .* http://yoursite.com/? [L,R=302]
</IfModule>Ну и конечно же, нельзя не сказать о том, что владельцы сайтов зачастую оставляют доступными на чтение некоторые директории. В том же WordPress чаще всего можно попасть в эти служебные папки:
-
/;wp-content/ -
/;wp-content/ plugins/ -
/;wp-content/ themes/ -
/;wp-content/ uploads/ files/ -
/.images/
Очевидно, что делать там посторонним совершенно нечего, поскольку в таких папках может храниться критичная информация, в том числе довольно‑таки конфиденциальная.
Запретить доступ к служебным папкам можно, опять же установив соответствующий шаблон, или самым простым способом — поместить в корне каждой директории пустой файл index. (либо добавить в . сайта строчку Options ). У многих хостинг‑провайдеров эта опция прописана по умолчанию, но далеко не у всех, в чем ты при желании можешь убедиться самостоятельно.
Кроме того, нужно осмотрительно обращаться с командой chmod, особенно при раздаче прав куче вложенных директорий на запись и выполнение скриптов. Последствия таких необдуманных действий могут быть самыми неожиданными.
Забытые учетки
Однажды к автору этих строк за помощью обратилась одна знакомая компания, сайт которой ежедневно падал без видимых на то причин. Восстановление содержимого серверной папки из резервной копии помогало ненадолго — в какой‑то совершенно непрогнозируемый момент все повторялось вновь. Поиск уязвимостей и бэкдоров в скриптах тоже ничего не дал. Сисадмин конторы пил ведрами корвалол и бился головой о серверную стойку.
Только вдумчивое курение логов помогло отыскать настоящую причину. Ею оказался «брошенный» FTP-доступ, созданный давным‑давно кем‑то из уволенных сотрудников, знавших пароль от панели управления хостингом. Видимо, не удовлетворившись размером выходного пособия, новоиспеченный безработный решил отомстить своему бывшему начальству таким вот незамысловатым способом. После удаления всех «лишних» FTP-аккаунтов и профилактической смены паролей проказы «барабашки» наконец полностью прекратились.
Выводы
Главное оружие владельца интернет‑ресурса в борьбе за безопасность — осторожность, осмотрительность и внимательность. Можно и нужно пользоваться услугами проверенного провайдера, однако поговорку «доверяй, но проверяй» придумали неглупые люди. Какими бы надежными ни казались решения «из коробки», для пущей уверенности нужно проверить наиболее характерные «узкие места» в конфигурации сайта самостоятельно.
А потом перепроверить еще раз. Просто на всякий случай.
