Сегодня мы подготовили для вас интересный материал о взломе крупной корпорации. Не скрою что это кропотливая и долгая работа, требующая терпения и усидчивости. Но собранная в данной статье база инструментарием позволит вам взломать корпоративную сеть, при этом будут применятся только бесплатные инструменты.
Reconnaissance, или сбор информации, — это первый этап тестирования на проникновение, когда цель уже определена. Понемногу этот этап превратился в отдельную науку, объединив в себе целый комплекс тактик и методик, а также обзавелся множеством инструментов и сервисов, упрощающих рутину. Какие возможности это нам открывает?
- Охота без конкретной цели или «нанимателя».
- Поиск новых масштабных угроз.
- Быстрая оценка распространенности конкретной угрозы.
- Нетсталкинг и просто исследование ради развлечения.
Дальше я перечислю самые популярные сервисы, с помощью которых можно провести полноценные исследования, и продемонстрирую основные приемы работы с ними. Однако главной темой статьи будет сервис grayhatwarfare.com, с помощью которого я и взломал корпорацию TUI Group.
Как взломать корпоративную сеть — Ресурсы
Сервисы для сбора информации можно условно разделить на несколько категорий — по типу предоставляемых данных или по сферам применения. Перечислим наиболее известные из них.
- Certificate Transparency — реестр привязанных к доменным именам цифровых сертификатов, в том числе и самых свежих, включая субдомены.
- Chaos, dnsdb.info, intelx.io, securitytrails.com, Сertspotter, threatminer.org, crt.sh — базы данных доменных имен, сертификатов и всей остальной информации, связанной с доменами.
- OpenIntel — отслеживает состояние глобальной системы доменных имен.
- Internet-Wide Scan Data Repository — это публичный репозиторий результатов сканирования интернет-протоколов, сервисов и служб по всему интернету. Хостится командой ZMap. Помимо своих собственных датасетов, команда аккумулирует и выкладывает данные и других похожих проектов. Этот ресурс — отличная возможность поработать с сырыми и полными данными.
- Rapid7 OpenData — то же самое, что и выше, только от создателей Metasploit Framework.
- Shodan, Zoomeye, Censys, fofa.so, riddler.io, spyse.com, thingful.net — поисковики, которые исследуют почти всю топологию интернета, предоставляя возможность поиска по баннерам сервисов и протоколов, их хешам или содержанию HTML-страниц. С их помощью можно найти подключенные к сети устройства или работающие приложения различных типов. В недавнем обновлении в Shodan появилась даже возможность поиска по идентификационным номерам уязвимостей.
- CommonCrawl — репозиторий многофункционального веб-краулера, собирающего массу интересной информации.
- GreyNoise, BinaryEdge, cybergreen.net, projecthoneypot.org — просто кладезь знаний о текущих угрозах! Если ты не знаешь, что исследовать, или хочешь быть в курсе самых актуальных уязвимостей, тебе сюда. Тренды и топ-листы GreyNoise расскажут о техниках, которые, возможно, еще даже не были обнаружены специалистами ИБ, но активно эксплуатируются в реальном времени.
- GrayHatWarfare — находит открытые для публичного доступа серверы Amazon AWS. Использует при поиске сразу несколько опенсорсных инструментов для сканирования, агрегируя все результаты. На данный момент GrayHatWarfare насканировал 279 тысяч доступных S3-бакетов и 4,5 миллиона файлов!
Подобных ресурсов достаточно много, и некоторые я даже специально пропустил — например, psbdmp.ws — из-за их чересчур узкой специализации. Однако сканировать весь интернет самостоятельно уж слишком долго и трудоемко. На гитхабе можно найти большой арсенал инструментов, адаптированных для работы почти с каждым из упомянутых сервисов. Но я постараюсь обратить твое внимание на упущенные кейсы и пробудить порыв к новаторству!
В конце статьи я кратко расскажу о моих экспериментах с, казалось бы, банальным Shodan. Ты, наверное, даже слышал об их последствиях, об этом уже писали. Я свято верю, что не нарушил никаких законов, так что смело раскрою свое авторство и некоторые оставшиеся за кадром подробности.
Кто чем занят при взломе корпоративных сетей
Если вспомнить большинство громких утечек за последние год-полтора, то можно выделить современные тенденции и цели атакующих. Я их перечислю:
Очевидно, под угрозой в основном плохо настроенные серверы и приложения, в которых авторизация зачастую отсутствует вовсе. Для сканирования используются все те же инструменты с открытым исходным кодом, которые можно найти на гитхабе, так что я не стану их перечислять. Некоторые атакующие используют для поиска Shodan, другие сканируют сеть самостоятельно.
Я не добавил AWS S3-бакеты в список неслучайно. Если посмотреть хронологию утечек информации из бакетов, то можно заметить явное снижение зафиксированных после 2018 года инцидентов. Этому поспособствовал ряд причин: шумиха, принятые Amazon меры, вооруженные сканерами баг-хантеры и так далее.
Конечно, можно купить хостинг, обзавестись новейшим софтом и принять участие в гонке сканеров, но мы не ищем легких путей! Подкрутить потоки и поковырять настройки какого-нибудь приложения может каждый, но самое интересное начинается там, где приходится использовать смекалку.
Обделенный Grayhat
Несмотря на обилие публикаций на тематических площадках, у довольно популярного и давно присутствующего на рынке GrayHatWarfare долго не было ни одного приложения или библиотеки для полноценной работы с предоставляемым им API. Все, что я нашел на гитхабе, — это криво написанный веб-парсер на python-mechanize.
Оказалось, этому есть причины: использование услуг этого сервиса стоит немалых денег, а условия бесплатного аккаунта не позволяют рассчитывать на достойный результат. Хотя я могу ошибаться. Язык запросов API настолько прост и лаконичен, что писать код по большому счету не нужно. Тем не менее я решил создать инструмент для работы с GrayHatWarfare, а вместе с этим реализовать многопоточность и обойти лимиты выдачи сервиса. Раз уж писать, то как следует!
Обходим ограничения бесплатного тарифа
Поиск по всем проиндексированным файлам ограничен 2000 результатов. Файлы же в обособленном бакете можно листать почти без ограничений, особенно когда мы ищем конкретные расширения файлов и используем исключающие ключевые слова. Так что я подменил один метод другим и реализовал перебор ID всех доступных бакетов. Таким образом, поиск всех имеющихся файлов с расширением .zip займет всего 20–30 минут. Ровно столько времени у меня ушло, чтобы скормить API 91 тысячу реквестов без единого фейла!
Логика и инструкции поиска
Итак, мы можем искать файлы с любыми расширениями. Между тем в API предусмотрена возможность добавлять к запросам ключевые слова, но только исключающие, иначе поиск ломается. Эти слова проверяются в каждой отдельной части полного URL-адреса искомого файла. Такой радикализм оправдан. В бакетах куча мусора типа медиафайлов, фронтенда и всяких опенсорсных бэкенд-модулей. Однако не бойся экспериментировать: все отброшенные урлы все равно запишутся в отдельный файлик trash.txt. Чтобы добавить свои собственные исключающие ключевики, сохрани их в файл exclude.txt.
Найденные файлы можно фильтровать и по размеру. Он указывается во время запуска программы. Чтобы запустить приложение, выполни в терминале следующие команды:
~$ git clone https://github.com/d34db33f-1007/grayhat2.git
~$ cd grayhat2 && python3 main.py
Деньги есть, ума не надо!
Фильтрация файлов по размеру — встроенная фича GrayHatWarfare API, но исключительно для оплаченных аккаунтов. В нашей реализации программы мы можем получать размеры файлов нативным образом только потому, что по факту мы не выполняем поиск, а просто листаем содержимое бакетов одно за другим.
Выходит, любой пользователь с оплаченным аккаунтом может просто запросить у API «топ-1000» самых тяжелых файлов, которые нередко и оказываются набором пользовательских данных, то есть пресловутой «утечкой». Значит, искать там больше нечего? А вот и нет!
Убиваем мейнстрим
Я попытался искать с помощью GrayHatWarfare файлы .csv
тяжелее 500 Мбайт. Среди них попадались интересные находки, но их оказалось недостаточно, чтобы ликовать и праздновать победу.
Второе, что мне пришло в голову, — это поиск приватных RSA/SSH-ключей. Вот тут мне повезло! Я проверил по очереди два расширения файлов: .priv
и .key
. К моему удивлению, уже через час после того, как я накатал на коленке свой питоновский скрипт, я обнаружил сразу три утечки! Как известно, беда не приходит одна. На серверах с приватными ключами я также нашел следующее:
- пользовательские данные фитнес-приложения с миллионом установок в Play Market;
- секретный токен аккаунта Amazon AWS от некоего uland.com.br;
- и самое стоящее — секретный токен Amazon AWS и приватный SSH-ключ веб-приложения Musement.com. Это итальянский стартап изначальной стоимостью в 60 миллионов долларов, теперь принадлежащий корпорации TUI Group.
По первым двум инцидентам мне не удалось связаться с владельцами ресурсов, но я уведомил Google и Amazon о произошедшем, хотя четкого ответа также не последовало. В TUI Group мне ответили на следующий день после обращения и залатали дыру уже спустя неделю.
Дальше я поэтапно опишу, как получил полный доступ с правами суперпользователя к продакшен EC2-инстансу Musement. Забавно, что такой очевидный инцидент до сих пор оставался незамеченным. Это тревожный звоночек: если тенденция стала мейнстримом, лучше всего ее избегать.
Первые результаты. Что дальше?
Собрав access-ключики, которые разработчики так любезно оставили в своем питоновском скрипте, я успешно авторизовался в аккаунте Amazon. Попробовав выполнить разные команды, я понял, что у меня имеется доступ только на чтение, причем далеко не везде. К тому же сервер, к которому я хотел подключиться по SSH, разрешал соединения только с IP-адресов из белого списка.
Собираем всю информацию об инфраструктуре
Недолго думая, я нашел на гитхабе популярный awesome-лист, посвященный пентесту Amazon, и начал с самого простого. Первым делом я собрал все публичные адреса EC2-машин, а также все IP-адреса из политик NACL (Network Access Control List) с помощью утилиты aws_public_ips
. В сумме набралось где-то тридцать адресов.
Собранные адреса я начал сканировать на наличие открытых портов в диапазоне 1–64 000 с помощью утилиты masscan
. Пока шло сканирование, я запустил еще две классические утилиты, которые позволяют получить более обширную и подробную информацию об имеющейся в твоем распоряжении облачной инфраструктуре:
- ScoutSuite2 — аудитор безопасности AWS. Незаменимый инструмент, который заглянет в каждый уголок облака и создаст максимально удобный для изучения отчет;
- pacu — то же самое, но заточен именно на поиск и эксплуатацию уязвимостей в облаке, в том числе на повышение привилегий, персистенцию, да и постэксплуатацию в целом.
Результаты оказались неожиданно приятными. Даже несмотря на то, что SGP (Security Group Policies) и IAM-права для утекшего аккаунта были настроены корректно. Для начала pacu
нашел способ повысить привилегии, пользоваться которым мне не позволяют этические принципы. Метод заключался в эксплуатации уязвимости CloudTrail CSV Injection. Имея возможность создавать trail (грубо говоря, события), я мог попытаться создать trail с вредоносной Excel-формулой в качестве названия. Эта попытка провалилась бы, но в логах осталось бы название. При импорте такого лога в формате .csv в Excel возникает опасность выполнения вредоносного кода на машине администратора.
ScoutSuite удивил меня еще больше. Ниже приведены частичные примеры того, что он смог нарыть в облаке.
Кроме того, на самом S3-бакете лежали очень интересные бэкенд-файлики. В общей сумме я смог вытянуть из пользовательских данных EC2-машин где-то 400 с лишним скриптов и конфигов.
Обходим защиту AWS SGP
Результаты сканирования внешних IP-адресов EC2-машин не сильно радовали, пока я не обнаружил роутеры с дефолтными админ-паролями и функцией VPN.
93.62.224.145 :: Huawei AR Web Platform 93.62.224.151 :: Huawei AR Web Platform
Главное достоинство этих роутеров заключалось в том, что они находились в белом списке NACL для входящего и исходящего трафика по всем портам, включая SSH, а также позволяли маршрутизировать трафик сквозь себя.
Теперь я мог спокойно подключиться к главному продакшен-серверу с root-правами, используя найденный приватный SSH-ключ.
Более подробные сведения о различиях между SGP и NACL
Этичность как она есть
Утечку компания пофиксила быстро, но, к сожалению, ни вознаграждения, ни даже банальной благодарности я от них не получил. Вместо этого мне сообщили, что на меня не станут подавать в суд, так как при тестировании я придерживался инструкций, которые они мне отправили на почту в ответ на мое письмо.
Для меня этот опыт — неприятное напоминание о том, что часто IT-компании ориентируются на гигантов индустрии, но игнорируют аспекты, связанные с безопасностью своего продукта и конечных пользователей. Поэтому давай сделаем мир безопаснее общими усилиями!
Не бакетами едиными!
Уже качаешь очередной hawkeye? Вот и правильно! Но не вздумай останавливаться на серых шляпах: попробуй совместить Google-дорки с Shodan’ом или поиграть с его родными тегами в трендах. Из этой затеи вполне может получиться что-нибудь интересное.
Наш блог в этом году писал об уязвимых видеорегистраторах LILIN. Эти уязвимые регистраторы изначально нашел я, заинтересовался и начал реверсить. Поэтому ответственно заявляю: в Qihoo 360 нагло приврали о количестве уязвимых устройств. На самом деле их было не 5К, а более 300К. Вот оригинальный дорк:
http.html_hash:"1640961097"
В итоге мне даже удалось продать найденные баги. Продавать я их пытался на легальных площадках вроде Zerodium, но не везде они котировались. Видимо, информация об уязвимости утекла в паблик с одной из таких платформ. В моем гитхабе ты можешь найти больше информации об этом инциденте.