- Ошибка «Запрещено администратором или политикой шифрования в Android»
- Описание
- Понятие политики администрирования и шифрования
- Почему появляется ошибка
- Сбой в программах Samsung Pay, Android Pay, Outlook
- Что делать при возникновении ошибки администрирования и шифрования
- Удаление учетных данных
- Удаление сертификатов в Андроид
- Отключение приложений, которые используют права администратора
- Безопасность Android — вот над чем стоит задуматься
- Разбираемся в системе обеспечения безопасности Android
- Содержание статьи
- Введение
- Хакер #166. DDoS
- Дыра в дыре?
- Приложения и права доступа
- Защита от срыва стека
- Репозиторий приложений
- Ревью кода и обновления
- Выводы
Ошибка «Запрещено администратором или политикой шифрования в Android»
Описание
В погоне за безопасностью пользователи Андроид-устройств устанавливают различный софт, а также используют системные утилиты для запароливания своих гаджетов. Казалось бы, безопасность лишней не бывает, но практика показывает, что подавляющее большинство впоследствии сталкиваются с такими ошибками, как «Запрещено администратором, политикой шифрования в Android». Фактически эти ошибки означают, что пользователь «что-то» из области безопасности включил, а выключить не может.
Понятие политики администрирования и шифрования
О безопасности личных данных на смартфоне или планшете сегодня не заботится, скорее всего, только тот человек, у которого попросту нет многофункционального устройства. Другими словами, практически у каждого юзера присутствуют на смартфоне данные, которые бы он хотел скрыть от общих глаз.
Политика шифрования Андроида отвечает именно за безопасность информации. Фактически при правильном оперировании инструментами шифрования и администрирования вы сможете наладить на своем девайсе достаточный уровень защиты, способный оградить конфиденциальную информацию от посягательств со стороны недоброжелателей.
Все настройки, которые относятся к понятию администрирования и шифрования, находятся на устройстве в разделе «Безопасность».
Именно там вы можете изменить протоколы защиты, а также обеспечить себя надлежащими условиями доступности к тем или иным возможностям устройства.
Почему появляется ошибка
Перед тем как изменить политику шифрования в Андроид, вы должны смириться с тем, что на вашем смартфоне или планшете могут возникнуть проблемы с работоспособностью. Процесс шифрования подразумевает обработку и кодирование данных, используемых на смартфоне. Все это влияет на рабочий ресурс девайса, делая его более медлительным.
То есть, когда вы включили шифрование и при этом решили использовать гаджет «по максимуму», может появиться вышеупомянутая ошибка. Зачастую такая ошибка появляется при желании сменить, например, графический ключ на цифровой пароль.
Запрет блокировки экрана
Когда «запрещена администратором блокировка экрана в Андроид», с такой ошибкой в работе можно смириться и пользоваться устройством дальше без каких-либо дискомфортных ощущений. Но отключение шифрования, которое привело к ошибке, способно повлиять на общий показатель безопасности.
Благодаря шифрованию все ваши данные на устройстве полностью защищены от несанкционированного доступа, а, следовательно, разработчики Андроид-устройств не рекомендуют выключать шифрование.
Сбой в программах Samsung Pay, Android Pay, Outlook
К появлению ошибки, связанной с администрированием и шифрованием данных, может привести сбой в любой из вышеупомянутых программ. Данный дополнительный софт, который вы можете установить через Play Market напрямую, использует сложные сертификаты безопасности.
Любое несоответствие вашего режима использования с политикой, которая была предусмотрена разработчиками Samsung Pay, Android Pay или Outlook, автоматически вызывает резонанс и появление ошибки. То есть после установки вы не сможете использовать полный потенциал софта, пока не проведете соответствующие манипуляции в настройках безопасности.
Что делать при возникновении ошибки администрирования и шифрования
Если на экране вашего смартфона появилось злосчастное сообщение «Запрещено администратором, политикой шифрования или хранилищем учетных данных», не стоит впадать в панику: с любой ошибкой можно справиться, достаточно обзавестись специфическими знаниями и навыками.
Первым делом вы, конечно же, можете очистить учетные данные. Это действие не привнесет в работу устройства особо глобальных изменений, но позволит избавиться от настроек, оставленных вами заранее.
Довольно часто пользователям, столкнувшимся с ошибкой администрирования и шифрования, достаточно сброса настроек, чтобы вернуть политику безопасности к стоковым показателям.
Если это действие не принесло желаемых результатов, попробуйте удалить все сертификаты в Андроид. Сделать это достаточно просто, поскольку они не защищены от удаления. При этом после удаления желательно перезагрузить устройство, чтобы оно могло заново залить сертификаты.
Удаление учетных данных
Столкнувшись с проблемой, когда запрещено администратором отключить графический ключ на Андроид 5, и решив почистить свои учетные записи, вы должны выполнить ряд определенных действий.
Процедура удаления не занимает много времени, если вы все делаете по инструкции. Итак:
- Перейдите в настройки смартфона.
- Найдите раздел «Безопасность» и зайдите в него.
- В представленном каталоге найдите «Хранилище учетных данных».
- Тапните один раз по разделу – перед вами выпадет меню с графой «Устранить учетные данные».
После этого действия все настройки администрирования должны будут сброситься, и вы сможете снова пользоваться своим устройством без ограничений.
Удаление сертификатов в Андроид
У вас не получается убрать пароль с Андроида и устройство пишет «Запрещено администратором» даже после удаления учетных данных? Попробуйте деинсталлировать сертификаты. Сделать это даже проще, чем удалить учетную запись.
Вы снова отправляетесь в раздел «Безопасность», находите пункт меню «Очистить учетные данные», тапаете по нему один раз и соглашаетесь с очисткой.
Данное действие удаляет все сертификаты, кроме системных. На общую работу смартфона или планшета удаление сторонних сертификатов особо не повлияет, так как необходимые данные снова подгрузятся с серверов разработчиков после перезагрузки системы, но уже без ошибок.
Отключение приложений, которые используют права администратора
Если для шифрования своего устройства вы использовали дополнительный софт, то он также может стать причиной возникновения ошибки. Лучшим вариантом возвращения нормальных условий эксплуатации гаджета будет деинсталляция данного приложения. Если это вам не подходит, попробуйте просто отключить программу на время и посмотреть на результат.
Сделать это можно с помощью стандартных инструментов системы Андроид:
- Перейдите в настройки девайса.
- Найдите в перечне каталог «Приложения» и тапните по нему.
- Перед вами откроется перечень установленного на устройство софта, в котором вы должны будете найти то самое стороннее приложение для обеспечения шифрования. Как только вы его найдете, тапните по нему и в открывшихся настройках выберете «Остановить».
- После перейдите в настройки безопасности и посмотрите, произошли ли какие-либо изменения и не выпадает ли снова ошибка, связанная с шифрованием и администрированием.
Следует отметить, что разработчики не рекомендуют использовать сторонние программы для блокирования и шифрования данных на устройствах Андроид. Все манипуляции, связанные с безопасностью гаджетов, можно выполнить с помощью стандартных встроенных утилит.
Сброс к заводским настройкам
Порой не один из перечисленных способов не помогает вернуть гаджет к привычным настройкам и тогда пользователю приходится осуществить сброс настроек девайса до заводских. Сделать это можно несколькими способами, но наиболее простым является сброс посредством предусмотренного операционной системой функционала.
Для так называемого обнуления гаджета вам понадобится перейти в настройки устройства, найти раздел меню «Восстановление и сброс» и выбрать в нем пункт «Сброс настроек». Эта процедура сотрет все пользовательские файлы и вернет ваш гаджет к первоначальному виду.
Перед обнулением скопируйте все важные файлы в отдельную папку на персональном компьютере или внешней карте памяти, чтобы уберечь их от удаления.
Источник
Безопасность Android — вот над чем стоит задуматься
Безопасность — крайне серьезная штука, которая важна, наверное, каждому пользователю. Кто хочет, чтобы за вами следили или могли украсть данные? Никто этого не хочет. Кто хочет, чтобы крупные компании знали, где вы находитесь? Кто хочет, чтобы приложения сторонних разработчиков имели доступ к личным данным? Никто этого не хочет. И именно поэтому мы предлагаем произвести ряд действий, чтобы уменьшить контроль над вашим устройством и сделать его использование более безопасным. Сделать всё, чтобы никто и никогда не смог следить за вами.
Как сделать Android безопасным?
Я бы разделил понятие безопасности на две части. Есть одна сторона, при которой мы защищаем наши данные от злоумышленников, которые распространяют вирусы и различный мошеннический софт, который, попадая на смартфон, может отправлять наши данные сторонним лицам. Также данными можно поделиться с другими, если потерять телефон с выключенной функцией поиска устройства. Именно поэтому мы не рекомендуем отключать её.
Есть и вторая сторона — это передача данных крупным компаниям, сервисами которых вы пользуетесь. Android — это открытая операционная система, которая не хранит данные пользователей на собственных серверах. Каждый желающий на базе Android может выпустить собственное устройство, и никто его не остановит. Однако всем известно, что, как правило, Android-телефоны распространяются с сервисами Google, как единственным источником правды. Это, безусловно, плохо, ведь отсутствие конкуренции и альтернатив ни к чему хорошему не приведет. Сегодня попросту нет достойной замены сервисам Google на Android-смартфонах. А без них телефон превращается в бесполезный гаджет: ни магазина приложений, ни картографических сервисов, ни чего-то еще. Одним словом — железка, от которой нет пользы.
Именно поэтому единственное, что нам остается, это смириться с тем, что мы имеем. А имеем мы дружбу с Google. И нам необходимо найти с ней общий язык. Компания предлагает ряд настроек, которые помогут сделать использование телефона менее отслеживаемым и более безопасным.
Давайте по порядку применим каждую функцию. В настройках телефона необходимо перейти в раздел Google. Далее нажимаем на “Управление аккаунтом Google”. Эта кнопка должна находиться под аватаром. В данном разделе мы увидим несколько подразделов, которые нам важны — это “Данные и персонализация”, а также “Безопасность”.
Начнём с последнего. Раздел “Безопасность” предлагает возможность активировать двухэтапную аутентификацию и вход в аккаунт с помощью телефона. 2FA позволит предотвратить вход в учетную запись даже при успешном подборе пароля. Кроме того, я не советую хранить пароли в аккаунте Google, так как даже 2FA не может на 100% защитить вас от взлома.
Теперь перейдем к самому главному — раздел “Данные и персонализация”. Здесь по умолчанию будут активированы функции отслеживания действий. Их нужно отключить. Речь идет об “Истории приложений и веб-поиска”, “Истории местоположений”, “Истории YouTube” и “Персонализации рекламы”. Все эти пункты являются частью раздела “Отслеживание действий”, перейти к которому можно, нажав на кнопку “Настройки отслеживания действий” в подразделе “Данные и персонализация”.
Единственная функция, которую я бы рекомендовал оставить включенной, это “История YouTube”. В этом случае Google будет лучше адаптировать рекомендации под ваши интересы. А так как YouTube мы используем часто, отключение данной функции негативно скажется на вашем опыте использования видеохостинга.
Остальное же можно смело отключать, некоторые из них, например, отвечают на персонализированную рекламу. Но зачем нам реклама, не так ли? Кроме того, Google позволяет вам скачать и удалить уже собранные о вас данные, что для многих будет полезно.
Также очень важно не использовать кастомные прошивки. Кто знает, какой код разработчик встроил в систему. Может, он будет воровать данные и следить за вами, и вы об этом никогда не узнаете. К тому же при использовании кастомных прошивок, как правило, перестает работать сканер отпечатков пальцев, а также различные банковские приложения, что сделает использование устройства не очень-то и полноценным. К тому же у многих при использовании кастомных прошивок может не работать Google Pay.
Еще одним способом обезопасить использование телефона станут специальные наклейки для гаджетов, которые с одной стороны прозрачны, а с другой полностью черные благодаря специальной поверхности с фильтром. Такую наклейку можно наклеить на основную и фронтальную камеры устройства. Внешне они не будут заметны, однако следить теперь никто не сможет.
Также я рекомендую в разделе разрешений приложений запретить доступ к разрешениям для тех приложений, которые вам кажутся сомнительными. Например, игра может требовать разрешение на совершение звонков или доступ к контактам, что не является нормальным.
Если вам не нравится браузер Chrome и вы считаете его не очень безопасным, можно присмотреться к Microsoft Edge. Не так давно мы сравнивали его с браузером Google. В данном сравнении решение Microsoft оказалось в роли победителя. Также присмотритесь к различным приватным браузерам, например, Firefox Focus или Aloha.
Ранее появилась информация о том, что Google сделает управление вкладками удобнее. Одновременно с безопасностью важно, чтобы возня с телефоном не становилась зависимостью. Чтобы контролировать использование аппарата, Google выпустила 3 приложения. Кроме того, компания не так давно пообещала меньше следить за пользователями Chrome.
А какие способы обезопасить использование смартфона знаете вы? Делитесь мнением в комментариях и не забывайте про наш чат Телеграм.
Источник
Разбираемся в системе обеспечения безопасности Android
Содержание статьи
Android — молодая операционная система, и ее, как любую другую новорожденную ОС, принято упрекать в отсутствии должного уровня безопасности. Антивирусные компании и профильные аналитики рапортуют о настоящем буме вредоносного ПО для Android и предрекают скорое наступление армии зомби-вирусов, которые опустошат кошельки пользователей. Но так ли уязвим зеленый робот на самом деле?
Введение
На заре своего развития Android стала настоящим магнитом для нападок со стороны антивирусных компаний и независимых исследователей: инженеров Google обвиняли в недальновидности, огромном количестве брешей и общей ненадежности архитектуры Android. Это касалось всех компонентов системы, но основной удар экспертов обрушился на реализацию механизма разграничения прав, который якобы ограничивал приложения друг от друга, но имел брешь в самой своей основе.
В пример обычно приводились приложения, использующие эксплойты ядра Linux, которые позволяли получить права root, а затем сделать с системой все, что захочет злоумышленник. Этих нескольких найденных уязвимостей хватило, чтобы создать в желтой прессе шумиху, которая не улеглась и по сей день.
Но как же обстоят дела на самом деле? Проблема существует или нет? Стоит ли бояться юзерам Android за сохранность своих данных, или перейти на iOS, и как, если это возможно, защитить свои данные от злоумышленников? Обо всем этом повествует наш сегодняшний обзор.
Архитектура Android
Хакер #166. DDoS
Дыра в дыре?
В своей основе Android полагается на ядро Linux, которое выполняет большую часть грязной работы за него. На Linux ложатся такие заботы, как соблюдение прав доступа, слежение за процессами и их корректным выполнением. На деле это значит, что ни одно приложение Android не может получить доступ к данным другого приложения, пока последнее этого не захочет.
Реализуется это простым и превосходным методом: через соблюдение прав доступа. В Android каждое приложение — это отдельный пользователь со своими правами доступа и полномочиями. Каждое приложение в такой системе получает свой собственный идентификатор пользователя (UID) и собственный каталог внутри каталога /data, так что все его данные защищаются с помощью простых прав доступа, которые разрешают самому приложению читать собственные файлы, но запрещают делать это любому другому процессу.
Увидеть, какому UID принадлежит приложение, можно с помощью любого менеджера задач
В Android это называется песочницей (sandboxing), которая позволяет сберечь данные соседних приложений друг от друга, не позволив зловреду утащить частную информацию, сохраненную любым приложением системы. В песочницу попадают абсолютно все приложения, включая заранее предустановленные на аппарат. Фактически лишь небольшая часть Android работает с правами root, а именно начальный процесс zygote, выполняющий функции контроля за исполнением приложений, и небольшая часть системных сервисов. Все остальные приложения всегда работают в песочницах, поэтому зловред, даже прошедший процедуру «впаривания» пользователю, не может утащить ничего ценного, кроме содержимого SD-карты, доступ к которой по умолчанию открыт всем (позже мы еще вернемся к этому).
Кроме данных отдельно взятых приложений, для доступа закрыта также базовая инсталляция Android, размещаемая на отдельном разделе внутренней NAND-памяти и подключенная к каталогу /system. По умолчанию она смонтирована в режиме только для чтения и, в принципе, не хранит в себе никакой конфиденциальной информации (для ее размещения также используются песочницы в /data), поэтому каким-то хитрым образом прописаться в автозагрузку или модифицировать системные компоненты не получится (если, конечно, не использовать эксплойты для получения прав root, о чем я подробнее расскажу ниже).
Для общения приложениям доступно несколько вариантов IPC, причем родные для Linux средства коммуникации, такие как разделяемая память и сокеты, доступны только процессам, принадлежащим одному приложению, да и то лишь в том случае, если хотя бы часть приложения написана на компилируемом в машинный код языке, то есть с использованием Android NDK. Во всех остальных случаях приложения смогут использовать Binder для безопасного обмена сообщениями и интенты для вызова сторонних приложений (о них мы также поговорим ниже).
Ознакомиться со списком полномочий приложения можно и после его установки
Интересно, что в Android, начиная с версии 2.2, есть понятие администратора устройства, но значит оно совсем не то, что под ним понимают пользователи UNIX и Windows. Это просто API, с помощью которого приложение может изменять политику безопасности паролей, а также запрашивать необходимость в шифровании хранилища данных и производить удаленный вайп смартфона. Это своего рода костыль, который был придуман в ответ на запросы корпоративных пользователей Android, которые хотели получить больший контроль над безопасностью данных на смартфонах сотрудников. Фактически этим API может воспользоваться любое приложение, но для этого пользователь должен явно подтвердить свое намерение предоставить приложению такие полномочия. Также в последних версиях Android появилась возможность загрузки устройства в безопасном режиме, когда пользователь получает доступ только к предустановленным приложениям. Она может понадобиться в случае компрометации устройства сторонним приложением.
Начиная с версии 3.0, Android имеет встроенную поддержку шифрования всех пользовательских данных с помощью стандартной подсистемы dmcrypt ядра Linux. Шифрование производится в отношении того самого каталога /data алгоритмом AES128 в режиме CBC и ESSIV:SHA256 с помощью ключа, генерируемого на основе пароля, который необходимо ввести во время загрузки ОС. При этом стоит учитывать, что карта памяти не шифруется, поэтому сохраненные на ней данные остаются полностью открытыми.
Приложения и права доступа
Наряду с песочницей, одним из основных механизмов системы безопасности Android являются права доступа приложений к функциям системы Android (привилегии), которые позволяют контролировать, какие именно возможности ОС будут доступны приложению. Это могут быть как функции работы с камерой или доступ к файлам на карте памяти, так и возможность использования функциональности, которая может привести к утечке информации со смартфона (доступ в Сеть) либо к трате средств пользователя со счета мобильного оператора (отправка SMS и совершение звонков).
У Android есть замечательная особенность: абсолютно любое приложение обязано содержать в себе информацию о том, какие именно из функций Android оно может использовать. Эта информация заключена в файле AndroidManifest.xml внутри APK-файла и извлекается инсталлятором перед установкой приложения для того, чтобы пользователь смог ознакомиться с тем, к какой функциональности смартфона приложение сможет получить доступ. При этом пользователь должен в обязательном порядке согласиться с этим списком перед установкой приложения.
На заре становления Android такой подход был раскритикован как слишком наивный, однако, как показало время, его эффективность получилась чрезвычайно высокой. Несмотря на то что большинство пользователей игнорирует список привилегий перед установкой приложения, многие ознакомляются с ним и, если обнаруживают какие-то несоответствия (например, когда игра запрашивает возможность отправки SMS или доступ к адресной книге), рассказывают об этом в отзывах и ставят одну звезду. В результате приложение очень быстро получает низкий суммарный рейтинг и большое количество негативных комментариев.
Также хочется заметить, что все возможные привилегии достаточно четко и логично разделены, благодаря чему злоупотребления привилегиями практически не бывает. Например, приложение может потребовать возможность читать SMS, но не отправлять их или получать уведомления о пришедшем сообщении. Фактически единственный серьезный недостаток системы привилегий был найден только в том, что инженеры Google вообще не предусмотрели никаких ограничений на чтение карты памяти (запись тем не менее ограничена), посчитав это бессмысленным для съемных накопителей. В свое время эта «брешь» привела к возможности получения координат смартфона, выуженных из кеша стандартного приложения «Галерея», который хранился на карте памяти. Что, в свою очередь, вынудило Google добавить в настройки последних версий Android опцию, после активации которой система будет явно спрашивать пользователя о возможности доступа какого-либо приложения к SD-карте.
Еще одна важная особенность такой системы заключается в том, что пользовательские настройки всегда будут приоритетнее запросов приложений, а это значит, что, если пользователь отключит GPS, приложение никак не сможет включить его самостоятельно даже при наличии всех прав на использование GPS. При этом некоторые функции ОС недоступны для приложений вовсе. Например, манипулировать SIM-картой имеет право только операционная система, и никто, кроме нее.
Проверка привилегий идет на самом низком уровне ОС, в том числе на уровне ядра Linux, так что для обхода этой системы безопасности зловреду придется не только получить права root на устройстве, но и каким-то образом скомпрометировать ядро, что гораздо более сложная задача.
Как уже было сказано выше, приложения могут обмениваться информацией, используя стандартные для Android средства коммуникации Binder, интенты (Intents) и провайдеры данных (Content Provider). Первый представляет собой механизм удаленного вызова процедур (RPC), реализованный на уровне ядра Linux, но контролируемый системным сервисом Service Manager. С точки зрения программного интерфейса Binder является всего лишь средством импорта объектов из другого приложения, но с точки зрения безопасности полностью контролируется обсуждаемым выше механизмом разграничения прав доступа. Это значит, что приложения смогут получить доступ друг к другу только в том случае, если оба этого захотят. Это особенно важно в свете того, что в Android Binder является основным средством коммуникации, на основе которого построен графический интерфейс, а также другие компоненты ОС, доступные программисту. Доступ к ним ограничивается с помощью обсуждаемого выше механизма привилегий. Как системные компоненты, так и сторонние приложения могут ограничивать доступ к своей функциональности с помощью декларации прав на доступ к своим функциям. В случае системных компонентов все они описаны в документации для программистов Android-приложений. Независимые разработчики, которые хотят открыть API к своим приложениям, должны описать требуемые для этого привилегии в AndroidManifest.xml и опубликовать соответствующую документацию. Все это относится также к провайдерам данных (Content Provider), специальному интерфейсу (также реализованному поверх Binder), с помощью которого приложения могут открывать доступ к своим данным другим приложениям. В Android провайдеры данных везде, это и адресная книга, и плей-листы, и хранилище настроек. Доступ к ним опять же ограничивается с помощью механизма привилегий и прав доступа.
Поверх Binder также реализована так называемая технология интентов, простых широковещательных сообщений. Приложения могут посылать их «в систему» с целью вызова внешних приложений для совершения какого-либо действия. Например, приложение может использовать интенты для вызова почтового клиента с указанием адреса, открытия веб-страницы, каталога в файловой системе и всего, что может быть записано в виде URI. Система автоматически находит все приложения, способные принимать данный тип интентов (а точнее URI-адресов), и передает URI им (а точнее, одному из них, выбранному пользователем). То, какие типы интентов может принимать и обрабатывать приложение, определяет программист во время сборки приложения. Кроме того, он может использовать фильтрацию по содержимому URI, чтобы избежать «спама».
Принцип работы Binder
Сами по себе перечисленные механизмы обмена данными и вызова функций приложений, контролируемые с помощью системы привилегий, в Android реализованы достаточно четко и ясно, однако они могут привести к проблемам в том случае, если программист недостаточно серьезно относится к декларации привилегий, необходимых для доступа к своему приложению. Это может привести к утечкам информации или возможности задействования функциональности приложения кем угодно. Например, в первых версиях Dropbox для Android имелась проблема с правильным определением привилегий, которая приводила к тому, что любое установленное приложение могло использовать Dropbox-клиент для заливки какой угодно информации на «облачный диск» www.securelist.com.
Защита от срыва стека
Для защиты приложений, созданных с использованием Android NDK, а также системных компонентов, написанных на языке Си, Android включает в себя обширный набор механизмов защиты от срыва стека, в свое время реализованных самыми разными разработчиками для различных проектов. В Android 1.5 системные компоненты были переведены на использование библиотеки safe-iop, реализующей функции безопасного выполнения арифметических операций над целыми числами (защита от integer overflow). Из OpenBSD была позаимствована реализация функции dmalloc, позволяющая предотвратить атаки с использованием двойного освобождения памяти и атаки согласованности чанков, а также функция calloc с проверкой на возможность целочисленного переполнения во время операции выделения памяти. Весь низкоуровневый код Android, начиная с версии 1.5, собирается с задействованием механизма компилятора GCC ProPolice для защиты от срыва стека на этапе компиляции.
В версии 2.3 в коде были устранены все возможные уязвимости манипуляции со строками, выявленные с помощью сборки исходных текстов с флагами ‘-Wformat-security’, ‘-Werror=format-security’, а также применены «железные» механизмы защиты от срыва стека (бит No eXecute (NX), доступный начиная с ARMv6). Также Android 2.3 задействует метод защиты от уязвимости, найденной в ноябре 2009 года во всех ядрах Linux 2.6 (возможность разыменования NULL-указателя), с помощью записи отличного от нуля значения в файл /proc/sys/vm/mmap_min_addr. Такой метод защиты позволил устранить уязвимость без необходимости в обновлении самого ядра Linux, что невозможно на многих устройствах.
Начиная с версии 4.0, Google внедрила в Android технологию Address space layout randomization (ASLR), которая позволяет расположить в адресном пространстве процесса образ исполняемого файла, подгружаемых библиотек, кучи и стека случайным образом. Благодаря этому эксплуатация многих типов атак существенно усложняется, поскольку атакующему приходится угадывать адреса перехода для успешного выполнения атаки. В дополнение, начиная с версии 4.1, Android собирается с использованием механизма RELRO (Read-only relocations), который позволяет защитить системные компоненты от атак, основанных на перезаписи секций загруженного в память ELF-файла. В той же версии 4.1 была впервые активирована функция ядра dmesg_restrict (/proc/sys/kernel/dmesg_restrict), появившаяся в ядре 2.6.37 и позволяющая отключить возможность чтения системного журнала ядра (dmesg) непривилегированными пользователями.
-В альтернативной Android-прошивке MIUI ни одно стороннее приложение не сможет отправить SMS без явного подтверждения со стороны пользователя.
-CyanogenMod расширяет стандартный механизм полномочий Android возможностью отмены любого полномочия уже после установки приложения.
- В рамках экспериментального проекта SE Android идет работа над форком Android с активированной системой безопасности SELinux.
Репозиторий приложений
Репозиторий приложений Google Play (в девичестве Android Market) всегда был самым слабым местом Android. Несмотря на то что механизм, требующий от приложений обязательного указания списка своих привилегий перед установкой, изначально работал правильно и позволял создать экосистему, в которой пользователи сами бы могли предупреждать друг друга о возможном зловредном поведении программы, опубликованной в репозитории, пользователи то и дело заражали свои смартфоны вирусами.
Основная проблема здесь заключалась в том, что приложение и его автор не подвергались каким-либо серьезным проверкам перед публикацией пакета в репозиторий. Фактически все, что нужно было сделать, — это написать программу, создать аккаунт в Google Play, внести членский взнос и опубликовать приложение. Все это мог сделать абсолютно любой человек, выложив в Маркет любой код, что и было многократно продемонстрировано в различных исследованиях безопасности Android.
Чтобы хотя бы частично решить эту проблему, не прибегая к ручной проверке приложений на безопасность, как сделано в Apple App Store, Google в начале этого года ввела в строй сервис Bouncer, представляющий собой виртуальную машину, в которой автоматически запускается любое публикуемое в репозитории приложение. Bouncer выполняет многократный запуск софтины, производит множество действий, симулирующих работу пользователя с приложением, и анализирует состояние системы до и после запуска с целью выяснить, не было ли попыток доступа к конфиденциальной информации, отправки SMS на короткие платные номера и так далее.
По словам Google, Bouncer позволил сократить количество вредоносов сразу после запуска сервиса на 40%. Однако, как показали дальнейшие исследования, его можно было легко обойти: проанализировать некоторые характеристики системы (e-mail-адрес владельца «смартфона», версию ОС и так далее) и затем создать приложение, которое при их обнаружении не будет вызывать подозрений, а после попадания на настоящий смартфон делать всю грязную работу.
Скорее всего, Google уже разработала схему противодействия обнаружению Bouncer с помощью генерации уникальных виртуальных окружений для каждого нового приложения, но так или иначе вирусы будут продолжать проникать в Google Play, и стоит быть внимательным при установке приложений, обязательно читая отзывы пользователей и анализируя список полномочий приложения перед его установкой.
Ревью кода и обновления
Последнее, но не менее важное, о чем хотелось бы сказать, говоря о системе безопасности Android, — это ревью кода и процесс реагирования команды разработчиков на появление новых уязвимостей. Когда-то программисты OpenBSD показали, что это один из наиболее важных аспектов разработки безопасной ОС, и Google следует их примеру достаточно четко.
В Google на постоянной основе работает команда безопасности Android (Android Security Team), задача которой заключается в том, чтобы следить за качеством кода операционной системы, выявлять и исправлять найденные в ходе разработки новой версии ОС ошибки, реагировать на отчеты об ошибках, присланные пользователями и секьюрити-компаниями. В целом эта команда работает в трех направлениях:
- Анализ новых серьезных нововведений ОС на безопасность. Любое архитектурное изменение Android должно быть в обязательном порядке одобрено этими ребятами.
- Тестирование разрабатываемого кода, в котором принимают участие также Google Information Security Engineering team и независимые консультанты. Идет постоянно на протяжении всего цикла подготовки нового релиза ОС.
- Реагирование на обнаружение уязвимости в уже выпущенной ОС. Включает в себя постоянный мониторинг возможных источников информации о найденной уязвимости, а также поддержку стандартного баг-трекера.
Если уязвимость будет обнаружена, команда безопасности начинает следующий процесс:
- Уведомляет компании, входящие в альянс OHA (Open Handset Alliance), и начинает обсуждение возможных вариантов решения проблемы.
- Как только решение будет найдено, в код вносятся исправления.
- Патч, содержащий решение проблемы, направляется членам OHA.
- Патч вносится в репозиторий Android Open Source Project.
- Производители/операторы начинают обновление своих устройств в режиме OTA или публикуют исправленную версию прошивки на своих сайтах.
Особенно важным в этой цепочке является тот факт, что обсуждение проблемы будет происходить только с теми членами OHA, которые подписали соглашение о неразглашении. Это дает гарантию, что общественность узнает о найденной проблеме только после того, как она уже будет решена компаниями, и фикс появится в репозитории AOSP. Если же об уязвимости станет известно из общедоступных источников (форума, например), команда безопасности сразу приступит к решению проблемы в репозитории AOSP, так чтобы доступ к исправлению получили сразу все и как можно скорее.
Приложениям вход в каталог с частной информацией других приложений закрыт
Опять же слабым местом здесь остаются производители устройств и операторы связи, которые могут затянуть с публикацией исправленной версии, несмотря на ранний доступ к исправлению.
В выводе ps хорошо видно, что все приложения с правами разных пользователей
- Подробное разъяснение реализации системы шифрования Android;
- описание системы полномочий для разработчиков приложений;
- руководство по созданию безопасных Android-приложений.
Выводы
Как и любая другая операционная система, Android не лишена уязвимостей и различных архитектурных допущений, упрощающих жизнь вирусописателей. Но говорить о том, что Android уязвима по определению, также не стоит. В ней явно прослеживается влияние последних тенденций в разработке безопасных операционных систем. Это и песочницы для приложений, и четко контролируемый системой механизм обмена данными между приложениями, и наработки проекта OpenBSD — единственной ОС общего назначения, разработка которой всегда велась с упором на безопасность.
Источник