Как я нашел SSRF в Facebook - история моего первого багаунти
Привет, мир ❤️,
Facebook - крупнейшая социальная сеть в мире и одна из наиболее широко используемых. Мне всегда было интересно проверить безопасность Facebook. Во время перечисления субдоменов я получил субдомен, который называется « https://m-nexus.thefacebook.com/ ». Он перенаправляет меня на https://m-nexus.thefacebook.com/servlet/mstrWebAdmin, см. Снимок экрана ниже:
Я быстро набрал в Google ключевое слово mstrWebAdmin и заметил, что это Портал бизнес-аналитики, основанный на инструментах MicroStrategy:
Я подтвердил это в блоге:
Из официального документа конфигурации MicroStrategy я обнаружил, что есть две общедоступные конечные точки:
Продолжая изучение официального документа конфигурации MicroStrategy, я обнаружил, что по умолчанию базовая аутентификация HTTP была включена на портале Business Intelligence (URL: https://m-nexus.thefacebook.com/servlet/mstrWeb), затем я заметил, что https://m-nexus.thefacebook.com/servlet/taskProc не требует аутентификации.
Требуется значение параметра «taskId» для выполнения сбора некоторых пользовательских данных и создания контента. Перечисляя предварительно созданные задачи (с помощью Intruder), я обнаружил, что каждая предварительно созданная задача проверяет действительный параметр сеанса аутентификации, но задача «shortURL», которая обрабатывает короткий URL-адрес и не проверяет действительный сеанс аутентификации. Злоумышленник может использовать это наблюдение для доступа к этой службе без какой-либо аутентификации.
Я начал фаззинг по всем параметрам, упомянутым в официальном документе, но ничего не нашел. 😔 Каждый раз, когда он выдает мне сообщение об ошибке «Исходный URL-адрес недействителен» с кодом состояния 500. Затем я подумал, давайте загрузим размещенное веб-приложение и начнем проверку исходного кода. Скачал пакет приложения более 400 Мб. В пакете было несколько скриптов и jar-файлов.
Просто я декомпилировал эти файлы jar с помощью инструмента jd-gui и начал просматривать код. Моей основной целью была задача shortURL, которая обрабатывает короткий URL и не проверяет действительный сеанс аутентификации. Наконец, я нашел этот класс Java из файла jar.
Затем я узнал, почему он выдает одно и то же сообщение об ошибке каждый раз, параметр srcURL задачи shortURL принимает только URL-адрес, созданный с помощью « https://tinyurl.com/ 'для импорта данных или чтения данных с этого URL-адреса. Обратите внимание на следующий фрагмент кода:
Что теперь? - Давай эксплуатируем! 💥
Шаги по репликации (что я отправил в Facebook):
1. Откройте инструмент прокси пакета Burp, перейдите в меню Burp и выберите «Клиент Burp Collaborator». Создайте полезную нагрузку Collaborator и скопируйте ее в буфер обмена.
2. Откройте «https://tinyurl.com/» в веб-браузере, введите полезные данные соавтора и создайте его крошечный URL-адрес. Скопируйте созданный крошечный URL.
3. Вставьте скопированный крошечный URL в параметр srcURL следующего URL и откройте его в браузере:
https://m-nexus.thefacebook.com/servlet/taskProc?taskId=shortURL&taskEnv=xml&taskContentType=json&srcURL = {YOUR_TINY_URL_HERE}
4. Обратите внимание, что Burp Collaborator сразу обращается, он показывает IP-адрес «199.201.64.1», откуда был получен запрос.
5. IP - 199.201.64.1 принадлежит Facebook, подтвержден записями whois.
6. Чтобы протестировать внутренний SSRF: создайте крошечный URL-адрес недопустимого внутреннего IP-адреса (например, 123.10.123.10), вставьте его в параметр «srcURL» и убедитесь, что от сервера нет ответа.
7. Снова создайте крошечный URL-адрес действительного внутреннего IP-адреса (127.0.0.1:8080), вставьте его в параметр «srcURL» и посмотрите, как он запрашивает базовую аутентификацию HTTP.
С помощью этого наблюдения мы можем перечислить внутреннюю инфраструктуру за брандмауэрной средой. Я быстро сообщил о своих выводах в Facebook, но это было отклонено, поскольку они не сочли это уязвимостью безопасности. Обратите внимание на ответ ниже:
Так что дальше? - Копаем глубже ⛏️
Я должен был представить доказательства. Я попытался прочитать внутреннюю информацию, используя схемы URL, такие как file: //, dict: //, ftp: //, gopher: // и т. Д. Также попытался получить метаданные экземпляров облака, но безуспешно.
Спустя какое-то время я, наконец, придумал несколько впечатляющих примеров. Вот несколько сценариев атак в реальном времени, которые я отправил в Facebook вместе с инструкциями по воспроизведению:
1. Отраженный межсайтовый скриптинг (XSS):
2. Фишинговая атака с помощью SSRF:
ШАГ 1. Создайте и разместите фишинговую страницу входа в Facebook, которая крадет учетные данные для входа в Facebook жертв, которые выглядят как законный портал входа.
ШАГ 2. Откройте https://tinyurl.com/ в веб-браузере, создайте крошечный URL-адрес размещенной фишинг-страницы, например http://ahmedabadexpress.co.in/fb/ логин / fb.html '. Скопируйте созданный крошечный URL.
ШАГ 3. Вставьте скопированный крошечный URL в параметр srcURL следующего URL и отправьте жертве:
https://m-nexus.thefacebook.com/servlet/taskProc? taskId = shortURL & taskEnv = xml & taskContentType = json & srcURL = {YOUR_TINY_URL_HERE }
Как только жертва вводит свое имя пользователя и пароль на этой странице, он сохраняется в файле http://ahmedabadexpress.co.in/fb/login/usernames.txt. И жертва перенаправляется на настоящую страницу входа в Facebook. Вы можете видеть, что имя хоста представляет собой строку m-nexus.thefacebook.com, поэтому оно выглядит допустимым.
ШАГ 4. Перейдите по URL-адресу http://ahmedabadexpress.co.in/fb/login/usernames.txt и проследите за украденными учетными данными.
Злоумышленник также может использовать эту уязвимость для перенаправления пользователей на другие вредоносные веб-страницы, которые используются для обслуживания вредоносных программ и аналогичных атак.
3. Внутренние сетевые сервисы по отпечатку пальца (без доступа к Интернету):
Мне удалось просканировать внутреннюю сеть за брандмауэром. Я использовал злоумышленник Burp Suite, чтобы отправить более 10000 запросов на поиск открытого порта на сервере или любого приложения, работающего на этом порту.
После сканирования я наконец нашел приложение, работающее на порту 10303, с именем «LightRay».
Прежде чем я продолжу расследование по этому поводу, команда безопасности Facebook устранила эту уязвимость.
И наконец:
… это конец? - Нет, история только началась 😉
Теперь я знал, что MicroStrategy Web SDK размещен на рабочем сервере Facebook. MicroStrategy Web SDK написан на языке программирования Java, и мне нравится находить ошибки в коде Java. Итак, я декомпилировал каждый файл jar SDK с помощью инструмента JD Decompiler и начал просматривать код. Я также разместил SDK на своем сервере, так что если я обнаружу что-нибудь подозрительное в коде, я могу проверить это там. 👨💻
После 26 дней усердия и усердия я наконец получил интересное наблюдение. 💡
В классе com.microstrategy.web.app.task.WikiScrapperTask я заметил, что строка str1 инициализируется введенными пользователем данными, которые мы отправляем в качестве параметра. Он проверит, начинается ли указанная строка с http: // (или https: //) или нет, если да, то вызовет функцию webScrapper.
Функция «webScrapper» внутренне отправит запрос GET на указанный URL с помощью JSOUP. Он использовался для выборки и анализа HTML-страницы.
БУМ !! Опять был ССРФ .. 🕺
К сожалению, на этот раз это был слепой SSRF, поэтому я не могу доказать, что он позволяет отправлять внутренние запросы GET. Однако из исходного кода MicroStrategy Web SDK (который развернут в домене m-nexus.thefacebook.com) я подтвердил, что это был внутренний SSRF.
Исходя из этого наблюдения, мы не можем перечислить внутреннюю инфраструктуру за брандмауэрной средой или не можем утечь какую-либо конфиденциальную информацию. Я знал, что если я сообщу об этом в Facebook, они отклонят его, потому что эта уязвимость не оказывает никакого воздействия. 😔
Так что дальше? - Я был пуст в этот момент!
Я оставил это и начал искать новую уязвимость в основном домене Facebook (facebook.com)
Несколько месяцев спустя .. ⌛
Я обнаружил еще одну уязвимость в Facebook, в которой программа сокращения URL-адресов могла привести к утечке конфиденциальной информации о сервере.
Сокращение URL-адресов - это метод во всемирной паутине, при котором унифицированный указатель ресурсов может быть существенно короче и по-прежнему направлен на требуемую страницу. -Википедия
У Facebook есть собственная служба сокращения URL на https://fb.me/. Эта служба сокращения URL-адресов используется как внутренними (сотрудники Facebook), так и общедоступными пользователями. Я заметил, что короткий URL-адрес просто перенаправляет пользователей на длинный URL-адрес с использованием заголовка HTTP Location. Я заметил, что на сайте fb.me не установлен лимит скорости. Я искал существующие (и / или скрытые) веб-каталоги и файлы. Я запустил атаку методом перебора по словарю (около 2000 слов) против этого веб-сервера и проанализировал ответ. С помощью злоумышленника burp Suite я захватил несколько коротких ссылок, которые перенаправляют пользователя во внутреннюю систему, но внутренняя система перенаправляет пользователя на основной домен Facebook (например, facebook.com).
вот сценарий:
Https://fb.me/xyz == ›301 перемещено навсегда - https://our.intern.facebook.com/intern/{some-internal-data } ==› Найдено 302 - https: //www.facebook.com/intern/{some-internal-data } ==› 404 Not Found
Обратите внимание, что некоторые короткие ссылки, перенаправляющие пользователя во внутреннюю систему, создаются внутренним персоналом Facebook. Он может содержать конфиденциальную внутреннюю информацию. например « https://our.intern.facebook.com/intern/webmanager?domain=xyz.com&user=admin& token = YXV0aGVudGljYXRpb24gdG9rZW4g »
Я смог получить больше подобной информации, используя список слов и злоумышленник. Я создал простой скрипт на Python для автоматизации этой задачи.
Посмотрите ниже скриншоты с информацией, которую я получил во время тестирования.
Я добавил только два скриншота. В соответствии с политикой Facebook я не могу раскрыть всю информацию. Эта уязвимость раскрывает внутренний HTTP-запрос GET. Эта уязвимость раскрывает информацию о внутреннем пути к папке журналов, других путях к файлам, внутренних системных запросах, которые используют данные выборки, внутренний IP-адрес, внутренний идентификатор, информацию, связанную с конфигурацией, частные документы и т. Д. Без какой-либо аутентификации. Используя эту уязвимость, злоумышленник может перечислить действительные внутренние URL-адреса, присутствующие в системе.
Цепочка уязвимостей ⛓️
Теперь у меня две уязвимости:
1. Слепой SSRF - отправляйте запросы GET во внутренние и внешние системы
2. Утечка конфиденциальной информации сервера - внутренний путь к папке журналов, другие пути к файлам, внутренние системные запросы, которые используются для получения данных, внутренний IP-адрес, внутренний идентификатор.
Я создал сценарий, который показывает, как утечка конфиденциальной информации может быть полезна для запуска определенных атак, таких как обход пути и подделка запросов на стороне сервера (SSRF). Если злоумышленник может узнать внутренние IP-адреса сети, ему будет намного проще нацеливаться на системы во внутренней сети.
Я отправил оба PoC в Facebook и получил ответ:
Я заметил, что слепая ошибка SSRF теперь исправлена (задача «wikiScrapper» больше не доступна / регистрироваться).
Ммм .. это нечестно 😥
Я ответил:
Я получил ответ:
не повезло 😟
После нескольких дней исследований я нашел еще один слепой SSRF. 😎
Из исходного кода веб-SDK MicroStrategy я подтвердил, что это внутренний SSRF. В классе «com.microstrategy.web.app.utils.usher» я заметил функцию «validateServerURL», которая обрабатывает параметр «serverURL». Функция «validateServerURL» внутренне отправит запрос GET на указанный URL.
Я попросил их разрешить мне выполнить действие, описанное в моем предыдущем письме.
Они ответили, что они могут воспроизвести ошибку и работают над исправлением. они скоро сообщат мне о решении о награде.
Наконец, через несколько дней я получил ответ:
Ух ты! 🤩🤩🤩🤩🤩
Затем я хотел проверить, существует ли уязвимость SSRF на демонстрационном портале MicroStrategy, я обнаружил, что эта уязвимость тоже присутствует. Мне удалось получить интересную информацию с их сервера с помощью API метаданных AWS.
Я сообщил об этом в службу безопасности MicroStrategy и получил следующий ответ:
Заключение
Теперь проблема исправлена. Это немного более длинная статья, но я хотел дать вам очень хорошее представление о том, как вы можете объединить все свои навыки, такие как безопасный обзор кода, перечисление и знание сценариев, чтобы найти критическую уязвимость.
Когда я впервые обнаружил эту ошибку на сервере Facebook, я попытался преобразовать ее в RCE, но, к сожалению, они реализовали хорошие меры безопасности. Однако на этой уязвимости я заработал в общей сложности 31500 долларов (1000 + 30 000 + 500 долларов). 💰
Надеюсь, вам понравилась статья. Простите меня за ошибки.
Спасибо, что прочитали. Продолжай учиться.
Оставайтесь в безопасности и будьте здоровы 😇
