Приложения Jekyll: как они атакуют безопасность iOS и что нужно о них знать |

Несмотря на то, что исследования Jekyll не новы и не должны вызывать паники, они могут помочь Apple лучше защитить iOS и повысить безопасность наших данных.

Сегодня исследователи Tielei Wang, Kangjie Lu, Long Lu, Simon Chung и Wenke Lee из Georgia Tech выступили с докладом на 22-м симпозиуме по безопасности USENIX и рассказали о том, как они получили так называемое «приложение Jekyll» благодаря одобрению App Store. процесс и в положение, где он может выполнять вредоносные задачи. Их методы выдвигают на первый план ряд проблем с эффективностью процесса проверки Apple App Store, а также с безопасностью в iOS. Исследователи сразу же забрали свое приложение из App Store после загрузки его на свои тестовые устройства, но продемонстрировали методы, которые могут быть использованы другими для проникновения вредоносного ПО в рецензенты Apple.

Детали процесса проверки приложений Apple не известны широкой публике, но, за исключением нескольких заметных исключений, он в значительной степени успешно защищал вредоносное ПО от устройств iOS. Основная предпосылка приложения Jekyll состоит в том, чтобы отправить на вид Apple безобидное приложение для одобрения, которое после публикации в App Store можно использовать для демонстрации злонамеренного поведения. Концепция довольно проста, но давайте углубимся в детали.

Процесс обзора App Store

Когда разработчик отправляет свое приложение в Apple для проверки, приложение уже скомпилировано, а это означает, что у Apple нет возможности просматривать фактический исходный код. Считается, что два основных компонента процесса проверки Apple — это практический обзор приложения и статический анализ двоичного файла приложения. Практический обзор состоит в том, что Apple фактически помещает приложение на устройство и использует его, чтобы убедиться, что оно соответствует Руководству по рассмотрению приложений и не нарушает какие-либо политики Apple. Часть статического анализа, вероятно, представляет собой автоматизированный процесс, который ищет любые признаки связи с частными средами использования частных API в скомпилированном коде. У Apple есть ряд частных платформ и API, которые необходимы для функциональности iOS и используются для системных приложений и функций, но по тем или иным причинам не разрешены для использования разработчиками. Если приложение ссылается на частную платформу или вызывает частный API, статический анализ обычно обнаруживает это, и приложение будет отклонено из App Store.

Приложение Jekyll начинается как любое обычное приложение, которое вы можете найти в App Store.

Приложение Jekyll начинается как любое обычное приложение, которое вы можете найти в App Store. В данном конкретном случае исследователи использовали приложение Hacker News с открытым исходным кодом в качестве отправной точки. В обычных условиях это приложение подключается к удаленному серверу, загружает новостные статьи и отображает их для пользователя. Это именно та функциональность, которую Apple увидит в процессе обзора. Apple увидит работающее приложение, которое соответствует их рекомендациям, статический анализ не выявит использования частных платформ или API, и приложение, скорее всего, будет одобрено для App Store. После того, как приложение Jekyll было одобрено и выпущено в App Store, именно тогда все пошло не так.

Внутри приложения Jekyll исследователи внедрили уязвимости в свой код, создав намеренный черный ход. После того, как приложение было добавлено в App Store, и они смогли загрузить его на свои тестовые устройства, исследователи разместили специально созданные данные на своем сервере новостей для загрузки приложений, которые будут использовать уязвимости, которые они внедрили в приложение. Используя уязвимость переполнения буфера в приложении, исследователи могут изменить выполнение логики приложения. Один из способов, которым исследователи используют это, заключается в загрузке многочисленных «гаджетов», которые распространяются по всему их коду. Каждый гаджет — это небольшой фрагмент кода, который что-то делает. Имея возможность изменять выполнение кода, исследователи могут связывать воедино несколько гаджетов, что заставит приложение выполнять задачи, которые оно не могло выполнить изначально. Но для того, чтобы найти эти гаджеты и вызвать нужные фрагменты кода, исследователи должны знать, как надежно вызвать местоположение этих фрагментов кода в памяти. Для того, чтобы сделать это, они должны были бы иметь возможность определить расположение памяти своих приложений на данном устройстве.

