Разбиране на сигурността на Android
Съдържанието на статията
Android е млада операционна система и, както всяка друга новородена операционна система, е обичайно да я обвиняваме за липсата на адекватно ниво на сигурност. Антивирусните компании и индустриалните анализатори отчитат истински бум на зловреден софтуер за Android и прогнозират армия от зомби вируси, които скоро ще изпразнят портфейлите на потребителите. Но наистина ли зеленият робот е толкова уязвим?
В първите дни на своето развитие Android се превърна в истински магнит за атаки от антивирусни компании и независими изследователи: инженерите на Google бяха обвинени в късогледство, огромен брой недостатъци и общата ненадеждност на архитектурата на Android. Това се отнасяше за всички компоненти на системата, но основният удар на експертите падна върху прилагането на механизма за диференциране на правата, който уж ограничаваше приложенията едно от друго, но имаше празнина в самата си основа.
Често цитирани примери са приложения, които експлоатират ядрото на Linux, което им позволява да получат root достъп и след това да правят каквото атакуващият иска да направи със системата. Тези няколко открити уязвимости бяха достатъчни, за да създадат шум в таблоидите, който не стихва и до днес.
Но как стоят нещата всъщност? Проблемът съществува ли или не? Трябва ли потребителите на Android да се страхуват за безопасността на данните си или да преминат към iOS и как, ако е възможно, да защитят данните си от натрапници? Всичко това е разказано от днешния ни преглед.
Хакер #166. DDoS
Дупка в дупка?
В основата си Android разчита на ядрото на Linux, за да свърши по-голямата част от мръсната работа вместо него. В Linux се крият такива грижи като зачитане на правата за достъп, наблюдение на процесите и тяхното правилно изпълнение. На практика това означава, че няма приложениеAndroid не може да получи достъп до данните на друго приложение, освен ако последното не иска.
В Android това се нарича sandboxing, което ви позволява да пазите данните на съседните приложения едно от друго, предотвратявайки кражбата на злонамерен софтуер от лична информация, запазена от всяко приложение в системата. Абсолютно всички приложения попадат в sandbox, включително предварително инсталираните на устройството. Всъщност само малка част от Android работи като root, а именно първоначалният процес zygote, който изпълнява функциите за контрол на изпълнението на приложението, и малка част от системните услуги. Всички останали приложения винаги работят в пясъчни кутии, поради което зловреден софтуер, дори ако е бил „насочен“ към потребителя, не може да открадне нищо ценно, освен съдържанието на SD картата, която е отворена за всички по подразбиране (ще се върнем към това по-късно).
В допълнение към данните на отделните приложения, основната инсталация на Android, която се намира в отделен раздел на вътрешната NAND памет и е свързана към директорията / system, също е затворена за достъп. По подразбиране той е монтиран в режим само за четене и по принцип не съхранява никаква поверителна информация (за поставянето й също се използват пясъчници в / data), така че няма да работи по някакъв хитър начин за регистриране при стартиране или модифициране на системни компоненти (освен ако, разбира се, не използвате експлойти за получаване на root права, което ще обсъдя по-подробно по-долу).
Няколко опции за IPC са достъпни за приложенията за комуникация, като собствените комуникационни инструменти на Linux, като споделена памет и сокети, са достъпни само за процеси, които принадлежат към едно и също приложение, и дори тогава само ако поне частПриложението е написано на език, компилиран в машинен код, тоест с помощта на Android NDK. Във всички останали случаи приложенията ще могат да използват Binder за защитени съобщения и намерения да се обаждат на приложения на трети страни (ще говорим и за тях по-долу).
Започвайки с версия 3.0, Android има вградена поддръжка за криптиране на всички потребителски данни, използвайки стандартната подсистема dmcrypt на ядрото на Linux. Шифроването се извършва по отношение на същата директория /data с помощта на алгоритъма AES128 в режим CBC и ESSIV:SHA256 с помощта на ключ, генериран въз основа на парола, която трябва да бъде въведена по време на зареждане на ОС. Трябва да се има предвид, че картата с памет не е криптирана, така че съхраняваните в нея данни остават напълно отворени.
Приложения и разрешения
Друга важна характеристика на такава система е, че потребителските настройки винаги ще имат предимство пред заявките на приложението, което означава, че ако потребителят изключи GPS, приложението няма да може да го включи самостоятелно, дори ако има всички права да използва GPS. В същото време някои функции на ОС изобщо не са достъпни за приложения. Например само операционната система има право да манипулира SIM картата и никой освен нея.
Проверката на привилегиите се извършва на най-ниското ниво на ОС, включително нивото на ядрото на Linux, така че за да заобиколи тази система за сигурност, зловредният софтуер не само ще трябва да получи root права на устройството, но и по някакъв начин да компрометира ядрото, което е много по-трудна задача.
Сами по себе си изброените механизми за обмен на данни и извикване на функции на приложения, контролирани от системата за привилегии, в Androidса реализирани достатъчно ясно, но могат да доведат до проблеми, ако програмистът не е достатъчно сериозен относно декларирането на привилегиите, необходими за достъп до неговото приложение. Това може да доведе до изтичане на информация или възможност за използване на функционалността на приложението от всеки. Например, в първите версии на Dropbox за Android имаше проблем с правилното определяне на привилегиите, което доведе до факта, че всяко инсталирано приложение можеше да използва Dropbox клиента, за да качи всякаква информация в „облачното устройство“ www.securelist.com.
Защита от падане на стека
За да защити приложения, създадени с помощта на Android NDK, както и системни компоненти, написани на езика C, Android включва обширен набор от механизми за защита срещу натрупване, които са били внедрени от голямо разнообразие от разработчици за различни проекти по това време. В Android 1.5 системните компоненти бяха превключени да използват библиотеката safe-iop, която реализира функции за безопасно извършване на аритметични операции с цели числа (защита срещу препълване на цели числа). Реализацията на функцията dmalloc е заимствана от OpenBSD за предотвратяване на атаки с двойно освобождаване и атаки за последователност на парчета, както и функцията calloc с проверка за възможността за препълване на цяло число по време на операция за разпределение на паметта. Целият код на Android от ниско ниво, започвайки от версия 1.5, е изграден с помощта на механизма на компилатора GCC ProPolice за защита срещу прекъсвания на стека по време на компилиране.
-В MIUI алтернативен Android ROM никое приложение на трета страна няма да може да изпраща SMS без изрично потвърждение от потребителя.
-CyanogenMod разширява стандартния механизъм за разрешения на Android с възможност за отмянавсеки орган след инсталиране на приложението.
-
Като част от пилотния проект за SE Android се работи върху разклонение на Android с активирана система за сигурност SELinux.
Хранилище на приложения
За да разреши поне частично този проблем, без да прибягва до ръчна проверка на приложенията за сигурност, както се прави в Apple App Store, Google стартира услугата Bouncer по-рано тази година, която представлява виртуална машина, в която всяко приложение, публикувано в хранилището, се стартира автоматично. Bouncer извършва многократни стартирания на софтуера, извършва много действия, които симулират работата на потребителя с приложението и анализира състоянието на системата преди и след стартирането, за да разбере дали е имало опити за достъп до поверителна информация, изпращане на SMS до кратки платени номера и т.н.
Най-вероятно Google вече е разработил схема за противодействие на откриването на Bouncer чрез генериране на уникални виртуални среди за всяко ново приложение, но по един или друг начин вирусите ще продължат да проникват в Google Play и трябва да внимавате, когато инсталирате приложения, не забравяйте да прочетете потребителските отзиви и да анализирате списъка с разрешения за приложения, преди да го инсталирате.
Преглед на кода и актуализации
И накрая, но не на последно място, това, което бих искал да кажа за системата за сигурност на Android, е прегледът на кода и процесът на реакция на екипа за разработка при появата на нови уязвимости. Имало едно време програмистите на OpenBSD показаха, че това е един от най-важните аспекти на разработването на сигурна операционна система и Google следва примера съвсем ясно.
Google разполага с екип за сигурност на Android на пълен работен ден, чиято задача е да следи качеството на кодаоперационна система, идентифициране и коригиране на грешки, открити по време на разработването на нова версия на операционната система, отговаряне на съобщения за грешки, изпратени от потребители и компании за сигурност. Като цяло този екип работи в три направления:
- Анализ на нови сериозни иновации в OS за сигурност. Всяка архитектурна промяна на Android трябва да бъде одобрена от тези момчета.
- Тестване на разработения код, в което участват и екипът на Google Information Security Engineering и независими консултанти. Продължава постоянно през целия цикъл на подготовка на нова версия на ОС.
- Отговор при откриване на уязвимост във вече пусната операционна система. Включва постоянен мониторинг на възможните източници на информация за откритата уязвимост, както и поддръжка на стандартен инструмент за проследяване на грешки.
Ако бъде открита уязвимост, екипът по сигурността започва следния процес:
- Уведомява OHA (Open Handset Alliance) компании и инициира дискусии за възможните решения на проблема.
- Веднага щом се намери решение, се правят корекции в кода.
- Пач, съдържащ решение на проблема, се изпраща на членовете на OHA.
- Корекцията се изпраща в хранилището на Android Open Source Project.
- Производителите/операторите започват да актуализират своите устройства в режим OTA или публикуват версия на фърмуера с корекции на своите уебсайтове.
Особено важен в тази верига е фактът, че обсъждането на проблема ще се проведе само с онези членове на OHA, които са подписали споразумение за неразкриване. Това гарантира, че обществеността ще знае за открития проблем само след като вече е разрешен от компаниите и корекцията се появи в хранилището на AOSP. Ако за уязвимосттастане известен от публични източници (форум, например), екипът по сигурността незабавно ще започне да разрешава проблема в хранилището на AOSP, така че всеки да има достъп до корекцията незабавно и възможно най-скоро.
Приложенията нямат право да влизат в директорията с лична информация на други приложения
Отново слабото място тук остават производителите и операторите на устройства, които могат да забавят публикуването на коригираната версия, въпреки ранния достъп до корекцията.
- Подробно обяснение на внедряването на системата за криптиране на Android;
- описание на системата за оторизация на разработчиците на приложения;
- Ръководство за създаване на сигурни приложения за Android.
Както всяка друга операционна система, Android не е без уязвимости и различни архитектурни допускания, които улесняват живота на авторите на зловреден софтуер. Но да се каже, че Android е уязвим по дефиниция, също не си струва. Ясно показва влиянието на най-новите тенденции в развитието на защитени операционни системи. Това са пясъчни кутии за приложения и механизъм за обмен на данни между приложения, който е ясно контролиран от системата, и разработките на проекта OpenBSD - единствената ОС с общо предназначение, която винаги е била разработена с акцент върху сигурността.