Как стать автором
Поиск
Написать публикацию
Обновить

Jailbreak checker — как обезопасить свое iOS-приложение

Уровень сложностиСредний
Время на прочтение7 мин
Количество просмотров6.3K
Всего голосов 25: ↑21 и ↓4+20
Комментарии35

Комментарии 35

Почему я не могу пользоваться всеми функциями приложения на джейлбрейкнутом/рутованном смартфоне, но могу делать всё то же самое в браузере, только менее удобно? Не говоря уже о ПК, где рут-доступ есть по умолчанию.

Мы не запрещаем доступ к функциям приложения, а лишь предупреждаем пользователя об опасности использования такого устройства. А по поводу браузера - в случае попытки совершить платеж на сайте, необходимо подтвердить действие еще одним фактором безопасности - ввести код из смс/пуш, чего в мобильном приложении не требуется.

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

Читая подобные статьи я всегда удивляюсь...
Неужели поколение современных прикладных разработчиков не знает такой простой и давно известной истины, что пользователь с root правами (а jailbreak на IOS как и root на Android именно эти права и позволяют получить) может "скрыть" от любого другого пользователя или программы работающих не от root (а все пользовательские приложения на IOS и Android таких прав не имеют) наличие у себя таких прав или любого приложения/файла на устройстве. Для этого достаточно просто иметь или соответствующие знания OS (в частности unix) или соответствующий сторонний софт (которого так же достаточно, если собственных знаний у вас нет).
Ну ладно законодатели (они "слышали звон, но не знают где он"), но IT то специалисты... Куда же катится уровень знаний современных разработчиков.... :-)

Снаряд и броня – разработчики банковских приложений и Skype совершенствуют методы обнаружения джейлбрейка, разработчики твиков добавляют новые обходы для этих проверок.

:-) Да уж... Я еще понимаю когда разработчики OS под устройство "защищают" от получения root доступа... Но куда "впрягаются" и "надувают щеки" прикладники то? А главное это абсолютно безуспешно... Но видимо знание базовых принципов прав и разделения доступа в unix - им просто никто нормально не объяснил... :-)

Так "прикладники" все прекрасно понимают. Взломать можно все. Защититься невозможно. Но можно сделать взлом экономически нецелесообразным. Это прикладникам доступно или тоже нет?

Ковырять приложение из под OS существенно дороже, чем напрямую само приложение. Поэтому и ковыряют приложение. И это надо сделать экономически нецелесообразным, чтобы сваливались на уровень OS, и пусть там творят, че хотят. На это мы-"прикладники" уже повлиять не можем. Но на свою часть повлиять можем. И будем.

Или у Вас другое мнение?

Т.е. прикладники не в курсе что такое отладчик или думают что их "защиту" сложно обойти парой ассемблерных инструкций? :-) Если прикладную "защиту" еще не сломали - в 90% случаев это значит что ваше "супер приложение" никому и не интересно... Хотя конечно прикладникам никто не мешает думать обратное... :-)

Так знаем же. И защищаемся и от дебага тоже. Еще раз – полностью защититься нельзя. Можно лишь поднять стоимость взлома до неинтересных значений.

Или Вы предлагаете и стоимость взлома не повышать на одном лишь утверждении, что защититься нельзя? – пусть ломают простые смертные в 2 клика мышкой?

Что Вы-то предлагаете?

Предлагаю вместо "напрасных приседаний" делать что-то полезное для приложения... Или же у вас много "лишних" ресурсов чтобы тратить их на бесполезную "защиту"? Поскольку те кто не может "в два клика" сам, могут почти всегда набрать нужную строку поиска в интернете...
Или пример корпораций гигантов (с миллионными установками и пользователями) отказавшихся от проверок собственных приложений на предмет наличия root доступа клиента вам "не пример"? :-)

Почему же... Пример.

Но ФСБ со своими законами - все же регламент. Поэтому и делаем.

Да и наши безопасники считают, что разобрать то, что написано в гугле не каждый сможет. Вон ниже ссылка про защиту SnapChat, если я правильно ее понял при беглом просмотре, то товарищу за 2 недели так и не удалось вскрыть SnapChat. Та самая неприемлемая стоимость вскрытия. А напихать сотни проверок - не такая уж и трудоемкая задача-то...

? ФСБ ? :-) Что-то мобильных приложений с сертификатами ФСТЕК и ФСБ на OS общего назначения я не знаю... :-)

Проверка выполняется не для таких людей, которые в состоянии скрыть наличие у себя прав. А для обычных пользователей, которые настолько доверчивы, что предоставляют рутовые права неограниченному кругу лиц.

:-) Это да... Проще посадить ребенка под замок, чем его воспитывать...

if UnsafeMutablePointer<FILE>(fopen("/bin/bash", "r")) != nil ||
            UnsafeMutablePointer<FILE>(fopen("/Library/MobileSubstrate/MobileSubstrate.dylib", "r")) != nil ||
            UnsafeMutablePointer<FILE>(fopen("/usr/sbin/sshd", "r")) != nil ||
            UnsafeMutablePointer<FILE>(fopen("/etc/apt", "r")) != nil ||
            UnsafeMutablePointer<FILE>(fopen("/Applications/Cydia.app", "r")) != nil {
            return true
        }

А закрыть файл, если его удалось открыть?

Спасибо за хорошее замечание!
В статье приведены абстрактные примеры кода, а реализации могут отличаться у всех.

