Под прессом. Ломаем и защищаем Wordpress своими руками
WordPress — это удобная блог-платформа для публикации статей и управления ими, на которой базируется огромное число различных сайтов. Из-за своей распространенности эта CMS уже давно является лакомым куском для злоумышленников. К сожалению, базовые настройки не обеспечивают достаточного уровня защиты, оставляя многие дефолтные дырки незакрытыми. В этой статье мы пройдем типичным путем «типового» взлома сайта на Wordpress, а также покажем как устранить выявленные уязвимости.
ВведениеНа сегодняшний день WordPress среди систем управления контентом популярнее всего. Его доля составляет 60,4% от общего числа сайтов, использующих CMS-движки. Из них, согласно статистике, 67,3% сайтов базируется на последней версии данного программного обеспечения. Между тем за двенадцать лет существования веб-движка в нем было обнаружено 242 уязвимости различного рода (без учета уязвимостей, найденных в сторонних плагинах и темах). А статистика сторонних дополнений выглядит еще печальней. Так, компания Revisium провела анализ 2350 русифицированных шаблонов для WordPress, взятых из различных источников. В результате они выяснили, что более половины (54%) оказались зараженными веб-шеллами, бэкдорами, blackhat seo («спам») ссылками, а также содержали скрипты с критическими уязвимостями. Поэтому устраивайся поудобней, сейчас мы будем разбираться, как провести аудит сайта на WordPress и устранить найденные недостатки. Использовать будем версию 4.1 (русифицированную).Индексирование сайта Первым этапом любого теста обычно бывает сбор информации о цели. И тут очень часто помогает неправильная настройка индексирования сайта, которая позволяет неавторизованным пользователям просматривать содержимое отдельных разделов сайта и, например, получить информацию об установленных плагинах и темах, а также доступ к конфиденциальным данным или резервным копиям баз данных. Чтобы проверить, какие директории видны снаружи, проще всего воспользоваться Гуглом. Достаточно выполнить запрос Google Dorks типа site: example.com intitle: «index of» inurl:/wp-content/. В операторе inurl: можно указать следующие директории: /wp-content/ /wp-content/languages/plugins /wp-content/languages/themes /wp-content/plugins/ /wp-content/themes/ /wp-content/uploads/ Если сможешь просмотреть /wp-content/plugins/, следующий шаг по сбору информации об установленных плагинах и их версиях значительно упрощается. Естественно, запретить индексирование можно с помощью файла robots.txt. Так как по умолчанию он не включен в установочный пакет WordPress, его необходимо создать самому и закинуть в корневую директорию сайта. Мануалов по созданию и работе с файлом robots.txt довольно много, поэтому оставлю эту тему для самоподготовки. Приведу лишь один из возможных вариантов: User-Agent: * Disallow: /cgi-bin Disallow: /wp-login.php Disallow: /wp-admin/ Disallow: /wp-includes/ Disallow: /wp-content/ Disallow: /wp-content/plugins/ Disallow: /wp-content/themes/ Disallow: /? author=* Allow: / Если в файлах, хранящихся в папке uploads, имеются сведения конфиденциального характера, добавляем к этому списку строчку: Disallow: /wp-content/uploads/. С другой стороны, в файле robots.txt не рекомендуется размещать ссылки на директории, которые были созданы специально для хранения чувствительной информации. Иначе этим самым ты облегчишь злоумышленнику задачу, так как это первое место, куда обычно все заглядывают в поисках «интересненького».Определение версии WordPress Еще один важный шаг — идентификация версии CMS. Иначе как подобрать подходящий сплоит? Существует три быстрых способа для определения используемой на сайте версии WordPress:1. Найти в исходном коде страницы. Она указана в метатеге generator: /> или же в тегах : .2. Найти в файле readme.html (рис. 1), который входит в состав установочного пакета и находится в корне сайта. Файл может иметь и другие названия типа readme-ja.html.3. Найти в файле ru_RU.po (рис. 2), который входит в состав установочного пакета и расположен по адресу /wp-content/languages/: «Project-Id-Version: WordPress 4.1.1\n».
Рис. 1. Версия WordPress в файле readme.html
Рис. 2. Подсматриваем версию WordPress в файле ru_RU.po
Один из вариантов защиты в данном случае — ограничить доступ к файлам readme.html и ru_RU.po с помощью .htaccess.
Автоматизация процесса тестирования Исследованием безопасности WordPress занялись не вчера, поэтому существует достаточное количество инструментов, позволяющих автоматизировать рутинные задачи.Nmap:
— определение версии и темы с помощью скрипта http-wordpress-info
nmap -sV --script http-wordpress-info— подбор пароля по словарям nmap -p80 --script http-wordpress-brute --script-args 'userdb=users.txt, passdb=passwords.txt' example.com Metasploit: — модуль для определения версии: auxiliary/scanner/http/wordpress_scanner; — модуль для определения имени пользователя auxiliary/scanner/http/wordpress_login_enum.
WPScan:
— перечисление установленных плагинов: wpscan --url www.exmple.com --enumerate p; — перечисление установленных тем: wpscan --url www.exmple.com --enumerate t; — перечисление установленного timthumbs: wpscan --url www.example.com --enumerate tt; — определение имени пользователя: wpscan --url www.example.com --enumerate u; — подбор пароля по словарю для пользователя admin: wpscan --url www.example.com --wordlist wordlist.txt --username admin; — подбор пароля с использованием связки имя пользователя / пароль с числом потоков, равным 50: wpscan --url www.example.com --wordlist wordlist.txt --threads 50.
Определение установленных компонентов
Теперь давай соберем информацию об установленных плагинах и темах независимо от того, активированы они или нет. Прежде всего такую информацию можно выудить из исходного кода HTML-страницы, например по JavaScript-ссылкам, из комментариев и ресурсов типа CSS, которые подгружаются на страницу. Это самый простой способ получения информации об установленных компонентах. Например, строчки ниже указывают на используемую тему twentyeleven:
Далее, HTTP-заголовки, такие как X-Powered-By, могут указывать на наличие плагина (например, на плагин W3 Total Cache).Так как информация о плагинах не всегда отображается в исходном коде HTML-страницы, то обнаружить установленные компоненты можно с помощью утилиты WPScan (см. врезку). Только не забывай, что перебор путей плагинов зафиксируется в логах веб-сервера.Получив данные об установленных компонентах, уже можно приступать к поиску уязвимостей своими силами либо найти общедоступные эксплойты на ресурсах типа rapid7 или exploit-db.Определение имени пользователей
По умолчанию в WordPress каждому пользователю присваивается уникальный идентификатор, представленный в виде числа: example.com/? author=1. Перебирая числа, ты и определишь имена пользователей сайта. Учетная запись администратора admin, которая создается в процессе установки WordPress, идет под номером 1, поэтому в качестве защитной меры рекомендуется ее удалить.Брутфорс wp-login
Рис. 3. Ошибки при аутентификации пользователяЗная имя пользователя, можно попробовать подобрать пароль к панели администрирования. Форма авторизации WordPress на странице wp-login.php весьма информативна (рис. 3), особенно для злоумышленника: при вводе неправильных данных появляются подсказки о неверном имени пользователя или пароле для конкретного пользователя. Разработчикам известно о данной особенности, но ее решили оставить, так как подобные сообщения удобны для пользователей, которые могли забыть свой логин и/или пароль. Проблему подбора пароля можно решить, используя стойкий пароль, состоящий из двенадцати и более символов и включающий буквы верхнего и нижнего регистра, числа и спецсимволы. Или же, например, при помощи плагина Login LockDown.
Security-плагины для WordPress — Login LockDown — ограничивает количество неудачных попыток авторизации; — Revisium WordPress Theme Checker — ищет типичные вредоносные фрагменты в темах WordPress; — Sucuri Security — проводит мониторинг и обнаружение вредоносного кода; — iThemes Security (бывший Better WP Security) — многофункциональный плагин для защиты WordPress; — BackUpWordPress — делает резервное копирование файлов и БД; — Google Captcha (reCAPTCHA) — устанавливает капчу при регистрации, авторизации, восстановлении паролей и в форме комментариев.
Заливаем Shell После того как мы сбрутили пароль, ничто не мешает залить шелл на скомпрометированный веб-ресурс. Для этих целей вполне сгодится фреймворк Weevely, который позволяет генерировать шелл в обфусцированном виде, что делает его обнаружение довольно сложным. Чтобы не вызывать подозрения, полученный код можно вставить в любой файл темы (например, в index.php) через редактор темы консоли WordPress. После чего с помощью того же Weevely можно подключиться к машине жертвы и вызывать различные команды: python weevely.py http://test/index.php Pa$$w0rd
[+] weevely 3.1.0
[+] Target: test [+] Session: _weevely/sessions/test/index_0.session
[+] Browse the filesystem or execute commands starts the connection [+] to the target. Type: help for more information.
weevely>: help Подключаем .htaccess Для запрета доступа к чувствительной информации лучше воспользоваться файлом .htaccess — это файл конфигурации, используемый в Apache Web Server. Рассмотрим возможности этого файла с точки зрения безопасности. С его помощью можно: запретить доступ к директориям и файлам, заблокировать различные SQL-инъекции и вредоносные скрипты. Для этого стандартный файл .htaccess для CMS WordPress 4.1 нужно немного расширить. Чтобы закрыть список файлов и папок, добавляем: Options +FollowSymLinks -Indexes
RewriteCond %{QUERY_STRING} base64_encode[^(]*\([^)]*\) [OR] заблокирует ссылки, содержащие кодировку Base64. Избавиться от ссылок, содержащих тег