Большинство рисёрчеров часто сталкивалось с проблемой когда есть какой-то api key, но не ясно откуда он, и работает ли он вообще. Для этого частенько использовалась база знаний KeyHacks. И вот так и жили. Находили ключики и смотрели что с ними сделать можно.
Но вот сегодня видимо правила игры поменялись.
Больше не нужно залипать на документацией по api у slack, stripe и других важных сервисов. Теперь все проблемы по валидации берет на себя TruffleHog v3 . Теперь нас ожидает куча детекторов на опенсорсе. Это же очень круто просканить сорцы и не сидеть над 20 aws ключами 19 из которых будт уже не активными. Теперь aws detect через вызов GetCallerIdentity сделает всё за вас.
Для тех кто сканит все сорцы внутри компании, это практически таблетка от фолзов.

У меня тут все истории о кавычка и нульбайтах. А между тем еще есть огромный мир security, о котором рассказывают на конференциях.
И вот совсем недавно прошла OffensiveCon, на которой был интересный доклад от участников Pwn2Own в категории сетевого оборудования(роутеров). И чуваки настолько классно рассказали о том как они работают вместе, как они хекают устройства от Cisco и прочих компаний что я не могу не поделиться с вами. Мне прям захотелось чуточку больше разобраться в этом и заказать какой-то девайс для изучения.
https://youtu.be/nnAxXnjsbUI

Вот классно вроде придумали ребята -

Protocol that allows clients to hide their IP addresses from DNS resolvers via proxying encrypted DNS over HTTPS (DoH) messages.  This improves privacy of DNS operations by not allowing any one server entity to be aware of both the client IP address and the content of DNS queries and answers.

Если бы не одно но. Оказывается можно подсунуть content-type, завернуть редирект и сделать Request forgery прямиком в aws meta-data. И конечно же такую интересную херовину у Cloudflare нашел никто иной как Frans Rosén.
Вся цепочка по ссылке в github issues - https://github.com/cloudflare/odoh-server-go/issues/30

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

Картина о том на сколько у меня всё херово с тайм менеджментом на "рисёрчи" и всякие интересности.
И тут я на самом деле заснул в 9 вечера, пока ребенка укладывал спать. Потом проснулся в 12 ночи и понял что очень хотел одну хрень посмотреть в приложении которым регулярно пользуюсь. Как итог - раскопал фатальную багу с возможностью чтения данных всех пользователей. И в итоге уснул между 3 и 4 ночи(утра). 🙈
Но именно такие истории хоть как-то возвращают меня во времена беззаботных ночных похеков. Так что я не жалуюсь, а скорее радуюсь. Как зафиксят так сразу полный дисклоуз сделаю в блоге.

Каждый раз когда встречаю на своем пути SSRF, то каждый раз возвращаюсь в свои же посты в данном канале где вспоминаю важные штуки или команды.
Кароч решил положить конец этому и обернуть тут всё важное и необходимое одним постом.
Если нам на пути встретилась не слепая ssrf. И если так получилось что сервис еще живет на AWS, то есть совершенно четкий сценарий что нужно делать с этим.
Сперва нужно проверить наличие IAM роли на профиле обратившись в

http://169.254.169.254/latest/meta-data/iam/
http://169.254.169.254/latest/meta-data/iam/security-credentials/

Если мы смогли получить в ответ role name то совершенно однозначно пытаемся забрать ключики

http://169.254.169.254/latest/meta-data/iam/security-credentials/your_role_name_here/

И если вам всё еще везет, то можно взять эти креды, сунуть их в ваш aws cli, и попытаться вызвать

aws ssm describe-instance-information --output text --query "InstanceInformationList[*]"

По прежнему всё чётко? Значит вы в пол шага от RCE на AWS через SSRF. Если нет, то можно поиграться в эти тулы:
https://github.com/RhinoSecurityLabs/pacu
https://github.com/nccgroup/ScoutSuite
https://github.com/andresriancho/enumerate-iam
А еще не забываем проверить какие s3 бакеты на аккаунте привязаны.

В целом шансов на полноценную rce через ssrf всё меньше и меньше т.к многие начинают переходить на IMDSv2(EC2 Instance Metadata Service) где всё же включили возможность обращения к метадате только через токен.
Т.е там заложено что для получения метадаты нужно запросить токен через PUT на

http://169.254.169.254/latest/api/token

при этом как-то сунув еще хедер

X-aws-ec2-metadata-token-ttl-seconds: 21600

. И вот потом с

X-aws-ec2-metadata-token: $TOKEN

, вторым запросом можно сходить на

http://169.254.169.254/latest/meta-data/

