Часть вторая. Начало читайте здесь.
Риски, связанные с уязвимостями
В своём отчёте Bluebox указывают, что в принципе уязвимость может быть задействована с целью повышения полномочий в системе до суперпользователя (Root), в результате чего открываются широчайшие возможности — от хищения личных данных до создания мобильного ботнета.
«В то время как риск для индивидуальных и корпоративных пользователей и так огромен, ситуация дополнительно ухудшается, если иметь в виду, что некоторые разработчики устройств (HTC, Samsung, Motorola, LG) или сотрудничающие с ними «третьи стороны» устанавливают приложения с изначально повышенными привилегиями в среде Android», — отмечается в сообщении Bluebox. И если модифицировать содержимое в таких приложениях, то злоумышленник получает полный контроль над всеми данными на устройстве. В свою очередь, если мы говорим о корпоративных гаджетах, то уязвимое устройство является потенциальной точкой несанкционированного доступа в корпоративную сеть.
«Радостная» картина, ничего не скажешь.
…И меры были приняты
Google проинформировали об обеих уязвимостях сразу же, а уже от Google информация разошлась по его партнёрам, так что патчи, по идее, должны были разойтись задолго до того, как сведения об уязвимостях стали достоянием широкой публики. Выпущен даже патч для Cyanogenmod.
В магазине GooglePlay установлены новые правила, так что в него больше не должны попадать приложения, содержащие обе уязвимости – их отсекают на этапе проверки. К сожалению, похоже, фильтры срабатывают не всегда.
Первооткрыватель уязвимости, компания Bluebox выпустила специальный сканер для выявления уязвимых устройств.
Естественно, свои меры приняли и производители решений по защите мобильных устройств. В частности, наши разработки позволяют с помощью данных из KasperskySecurityNetwork выявлять уязвимые устройства и приложения, эксплуатирующие эти бреши; подробнее об этом – в статье нашего эксперта Стефано Ортолани на Securelist.com.
Но означает ли это, что можно трубить отбой? С одной стороны, да, с другой — нет.
Хакеры не дремлют
Несмотря на все принятые меры, авторы вредоносного ПО, похоже, решили тоже не откладывать дело в долгий ящик и довольно быстро написали вредоносный код, эксплуатирующий первую из двух описанных в предыдущем посте уязвимостей. По словам Джеффа Форристола из Bluebox Security, это, возможно, связано с тем, что официальный патч для уязвимости попал в открытый репозиторий Cyanogenmod ещё до того, как сама компания Google опубликовала его.
Как уже указывалось, Bluebox Security проинформировали Google об уязвимости Master Key ещё в феврале этого года. Согласно политике Google, информация о бреши публикуется спустя 90 дней, с тем чтобы партнёры компании успели принять меры. В этот раз, однако, в связи с серьёзностью проблемы Google опубликовала патч и информацию о бреши в Android спустя целых 150 дней — патч появился в репозиториях Android Open Source Project только 25 июля.
В то же время в репозитории Cyanogenmod этот патч оказался 6 июля. Каким образом это произошло, загадка: Cyanogenmod базируется на коде, который публикует Google, то есть патч, по идее, должен был сначала оказаться в репозиториях Android Open Source Project, и лишь потом дойти до Cyanogenmod. Как бы там ни было, патч был опубликован, и злоумышленники скорее всего произвели его обратную разработку, чтобы изготовить свой эксплойт, который впервые был замечен 23 июля.
Предъявлять претензии к Cyanogenmod по этому поводу нет смысла. Как отметил Форристал, стандартные для Google «90 дней молчания» давно прошли, положенная пауза выдержана, так что операторы репозитория Cyanogenmod имели и право, и основания опубликовать патч для опасной бреши.
Любопытно, однако, что хакеры довольно оперативно написали работающий эксплойт: если Форристал прав, и злоумышленники действительно осуществили обратную разработку патча из репозитория Cyanogenmod, то на всё про всё у них ушло семнадцать дней.
Родовая травма Android
По нашей статистике, 98,96% вредоносных программ для смартфонов и планшетов, появившихся в прошлом году, написаны под Android: для злоумышленников это мишень номер один. Ключевым источником проблем оказался, как это ни печально, сам децентрализованный подход Google к этой операционной системе. Если Apple самостоятельно производит свои устройства и операционную систему к ней, то выпуском гаджетов на Android занимается большое количество разномастных производителей, заинтересованных в значительной степени в том, чтобы потребители покупали новые устройства. В результате, обновление прошивок затруднено (если возможно вообще), установить более новые версии операционной системы на старые устройства невозможно. Но у владельцев смартфонов нет никаких стимулов покупать новые устройства, пока работают прежние.
В результате, как показывает статистика, более чем на трети устройств под Android установлена версия 2.3.x Gingerbread, выпущенная в начале 2011 года. Доли более новых версий — 4.0 Ice Cream Sandwich и 4.1 Jelly Bean составляют, соответственно, 23,3% и 32,5%, в то время как версия 4.2.x Jelly Bean только-только перешагнула отметку 5,5%.
Уже не говоря о том, что, помимо официального магазина приложений Google Play, где поступающие приложения проверяются на наличие вредоносных модулей (хотя эта проверка порой далека от совершенства), существует масса сторонних магазинов, где никаких препон и фильтров против заразы нет. Естественно, в них приложения, эксплуатирующие данные уязвимости, появились, как только информация стала публичной. Нельзя также не упомянуть и многочисленные взломанные устройства, на которые устанавливаются «пиратские» приложения.
Система Android высокофрагментированна, уязвима, большое количество функционирующих устройств используют устаревшие её версии, и при всём этом она чрезвычайно популярна.
В связи с этим возникает вопрос, что делать с устройствами под Android в корпоративных средах, если в компании действует парадигма Bring Your Own Device (BYOD). Поверхностный ответ очевиден: вводить режим «нулевой терпимости», в обязательном порядке изолировать пользовательские и корпоративные данные друг от друга; максимально ограничивать возможности несанкционированного проникновения чего бы то ни было с мобильного устройства в корпоративную сеть; опять же в обязательном порядке устанавливать решения по защите мобильных устройств от вредоносного ПО — ещё весной в нашем блоге был опубликован развёрнутый материал, посвящённый типовым рискам концепции BYOD , в котором приводился ряд советов по контролю над личными мобильными устройствами в корпоративных сетях и защите данных.
Вышеописанные «отмычки» — это очередное напоминание о том, сколько проблем может создавать недостаточно внимательное отношение к вопросам защиты данных. Ни один разработчик программного обеспечения не застрахован от ошибок, в том числе критических. Это необходимо иметь в виду и к этому нужно быть готовым, тем более, что существует масса способов уменьшить риски и не становиться безропотной жертвой злоумышленников.