Просто копипастить же начнут, это же код на Swift, а не псевдокод)

:-) Как то так примерно...
#chown root.root /bin/bash
#chmod 700 /bin/bash
.......
Для .app дать права +rx только пользователю с "нужным" id... У остальных отобрать.

А можно пару примеров реальных векторов атак? А то пока видится что-то из серии "Раз пользователь убежал из клетки, то он бандит и ужас-ужас мы на взломанном устройстве!"

Было бы интереснее увидеть другую статью: "Наше приложение умеет безопасно работать в любой клоаке где его запускают. А ваши разработчики так умеют?".

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

Кто-то за удобство и безопасность, а кто-то потому что модно. Кроме того, существует ещё огромное количество устройств со вторичного рынка, зачастую устаревших, на которые штатным способом нужные приложения уже не поставить, так как они не поддерживаются современными версиями приложений, находящимися в App Store.

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

Насколько я заметил, единственное, что не работает из-за санкций - это Apple Pay, который джейлбрейком не починить.

Как там приложения банков, обновляются?

Да вроде никто не жалуется. Им-то чего сделается? Apple лениво банит старые релизы раз в полгода, банки лениво перевыпускают каждый релиз под новым id. Все при деле, ворон ворону глаз не выклюет, а для пользователей это прозрачно. Появляется в приложении кнопочка “Обновить”.

По факту приложения банков для iOS и для Android синхронны.

И как раз приложения банков не работают с джейлбрейком.

Что-то я не понял, это что, любое приложение на iOS может посмотреть какие ещё приложения установлены в системе? Получить доступ к практически произвольным файлам на устройстве???

Прошу прощения, но все приведенные проверки либо устарели, либо не будут работать должным образом.

...
blackra1n.app
FakeCarrier.app
Icy.app
...

Неужель у нас на дворе все еще 2013 год? Эти приложения пропали еще в те времена.

jailBreakText.write(toFile: "/private/jailbreak.txt", atomically: true

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

fopen("/bin/bash"

Чем fopen() в контексте проверки будет отличаться от stat(), указанного чуть выше по статье? Абсолютно ничем, разве что потратит лишние ресурсы. Про закрытие успешно открытого файла уже тут написали.

По итогу: если хотите проверять на джейлбрейки, делайте это хотя бы правильно. Как Snapchat. Иначе получается какой-то детский сад из прошлого века

P.S.: И тут еще в комментариях есть абсолютно верная мысль про абсолютную бесполезность таких детектов. Они почти все обходятся в два счета. Как минимум потому что вы и ваше приложение ограничено приватными API, а джейлбрейкеры - нет.

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

Пока они не ограничивают пользователя в действиях - пускай. Предупреждение - это одно.

Кстати задумался, каким боком в современной модели безопасности телефонов коды по SMS - безопасный канал? Нет, не говоря про атаки на сотовве сети, ЛЮБОЕ приложение с доступом к SMS (мы-то среднестатистического пользователя и про разрешения знаем) - потенциальная угроза. Не нужны никакие джейлбрейки и руты.

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

Не то что в подвале, у меня дома не ловится связь. В лучшем случае нестабильные 2 балки. Как оказалось (хвала приложениям), я ровно равноотдаленно от всех трех вышек, попросту в центре треугольника.

Поддержка Voice-over-Wifi и т.п. оставляет желать лучшего из-за секретничанья операторов, их отсталости (это типа как "нахой нам IPv6") и необновления прошивок телефонов. Да, в каждом телефоне должны быть захардкожены параметры оператора во внутренностях прошивки - иначе адиос. Плюс к этому идет натуральный region lock - ну не будет же производитель пихать в европейскую прошивку настройки азиатских операторов. Как-то так.

VoWiFi это вообще далекая галактика, они VoLTE-то доделать не могут...

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

Борьба с потенциальным фродом это всегда статистика и 100%-й эффективности не достичь. А далее вступает в силу требования по уровню операционных рисков, потреь, резервирования и т.п. Так система и работает.

Да я и не против таких требований, в общем-то, поэтому и написал в постскриптуме :). Мои претензии касаются скорее весьма низкого уровня исследования реализуемой области. Взять код 10-летней давности, надеяться, что он идеально работает, да еще и про это написать на хабре целую статью - извините, но уж лучше ничего тогда не писать.

В противовес могу привести статью из предыдущего моего комментария. Человек, в основном не работающий с iOS, детально и по полочкам разобрал весь принцип обнаружения рута/джейлбрейка в Snapchat. Полноценно провел настоящее исследования и убедился, что его метод обхода детекта работает. Вот если бы подобное было озвучено в текущей статье - вопросов бы не было от слова совсем.

Тоже добавлю, что результат перечисленных проверок на взломанном устройстве тупо подменится злоумышленником на необходимый. И приложение, получив ожидаемый результат, даже не увидит, что запущено на взломанном устройстве, и продолжит работать, как в безопасной среде со всеми вытекающими.

Этих проверок мало, нужна еще как минимум защита от дебага.

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

Если взять во внимание этот простой тезис, то становится вообще непонятно, почему люди публикуют проверки безопасности под тезисом: "Мы настолько уверены в своей защите, что готовы показать ее всем!". Кто-то сможет пояснить о чем, кроме пиара думают эти люди?

Автор – молодец! Копай глубже!

А к Qiwi теперь вопросики...

Зарегистрируйтесь на Хабре, чтобы оставить комментарий