Содержание статьи
Свойственные платформе Android гибкость и открытость вместе с пришедшими позже популярностью и фрагментацией привели к тому, что в головах простых пользователей прочно закрепилась идея об общей небезопасности системы. И конечно же, быстро нашлись люди, которые начали на этом спекулировать. Сначала подключились разработчики антивирусов, а затем и производители смартфонов. Но так ли на самом деле безопасны эти самые смартфоны по сравнению с обычными? Попробуем разобраться.
Существует несколько проектов смартфонов, работающих под управлением Android с якобы усиленной безопасностью. Есть среди них как совсем смешные разработки типа GATCA: Elite, так и на первый взгляд довольно серьезные устройства от именитых компаний. Наиболее известный представитель вторых — это BlackBerry Priv, о котором компания написала множество статей и блог-постов. Один из них носит очень претенциозное название «Почему Android от BlackBerry — лучший выбор в плане безопасности и приватности».
Сам пост довольно короткий и, кроме нескольких абзацев маркетингового булшита, содержит список функций, которые делают их Android таким крутым. Я приведу этот список целиком, стараясь не слишком искажать смысл сказанного (хотя в некоторых местах это сделать довольно сложно из-за изначально неверного смысла):
- реализация доверенной загрузки всех компонентов ОС (маркетинговое имя Root of Trust, аналог UEFI Secure boot);
- улучшения в поддержке технологии ASLR, что делает эксплуатацию уязвимостей намного более трудной задачей;
- улучшения в системе мандатного контроля доступа SELinux;
- утилита Pathtrust, гарантирующая, что непроверенный код не будет внедрен в систему через вредоносное ПО;
- множество модификаций в ядре Linux и Android в целом, введенных для поддержки DTEK, фирменного приложения для обеспечения безопасности и приватности;
- сертифицированная по стандарту FIPS 140-2 криптобиблиотека и другие улучшения, направленные на защиту паролей от brute-force-атак;
- поддержка смарт-карт и другие Enterprise-функции, необходимые бизнес-пользователям.
Звучит неплохо, не правда ли? Особенно если ты человек, плохо понимающий Android и описанные технологии. Однако давай пройдемся по каждому из этих пунктов и разберемся, о чем конкретно говорит BlackBerry и так ли все хорошо на самом деле.
Доверенная загрузка
BlackBerry не зря поставила эту технологию на первое место. Root of Trust — это действительно хорошая идея, позволяющая подтвердить целостность системы на всех уровнях, начиная с загрузчика. Реализована она с помощью сверки контрольной суммы загрузчика, с последующей сверкой контрольной суммы ядра ОС, проверкой SHA-хеша раздела /system и сверкой контрольных сумм установленных приложений. Все это в несколько искаженном виде показано на рисунке ниже.
Xakep #205. Взлом Single Sign-On
Говоря простым языком, Root of Trust гарантирует, что ни загрузчик, ни ядро, ни сама система, ни даже установленные приложения не были изменены с момента прошлой загрузки. Например, если ты случайно подхватил особо хитрый зловред, который сумел получить root и внедриться в одно из установленных легитимных приложений или даже ядро ОС, то во время следующей загрузки система это определит и откатится к предыдущему состоянию.
Все это замечательно, но есть как минимум две проблемы. Первая: система защищает именно от зловредов, способных получить доступ к компонентам системы или другим приложениям, а это возможно только при наличии прав root. Большинство зловредов не такие, обычно они используют вполне легитимные функции системы, а если и получают root, то никуда не внедряются, а спокойно живут себе в своей песочнице, по-тихому похищая данные или следя за пользователем.
Вторая: BlackBerry не дает никаких пояснений по поводу реализации данной функции. Как и где хранятся ключи и хеши? Как они защищены? Как система хранит хеши установленных приложений и можно ли получить к ним доступ, имея права root? Другими словами, насколько бОльшую безопасность предоставляет Root of Trust по сравнению с обычным залоченным загрузчиком, который точно так же откажется загружать систему при изменении ядра? Пока на эти вопросы не будет дан ответ, система ничем не лучше идеи залоченных загрузчиков.
Ну и как мы все знаем, все подобные системы убивают любые возможности модификации прошивок, рутинга, установки Xposed или смены прошивки. Через годик-другой BlackBerry выпустит Priv 2 и забьет на текущий смартфон. А еще через годик в нем найдут дыру и пользователи окажутся не защищены. Да, через три года смартфон уже пора и выкинуть, но это вовсе не аргумент (та же Apple до сих пор обновляет iPhone 4S, например). Но я могу быть и не прав, и BlackBerry будет поддерживать смартфон лет пять.
Улучшения в поддержке ASLR
Технология ASLR (Address space layout randomization) появилась как ответ на разные виды атак, направленных на переполнение буфера, и впервые была реализована в рамках проекта PaX (патч для ядра Linux) в 2001 году. Суть технологии проста и сводится к тому, чтобы вместо размещения кода приложения, его стека, хипа и библиотек-зависимостей последовательно в оперативной памяти (при загрузке приложения) рандомно раскидать их по разным участкам. ASLR сильно затрудняет работу взломщика (а точнее, написание эксплоитов), так как, вызвав переполнение, он не будет точно знать, на какой адрес «прыгнуть», чтобы выполнить шелл-код или, например, вызвать нужную функцию libc (ее адрес в памяти может быть буквально любым).
Сегодня ASLR в том или ином виде поддерживается практически всеми популярными ОС, и Android вовсе не исключение: полная поддержка этой технологии появилась в версии 4.1, а в урезанном виде (только для стека) была доступна аж с первых версий системы. Проблема только в том, что из-за самого принципа работы Android, который предполагает использовать одну и ту же загруженную в память среду исполнения для запуска всех приложений (форк процесса zygote в режиме copy-on-write), ASLR здесь не так эффективна, как в других системах (адреса всех библиотек и классов среды исполнения остаются одинаковыми для всех приложений).
Практически единственный способ решить эту проблему — повторно загружать среду исполнения для каждого приложения отдельно. Именно так, кстати говоря, поступили создатели прошивки CopperheadOS, что привело к дополнительному расходу памяти (от 3 до 15 Мбайт на каждое приложение). Сделали ли так же создатели BlackBerry Priv? Конечно, нет, поэтому говорить о каких-либо улучшениях они просто не имеют права.
Улучшение политик SELinux
SELinux (Security Enhanched Linux) — это один из так называемых security-модулей ядра, добавляющий в него реализацию модели мандатного контроля доступа. Две его основные функции — это тонкая настройка прав доступа к файлам и ограничение приложений в полномочиях (а точнее, в возможности выполнять системные вызовы ядра). Проще говоря, SELinux позволяет точно указать, что может делать приложение (например, создавать сетевые подключения) и к каким файлам оно может получить доступ.
В Android SELinux появился в версии 4.2 и в первую очередь используется для урезания прав низкоуровневых сервисов, написанных на языке C или C++ (если в одном из них будет найден баг, взломщику будет гораздо труднее использовать его для получения доступа к системе). На более высоком уровне (там, где работают простые приложения и большая часть системы) в Android и раньше существовали свои довольно надежные механизмы защиты: песочницы для приложений, права доступа (своя отдельная реализация) и контролируемая ядром система обмена сообщениями. С помощью SELinux к ней лишь добавили дополнительный слой защиты.
Однако важно не это, а то, что модификацию политик SELinux выполняют и многие другие вендоры и разработчики прошивок. Вопрос только в том, что именно они модифицируют и что конкретно там нужно улучшать. В основном они занимаются созданием политик для своих собственных сервисов и приложений, что имеет мало общего с укреплением общей безопасности системы (по факту она была бы безопаснее, если бы этих сервисов и приложений не было вообще). Что улучшила BlackBerry? Опять же непонятно.
Утилита Pathtrust
Pathtrust — это утилита из операционной системы QNX 6.6, на которой ранее базировались все смартфоны BlackBerry. Сама по себе она не очень интересна, но является частью технологии так называемых доверенных файловых систем. Последняя представляет собой просто защиту от запуска приложений с определенных разделов диска или каталогов. В общем-то, штука довольно полезная, но есть одно но — в Android все это уже есть из коробки.
Например, обычное приложение имеет право запускать какие бы то ни было файлы только из своей песочницы или одного из каталогов, содержащих стандартный набор UNIX-команд (/system/bin и другие), а запуск файлов с карты памяти запрещен в принципе (все это контролируется с помощью не только обычных прав доступа, но и политик SELinux). Более того, в данном случае, говоря о запуске, я имею в виду именно нативные приложения, работающие поверх ядра Linux, запуск Android-приложений полностью контролируется системой, и можно запустить только те, что явно установлены. То есть нельзя просто куда-то кинуть пакет APK с вирусом и запустить его из другого приложения (по крайней мере до тех пор, пока смартфон не рутован).
Приложение DTEK
DTEK — фирменное приложение от BlackBerry, представляющее собой нечто вроде центра безопасности. По сути, это симбиоз двух инструментов: анализатора текущего состояния смартфона, подсказывающего пути повышения его безопасности, и менеджера полномочий приложений, который позволяет узнать, какие приложения используют определенные функции ОС, и уведомляет об этом юзера.
Работу обеих функций в деле можно оценить по скриншотам ниже. Нетрудно заметить, что тот самый «анализатор безопасности» — это не что иное, как просто система для проверки тех или иных настроек: включена отладка по USB — плохо, включена установка приложений из сторонних источников — плохо, нет ПИН-кода — плохо и так далее. Обрати особое внимание, что отсутствие логина в аккаунт Google — это тоже плохо: BlackBerry Priv полностью полагается на гугловские функции сброса до заводских настроек и поиска смартфона, но на то, что данные будут утекать в Google, можно, по их мнению, и забить. В целом довольно бесполезная штуковина, не учитывающая реальные потребности юзера и рассчитанная на неискушенного пользователя.
«Менеджер полномочий» (это я его так называю) — гораздо более интересная штука. Он позволяет точно определить, какие функции ОС (камера, местоположение и прочее) и когда использовали установленные приложения, а самое главное — уведомляет юзера об этом в режиме реального времени. Удобно? Безусловно. Если не брать в расчет тот факт, что эта функция временно появилась в Android 4.3 и является стандартной начиная с CyanogenMod 10.1 (откуда, я уверен, ее сперла BlackBerry). Причем реализация данной функции в CyanogenMod позволяет также и отзывать полномочия, что в BlackBerry сделать нельзя по простой причине: приложение может работать некорректно или падать.
Кстати, штатная функция корректного отзыва полномочий и их запроса прямо во время работы приложений появилась в Android 6.0, однако работает она только в отношении новых приложений, собранных специально для нее (Target SDK: 23).
 |
 |