iOS использует два известных метода безопасности для предотвращения атак переполнения буфера: рандомизация размещения адресного пространства (ASLR) и предотвращение выполнения данных (DEP). ASLR работает путем рандомизации распределения памяти для процессов и их различных компонентов. Рандомизируя, где эти компоненты загружаются в память, злоумышленнику очень трудно надежно предсказать адреса памяти, которые будут использоваться для любого другого фрагмента кода, который он может захотеть вызвать. DEP усиливает защиту от атак переполнения буфера, гарантируя, что части памяти, которые могут быть записаны, и части памяти, которые могут быть выполнены, остаются отдельными. Это означает, что если злоумышленник может записать в часть памяти, например, чтобы вставить фрагмент maliciuos своего собственного кода, он никогда не сможет выполнить его. И если бы они смогли выполнить то, что было в определенном фрагменте памяти, этот фрагмент памяти был бы тем, в который им не разрешено писать.

Исследователи отметили слабость iOS-реализации ASLR. iOS обеспечивает только рандомизацию на уровне модулей. Это означает, что каждому исполняемому файлу, приложению, библиотеке и т. Д. В памяти назначается случайное место для работы. Однако в каждом из этих модулей структура памяти останется прежней, что сделает ее предсказуемой. В результате, если вы можете получить адрес памяти одного фрагмента кода, вы можете вывести макет памяти для всего модуля, что позволит вам вызывать любой другой фрагмент кода в этом модуле. Чтобы получить для этого адрес памяти, исследователи внедряют в свое приложение уязвимости раскрытия информации, которые вызывают утечку информации о модулях памяти в их приложении. Затем эта информация отправляется обратно на сервер, который может определить макет памяти всего приложения, позволяя ему определять адрес памяти любых фрагментов кода, которые он заинтересован в запуске, и произвольно выполнять их.

Что касается DEP, это, как правило, предназначено для предотвращения использования злоумышленником переполнения буфера в приложении, над которым он имеет ограниченный контроль. Приложение Jekyll — это совершенно другой сценарий, в котором злоумышленник также является разработчиком используемого приложения. В этой ситуации им не нужно контролировать запись в память и ее выполнение. Любой вид полезной нагрузки или вредоносного кода, который злоумышленнику обычно необходимо записать в память в рамках своего эксплойта по переполнению буфера, разработчик приложения Jekyll может просто включить в код своего исходного приложения. Затем они могут использовать переполнение буфера, чтобы изменить выполнение памяти, чтобы загрузить нужные гаджеты. Доказано, что DEP в других системах подвержен так называемому программированию, ориентированному на возврат. Идея состоит в том, что злоумышленник может обойти DEP, повторно используя код, который уже существует в памяти. В приложении Jekyll разработчик может внедрить любой код, который позже понадобится, и эффективно обходить DEP, повторно используя свой собственный код, который он создал.

На данный момент у исследователей есть приложение, в которое они встроили несколько программных гаджетов.

На данный момент у исследователей есть приложение, в которое они встроили несколько программных гаджетов, которые они теперь могут вызывать и связывать вместе по желанию, и они могут изменять поток логики приложения без какого-либо знания пользователя. Они могут использовать это для выполнения поведения, которое обычно приводит к отклонению приложения из App Store, например, к загрузке адресной книги пользователя на его сервер (после того, как сначала убедить пользователя предоставить доступ к его контактам). Но iOS ограничивает приложения своей собственной песочницей, и Apple не разрешит приложения, использующие частные API, поэтому влияние приложения Jekyll все еще довольно ограничено, верно?

Интимные части тела

Как упоминалось ранее, Apple, как правило, отклоняет любые приложения, которые ссылаются на частные платформы или вызывают частные API. Из-за отсутствия прозрачности мы можем только догадываться о том, как именно Apple собирается их обнаруживать, но наиболее вероятный ответ заключается в том, что Apple использует инструменты статического анализа для обнаружения любых частных сред, которые были связаны, или любых частных методов, которые явно использовались в код. Но с приложением Jekyll мы увидели, что у исследователей есть возможность динамически изменять код, так как это влияет на частные API?

Здесь есть два частных API, представляющих особый интерес: dlopen () и dlsym (). dlopen () позволяет загружать и связывать динамическую библиотеку только по имени файла. Так уж получилось, что частные фреймворки всегда находятся в одном и том же месте на устройстве, так что это достаточно легко выяснить. dlsym () позволяет вам искать адрес памяти указанного метода для платформы, загруженной dlopen (), что именно то, что вам нужно для вызова частного метода в приложении Jekyll. Поэтому, если исследователям удастся найти dlopen () и dlsym (), они смогут использовать эти закрытые методы для простой загрузки любых других частных API на устройство.

