Показаны сообщения с ярлыком yandex. Показать все сообщения
Показаны сообщения с ярлыком yandex. Показать все сообщения

03 января 2018

[pda-test.yandex.ru] Arbitrary File Reading


Для автоматизации простых проверок на сайтах bug bounty я использую два php скрипта. Первый собирает поддомены с разных источников (например, crt.sh, virustotal, shodan) для программ, где scope указан в виде *.blah.com. Второй скрипт уже непосредственно ищет уязвимости по всему списку хостов, которые можно проверить за 1 запрос. Именно они и находят все эти пачки CRLF Injection и Open Redirect из моего профиля на hackerone. Причем, чем больше уязвимостей раскрываешь на h1, тем реже они потом находятся скриптами :)

Придумывая новые идеи для второго скрипта, я решил проверить раскрытие исходного кода для JS приложений. Иногда из-за неправильной настройки приложения раздача статических файлов может быть из той же папки, где находится и серверный JS код.

/app.js
/server.js

Данная проверка выстрелила на одном из поддоменов Yandex.

https://pda-test.yandex.ru/app.js

Данный файл был серверным JS кодом, но не содержал никакой интересной информации и больше был похож на шаблон. Поэтому я дополнительно перебрал js файлы по словарю. В случае, если имя файла содержало нижнее подчеркивание и заканчивалось на “.js”, сервер выдавал stacktrace.

За счет того, что nginx не нормализует path traversal с использованием обратного слэша, а NodeJS корректно его обрабатывает, удалось получить чтение js кода из произвольной папки. Подробнее про это можно прочитать тут - Arbitrary File Reading in Next.js. Единственным условием было наличие в пути нижнего подчеркивания, причем вариант “fake_path/../realfile” не работал. К счастью, в stacktrace был путь до папки node_modules, которую я и использовал.

Протестировав варианты отбрасывания постфикса “.js” внезапно отработал %3F, что в результате дало чтение произвольных файлов.

Более того, прав хватало даже на чтение /etc/shadow.

PS: Пользователь с логином zlietapki особенно порадовал.

12 сентября 2016

[developer.store.yandex.ru] Stored XSS


Нестандартная XSS в сервисе для публикации Android приложений в Яндекс.Store.

При добавлении нового приложения из apk извлекаются иконки, которые доступны по адресу
https://developer.store.yandex.ru/static/icon/<app_id>/<name>.png

Я обнаружил, что для иконок проверяется только расширение по белому списку (png, gif, jpg), но отсутствует проверка содержимого и регистра названия. Оказалось, что использование нестандартного регистра в расширении (например, ic_launcher.PNG) не поддерживается веб-сервером и заголовок Content-Type начинает определяться по контенту файла.

Таким образом, если в Android приложении заменить иконку файлом <html><script>alert(1)</script></html> с названием ic_launcher.PNG, подписать его и загрузить на сервер, то получается Stored XSS.

Аналогичным образом можно было загрузить вместо иконки SWF-файл и, используя дополнительные уязвимости, найденные ранее, довести атаку до полного захвата пользовательской сессии.

А именно:
1) Небезопасная настройка crossdomain.xml на browser.export.yandex.com (файл уже недоступен)
<allow-access-from domain="*"/>

2) XScript сценарий, выводящий все Cookie пользователя, включая Session_id. Для доступа к нему необходим был заголовок Referer, соответствующий регулярному выражению yandex сайтов.
browser.export.yandex.com/xml/common.xml (файл уже недоступен)

Примеры используемых apk:
https://blackfan.ru/bugbounty/xss_html.apk
https://blackfan.ru/bugbounty/xss_flash.apk