Установка и подготовка CMS WordPress для нужд начинающего пентестера или WP PenLAB - своими руками - часть 1

Содержание:

• установка Apache, БД, CMS WordPress на локальный хост + альтернативный вариант для ленивых
• первоначальная настройка, обзор возможностей админ-панели
• выявление природы основной массы уязвимостей
• downgrade нашего сайта до уязвимой версии
• первый скан с помощью WPScan, заключение

В этом цикле статей я поделюсь с вами опытом настройки собственного локального “поля для экспериментов”, построенного на стеке LAMP+WordPress. Не секрет, что для отрабатывания какого-либо навыка до высокого уровня нужна постоянная практика. Тестирование на проникновение – не исключение, в этой сфере опыт специалиста чрезвычайно важен, а помимо опыта эмпирического, нужна хотя-бы начальная теоретическая база, необходимая для того, чтобы начать углублённое изучение предмета.

Итак, я предусмотрел 3 статьи (лекции), в которых будут рассмотрены следующие темы:

1. Установка и подготовка CMS WordPress для нужд начинающего пентестера
2. Перечисление, уязвимости, эксплуатация
3. Защита - основные методы.

Приступим. Чтобы установить CMS WordPress на хост, нам необходимо подготовиться. Для работы WordPress требуется веб-сервер, база данных, к которой будет обращаться наш сайт, а так же установленный PHP, без него никак, ведь WordPress на нём написан.

Установку и настройку я буду проводить на Debian 9.9.0, работающем в виртуальной машине. Установка будет аналогична на всех Debian-based дистрибутивах, включая kali и Parrot OS.


Сразу после установки рекомендую добавить веб-сервер в автозагрузку и проверить его работоспособность. Убедиться в корректной инсталляции можно просто открыв браузер и перейдя по адресу localhost. Увидели дефолтную страницу Apache2 - убедились в корректной установке.

Произведем настройку базы данных. Пишем в терминал команду:
Внимательно вчитываемся в каждый пункт, отвечая на вопросы помощника (Y/N).

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

Выполним следующие команды:
ПРИМЕЧАНИЕ: бывали случаи, когда распаковывать архив не приходилось, и скрипт сразу же поставлялся распакованным. Как я понимаю – дело в том, что для различных дистрибутивов пакеты собираются по-разному, и кто-то может встретиться со сжатым скриптом, а кого-то это обойдет стороной. В любом случае – операция по распаковке тривиальна.

После распаковки и установки разрешения на исполнние файла, запускаем сам скрипт:
Таким образом, если скрипт завершился без ошибок, переходим к настройке конфига веб-сервера для нашего сайта. Конфиг для apache2 мы писать будем не вручную, а следуя рекомендациям из примеров, данных нам разработчиками. Находится файл в папке /usr/share/doc/wordpress/examples/ , вам нужно лишь скопировать, например первый пример из файла apache.confв файл localhost.conf и поместить последний в папку/etc/apache2/sites-available/.

Примечание: в файле apache.conf указано, какие действия нужно выполнять при использование примеров. Например, при использовании первого примера из файла, в терминале нужно будет выполнить пару команд. Будь внимателен в настройке!

Нажмите, чтобы раскрыть...

И наконец, мы максимально близко подошли к запуску собственного “хомячка для пыток”. Для того, чтобы наш сайт начал работать, нужно выключить дефолтный 000-default и активировать наш localhost. Пишем в терминал:
После перезагрузки веб-сервера, нам нужно снова в адресной строке браузера написать “localhost” и перейти на страницу.

WordPress после успешной установки предложит нам ввести имя администратора, пароль и e-mail. Заполняем всё это, для еще большего обучающего эффекта ставим словарный пароль (в цикле статей отработаем брутфорс админки и способы защиты от такой атаки). Итак, введя пару на подобии admin:wpadmin,проходим авторизацию и попадаем в панель управления нашим сайтом. Сразу скажу – WordPress создавался и задумывался как CMS для блогов и новостных сайтов, поэтому не удивляйтесь “блоггерской” тематике разделов в админ-панели. Первый блок возможностей нас не интересует – оставим записи, комментарии и медиафайлы(пока что) контент-мейкерам.

Самый большой интерес для нас представляют плагины и встроенный редактор шаблонов оформления. В функционале раздела плагинов так же имеется редактор, но о нём попозже.

Обязательно переходим в раздел Внешний вид- Темы – Добавить новую и устанавливаем любую приглянувшуюся. В момент, когда вы нажмете на кнопку “установить” WordPress попросит вас дать пару логин:пароль для FTP доступа к файлам на сервере. С этим я настоятельно рекомендую разобраться самостоятельно, всё очень просто.

Нажмите, чтобы раскрыть...

Для тех, у кого не вышло, или есть мотивированное желание не давать WordPress’у FTP доступ, я приготовил следующую рекомендацию. В файлwp-config.php в корневой директории сайта мы допишем строку:

Таким образом, давать FTP доступ нам не придется.

Внимание! В подавляющем большинстве случаев настройки WP на локальном хосте, возникают проблемы, связанные с тем, что на папки и файлы установлены некорректные для работы WP разрешения. С этой проблемой, в случае её возникновения, тоже предалгаю разобраться самостоятельно, ведь права в Linux – основа, без знания которой в дальнейшей работе придется очень тяжело.