К счастью для исследователей, эти два API-интерфейса обычно используются в общедоступных средах. Публичные платформы используют эти API через так называемые функции батута. С помощью отладчика исследователи смогли определить смещения этих функций батута относительно начала некоторых общедоступных структур. Используя рассмотренные выше уязвимости раскрытия информации, которые позволяют исследователям утекать информацию о структуре памяти любого данного модуля, исследователи могут использовать эти известные смещения, чтобы указывать на функции батута для dlopen () и dlsym () с их приложением. Указывая на эти функции, исследователи теперь могут динамически загружать любую частную платформу и вызывать любой частный API в своем приложении. И помните, ничего этого не происходит, когда Apple рассматривает приложение. Это срабатывает только после одобрения приложения.

Атака

Теперь, когда мы видим, как исследователи могут изменять поток своего приложения и вызывать частные API, давайте посмотрим, что это значит с точки зрения злонамеренного поведения в приложении Jekyll.

В iOS 5 и 6 исследователи получили доступ к частным API-интерфейсам для публикации твитов, доступа к камере, набора телефонных номеров, манипулирования Bluetooth и кражи информации об устройстве — и все это без вмешательства пользователя.

Исследователи отметили ряд различных возможностей атаки (хотя это не следует рассматривать как полный список возможных атак) для iOS 5 и 6. В iOS 5 они могут отправлять SMS и электронную почту без какого-либо взаимодействия с пользователем или уведомления. Используя частные API для отправки SMS и электронных писем непосредственно процессам iOS, ответственным за фактическую отправку этих сообщений с устройства, приложение Jekyll смогло отправить их, ничего не показывая пользователю. К счастью, способ работы этих операций с тех пор изменился, и эти атаки не работают с iOS 6.

В iOS 5 и 6 исследователи получили доступ к частным API-интерфейсам для публикации твитов, доступа к камере, набора телефонных номеров, манипулирования Bluetooth и кражи информации об устройстве — и все это без вмешательства пользователя. Хотя размещение неавторизованных твитов не может быть концом света, другие вызывают немного больше беспокойства. Доступ к вашей камере будет означать, что злоумышленник может скрытно сфотографировать и отправить их обратно на свой сервер. Набор телефонных номеров без ведома пользователя можно использовать для совершения платных звонков или даже для настройки переадресации вызовов, чтобы все входящие телефонные звонки жертвы переадресовывались на другой номер. Очевидно, что когда приложение может получить доступ к закрытым методам, все может стать жутким, и становится очевидным, почему Apple ограничивает доступ к этим функциям.

Решение проблемы

К сожалению, текущий процесс проверки Apple не настроен на обнаружение такого типа поведения. Apple только анализирует поведение приложения, как оно есть на момент проверки. Если его поведение изменяется после того, как оно появилось в App Store, Apple вообще не имеет возможности обнаруживать эти изменения и отслеживать поведение приложений в реальном времени после их запуска. Apple может потребовать, чтобы разработчики также представили свой исходный код, но для Apple было бы невозможным пройти и проверить исходный код каждого приложения, представленного в App Store. Даже если бы они могли проверять каждую строку кода либо вручную (даже близко не возможно), либо с помощью автоматических инструментов, часто визуально обнаружить ошибки в коде нелегко, особенно если у вас есть злонамеренный разработчик, намеренный скрывать ошибки намеренно. Исследователи сказали, что Apple с удовлетворением отреагировала на их выводы, но исследователи не знают, что Apple планирует предпринять в отношении этих проблем. Стоит также отметить, что эти проблемы не являются уникальными для Apple.

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

iOS 7 а что там еще делать?

Многие из атак, которые они поместили в свое приложение Jekyll, не работали на iOS 7.

Исследователи смогли поделиться с iMore одной информацией о том, что многие атаки, которые они проводили в своем приложении Jekyll, не работали на iOS 7. Хотя мы не знаем конкретно, какие из них все еще работают, а какие нет, возможно, что Apple смягчила некоторые угрозы аналогично тому, как они нарушили возможность отправлять SMS и электронную почту без взаимодействия с пользователем в iOS 6. Хотя это напрямую не решает основные проблемы в iOS, которые допускают динамическое выполнение кода, это не совсем Ясно, если это то, что Apple может или даже должна сделать.

Изменение поведения приложения на основе ответов от сервера не является чем-то новым, просто оно обычно не используется со злым умыслом. Многие совершенно законные приложения в App Store используют файлы удаленной конфигурации, чтобы определить, как они должны себя вести. Например, телевизионная сеть может создать приложение, которое будет вести себя по-разному в течение медленного лета, чем осенью, когда все любимые шоу снова начинают работать. Было бы разумно и совершенно законно для приложения периодически проверять сервер, чтобы выяснить, должен ли он быть в летнем или осеннем режиме, чтобы он знал, как отображать какой контент.

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

