Доля пользователей, которые применяют в ежедневной жизни мобильные устройства, неуклонно возрастает. Большая часть этих устройств – смартфоны и планшеты на базе iOS, Android и Windows. Мобильность, специфические особенности взаимодействия пользователя с устройством и новые операционные системы – факторы, приводящие к появлению необычных проблем, связанных с информационной безопасностью. Мы рассмотрим часть из этих проблем, их решения, и на практике убедимся, что разработка инструментов для анализа мобильных приложений не так уж сложна.
Начнем с того, что перечислим несколько характерных для большинства мобильных устройств черт, которые могут влиять в том числе и на безопасность:
- миниатюрность;
- массовость;
- универсальность;
- хранение важных для пользователя данных;
- постоянное подключение к сети (GPRS/3G/EDGE/WiFi).
Так какие же риски порождают эти особенности. Миниатюрность приводит к тому, что устройство нетрудно потерять, после чего оно потенциально может оказаться в руках злоумышленника. Массовость и простота монетизации делает устройства привлекательными для злоумышленников. Просто заставив телефон послать SMS на платный номер, можно получить неплохую выгоду. Большое количество пользователей также означает, что и процент не очень технически грамотных пользователей достаточно велик. Универсальность мобильных устройств подразумевает, что в них может храниться практически весь спектр персональной информации, которую можно использовать: контакты, переписка, фотографии, видео, пароли и токены от различных важных сервисов вплоть до банковских клиентов. Постоянное подключение к сети – это дополнительный риск, так как злоумышленникам не нужно выгадывать моменты для атаки.
К сожалению, из-за того, что рынок мобильных устройств пережил такой взрывной рост, безопасники немного поотстали от противостоящей стороны, поэтому сейчас между ними и злоумышленниками идут практически гонки на выживание. Это непросто. Устройства производят десятки различных вендоров, они работают под управлением разных платформ, на них устанавливаются огромное количество приложений, во многих из которых есть уязвимости. Все это порождает огромное количество проблем.
Безопасность в Android
Конечно, разработчики мобильных платформ знают обо всех этих рисках и стараются предусмотреть защиту от них. Рассмотрим, какие уровни защиты есть в Android. Во-первых, там есть защита от физического доступа: PIN, пароли, биометрия, росчерки. Однако биометрия там весьма специфическая, а с паролями и росчерками есть определенные проблемы: при вводе на экране могут оставаться заметные следы, по которым можно восстановить, что именно было набрано.
Тем не менее, защита есть, и часто срабатывает. Для приложений также есть несколько уровней защиты. Во-первых, у почти всегда у приложений есть уникальные UID и запускаются они отдельными процессами и в изолированной виртуальной машине. Интересная особенность Android – нединамические привилегии приложений: все доступы запрашиваются при установке. Т.е. пользователь сразу ознакомлен с тем, к чему могут обращаться приложения. К вопросу безопасности файловой системы разработчики Android подошли достаточно строго. Системный раздел примонтирован в режиме read-only, расстановка привилегий и прав в файловых системах сделана практически вручную, начиная с версии 3.0 появилось шифрование файловой системы. Приведу пример скрипта init.rc для андроидов версий 4.x:
...
# create data/gps for GPS demon
mkdir /data/gps 771 gps system
chown gps system /data/gps
chown gps root /sys/class/sec/gps/GPS_PWR_EN/value
chmod 660 /sys/class/sec/gps/GPS_PWR_EN/value
# for sensor control
chown system input /sys/class/input/input0/enable
chown system input /sys/class/input/input0/delay
chown system input /sys/class/input/input0/wake
chown system input /sys/class/input/input0/data
...
Это лишь небольшая часть скрипта, но видно, что права на файлы и папки для критически важных участков системы расставляются очень тщательно. Доступа к ним у злоумышленника быть не должно.
Разработчики также позаботились о возможности шифрования трафика, внедрив SSL. Однако тут есть одна специфическая особенность. В Android есть хранилище корневых сертификатов, и если заглянуть в дамп этого хранилища, то можно обнаружить, интересную штуку: кроме корневых сертификатов известных удостоверяющих центров, там есть и довольно странные сертификаты. Например, сертификат японского правительства:
...
Alias name: 123
Creation date: 30.08.2011
Entry type: trustedCertEntry
Owner: C=JP,O=Japanese Government,OU=ApplicationCA
Issuer: C=JP,O=Japanese Government,OU=ApplicationCA
Serial number: 31
Valid from: Wed Dec 12 18:00:00 MSK 2007 until: Tue Dec
12 19:00:00 MSK 2017
...
Такой же сертификат есть и от правительства Китая. Так что, находясь в Японии или Китае, вы можете стать жертвой атаки типа man in the middle. По счастью, в четвертых андроидах встроенное хранилище можно отключить.
Как я уже говорил выше, механизм привилегий в Android достаточно хитроумный. Разработчики изначально выделили API-вызовы, которые могут предоставлять определенные риски и разделили на группы: доступ к камере, bluetooth, геолокации, сообщениям, звонкам, сети. Чтобы воспользоваться этими API приложение должно при установке в явном виде запросить к ним доступ. Механизм гибкий и удобный, но не лишенный некоторых проблем, с которыми иногда сталкиваются разработчики. Дело в том, что механизм этот не очень хорошо документирован, буквально несколько строчек описывают каждое разрешение. И разработчики очень часто сталкиваются с тем, что создаваемое приложение не работает из-за недостатка разрешений. Многие не разбираются, а просто запрашивают как можно больше разрешений. Все начинает работать, но при этом приложение имеет доступ к совершенно ненужным вещам, что крайне отрицательно влияет на безопасность. Компания Google, понимая эту проблему, выделила грант сторонним исследователям на более подробное описание API.
Пользователи и Android
Итак, мы пришли к выводу, что операционная система все-таки относительно защищена. В чем же может быть проблема? Часто проблемы возникают по вине самих пользователей. Есть множество способов сломать защиту системы самостоятельно, без вмешательства злоумышленников. Первый способ – jailbreaking. На андроиде он делается на удивление легко. Часто можно просто в загрузчике выбрать, что загружать вместо обычного ядра операционной системы. Это позволяет полностью убить практически все защитные механизмы. Часто пользователи используют слишком простые пароли, которые без труда взламываются злоумышленниками. Иногда пользователи ставят странные приложения из недоверенных источников. В принципе, троянского коня можно заполучить даже в Google Play, но при установке из сторонних магазинов или с пиратских сайтов вероятность такого исхода возрастает в разы. Часто пользователи забывают отключать на устройстве режим отладки, который позволяет не только быстро установить jailbreak, но и быстро вытащить все данные, получив физический доступ к устройству. Впрочем, в современных версиях Android уже меньше проблем с отладочным режимом.
Разработчики и Android
К сожалению, проблемы возникают не только по вине пользователей. Причиной могут стать и разработчики. В первую очередь проблемы возникают, когда разработчики не до конца понимают, как их приложение функционирует на мобильной платформе. Очень часто можно видеть такое ограниченное мировоззрение, когда разработчик представляет себе некоторое абстрактное устройство, на котором в вакууме работает его сферическое приложение, с которым взаимодействует только пользователь. Это слишком однобокая картина. Например, она не учитывает, что к устройству может получить физический доступ злоумышленник. Значительная часть приложений взаимодействует с серверным бэкэндом, о безопасности которого многие забывают. Часто не принимается во внимание, что приложение может взаимодействовать с другими установленными программами, которые могут оказаться вредоносными. Да и с устройством приложения взаимодействуют не напрямую, а через фреймворки, среду исполнения, библиотеки, ОС. В каждом из этих компонентов могут быть уязвимости. И уязвимости эти могут быть очень низкоуровневыми: в ядре, в драйверах, в оболочках вендоров.
В приложениях также могут возникать проблемы. Многие разработчики позволяют своим приложениям хранить данные не только в своем изолированном участке файловой системы, но и в общедоступном хранилище (например, на SD-карте). Позволяя сохранять таким образом конфиденциальные пользовательские данные, разработчик создает серьезную уязвимость. Еще одна потенциальная приманка для злоумышленников – передача данных по открытым каналам, либо через SSL, но без проверки сертификатов. Для мобильных устройств также актуален практически весь набор уязвимостей их больших братьев. Многие об этом забывают и не обеспечивают санитизацию пользовательского ввода. Используя для отображения информации WebView, также можно получить весь букет атак. Специфичная для андроида проблема – передача чувствительных данных в лог-файлы. Пользователи часто не обращают внимание на запрос чтения системных лог-файлов со стороны приложения. А разработчики часто забывают в релизных версиях минимизировать отладочную информацию, попадающую в логи. Из-за этого туда может записываться очень важная информация. Например, токены, которыми могут воспользоваться злоумышленники.
Работа приложения в сэндбоксе – не панацея против атак. Работать в полной изоляции приложение не может, у него должны быть точки взаимодействия, как с другими приложениями, так и с операционной системой. Межпроцессное взаимодействие в андроиде достаточно гибкое. Например, ваше приложение может содержать в себе такую функциональность, как контент-провайдеры, позволяющую сторонним приложениям получить доступ к данным. Существуют также сервисы, активности и бродкаст ресиверы, которые могут получать доступ к сообщениям, циркулирующим внутри операционной системы. Фактически, если эти компоненты не защищены привилегиями, как это часто бывает, к ним может обратиться какой-то сторонний код. В итоге некоторое приложение может производить действия, которые ему доступны быть не должны. Допустим, ваше приложение имеет доступ к чтению и отправке SMS. Если вы забудете ограничить доступ к контент-провайдерам, кто угодно сможет прочитать сообщения пользователя, не обладая необходимыми привилегиями.
Анализ контент-провайдеров
Перейдем к практической части. Контент-провайдеры позволяют получить доступ к информации через универсальный интерфейс, это такая абстракция курсора баз данных. В качестве контент-провайдера доступна, например, адресная книга. Разрешения на доступ к ним могут быть не установлены ни на чтение, ни на запись, что позволяет злоумышленнику просмотреть или внести какую-то критичную информацию. Для выявления таких уязвимостей есть несколько программных средств. В качестве примеров я хотел бы упомянуть Mercury, разработку компании MWR, и свою standalone-утилиту CPA. Если задаться целью написать такое приложение самостоятельно, то можно понять следующее. Так как многие вещи регистрируются при установке приложения, данные о контент-провайдерах извлечь очень легко. Они прописываются в манифесте приложения, контент-провайдеры регистрируются, соответственно, информация о них доступна через стандартный менеджер пакетов андроида. Там содержатся сведения как о пути, по которому доступен контент-провайдер, так и о привилегиях. Соответственно, я своей утилитой эти данные извлекаю и даю возможность выбрать любой из контент-провайдеров. Естественно, интерес представляют именно незащищенные. Далее можно попытаться передать контент-провайдеру данные, либо заставить его прочитать какой-либо файл. Результаты можно получить довольно неожиданные. Например, на смартфонах Samsung Galaxy S есть биометрическая блокировка экрана, которая снимается, когда пользователь подносит камеру к своему лицу. Это приложение ставит вместе с собой контент-провайдер com.sec.provider.facekey.
Привилегий на чтение и запись у него нет. Если попытаться к этому провайдеру обратиться, используя запрос * from sqlite_master--, результат будет весьма неожиданным. Вернее, он будет неожиданным для тех, кто думает, что SQL-инъекции бывают только в веб-приложениях. Этот запрос позволяет ознакомиться со всей базой данных, дам действительно есть SQL-инъекция. И мы видим там забавную таблицу с названием facefeature, у которой есть поля «особенности лица» и «изображение лица». Можно обратиться к ним напрямую и получить закодированные данные. Таким образом, не имея никаких привилегий, мы получаем доступ к биометрическим данным пользователя.
Ближайший научно-технический семинар в Яндексе состоится 10 июня. Он будет посвящен теме рекомендательных систем и распределенных алгоритмов.
Автор: tracer0tong
