ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • Android Hacker's Handbook_2장 [정리 및 번역]
    Mobile/Android 2019.04.07 00:53

    Android Hacker's Handbook Athor.Joshua J

    해당 번역글은 개인 공부를 위해 번역한 글로써, 다소 틀린 표현들이 있을 수 있으니 참고할 때 유의해주시길 바랍니다.

    원문은 https://www.pdfdrive.com/android-hackers-handbookpdf-e39599871.html 여기에서 받으실 수 있습니다.

    Android Hacker's Handbook_2장.pdf
    0.32MB


    [2장. 안드로이드 보안 설계 및 아키텍처]


    안드로이드는 보안 검사 및 처리를 몇 가지 메커니즘으로 구성하고 있다.
    다른 운영 체제와 마찬가지로 이러한 메커니즘(App/User)객체(App/File,Device) 및 행할 작업(읽기,쓰기,삭제 등)에 

    대한 정보를 교환할 수 있다. 

     

    대부분의 경우에서는 이러한 과정에서 문제가 발생하지 않지만, 어떠한 균열을 통해 이러한 정보들이 빠져나가 

    공격자에게 좋은 기회를 제공하기도 한다.

     

    2장에서는 안드로이드 플랫폼의 전반적인 Attack Surface를 분석하기 위한 보안설계와 아키텍처에 대해 설명한다.


    1. 안드로이드 시스템 아키텍처 이해

     

    일반적인 안드로이드 아키텍처는 "Java on Linux"로 불려 왔다.
    하지만, 이런 표현은 잘못된 표현이며 플랫폼의 복잡성과 아키텍처를 완벽히 정의하지 못한다.
    전반적인 아키텍처는 '어플리케이션프레임워크달빅(Dalvik)가상머신사용자 공간의 Native Code리눅스 커널'로 

    총 5가지 주요 레이어로 분류되는 컴포넌트들로 구성된다.

     

    [그림2-1] 안드로이드 아키텍처

    [그림 2-1]은 주요 레이어들이 Android 소프트웨어 스택을 구성하는 방법을 의미한다.

    Android 어플리케이션을 사용하면 개발자가 Low-level까지 건들이지 않고 장치의 기능을 확장하고 향상시킬 수 있다.
    또한, Android 프레임워크는 개발자에게 다양한 기능을 모두 사용할 수 있는 풍부한 API를 제공한다.

    Android기기는 개발자가 UI(User Interface)요소 관리, 공유 데이터 저장소 액세스 및 응용 프로그램 구성 요소간에 

    메시지 전달과 같은 일반적인 작업을 수행할 수 있도록 App과 Dalvik가상머신 간의 연결을 제공해야 한다.

    어플리케이션과 프레임워크는 Java로 개발되어 달빅 가상시스템 내에서 실행된다.

    달빅 가상시스템의 특징을 살펴보자면, 우선 Dalvik Executable(DEX)바이트 코드 형식을 해석하는 

    '레지스터 기반 시스템'이다.  또한, Native Code 라이브러리를 지원하기 때문에 C/C++를 사용할 수 있다. 
    이렇듯 DalvikVM은 기본 운영 체제에 효율적인 추상화 계층을 제공하도록 특별히 설계된 가상 시스템이다.

    '안드로이드 사용자 공간의 고유 코드 구성 요소'에는 DBus와 같은 시스템 서비스가 포함된다. 

    시스템 서비스에는 dhcpd, wpa_supplicant와 같은 네트워킹 서비스, bionic_libcWebKit, OpenSSL과 같은 

    라이브러리가 있다. 이러한 서비스 및 라이브러리는 커널 서비스, 드라이버와 통신하지만 일부는

    'Managed code'에 대한 Low-level 수준의 작동을 용이하게 하기도 한다.

    안드로이드는 Linux커널 기반의 시스템이다.
    안드로이드는 'Kernel-source-tree'에 대한 수많은 추가와 변경을 진행했으며, 그 중 일부는 자체 보안기능을 가지고 있다. 이 부분은 3,10,12장에서 좀 더 자세히 다루도록 하겠다.

     

    커널 드라이버는 '카메라 액세스', 'Wi-Fi 및 기타 네트워크 장치 액세스'와 같은 추가적인 기능을 제공한다.
    그 중 하나의 예로는 프로세스 간 통신(IPC)을 구현하는 '바인더 드라이버'가 있다.

    바인더 드라이버에 대해서는 뒤에서 다시 다루도록 하겠다.


    2. 보안 경계 및 처리 이해


    'Trust Boundary'라고도 말하는 보안경계는 신뢰수준이 서로 다른 시스템의 특정위치를 의미한다.
    가장 좋은 예로는 '커널 공간'과 '사용자 공간'의 경계이다.

     

    커널 공간의 코드는 하드웨어에 대한 하위 수준의 작업을 수행하고 모든 가상 및 실제 메모리에 접근할 수 있도록 신뢰 된다.
    그러나 사용자 공간 코드는 CPU에 의해 적용되는 경계로 인해 모든 메모리에 접근할 수 없다.


    안드로이드는 Linux 사용자 기반 보호를 활용하여 'Users'와'Groups' 두 개로 권한을 분리한다.
    두 개의 권한 그룹은 Linux 기반이며, 파일 시스템 항목 및 기타 Android관련 리소스에 대한 접근이 권한에 맞게 분리된다.
    이것을 'Android SandBox'라고 한다.

    'Groups'에 대한 권한은 Android런타임 때 달빅VM과 프레임워크를 통해 적용된다.
    어플리케이션을 설치할 때 사용자가 App의 권한을 정의하는 것이 그것이다.  

    이 과정에서 정의되는 권한은 실제OS의 특정 사용자,그룹 및 기능에 매핑된다.

    2-1. Android SandBox

    안드로이드는 Unix계열의 프로세스 격리 절차와 최소한의 권한 원칙을 따른다.
    구체적으로 말하자면 '별도의 사용자로 실행되는 프로세스는 신호를 보내거나, 서로의 메모리 공간에 접근하는 것과 같은 

    서로 간섭하는 행위가 불가능 하다.'는 개념을 말한다.

    Android의 Sandbox는 '프로세스 격리', '프로세스에 대한 고유 사용자(UID)', '파일 시스템 권한'과 같은 핵심 개념을 전제로 하지만, Linux의 UID/GID(GroupID) 패러다임을 공유할 뿐 사용자 및 그룹 자격 증명 원본에 대한 암호 및 그룹 파일을 가지고 있지는 않는다.

    대신 'Android ID'(AID)라고 하는 고유 식별자를 정의한다.
    AID정의에는 시스템 사용자/그룹 과 같이 권한이 있거나, 시스템에 중요한 사용자를 위한 예약된 정적 항목이 들어 있다.  또한, 앱UID의 Provisioning을 위해 AID범위를 예약한다.

     

    [?]계정Provisioning:  신입사원이 입사하거나 조직내에서 인사 이동을 하거나 직무변경이 발생해 사용자가 접근하는 자원(Resource)의 범주가 변경되었을 때 HR담당자와 IT관리자는 승인절차 밟은 후 e-mail ,그룹웨어 ,ERP등 다양한 어플리케이션에 필요한계정을 생성하거나 접근권한을 변경해주는데, 이러한 일련의 과정을 계정 프로바이저닝이라고 한다.

    출처:https://web-front-end.tistory.com/104


    Android v4.1 이후에는 여러 사용자 프로필 및 분리된 프로세스 사용자(예: Chrome 추가 샌드박싱)를 위해 추가 AID범위를 추가했다.
    AOSP(Android Open Source Project)트리의 'symstem/core/include/private/android_filesystem_config.h'에서 

    AID에 대한 정의를 찾을 수 있다. [그림2-2]는 해당 내용을 간략하게 편집한 것이다.

     

    [그림2-2] AOSP_Define AID


    AID 외에도 보조 그룹을 사용하여 프로세스가 공유나 보호된 자원에 접근을 허용하기도 한다. 
    예를 들어, sdcard_rw그룹의 멤버쉽은 마운트 옵션이 읽기/쓰기가 가능한 그룹을 제한하기 때문에 프로세스가 /sdcard 디렉터리를 읽고 쓸 수 있다.  이것은 보조그룹이 많은 Linux배포판에서 사용되는 것과 유사하다.

    [?]보조그룹: /etc/group 파일에 추가적인 Group들을 할당할 수 있다.

     

    모든 AID항목은 UID와 GID로 매핑되지만 UID는 반드시 시스템의 사용자를 나타내는데 사용되지 않을 수 있다.
    AID_SDCARD_RW는 sdcard_rw에 매핑되지만 시스템의 UID가 아닌 보조그룹으로만 사용되는 것처럼 말이다.


    파일 시스템 접근을 강화하는 것 외에도 AID_INET그룹은 사용자가 AF_INET/AF_INET6 소켓을 열 수 있도록 하는 

    권한을 부여하는 것 처럼 보조그룹을 사용하여 프로세스에 추가 권한을 부여할 수도 있다.

    또 다른 경우 에는 권한이 'Linux Capability'를 부여하는 형태로 나타날 수 있다.
    AID_INET_ADMIN그룹은 CAP_NET_ADMIN의 Capability를 부여하여 사용자가 네트워크 인터페이스 및 라우팅 테이블 

    구성을 설정할 수 있도록 허용하는 것이 이러한 형태라고 할 수 있다.

    Android v4.3이상에서는 위와 같은 Capability를 사용을 더 늘리게 되는데, /system/bin/run-as바이너리의 UID루트를 

    수정하여 높은 권한의 리소스에 접근하는 것을 막는 등 다양하게 응용 되었다.

    'Linux Capability'에 대한 자세한 정보는 Linux커널의 Documentation/security/credentials.txt 및 Capability 설명서 페이지에서 찾아볼 수 있다.


    App이 실행되면 UID,GID 및 보조그룹이 새로 생성된 프로세스에 할당된다. 

    고유한 UID/GID로 실행하면 운영체제가 커널에서 더 낮은 수준의 제한을 적용할 수 있으며, 런타임에서 App간 상호작용을 제어할 수 있도록 한다. 이것이 Android SandBox의 핵심이다.

     

    아래 [그림2-3]은 HTC One V에서 ps명령어를 입력한 모습이다.

    맨 왼쪽에서 2번째에 위치한 UID들이 각 App마다 고유한 것을 확인할 수 있다.

     

    [그림2-3] ps Command on HTC One V

    App은 Application Package의 특수 지시문을 통해 UID를 공유할 수도 있다. 

    자세한 내용은 '주요 응용 프로그램 구성 요소'에서 설명하도록 한다.

    내부적으로 프로세스에 대해 표시되는 UID/GID는 실제로 이러한 값을 설정하고 가져오는데 사용되는 

    'POSIX'기능 중 getpwuid( )과 같은 안드로이드 특정 구현에 의해 제공된다.

    [?]getpwuid: Bionic라이브러리에서 stubs.cpp에 정의되어 있다.

     

    [그림2-4] getpwuid( )

    getpwuid( )는 android_id_to_passwd, app_id_to_passwd와 같은 Android 관련 기능을 호출한다.
    그런 다음 'Unix Password 구조체'를 AID정보로 채운다.
    android_id_to_passwd( )는 android_i info_to_passwd( )를 호출하여 이를 수행한다.

     

    [그림2-5] android_i info_to_passwd( )

     

    2-2 Android 권한

    안드로이드 권한 모델은 API권한파일 시스템 권한IPC권한 3가지의 관점으로 나눌 수 있다.
    때때로, 이들 각각 얽힐 때가 있는데 앞에서 언급했듯이 일부 높은 수준의 사용 권한은 낮은 수준의 운영 체제 기능으로 다시 매핑된다.  여기에는 소켓 열기, Bluetooth장치 및 특정 파일 시스템 경로와 같은 작업이 포함될 수있다.

     

    App사용자의 권한과 보조 그룹을 결정하기 위해 Android는 App Package의 'AndroidManifest.xml'파일에 지정된 상위 수준 권한을 처리한다. (Manifest 및 권한에 대해서는 '주요 애플리케이션 구성 요소'섹션에서 자세히 설명하도록 한다.)
    App의 사용 권한은 설치시 Package Manifest에서 추출되고, '/data/system/packages.xml'에 저장된다.
    그런 다음 이 항목을 사용하여 App프로세스의 인스턴스 생성시 적절한 권한을 부여한다.
    [그림2-6]은 Chrome패키지의 Packages.xml의 저장된 App의 고유한 userID와 권한을 보여준다.

     

    [그림2-7] Packages.xml in Chrome_Package

    그룹에 대한 접근 권한 설정은 '/etc/permissions/platform.xml'에 저장된다. 

    이것은 응용 프로그램에 설정할 보조그룹ID를 결정하는데 사용된다.
    [그림2-7]은 이러한 설정 중 일부를 보여준다.

     

    [그림2-7] /etc/permissions/platform.xml

    Package항목에 정의된 권한은 나중에 두 가지 방법 중 하나로 적용된다.
    첫번째는 주어진 메소드 호출 시 완료되며 런타임에 의해 적용된다.
    두번째는 라이브러리 또는 커널 자체의 OS레벨에서 적용된다.


    [API권한]
    API권한에는 Android API/Framework 및 경우에 따라 타사 Framework에서 상위 수준 기능에 대한 접근을 

    제어하는데 사용되는 권한이 포함된다. READ_PHONE_STATE를 예로 들 수 있는데,

    'Android Documentation'에서 '전화상태에 대한 읽기 전용 접근'을 허용하는 것으로 정의되어 있다.
    따라서, 이 권한을 요청하여 해당 권한이 부여된 App은 전화정보를 쿼리하는 것과 관련된 다양한 메소드를 호출할 수 있게된다.
    메소드에는 'getDeviceSoftwareVersion','getDeviceId'등의 TeleponyManager클래스의 메소드가 있다.

    앞서 언급했듯이 일부 API 사용권한은 커널 수준 메커니즘에 해당된다.
    예를 들어, INTERNET권한이 부여되면 요청한 App의 UID가 INET그룹의 구성원으로 추가된다.(GID 3003)
    이 그룹의 멤버쉽은 사용자에게 HttpURLConnection 객체 생성과 같은 상위 레벨 API기능에 필요한 AF_INET/AF_INET6 소켓을 여는 기능을 제공한다.
    4장에서 API권한에 관련된 몇가지 문제점에 대해서 다루도록 한다.

    [파일 시스템 사용권한]
    Android의 어플리케이션 샌드박스는 Unix 파일 시스템 권한으로 지원된다. 
    App의 고유한 UID/GID는 기본적으로 파일 시스템의 해당 데이터 저장소 경로에만 접근할 수 있다.
    [그림2-8]의 디렉터리 목록을 UID/GID(두번째와 세번째 줄)에 유의해서 보도록 하자.

     

    [그림2-8] App 디렉터리 목록

     

    따라서, 어플리케이션에서 만든 파일에는 적절한 파일 사용권한이 설정된다.
    다음 [그림2-9]는 어플리케이션의 데이터 디렉터리를 보여준다.
    하위 디렉터리 및 파일에 대한 소유권과 실행권한은 어플리케이션의 UID/GID에 대해서만 설정된다.

     

    [그림2-9] Application /data

    SD카드 또는 기타 외부 저장소와 같은 공유 리소스에 접근할때는 특정 보조그룹(GID)이 사용된다. 
    아래 그림에서 mount와 ls 명령의 출력을 확인해보길 바란다.

     

    [그림2-10] mount GID

    여기서 SD카드가 sdcard_rw그룹에 해당하는 'GID1015'로 마운트 되었음을 알수 있다.
    WRITE_EXTERNAL_STORAGE권한을 요청하는 App은 이 그룹에 UID를 추가하여 이 경로에 대한 쓰기권한을 부여한다.

    [IPC권한]
    IPC권한은 API권한과 일부 겹치지만 App구성요소 간의 통신과 직접 관련된 권한이다.
    이러한 사용권한의 선언 및 적용은 런타임,라이브러리 함수, Application 직접 수행과 같이 다양한 수준에서 발생할 수 있다.
    특히, IPC권한은 Android의 바인더 IPC메커니즘을 기반으로 하는 주요 Android App 구성요소에 적용된다.
    이러한 구성 요소와 바인더 자체에 대한 자세한 내용은 뒷부분에서 설명하도록 한다.

    댓글 3

Designed by Tistory.