Нижняя линия

Команда Georgia Tech предоставила очень интересные исследования. Оценивая механизмы безопасности Apple в iOS и методы их проверки в App Store, они смогли выявить слабые места, которые можно было использовать для загрузки вредоносных приложений на устройства пользователей. Однако тот же результат может быть достигнут с помощью более простых средств.

Злоумышленник-разработчик может запутывать вызовы частных API, разбивая их по нескольким переменным, которые впоследствии будут объединены в одну строку текста, которая может вызывать API. Разработчик может использовать значение в простой конфигурации, размещенной на их сервере, чтобы сообщить приложению, запускать этот код или нет. Если флаг отключен во время процесса проверки, Apple не обнаружит злонамеренное поведение, и после его подтверждения злоумышленник может изменить флаг на сервере, и приложение может начать атаку.

Эти типы атак определенно возможны на iOS и были в течение некоторого времени. Так почему же мы не видим их эксплуатируемых в дикой природе чаще? Там, вероятно, множество причин:

• Даже законные разработчики с отличными приложениями изо всех сил пытаются быть замеченными. — С более чем 900 000 приложений в App Store ваши приложения останутся незамеченными для пользователей. Законные разработчики, которые вкладывают все свои силы в приложения для разработчиков, которые, как полагают, будут по-настоящему восхитительными в использовании, часто испытывают трудности с получением значительного числа людей для загрузки своего приложения. Приложение Jekyll может использоваться для конкретных пользователей, которых вы можете убедить установить приложение, но получить значительную часть пользовательской базы Apple для установки или даже заметить, что ваше приложение — это не малое дело.
• Там гораздо ниже висящие фрукты там. — Магазин Google Play боролся с защитой от вредоносных программ с момента своего появления на Android Market в 2008 году. У вас также есть неофициальные магазины приложений, используемые как джейлбрейкерами, так и пиратами, которые не проходят такой же процесс обзора, как Apple, где их было бы много. проще разместить вредоносное приложение. Суть в том, что помимо App Store есть много мест для распространения вредоносных программ, которые могут нанести гораздо больший ущерб, требуя при этом гораздо меньших усилий. Чтобы защитить свой дом от грабителей, он не должен быть полностью безопасным, он просто должен быть более безопасным, чем дом вашего соседа.
• Apple может легко извлекать приложения из App Store в любое время и отзывать учетные записи разработчиков. — Как мы уже неоднократно видели, если приложению удается проникнуть через ворота Apple, которые не соответствуют их рекомендациям, оно быстро удаляется из App Store, как только Apple осознает их ошибку. Кроме того, в случае более серьезных нарушений Apple может и закрыла учетные записи разработчиков. Разработчик может зарегистрировать другую учетную запись разработчика с другой информацией, но каждый раз ему придется платить еще 99 долларов.
• Как только вредоносная программа проходит через ворота, она все еще играет в песочнице. — Apple применила несколько уровней безопасности в iOS. В iOS нет единой точки отказа, которая бы нарушала все остальные механизмы безопасности. Одной из мер безопасности, которую использует iOS, является песочница. «Песочница» ограничивает все приложения своей областью в системе. Даже беспризорное приложение очень ограничено в том, как оно может взаимодействовать с другими приложениями и их данными. Некоторые приложения позволяют другим приложениям взаимодействовать с ними посредством использования схем URL-адресов клиентов, но эта связь очень ограничена, и многие приложения не имеют их. Поскольку каждое приложение ограничено собственной песочницей, его способность выполнять вредоносные задачи весьма ограничена.

Это, конечно, не исчерпывающий список, но он показывает некоторые из причин того, что, хотя технически возможно распространять вредоносные приложения для iOS, мы не видим более распространенной проблемы с вредоносным ПО на iOS. Это не значит, что Apple должна пожать плечами и ничего не делать, конечно. Как упоминалось ранее, Apple осведомлена об исследованиях, которые были проведены здесь, и, вероятно, рассматривает их варианты для снижения угрозы. Тем временем пользователи должны стараться не слишком беспокоиться. Крайне маловероятно, что это исследование приведет к вспышке вредоносного ПО для iOS.

Jekyll на iOS: когда добрые приложения становятся злом (PDF)

Оцените статью!