. Но есть твитт (https://twitter.com/Yassineaboukir/status/1512091514259873799) как рисёрчер умудрился и это сделать:

We found a way to control the headers and request method.

А тут собственно история про то как это у них получилось - https://www.yassineaboukir.com/blog/exploitation-of-an-SSRF-vulnerability-against-EC2-IMDSv2/
Если кратко, то чувакам повезло найти Confluence SSRF в которой через atlassian gadget можно было выполнить полноценный PUT запрос. По итогу они там еще и сложность встретили одну и обходили её через double URL-encoded. Круто что не растерялись.

Остальное полезное на почитать собрал тут:
https://hackingthe.cloud/aws/exploitation/ec2-metadata-ssrf/
https://sanderwind.medium.com/escalating-ssrf-to-rce-7c0147371c40
https://zonduu.medium.com/ssrf-to-fetch-aws-credentials-with-full-access-to-various-services-18cd08194e91
https://kloudle.com/academy/iam-bad-privilege-escalation-using-misconfigured-policies-in-aws-iam-webinar
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html

Каждый раз когда я делаю Responsible Disclosure report, то каждый раз нахожу в смешанных чувствах. Вроде правильное дело делаю, спасаю компанию от фатального штрафа или от кражи данных клиентов. Но иногда своими действиями я делаю кому-то хуже.

Первый пример такого "хуже" случился, когда я у RedBull нашел доступ к данным всех их спонсируемых атлетов. Можно было на мобильник позвонить гонщикам формулы. Или даже родителям этих атлетов. И ладно бы я нашел это один раз. Это произошло дважды. Как итог - консалтинг компания, которая занималась этим проектом потеряла контракт с Redbull. А потеря подобных контрактов всегда оборачивается потерей рабочих мест у консалтеров.

И вот сегодня случился очередной пример результативной работы "консалтинг компании". Один брэнд делает интересный продукт для маркета(которым я пользуюсь), и как итог - разработанное приложение на коленке консалтерами оказалось нифига не безопасным. И по сути афектило мои персональные данные.
Я даже не понял как они ревью в эппсторе прошли! Ведь без бурпа было ясно что идея так себе.
Ну и на мой репорт спустя почти неделю получил такой ответ:
Heard back and they are working on it. We are moving away from them for future development.
Just wanted to follow up, thanks!
Видимо снова с моей легкой руки кто-то будет искать работу 🙁

«Мотороллер не мой, я просто разместил объяву»
https://paramatter.art
Выглядит кстати очень годно. Попробую на выходных найти время и зачекать на реальных штуках 😇
Ps: мимо меня не менее топовая штука прошла. Но комьюнити сила 💪🏻
https://github.com/1ndianl33t/Gf-Patterns

Периодически залетаю почитать публикации этого парня, и каждый раз удивляюсь его сконцентрированности в client side атаках. Некоторые кривят нос и пишу - «client side фуу». Но пока некоторые так думаю, ровные ребятки нагибают фэйсбучек с багами по угону аккаунтов на десятки тысяч «беджаминов франклинов»💁🏻‍♂️
https://ysamm.com/?p=763
PS: есть ощущение что он самый experienced user фэйсбучка 🤪

Бесконечно можно смотреть на три вещи: как горит огонь, как течет вода и как Burp Suite Pro на Java пытается найти свободные ресурсы.

Я часто сталкиваюсь с проблемой, что люди которые уходят работать на полный день - не могут открыто и спокойно искать уязвимости в свободное от работы время.
Часто это ограничение связано с контрактом, который они подписывают с организацией. Есть несколько причин почему самой организации в которой вы работаете - это может быть нужно и даже выгодно.

1) Самое простое конечно это саморазвитие. Нельзя искать баги без прокачки скила, без чтения статей и новых техник. Так не работает. Собственно осуществляя эту активность регулярно, сотрудник в перспективе имеет постоянный и современный взгляд на вещи и на уязвимости.

2) Неоднократно из-за моей увлеченности в поиске уязвимостей, я находил уязвимости в сервисах организации в которой работаю. И происходило это из-за моей вне рабочей активности. Но каждый раз когда я что-то исследую я думаю - а нет ли в моей компании той или иной проблемы. И такие уязвимости находились.

3) Но более уникальным примером может стать история, когда я в результате своих исследований нашел уязвимость, которая по сути являлась supply chain атакой. Уязвимость затрагивала организацию для которой я хотел сделать ответственное раскрытие. Но когда я оценивал проблему, то заметил очень знакомое слово. Этим словом было название подрядчика, который привлекался в моей организации. Оказалось что "случайно взломанная" компания имеет второе юридическое лицо, которое и осуществляет работу в виде подрядчика для организации в которой я работал. В итоге в свободное от работы время я нашел очень серьезную проблему (CVSS 10.0) которую вряд ли бы нашел занимаясь основными обязанностями. И даже бы оценка вендора/подрядчика не показала бы эту проблему. Т.к оценка вендора не учитывает другие юридические лица и потенциальные связи нескольких юридических лиц. Ощущение было такое что я достал кролика из шляпы. Ну и ребята которым пришлось звонить в выходные ночью были очень удивлены и благодарны.