Криптобиблиотека, сертифицированная по стандарту FIPS 140-2
FIPS 140-2 — это стандарт США, используемый для сертификации криптографических модулей (как железных, так и программных). Его назначение в том, чтобы не пропустить в госучреждения и компании, работающие с важной информацией (финансовый и медицинский сектор), потенциально небезопасный софт, реализующий уязвимые методы защиты данных (или не реализующий их вовсе). В рамках программы CMVP (Cryptographic Module Validation Program) любая компания может получить сертификат соответствия FIPS 140-2, отдав свой софт на экспертизу.
С одной стороны, все отлично, серьезная организация дала свое добро на использование криптоалгоритмов BlackBerry Priv для хранения и обработки критически важных данных. С другой стороны, пройти проверку на соответствие 140-2 может практически любая испытанная временем реализация считающегося надежным криптоалгоритма. То есть в буквальном смысле ее пройдет и реализация алгоритмов шифрования ядра Linux, и OpenSSH, и OpenSSL. Поэтому в случае с BlackBerry Priv соответствие FIPS 140-2 не значит ровным счетом ничего и используется просто как маркетинг, а на деле это, скорее всего, все тот же алгоритм шифрования AES, используемый в Android.
И да, не стоит забывать, что в последний раз стандарт FIPS 140-2 обновлялся в 2002 году.
Выводы
Как видишь, если даже BlackBerry, компания, дорожащая своим имиджем среди Enterprise-клиентов, сильно преувеличивает значимость своей ОС и своих технологий, то что говорить обо всех остальных?
Так, создатели GATCA: Elite, смартфона, приведенного как пример в начале статьи, вообще нарушают все границы наглости в своем вранье и заявляют о технологиях, которые есть даже в голом Android (256-битный ключ шифрования, необходимость мигнуть при снимке лица, блокировка при выходе из географической зоны) или легко реализуются с помощью одного из десятков антиворов (блокировка в случае смены SIM-карты). Так что будь внимателен и не ведись на маркетинговые разводки.
