Ⅰ. 개요
안드로이드 보안과 관련된 간단한 지식을 살펴본다. 정적 분석과 동적 분석에 대해 알아볼텐데, 정적 분석은 애플리케이션이 실행되지 않은 상태에서 소스 코드를 분석하고 결함(취약점)을 찾아내는 기법이다. 동적 분석은 애플리케이션이 실행 중인 상태에서 Hooking 혹은 ELF 실행 파일들의 구조를 분석해서 취약점을 찾아내는 기법이다. 모바일 애플리케이션의 주요 점검 항목으로 첫 번째 OS 변조 탐지 기능 적용 여부, 두 번째 프로그램 무결성 검증, 세 번째 메모리 내 중요 정보 노출 여부, 네 번째 단말기 내 중요 정보 저장 여부, 다섯 번째 화면 강제 실행에 의한 인증 단계 우회가 있다.
Ⅱ. 안드로이드 보안 관련 여러 지식
주요 내용은 동적분석, 정적분석, MultiDex가 될 예정이다. 그 전에 이전 게시글과 관련하여 리뷰느낌으로 몇 가지를 적고자 한다. 그래서 초반 문단은 두서없는 글이 될 수 있는 점 감안해줬으면 좋겠다. 먼저, IOS도 마찬가지지만, 안드로이드에서는 악성 코드 앱으로 부터 기기를 보호하기 위해 앱에 개발자 서명이 필요하다. 서명이 없는 앱은 설치 및 실행이 안되며, 서명은 유일한 값으로 위변조하기에도 어렵다. 스미싱(문자메시지를 이용한 개인정보탈취 및 돈 갈취)같은 공격을 할 때, 웹 주소를 기반으로 하는데 공격측에서 실제로 개인 정보를 빼오려고 할 때 어떤 기기이며, 실제로 사용하는 기기인지 확인하려면 어떻게 해야 할까? 웹개발 때도 고려해야할 점이지만, 운영체제에 user agent란 식별자 값이 있어서 이를 통해 상대 기기에 대한 정보를 파악 후 공격을 시도한다. 그래서 웹 서비스 운영에서 user agent를 통해 모바일, PC를 구분해서 웹 페이지를 보여주는 방식(반응형)도 구분할 수 있고 운영체제에 맞는 악성 코드도 배포할 수 있게 된다.
※ TIP: Nox player나 LD Player 같은 가상 안드로이드를 파악할 때는 추가적으로 블루투스, 통신사, 전화번호 등의 정보가 있는지 확인하기도 한다.
※ 네트워크 환경 구축 관점에선 망 분리를 통해 사내망, 게스트망을 나눠 보안을 유지하기도 한다.
지난 게시글에 아이폰은 보안이 뛰어나다고 얘기하긴 했지만, 사실 아이폰도, 안드로이드도 C언어 코드가 들어가기 때문에 보안에 취약해질 수 있다. 특히, 게임 같은 애플리케이션을 만들 때 아이폰과 안드로이드 용을 같이 만드는 개발사에서 공통적인 C언어 코드가 들어갈 수 있기 때문에 주의가 필요하다. 안드로이드의 경우 Native Libraries에서 C언어 코드를 실행시켜준다.
안드로이드 APK파일을 디컴파일하고 리패키징, 컴파일하면서 코드를 분석해보거나 조작해보는 실습을 했는데, 그에 관련한 디컴파일, 컴파일 명령어만 올린다. 또, 안드로이드 어셈블리어인 smali 관련 참고 구글 문서를 첨부한다.
java -jar apktool_2.5.0.jar(java의 디컴파일, 컴파일 도구) d(디컴파일 옵션) apk(디컴파일 할 apk명) path(저장경로 및 디렉토리명)
java -jar apktool_2.5.0.jar b(컴파일 옵션) directory(컴파일 할 소스 코드 담긴 디렉토리) -o(이 옵션 다음에 apk 저장할 디렉토리) apk(새로 만들 apk명)Dalvik 바이트 코드 | Android 오픈소스 프로젝트 | Android Open Source Project
Dalvik Executable 형식 | Android 오픈소스 프로젝트 | Android Open Source Project
Ⅲ. 정적분석과 동적분석
정적 분석은 애플리케이션을 실행하지 않은 상태에서 소스 코드 상에서 결함을 찾아내는 분석 기법이다. Decomplie 등을 통해 소스 코드를 어셈블리어 혹은 원문을 가지고 분석을 시도한다. 그때 사용할 수 있는 여러 Tool이 있는데, 그 중 위에서 언급한 apktool, jadx 등이 있다. 안드로이드에선 AndroidManifest.xml, 서명값 등을 보고 대략적으로 어떤 권한을 사용하는지 악성 코드인지를 파악해볼 수도 있다. DEX 구조에선 각 기능들이 classes.dex로 묶여 있기 때문에,
이 구조를 기반으로 소스 코드 분석을 시도한다.
동적 분석은 앱이 실행 중인 환경에서 결함을 찾아내는 분석 기법이다. 사용자의 입출력을 변조하거나 혹은 실행 흐름을 변조해서 취약점이 어떻게 생길 수 있는지 확인한다. 실행 중인 환경에서 데이터나 실행 흐름을 변조하기 위해 Hooking이 필요하다. Hooking으로 잘 알려진 Frida를 통해 애플리케이션 내에서 어떤 클래스, 메서드가 있는지 살펴보고 어떤 메서드들이 동작하는지 파악하고 조작도 한다. Frida는 Javascript 기반으로 어느 정도의 틀은 있지만, 직접 코드 로직을 구성해야 한다. 그 외에 Java의 JEB라는 상용 소프트웨어도 있다. 원래 유닉스 계열의 실행 파일을 의미하는 ELF(Executable and Linkable Format)의 so(Shared Object) 확장자 파일들이 안드로이드에선 동적으로 로딩될 때가 많다고 한다. 이 확장자 파일들은 C/C++ 언어로 작성되었으며 Native Libraires를 통해 동작하게 될텐데, 안드로이드의 기반인 리눅스 시스템과 연계되기 때문이다.
점검 항목 | 설명 |
OS 변조 탐지 기능 적용 여부 | OS가 변조(루팅, 탈옥) 된 단말 이용 시 보안 위협이 증대됨에 따라, OS 변조 시 서비스 이용가능 여부를 점검 |
프로그램 무결성 검증 | 변조된 프로그램이 정상실행 될 경우, 악성코드가 포함되어 재 배포되는 등의 보안 위협이 존재함에 따라, 변조 프로그램 정상 실행 가능 여부 점검 |
메모리 내 중요정보 노출 여부 | 이용자 단말기 메모리 영역에서 이용자 중요정보의 평문 노출 여부 점검 |
단말기 내 중요정보 저장 여부 | 어플리케이션 사용 폴더 및 외부 저장소에 존재하는 파일 내 중요정보 저장 여부 점검 |
화면 강제 실행에 의한 인증단계 우회 | 화면 강제 실행, 인증관련 파일 조작 등을 통해 인증단계 우회 가능 여부 점검 |
위 표를 보면 모바일 애플리케이션에서 점검해야 할 주요 항목 다섯 가지가 있다. 첫 번째, OS 변조 탐지는 운영체제의 관리자 권한을 얻어 기기에 대한 완전한 통제가 가능한지 여부에 대한 검사이다. 안드로이드의 경우 루팅, 아이폰의 경우 탈옥이라고 하며, 일반 사용자가 루팅이나 탈옥을 하게 된 경우 보안 시스템인 샌드박스가 기능을 상실할 수 있어 굉장히 보안에 취약해진다. 물론, 악성 코드로 인해 관리자 권한을 해킹당하는 것도 기기에 저장된 모든 데이터가 빠져나갈 수 있어 심각한 상황을 초래할 수 있다.
※ 모바일만이 아닌 PC에서도 특정 프로그램을 사용할 때 그 프로그램이 운영체제의 높은 권한을 이용하게 될 때가 있다. 그 프로그램을 해킹해서 내 PC의 정보를 빼올 수 있기 때문에 주의가 필요하다. 예를 들어, VMware, Nox Player 등은 가상머신으로 커널을 직접적으로 건드릴 수 있기 때문에 위험하다.
그래서 이런 OS 변조를 탐지하기 위해 특정 앱을 이용하거나 시스템 설정 파일(ro.debuggable, service.adb.root) 등을 확인해보거나 안드로이드 운영체제로 들어가 루트 명령어인 su 실행 여부를 확인해보거나 루팅시 설치되는 파일(/sbin/su, /system/su, /system/bin/su, /system/xbin/su, /system/app/Superuser.apk 등)들이 있는지 찾아볼 수 있다.
getprop | grep debug위 명령어를 입력해보면,
이런 결과를 볼 수 있을텐데 ro.debuggable 부분이 0으로 되어 있다면 루팅이 되지 않은 상태이고 1로 되어 있다면 루팅이 된 상태이다.
프로그램 무결성 검증은 일반 사용자가 특히 조심해야될 부분인데 겉으로 봤을 때 정상적인 애플리케이션으로 보일지라도 실제로 내부에서 악성 코드가 돌아다닐 수 있기 때문에 주의가 필요하다. 구글 플레이 스토어라는 정식 스토어가 아닌 apk 마켓 같은 곳에서 다운로드 받는 앱이 특히 위험하고 IOS는 사실상 앱스토어(애플스토어)에서 밖에 다운받을 수 없기 때문에 상대적으로 안전한 편이다. 윈도우도 웹 상에 돌아다니는 프로그램을 손쉽게 다운받아 사용할 수 있기 때문에 마찬가지로 조심해야 한다. 한 번 실행하게 되면 이미 늦어버리는 결과가 초래될 수 있기 때문이다.
메모리 내 중요 정보 노출은 모든 기기가 가진 메모리를 공격한다는 점에서 보안에 대해 많이 신경써야할 부분이다. 사실상 모든 애플리케이션은 메모리에 할당되어 각종 데이터들이 쌓이고 지워질텐데 만약, 누군가 실시간으로 메모리 정보를 dump하고 있다면 내 계정과 비밀번호, 카드번호, 계좌 등이 모두 노출될 수 있게 된다. 그래서 메모리에 내가 입력한 중요 정보들이 평문으로 존재한다면 취약점이며, 암호화를 통해 메모리 정보가 유출되더라도 알아볼 수 없게 해야 한다. 이는 웹상에서도 특히 보안을 신경써야 한다. Javascript가 보안에 취약한 면이 있기 때문에, 그대로 노출된다면 위험하고 DB에 개인 정보를 저장할 때도 암호화가 필요하며 손쉽게 해독할 수 없는 상태여야 한다.
단말기 내 중요 정보 저장의 경우 일반적인 경우는 많지 않지만 중요 개인 정보가 일반 디렉토리 혹은 외부 저장소에 저장된다면, 기기가 한 번이라도 해킹됐을 때 모든 개인 정보가 탈취당한다. 게임의 경우 사용자 데이터가 남아 있다면, 이를 조작해 게임을 즐기는 방법도 있겠지만(???) 그런 경우는 거의 없을텐데, 게임만이 아니라 은행같은 경우 중요 정보를 서버에서 관리하고 있고 서버에 대한 보안에 굉장히 많은 신경을 쓰고 있기 때문에, 일반적으로는 안전하다고 할 수 있다. 만약 사용자가 별도로 단말기 내 중요 정보를 저장하지 않는 한 상대적으로 덜 위험하다.
화면 강제 실행에 의한 인증 단계 우회는 로그인이나 키를 입력하는 등의 인증 단계 관련 파일들을 조작해서 우회하는 방법으로 사용자 앱에 접속해서 개인 정보를 빼올 수 있다. Androidmanifext.xml에 권한과 컴포넌트 설정이 정의되어 있는데, exported 값이 true면 다른 애플리케이션이나 시스템에서 해당 서비스에 직접 접근 가능해지고 false면 앱 내부에서만 접근 가능하게 된다. 만약, 저 설정을 통해 외부에서 해당 애플리케이션 로그인 액티비티에 접근하여 그 로그인 액티비티에서 다른 액티비티를 호출 시켜 인증 단계를 우회할 수 있다. 즉, 정상적인 로그인 관련 기능이 아닌 다른 악성 코드가 실행시킬 수 있다.
Ⅳ. MultiDex
MultiDex는 간단히 말해 Dex구조가 이중으로 되어 있다고 생각하면 좋다.
위 이미지를 보면 이해가 용이할텐데, 이 구조를 가지게 된 배경은 메서드의 제한 때문이다. 간단한 애플리케이션을 제작하는 경우 해당되지 않겠지만, 굉장히 많은 기능을 제공하거나 개발 단계에서 여러 라이브러리를 참조하여 많은 메서드를 사용하게 되면, 하나의 Dex로 구성하는데 제한이 걸린다. 64K 참조 제한이라고 불리는데, 실질적으로 65,536개의 메서드를 초과할 수 없고 개수의 값이 64 X 1,024와 동일하기 때문에, 64K 참조 제한이라고 부른다. 그래서 위 이미지처럼 Main Dex와 Sub Dex의 구조로 나누어 서로 동적으로 로드하면서 애플리케이션을 작동시킨다. 하지만, 꼭 제한 때문에 이 구조를 띄는 것이 아닌 경우도 있는데, 이 구조의 장점 때문이다. Sub Dex의 경우 코드들이 숨겨질 수 있기 때문에, 중요한 코드는 Sub Dex에 숨겨서 작동시키고 Main Dex에서 일반적인 코드를 실행시킬 수 있다. 이 구조의 apk파일을 디컴파일해보면, Main과 Sub Dex가 다른 영역에 있는 걸 볼 수 있다.
ELF(Executable and Linkable Format)가 안드로이드에서 어떻게 호출되고 작동할 수 있는지 간단히 살펴보고자 한다.
안드로이드 구조의 Native Libraries를 참조해서 C/C++ 언어로 구성된 코드를 실행시키는데, DEX 구조에서 CLASS의 METHOD가 실행할 때 그 안에 참조해야 할 ELF 메서드가 있다면, PLT(Procedure Linkage Table)를 통해 로드 가능하다. PLT는 외부 Procedure를 연결해주는 테이블인데 Procedure들의 주소를 GOT(Global Offset Table)를 참조해서 불러올 수 있다. GOT는 PLT가 참조하는 Procedure들의 주소가 있는 테이블인데 그림에서 보는 것처럼 ELF 파일에 포함되어 있다. 즉, 안드로이드의 DEX 구조에서 CLASS의 METHOD는 자신의 로직 상 실행해야 할 ELF의 메서드들을 PLT로 가지고 있고 이 PLT는 GOT를 참조해서 로드할 수 있는 것이다.
apk파일을 열어보면 다양한 구성이 있겠지만, 저렇게 lib 디렉토리가 있다. 이 디렉토리안에 ELF 파일들이 포함되어 있는데 들어가보면,
이런 lib[name].so(Shared Object) 형태로 포함되어 있다. '.so' 확장자는 리눅스에서 실행 파일을 의미하고 ELF가 윈도우의 PE처럼 리눅스에서 실행 파일 구조를 의미한다.
후기
오늘은 사실 글을 쓰기 전에 후기를 먼저 썼습니다. 이번주는 특히 게시글 수가 줄어들게 되었는데, 아무래도 해킹 관련 기법들을 배우다보니 쓸 수가 없을 것 같습니다...ㅎㅎ 그래서 개인적으로 정리해놓고 이 게시글을 마지막으로 취약점 진단 부분은 마무리하려고 합니다. 게시글이 줄어드니까 뭔가 개운해진 느낌도 있네요.😆