PS: Аналогичный пост закинул в твиттер. Можно полайкать чтоб больше рисёрчеров смогло объяснить своим менеджерам почему research activities не должны иметь ограничения по времени. А результаты могут быть полезны абсолютно всем.

Похоже что если я соберусь навестить свой родной город, то мой визит будет выглядеть вот так.
https://youtu.be/Da1NzX74T0c

Занимался я тут недавно поиском моих любимых уязвимостей. И так получилось что обнаружил какой-то богом забытый Docker Hub репозиторий принадлежащий одной компании.
Чутье мне подсказывало что надо делать

docker pull example/servicetool:latest

и потом смотреть что там внутри есть. Но совершенно точно и очевидно, что внутри надо как-то поиск автоматизировать. На помощь пришел SecretScanner (https://github.com/deepfence/SecretScanner)
Достаточно просто сделать:

docker run -it --rm --name=deepfence-secretscanner -v $(pwd):/home/deepfence/output -v /var/run/docker.sock:/var/run/docker.sock deepfenceio/deepfence_secret_scanner:latest -image-name example:latest

и в результатах будут всякие интересные находки.
Объем фолзов будет приличный. Но кто ищет - тот всегда найдет 😉

PS: Этот тул пришел на помощь мне значительно раньше по рабочим вопросам. Но пользовался один раз и вот когда припёрло снова, с трудом вспомнил как там и чего. Так что этот пост скорее напоминалка самому себе. Но и вы пользуйтесь. Я например не припомню репортов про leaked secrets from public dockerhub. Вполне себе логичный и валидный дополнительный вектор при реконе.

Отличное чтиво от @ByQwert
https://medium.com/@byq/from-open-redirect-to-rce-in-one-week-66a7f73fd082

Очередная попытка засэйвить кое-какие знания. На этот раз история про то как подружить api-doc от swagger и Burp Suite.
Тыкая в ночи на кнопочки, наткнулся на одном проекте на возможность прочитать

api/v2/api-docs

где в заголовке json было написано swagger 2.0. В этот момент это прям желанный файлик был, т.к сервис полностью блэкбокс. И даже стандартного юзера на вход у меня небыло. Пришлось проявлять изобретательность.
Ну быстрым гуглением обнаружилось что если отослать нужный запрос на API спеку в OpenAPI Parser(официальный BApp Extension) то можно получить сразу всё дерево api в Site map. Но в моей ситуации произошел облом. Extension сыпал ошибки и не мог подсосать описание API. А мне прям очень надо было, т.к это позволяло протестить ранее не известные методы. Руками добавлять все было не варик. Свыше 500 различных новых запросов с различными параметрами. Ребята из комьюнити отписались что сталкивались с подобными трудностями. И в конечном счете они шли в православный Postman и протыкивали всю апиху руками из Postman. Меня такие перспективы совсем не радовали.
В итоге не без помощи коллег по цеху удалось наткнуться на очень полезный сервисы от rhinosecuritylabs. По сути они написали тул, который парсит json на все возможные запросы. А потом отсылает их на эндпоинт, что позволяет Burp proxy увидеть их и затрэкать всё это безумие в site map.
Порядок действий:
1) качаем json спеку нашей API.
2) дописываем в нее (в моем случае этот кусок отсутствовал)

"host": "api.ourtargethere.com",
  "schemes": [
    "https"
  ],

3) копируем себе целиком весь json в буфер обмена.
4*) Открываем https://rhinosecuritylabs.github.io/Swagger-EZ/ и запихиваем наше содержимое json в поле.
5) Пытаемся настроить CORS для сервиса через автозамену в бурпе. Я в этой ситуации поел говна и примерно день думал над тем как решить, чтоб через проксю у меня шли не только OPTIONS запросы. Я так и не понял почему Regex для Match/Replace не помогли мне в этом. Спасением стал плагин на Firefox под названием CORS Everywhere.
6) После того как порешали с CORS или включили плагин CORS Everywhere, нужно ткнуть кнопочку Auto Fill и затем нажать Send All. В Site map сразу же появятся новые пути и новые запросы.
*Для владельцев шапочки из фольги, можно поднять свой локалхвост с этим сервисом дабы не сливать спеку API ребятам из rhinosecuritylabs.(https://github.com/RhinoSecurityLabs/Swagger-EZ)
PS: Если есть более гениальные решения - буду рад почитать в комментах.

Достаточно быстро предыдущий пост получил продолжение.
Чуваки из security команды не стали включать душнил. Поблагодарили за проделанную работу и спокойно триажнули багу, предвариетльно написав, что она будте оплачена по уровню Critical 🤑🎉
https://twitter.com/Krevetk0Valeriy/status/1534636951533498371?s=20