Если следующая команда возвращает missing_text_or_fallback_or_attachments, это означает, что URL действителен; любой другой ответ означает, что URL недействителен.
HackWare.ru
Эта статья об инструменте XRay для обнаружения и сбора информации о поддоменах.
Существует множество различных инструментов для пассивного и активного сбора информации, многие из которых уже были рассмотрены на страницах HackWare.com. Предлагаются также инструменты для регистрации поддоменов — только HackWare.ru недавно рассмотрел три отличных инструмента, каждый из которых имеет свои особенности и преимущества:
И все же программа XRay уникальна и имеет ряд удивительных преимуществ:
- Продолжение сбора данных по найденным субдоменам, включая использование сервисов Shodan и ViewDNS.
- Извлеченные данные имеют очень удобный веб-интерфейс с функцией поиска по всем полям извлеченных данных.
API ключи для XRay
Инструмент XRay можно использовать без API-ключей, но я бы рекомендовал получить их для Shodan, поскольку многие функции зависят от них. Кроме того, API-ключи Shodan можно использовать бесплатно — для целей этой статьи вам не нужен платный пакет.
API-ключ Shodan
Параметр ключа API shodan.io является необязательным ( -shodan-key KEY ). Однако, если он не указан, отпечатки сервисов не собираются и отображается гораздо меньше информации (фактически, функции XRay в этом случае ограничиваются списком DNS поддоменов).
Ключ API ViewDNS
Если указан ключ API ViewDNS ( -viewdns-key KEY ), также извлекаются исторические данные о хостах.
Бесплатные API предоставляются только на 250 запросов — этот лимит был превышен при первом запуске XRay. И лимит невозобновляемый — т.е. это не лимит на 1 день или 1 месяц — как только 250 запросов будут использованы, они исчезнут навсегда (или вам придется перейти на платный пакет).
Вопросы анонимности
Эта программа использует ваш основной DNS-сервер для регистрации поддоменов. Чтобы захватить баннеры открытых портов, он также может установить несколько соединений с вашего хоста с компьютерами в сканируемой сети. Технически, вы просто подключаетесь к публичным адресам через открытые порты (сканирования портов не происходит, информация об открытых портах извлекается непосредственно из Shodan через его API), но понятно, что некоторым людям такое поведение не нравится.
Вам следует рассмотреть возможность использования прокси-сервера, чтобы скрыть свой IP.
Если следующая команда возвращает missing_text_or_fallback_or_attachments, это означает, что URL действителен; любой другой ответ означает, что URL недействителен.
Steam API Scam
Сегодня мы хотели бы проинформировать наших клиентов о мошенничестве под названием Steam API Scam. Он используется с весны 2018 года, но некоторые пользователи все еще попадаются на эту аферу, и эта статья адресована именно им.
Мошенники крадут API-ключ от вашего аккаунта и используют его для контроля входящих и исходящих обменов. Они заменяют оригинальный обмен на поддельный, который уже отправляет вещи их боту. Скрипт мошенников копирует имя и аватар бота и даже сообщение обмена.
Как могут своровать мой API ключ?
Они просят вас ввести логин, пароль и пароль охраны, чтобы скрипт мог сгенерировать ключ API и использовать его в дальнейшем. Окно почти неотличимо от оригинала, но есть и отличия:
1). Окно создается как элемент HTML на сайте и не может быть перемещено за пределы браузера. (Не всегда).
4) Вы не можете изменить язык окна.
Как они воруют мои предметы?
1). Наш сайт отправляет вам обмен, и вы подтверждаете его.
2) После подтверждения обмена в браузере, пока вы входите в мобильный верификатор для повторного подтверждения, его скрипт уже заменил оригинальный обмен на поддельный и подтвердил его сам.
3) К тому времени, когда вы заходите на мобильный верификатор и видите подтверждение отправки данных, это уже мошеннический обмен. Чаще всего люди не замечают этого и оставляют свои вещи сами.
Как вы можете обеспечить обмен с нашего бота?
Мы не можем проверить, что ваш API-ключ не был украден, но мы стараемся уделить вам максимум внимания.
Если первоначальный обмен отклонен и наша система получила эту информацию, вы увидите эту таблицу на странице деталей и услышите предупреждающий сигнал.
К сожалению, это не поможет пользователям, совершающим транзакцию с мобильного телефона, так как их браузер в это время свернут.
Отсутствие этого заголовка, конечно, никого не остановит, но не стоит сразу давать такой намек. Поэтому передача этого заголовка должна быть запрещена.
Как проверить не взломан ли мой аккаунт?
Зайдите сюда https://steamcommunity.com/dev/apikey и проверьте, есть ли у вас ключ для API. Если у вас нет ключа (как на скриншоте ниже), ваша учетная запись не была взломана. Если у вас есть ключ, но вы не создали его самостоятельно, то ваша учетная запись на 100% скомпрометирована.
Вы также можете попробовать продать что-то дорогое, чтобы проверить это.
Прежде чем подтвердить обмен на своем телефоне, перейдите по этой ссылке http://steamcommunity.com/id/me/tradeoffers/. Если вы видите два обмена с одинаковыми кодами безопасности от одного и того же бота, один из которых отменен, а другой нет, ваш аккаунт на 100% взломан.
Как вернуть предметы которые переданы через поддельный трейд?
К сожалению, это невозможно обойти.
Если вы не создали ключ API и не знаете, зачем он вам нужен, перейдите по этой ссылке https://steamcommunity.com/dev/apikey и удалите его, нажав на кнопку «Revoke my Steam web API key».
Затем перейдите по следующей ссылке https://store.steampowered.com/twofactor/manage и нажмите «Отключить на всех других устройствах».
Затем вам нужно будет изменить пароль учетной записи Steam.
Пожалуйста, сообщите своим друзьям об этом мошенничестве, переслав им ссылку на эту статью, чтобы они не нажимали на нее.
Урок заключается в том, что отправлять ключ API или любой другой секрет в коде мобильного приложения — это все равно что запереть входную дверь, но оставить ключ под ковриком!
API1:2019 Broken Object Level Authorization (Недостатки контроля доступа к объектам)
Другое название этой опасности: небезопасные прямые ссылки на объект. В настоящее время это самая распространенная проблема с API. Вот пример API, который в будущем я буду использовать для еще нескольких примеров уязвимостей.
Загрузка пользователя с идентификатором userID:
Извлечь всех пользователей (это может сделать только администратор):
Удаление пользователя с идентификатором userID: DELETE /users/.
Таким образом, если вызывается команда для удаления пользователя:
Затем необходимо проверить, что эту команду может вызвать только пользователь 1 или сам администратор, а не, например, пользователь 2 от его имени, просто изменив значение ID в вызове команды. Чтобы избежать подобных проблем, вам следует:
- Проверьте разрешения объектов для каждого запроса.
- Убедитесь, что вошедший в систему пользователь имеет доступ только к авторизованным объектам.
- Идентификаторы объектов должны быть сложными для угадывания, например, UUID, а не просто 1, 2, 3.
- Управление доступом на основе ролей (RBAC)
- Дискретный контроль доступа (DAC)
- Обязательный контроль доступа (MAC)
- Управление доступом на основе разрешений
API5:2019 Broken Function Level Authorization (Недостатки контроля доступа на функциональном уровне)
Необходимо разработать четкую систему для разграничения доступа между ролями пользователей API. Например, есть одна роль: обычные пользователи и одна роль: администраторы. Только администратор может вызвать команду «Все пользователи»:
При каждом вызове команды требуется проверка прав, поэтому обычный пользователь не может вызвать команду, просто изменив формат.
API3:2019 Excessive Data Exposure (Разглашение конфиденциальных данных)
На самом деле этот элемент называется — предоставление избыточных данных, но это может привести к раскрытию конфиденциальных или личных данных. Как это может произойти? В ответ на запрос клиента сервер обычно создает запрос к базе данных, который возвращает запись или список записей. Эти данные часто сериализуются в JSON без какой-либо проверки и отправляются клиенту, предполагая, что клиент сам отфильтрует данные. Проблема, однако, заключается в том, что не только клиент может отправить запрос, но и злоумышленник может создать запрос непосредственно на сервере и получить конфиденциальные данные. Например, безобидный запрос данных для пользователя с идентификатором 1:
Может возвращать не только имя/возраст, но и ответ на секретный вопрос, заданный пользователем при регистрации:
Это называется чрезмерной передачей данных. Проблема усугубляется тем, что избыточные данные также могут иметь слишком большой объем. При высокой нагрузке это приводит к проблемам в сети. Поэтому при разработке API не стоит полагаться на фильтрацию данных на клиенте — все данные должны фильтроваться на сервере.
Урок заключается в том, что отправлять ключ API или любой другой секрет в коде мобильного приложения — это все равно что запереть входную дверь, но оставить ключ под ковриком!
🔗 API Key Authentication using OpenAPI
В дополнение к человекочитаемой документации по API, определение OpenAPI необходимо для разработки API. Вы можете описать весь свой API в машиночитаемом файле (YAML или JSON). Формат предназначен для охвата множества способов создания разработчиками REST API и поэтому является достаточно гибким для различных обсуждаемых ключевых методов API.
Например, вот раздел безопасности документа OpenAPI компании Stripe, показывающий два подхода к заголовкам, поддерживаемых для ключей API:
Наконец, машиночитаемая спецификация API позволяет без особых усилий тестировать реализацию на соответствие спецификации на протяжении всего цикла разработки API.
Stoplight Studio облегчает визуальное проектирование вашего API — включая определения безопасности вокруг аутентификации — в OpenAPI.
Чтобы проверить действительность ключа записи, вам понадобится projectId, публичное значение, которое обычно находится в файле cypress.json. Замените его и тело JSON своими значениями.
Reverse Engineer the Mobile App Binary
Обратная разработка бинарного мобильного файла может показаться очень техническим заданием, которое под силу только хакерам, экспертам или опытным программистам, но это оказывается проще, чем можно подумать. Это стало возможным благодаря тому, что мир открытого кода полон отличных инструментов, которые помогают исследователям безопасности в их работе. Но знаете что, поскольку это инструменты с открытым исходным кодом, они доступны для всех, кто хочет их использовать, включая разработчиков, инженеров по безопасности, хакеров и скрипт-кидди. Дети-скриптеры, естественно, достаточно способные, чтобы понять, как использовать эти инструменты, не имея образования в области компьютерных наук, точно так же, как они достаточно умны, чтобы изучить и освоить использование повседневного программного обеспечения, например, программ Microsoft. Так что если скриптовые детишки могут это делать, то и мы, программисты, должны это делать, и обучение думать как злоумышленники должно стать регулярным упражнением, поэтому мы должны взломать себя и попытаться провести реинжиниринг нашего мобильного приложения так же, как это делают они.
Спектр инструментов с открытым исходным кодом для реверс-инжиниринга огромен, и мы не сможем охватить его в этой статье. Вместо этого мы сосредоточимся на использовании Mobile Security Framework (MobSF), чтобы показать, как можно провести обратное проектирование APK нашего мобильного приложения. MobSF — это набор инструментов с открытым исходным кодом, которые представляют свои результаты в виде привлекательной приборной панели, но те же самые инструменты, используемые под капотом MobSF и в других местах, могут быть использованы по отдельности для достижения тех же результатов.
Mobile App — Android Hide Secrets
В этой статье мы используем Android Hide Secrets Research Repository — виртуальное мобильное приложение, в котором API-ключи скрываются с помощью различных техник.
Первый подход, который может предпринять разработчик для предоставления API-ключа мобильному приложению, — это сохранить его в исходном коде мобильного приложения. Мы приведем пример такого подхода с ключом API, хранящимся в переменной SOURCE_CODE_API_KEY. Этот подход легко поддается реинжинирингу и имеет тот недостаток, что он присутствует в коде, отслеживаемом Git’ом.
Другой подход заключается в хранении ключа в файле манифеста Android, но это также легко поддается реинжинирингу и контролируется Git’ом. Лучший подход — получить ключ API из файла gradle, а затем получить его из окружения. Это решает проблему отслеживания ключа API в Git, но при этом не возникает проблемы его легкой обратной разработки.
Пришло время искать более продвинутую технику, чтобы скрыть ключ API так, чтобы его было очень трудно извлечь из APK. Для этого мы будем использовать родной код на C++ для хранения ключа API и использовать интерфейс JNI, который NDK использует под капотом.
MobSF demo
Давайте клонируем исследовательский проект Android Hide Secrets с Github, скомпилируем APK для Android и загрузим его в среду MobSF. Я не буду подробно рассказывать о том, как скомпилировать APK для Android, но я могу облегчить вам жизнь, и вы сможете получить его уже скомпилированным со страницы релиза на Github.
Сейчас я покажу вам небольшую демонстрацию того, как провести реверс-инжиниринг APK с помощью MobSF для извлечения ключа API. Мы будем использовать образ MobSF Docker, но вы можете установить его на свой компьютер, просто следуйте инструкциям.
Чтобы запустить образ Docker, просто запустите его в терминале:
docker ru n-it —name mobs f-p 8000:8000 opensecurity/mobile-security-framework-mobsf.
В зависимости от вашей системы, вам может потребоваться добавить sudo к команде.
Если вы запустили команду Docker, а образ MobSF Docker еще не присутствует в вашей системе, он будет загружен, а затем немедленно запущен:
Теперь перейдите на сайт http://localhost:8000 в вашем браузере и загрузите APK:
После того как вы загрузите APK, MobSF начнет разбирать файл. Это может занять несколько минут, поэтому будьте терпеливы, наблюдая за этим экраном:
По завершении анализа результаты сводятся в красивую приборную панель:
Но поскольку нас интересует только ключ API, мы можем начать с поиска его в файле Android Manifest xml. Мы можем просмотреть его, нажав на темно-синюю кнопку в разделе «Просмотр кода» в правом нижнем углу скриншота выше, и мы окажемся на этой странице:
Как видно из файла манифеста Android, значения для MANIFEST_API_KEY и GRADLE_API_KEY_PLACEHOLDER легко доступны, но значения для GRADLE_API_KEY и GRADLE_ENV_API_KEY не доступны, хотя мы видим в манифесте Android, что они извлекаются как строки, поэтому мы также можем легко найти их в разделе Strings отчета MobSF:
The Android manifest xml file is one of the places where developers like to drop their API keys, but you might be interested to take a look into the source code itself by clicking on Security Analysis > Анализ кода в левом меню:
Теперь мы попадаем в раздел страницы со ссылками на файлы с распакованным исходным кодом, и именно там мы должны искать этот раздел:
