Как взломать корпоративную сеть используя бесплатные инструменты

Как взломать корпоративную сеть используя бесплатные инструменты

Life-Hack [Жизнь-Взлом]/Хакинг

#Обучение 

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

Reconnaissance, или сбор информации, — это первый этап тестирования на проникновение, когда цель уже определена. Понемногу этот этап превратился в отдельную науку, объединив в себе целый комплекс тактик и методик, а также обзавелся множеством инструментов и сервисов, упрощающих рутину. Какие возможности это нам открывает? 

  1. Охота без конкретной цели или «нанимателя».
  2. Поиск новых масштабных угроз.
  3. Быстрая оценка распространенности конкретной угрозы.
  4. Нетсталкинг и просто исследование ради развлечения. 

Дальше я перечислю самые популярные сервисы, с помощью которых можно провести полноценные исследования, и продемонстрирую основные приемы работы с ними. Однако главной темой статьи будет сервис grayhatwarfare.com, с помощью которого я и взломал корпорацию TUI Group.

Как взломать корпоративную сеть — Ресурсы 

Сервисы для сбора информации можно условно разделить на несколько категорий — по типу предоставляемых данных или по сферам применения. Перечислим наиболее известные из них. 

  • Certificate Transparency — реестр привязанных к доменным именам цифровых сертификатов, в том числе и самых свежих, включая субдомены.
  • Chaosdnsdb.infointelx.iosecuritytrails.comСertspotterthreatminer.orgcrt.sh — базы данных доменных имен, сертификатов и всей остальной информации, связанной с доменами.
  • OpenIntel — отслеживает состояние глобальной системы доменных имен.
  • Internet-Wide Scan Data Repository — это публичный репозиторий результатов сканирования интернет-протоколов, сервисов и служб по всему интернету. Хостится командой ZMap. Помимо своих собственных датасетов, команда аккумулирует и выкладывает данные и других похожих проектов. Этот ресурс — отличная возможность поработать с сырыми и полными данными.
  • Rapid7 OpenData — то же самое, что и выше, только от создателей Metasploit Framework.
  • ShodanZoomeyeCensysfofa.soriddler.iospyse.comthingful.net — поисковики, которые исследуют почти всю топологию интернета, предоставляя возможность поиска по баннерам сервисов и протоколов, их хешам или содержанию HTML-страниц. С их помощью можно найти подключенные к сети устройства или работающие приложения различных типов. В недавнем обновлении в Shodan появилась даже возможность поиска по идентификационным номерам уязвимостей.
  • CommonCrawl — репозиторий многофункционального веб-краулера, собирающего массу интересной информации.
  • GreyNoiseBinaryEdgecybergreen.netprojecthoneypot.org — просто кладезь знаний о текущих угрозах! Если ты не знаешь, что исследовать, или хочешь быть в курсе самых актуальных уязвимостей, тебе сюда. Тренды и топ-листы GreyNoise расскажут о техниках, которые, возможно, еще даже не были обнаружены специалистами ИБ, но активно эксплуатируются в реальном времени.
  • GrayHatWarfare — находит открытые для публичного доступа серверы Amazon AWS. Использует при поиске сразу несколько опенсорсных инструментов для сканирования, агрегируя все результаты. На данный момент GrayHatWarfare насканировал 279 тысяч доступных S3-бакетов и 4,5 миллиона файлов! 

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

В конце статьи я кратко расскажу о моих экспериментах с, казалось бы, банальным Shodan. Ты, наверное, даже слышал об их последствиях, об этом уже писали. Я свято верю, что не нарушил никаких законов, так что смело раскрою свое авторство и некоторые оставшиеся за кадром подробности.

Кто чем занят при взломе корпоративных сетей 

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

  • серверы MongoDB;
  • Rsync-демоны;
  • Elasticsearch;
  • DigitalOcean;
  • Azure Blobs;
  • Google Storage. 

Очевидно, под угрозой в основном плохо настроенные серверы и приложения, в которых авторизация зачастую отсутствует вовсе. Для сканирования используются все те же инструменты с открытым исходным кодом, которые можно найти на гитхабе, так что я не стану их перечислять. Некоторые атакующие используют для поиска 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 удивил меня еще больше. Ниже приведены частичные примеры того, что он смог нарыть в облаке.

Учетные данные суперпользователей в Tomcat-сервере
Некоторые лицензионные ключики
Спокойно брутим Basic HTTP auth 

Кроме того, на самом S3-бакете лежали очень интересные бэкенд-файлики. В общей сумме я смог вытянуть из пользовательских данных EC2-машин где-то 400 с лишним скриптов и конфигов.

Обходим защиту AWS SGP

Результаты сканирования EC2-машин

Результаты сканирования внешних IP-адресов EC2-машин не сильно радовали, пока я не обнаружил роутеры с дефолтными админ-паролями и функцией VPN. 

93.62.224.145 :: Huawei AR Web Platform 93.62.224.151 :: Huawei AR Web Platform 

Главное достоинство этих роутеров заключалось в том, что они находились в белом списке NACL для входящего и исходящего трафика по всем портам, включая SSH, а также позволяли маршрутизировать трафик сквозь себя.

Роутеры позволяли маршрутизировать трафик

Теперь я мог спокойно подключиться к главному продакшен-серверу с root-правами, используя найденный приватный SSH-ключ.

Подключаемся к главному продакшен-серверу

Этичность как она есть 

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

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

Не бакетами едиными! 

Уже качаешь очередной hawkeye? Вот и правильно! Но не вздумай останавливаться на серых шляпах: попробуй совместить Google-дорки с Shodan’ом или поиграть с его родными тегами в трендах. Из этой затеи вполне может получиться что-нибудь интересное. 

Наш блог в этом году писал об уязвимых видеорегистраторах LILIN. Эти уязвимые регистраторы изначально нашел я, заинтересовался и начал реверсить. Поэтому ответственно заявляю: в Qihoo 360 нагло приврали о количестве уязвимых устройств. На самом деле их было не 5К, а более 300К. Вот оригинальный дорк: 

http.html_hash:"1640961097" 

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

Источник


Report Page