Другой инструментарий Framework
Недавно мы обнаружили хак, который включает в себя боковую загрузку взломанного IPA с использованием "Cydia Impactor" ...
Другой инструмент, который часто используется в iOS это Фрида:
Внедрить свои собственные сценарии в процессы черного ящика. Подключите любую функцию, следите за крипто-API или отслеживайте частный код приложения, исходный код не требуется. Отредактируйте, нажмите Сохранить и мгновенно увидите результаты. Все без шагов компиляции или перезапусков программы.
В Решениях приложения
В идеале, мы бы хотели, чтобы клиент мог сообщать какой-либо сгенерированный идентификатор / контрольную сумму / отпечаток пальца нашему серверу. Нечто подобное поможет избежать очевидного взлома на стороне клиента, когда функция «IsHacked» всегда возвращает false!
К сожалению, злоумышленник всегда может вернуть один и тот же identifier/checksum/fingerprint, используя ту же технику, чтобы сделать IsHacked вернуть всегда false. Обычно это достигается с помощью инструментария инструментария, который подключается к коду во время выполнения и всегда возвращает identifier/checksum/fingerprint для подлинного мобильного приложения.
Любые решения, основанные на клиентских решениях для проверки целостность / подлинность устройства или мобильного приложения может быть обойдена инструментальными средами.
iOS DeviceCheck
Итак, я не уверен, легко ли можно обнаружить какие-либо из них, или iOS "официально" поддерживает какой-либо из этих методов для обнаружения небезопасных или взломанные приложения.
Я видел, как многие разработчики обращались к iOS DeviceCheck , чтобы решить этот тип проблемы, но обычно они упускают суть и цели DeviceCheck:
Решение Apple DeviceCheck в первую очередь предназначено для проверки личности и отслеживания физического мобильного устройства без необходимости отслеживать какую-либо личную информацию об устройстве или его пользователе:
Использование DeviceCheck API-интерфейсы в сочетании с межсерверными API-интерфейсами позволяют устанавливать и запрашивать два бита данных на устройство, сохраняя при этом конфиденциальность пользователя. Вы можете использовать эти данные для идентификации устройств, которые уже воспользовались рекламным предложением, которое вы предоставляете, ...
Однако важно отметить, что ответственность за идентификацию статуса устройство, ie уже получило вознаграждение, проявило ли оно оскорбительное поведение, было ли оно виновным в мошенничестве и т. д. c. с разработчиком:
... или чтобы пометить устройство, которое вы определили как мошенническое. API-интерфейсы DeviceCheck также позволяют вам проверить, что полученный вами токен получен с устройства Apple, на которое было загружено ваше приложение c.
Здорово, что мы можем убедиться, что токен DeviceCheck исходит от устройство authenti c iOS, но разработчики не должны недооценивать дополнительные усилия, необходимые для идентификации устройств, в частности тех, которые связаны со злоупотреблениями и мошенничеством, из-за уже упомянутых инструментальных средств, которые могут быть не обнаружены или могут обойти DeviceCheck.
Таким образом, DeviceCheck может что-то сказать о подлинности устройства, но не может ничего сказать о подлинности мобильного приложения, это ваше мобильное приложение, точно такое же, которое вы загрузили в магазин Apple, и его инструментируют с помощью фреймворка как и Фрида, это объект атаки человека посередине (MitM)? Это все, что выходит за рамки DeviceCheck, и те, от которых вы ищете защиту.
Возможное решение
Был ли у кого-нибудь опыт или успех при обнаружении любого из вышеуказанные ситуации?
Определение подлинности / целостности мобильного приложения достижимо с очень высокой степенью достоверности с помощью внешнего решения для аттестации мобильных приложений, то есть службы, которая не будет принимать решения в мобильном приложении или на устройстве, на котором оно запущено, вместо этого оно будет использовать внешний сервер для принятия решений, которые будут отправлять случайные вызовы мобильному приложению для определения его подлинности / целостности. Вы можете прочитать больше о статье, которую я написал, в частности, в разделе Роль аттестации мобильных приложений :
Прежде чем мы погрузимся в роль службы аттестации мобильных приложений, Сначала нам нужно понять разницу между тем, кто и кто обращается к серверу API. Это обсуждается более подробно в этой статье, где мы можем прочитать:
Что делает запрос на сервер API. Действительно ли это подлинный экземпляр вашего мобильного приложения, или это бот, автоматизированный скрипт или злоумышленник, вручную копающийся в вашем API-сервере с помощью такого инструмента, как Postman?
Кто является пользователем мобильного приложения? что мы можем аутентифицировать, авторизовать и идентифицировать несколькими способами, например, используя OpenID Connect или потоки OAUTH2.
Роль службы аттестации мобильных приложений заключается в аутентификации того, что отправляет запросы, таким образом, только отвечая на запросы, поступающие от подлинных экземпляров мобильных приложений и отклоняющие все другие запросы из неавторизованных источников.
Чтобы узнать, что отправляет запросы на сервер API, служба аттестации мобильных приложений во время выполнения будет идентифицироваться с высокая уверенность в том, что ваше мобильное приложение присутствует, не было подделано / переупаковано, не запущено в рутированном устройстве, не было подключено инструментальной средой (Frida, xPposed, Cydia и др. c.) и не является объект Человек в средней атаке (MitM). Это достигается путем запуска SDK в фоновом режиме, который будет взаимодействовать со службой, работающей в облаке, для подтверждения целостности мобильного приложения и устройства, на котором оно работает.
При успешном подтверждении целостности мобильного приложения выдан кратковременный токен JWT, подписанный секретом, который известен только облачному API-серверу и службе аттестации мобильных приложений в облаке. В случае неудачной аттестации токен JWT подписывается с неверным секретом. Поскольку секрет, используемый службой аттестации мобильных приложений, не известен мобильному приложению, невозможно выполнить обратный инжиниринг его во время выполнения, даже если приложение было взломано, запущено на корневом устройстве или обменивается данными через соединение это цель атаки MitM.
Мобильное приложение должно отправлять токен JWT в заголовке каждого запроса API. Это позволяет серверу API обслуживать запросы только в том случае, если он может проверить, что токен JWT был подписан общим секретным ключом и срок его действия не истек. Все остальные запросы будут отклонены. Другими словами, действительный токен JWT сообщает серверу API, что запрос выполняет подлинное мобильное приложение, загруженное в магазин Google или Apple, в то время как неверный или отсутствующий токен JWT означает, что то, что делает запрос, не авторизовано для этого. потому что это может быть бот, переупакованное приложение или злоумышленник, выполняющий атаку MitM.
При самостоятельной реализации аттестации мобильного приложения всегда помните, что SDK, поставляемый с мобильным приложением, должен не принимать никаких решений и должен использовать закрепление сертификатов в канале связи с сервером, который запускает испытания и принимает решения.
ИДЯ НА ДОПОЛНИТЕЛЬНУЮ МИЛЮ
Мне всегда нравится рекомендовать отличный ресурс от OW ASP, OW ASP Руководство по тестированию мобильной безопасности :
Руководство по тестированию мобильной безопасности (MSTG) - это всеобъемлющее руководство по разработке безопасности мобильных приложений, тестированию и обратный инжиниринг.