Нажмите, чтобы раскрыть...

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


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

• ищем хостинг с тестовым периодом
• регистрируемся
• запускаем сайт на CMS WordPress

Да, все именно так просто. Эти действия с регистрацией нового ящика я выполнил менее, чем за 2 минуты. Каким именно хостингом воспользоваться решать вам, я лишь подскажу, что я воспользовался услугами хостера, у которого сайты на различных CMS находятся в разделе СПЕКТР (гуглим пару минут, получаем адрес моего хостера). Не даю URL сервиса, так как уверен в том, что человеку, не справившемуся с установкой WP на свою машину, не стоит тратить ресурс хостера на свои эксперименты. Не получилось – try harder, как говорится. Те, у кого есть веские причины не запускать веб-сервер на виртуальной машине/хосте, смогут воспользоваться поисковой системой.

Прошу учесть, что FTP-доступа на большинстве хостингов вам выдано не будет(пока не заплатите денежку,конечно же), поэтому для работы с файлами рекомендую установить в самом WordPress плагин для работы с файловой системой. WP File Manager полностью удовлетворит наши потребности.


Причина большинства уязвимостей, с которыми можно встретиться в реальной жизни – невнимательность кодера, написавшего какой-либо плагин для WordPress. Это случается часто, почти регулярно, так что не удивляйтесь, когда новая CVE будет применена к вашему ресурсу и эксплуатировать она будет уязвимость в коде вашего любимого SEO-плагина, который вы не удосужились обновить до последней версии.

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

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

Первое, и пожалуй самое важное – неактуальная версия WordPress. Объясню, почему очень часто у заказчиков не установлено последнее актуальное обновление. Дело в том, что в условиях тотальной экономии на всем, на чем только можно, при заказе сайта на бирже фриланаса, заказчик зачастую просто забывает о том, что некоторым приватным решениям, будь то специальный плагин или особо-хитрое оформление меню,зависящее от приблизительного местоположения клиента, требуется поддержка. Такой сервис, разумеется, стоит денег. Так вот, после исполнения заказа, убедившись в работоспособности приватного решения, разработчик или человек, занимающийся администрированием сайта, либо не включает автообновление, либо обновившись, сталкивается с проблемами в работе этих самых решений, в условиях той же экономии, дабы не тратить деньги, просто откатывается до последнего бэкапа и спокойно “забивает” на обновления.

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

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

Четвертое, и пожалуй самое противное, что может вам встретиться – некорректно выставленные права доступа на файлы и папки. Вместе с этой проблемой выделю так же те самые пресловутые “приватные решения за дешево”, несущие в себе зачастую XSS-уязвимости. В особо тяжелых случаях приходится сталкиваться с инъекциями в базу данных.

Итак, приступим. Даунгрейд версии CMS WordPress мы будем производить с помощью плагина с названием WP Downgrade | Specific Core Version.

Переходим в Плагины-Добавить новый, пишем в строку поиска “WP Downgrade”. Устанавливаем, активируем. Плагин будет добавлен к меню “Настройки”. Переходим к даунгрейду версии. В поле WordPress Target Version мы вписываем версию, до которой хотим откатиться. Рекомендую откатывать версию до 4.7.1 (встречается часто). Сохраняем изменения, после переходим к “обновлению”, после чего проверяем версию WordPress, она в админ-панели указана в правом нижнем углу экрана. Если видим там заветные цифры “4.7.1”, то это значит, что мы готовы приступать к первому сканированию и разбору результатов(домашнее задание).


Первое сканирование. В нашем случае – самое простое. Для сканирования на уязвимости нам понадобится WPScan. Установить вы его можете отсюда:

wpscanteam/wpscan

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

По причине того, что статья пишется для людей, которые уже знакомы с Linux, не буду приводить примеры команд для сканера, в нашем случае вам хватит прсото запуска сканера с заданным параметром –url. Сканирование происходит некоторое время, на устаревших машинах процесс может занимать до 7 минут.

Нажмите, чтобы раскрыть...

Без установленных плагинов, несущих в себе уязвимость, WPScan выдал в отчете следующую информацию:
Прошу не радоваться раньше времени, далеко не все уязвимости, а точнее – почти все, не являются волшебной лазейкой в админку или дают возможность заливки веб-шелла. В списке будут перечислено множество уязвимостей, которые, например, дают возможность удаления определенного файла на сервере или же допускают использование XSS-атаки. Ничто серьезное не бывает простым, настоятельно рекомендую вам пройти по ссылкам, которые выдаст вам WPScan и внимательно прочитать информацию о каждой найденной уязвимости, а после этого найти видео, где выбранная CVE будет эксплуатироваться. Для общего понимания специфики WordPress-пентеста это то, что нужно. Если вам тяжело разобраться в чем-то – не отчаивайтесь. Пробуйте понять заново и обязательно пробуйте выполнить нужные действия САМОСТОЯТЕЛЬНО, почти наверняка вы столкнетесь с проблемами, решив которые, вы станете только лучше.

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

Прошу читателей выразить мнение, по поводу дальнейших статей. Интересует меня следующее - стоит ли приводить готовые примеры команд для эксплуатации уязвимостей? Давать прямые ссылки на эксплойты или нет? Не будет ли это "вредно" аудитории, которая не всегда оказывается вдумчивой и идет ломать все, что под руку попадется?