- 『 Team Assignment 』 -

과 목 명: SW보안개론 [1분반]담 당 교 수: 조 성제학 과: 소프트웨어학과학 번: 32157296, 32167055, 32167102, 32167400이 름: 송 찬용, 김 수인, 김 남수, 유 근하제 출 일: 2019. 05. 13. ( 월 )

- 2 -

목차

Ⅰ.동작 방식 분석 ····················································································· 3 1.정상 앱 동작 방식 분석-1 ··················································································· 3 2.악성 앱 동작 방식 분석-1 ··················································································· 7 3.악성 앱 동작 방식 분석-2 ··················································································· 9 4.악성 앱 동작 방식 분석-3 ················································································· 12

Ⅱ.정상/악성 판단 기준 ········································································ 14 1.Permission ·········································································································· 14 2.인증서 해시 ·········································································································· 15

Ⅲ.악성 앱 분석 자동화 프로그램 ······················································· 16 1.알고리즘 개요 ······································································································ 16 2.알고리즘 설명 ······································································································ 16

Ⅳ.실험 결과 및 분석 ············································································· 19

Ⅴ.논의 ······································································································ 20

- 3 -

Ⅰ.앱 동작 방식 분석 Windows 환경에서 제공받은 Dataset과 APK 분석 도구인 jadx를 사용하여 정적 분석을 수 행하였다. 앱 동작 방식 분석을 위한 자세한 환경은 다음과 같다.

안드로이드에 설치 가능한 형태인 APK파일을 분석하기 위해서는 가장 먼저 APK 디컴파일 도구인 jadx를 사용해 디컴파일 후, Androidmaifest.xml 파일을 열어보아야 한다. Androidmanifest.xml 파일은 다음과 같은 역할을 한다. - 앱에 대한 Java 패키지의 이름을 지정하여 고유한 식별자 역할 - 액티비티, 서비스, 브로드캐스트 수신자, 콘텐츠 제공자 등 앱을 이루는 구성 요소 설정 - 앱 구성 요소를 호스팅하는 프로세스 결정 - 앱이 API의 보호된 영역에 액세스하거나 다른 앱의 구성 요소와 상호작용을 위한 권한 선언 - 앱이 작동하기 위한 안드로이드 API의 최소 레벨 선언 - 앱이 링크되는 라이브러리 나열

Androidmanifest.xml에서 얻은 정보를 이용해 소스코드를 따라가며 안드로이드의 4대 컴포 넌트인 액티비티, 서비스, 브로드캐스트 수신자, 콘텐츠 제공자 등을 위주로 분석해 나간다. - 액티비티 : 앱을 구성하는 화면을 구현 - 서비스 : 백그라운드에서 실행되는 프로세스 - 브로드캐스트 수신자 : 전달된 브로드캐스팅 메시지를 수신 - 콘텐츠 제공자 : 제공하고자 설정한 공유 범위 내에서 네트워크, 데이터베이스, 파일시스템을 제공

1.정상 앱 동작 방식 분석-1

CPU Intel i5-9600K @ 3.70GHz

RAM 32GB

OS Windows 10 x64

Analytical method Static analysis

Dataset100 benign apps from F-Droid /

100 malicious apps from AndroZoo

Tool jadx-gui-0.9.0

APK app.varlorg.unote_15.apk

위험 권한 요청READ_EXTERNAL_STORAGE

WRITE_EXTERNAL_STORAGE

악성 행위 여부 X

- 4 -

Androidmanifest.xml을 열어 확인한다. 인텐트 필터의 action.MAIN과 category.LAUNC- HER 옵션이 있는 “app.varlorg.unote.NoteMain” 액티비티가 가장 먼저 실행됨을 알 수 있다. 또한 외부 저장소에 읽기/쓰기를 허용하는 권한인 READ/WRITE_EXTERNAL_STORAGE 권한을 요청함을 확인할 수 있는데, 이 둘은 안드로이드 개발자 홈페이지에 명시된 위험한 권한이다.

“app.varlorg.unote.NoteMain” 액티비티의 첫 실행부분인 onCreate 메소드다. SharedPreferences 방식을 사용하여 기존 앱을 view 해준다. getString(), getBoolean(), findViewById()로 각각의 this 변수들에 킷값을 대응하여 데이터를 저장을 하고 ArrayAdapter에 넣어 보여준다. 그 후 EditText를 생성하여 이 객체의 정보를 넣고 각종 상황별 title, message, button을 설정하여 error 메시지창을 띄운다. 이후 정상적인 작동이 된다고 판단하면 Intent(NoteMain.this, NoteEdition.class); 명령으로 NoteEdition의 액티비티를 실행한다. 이외에 onCreateContextMenu()로 위젯연결, onCreateOptionsMenu()는 최초에 메뉴키가 눌렸을 때 호출, onOptionsItemSelected()로 메뉴 아이템이 클릭되었을 때 호출,

- 5 -

onResume, onPause()는 액티비티 활성화를 제어하고, 종료 quit(), thread를 search() 하는 메소드를 가지고 있다.

NoteEdition 액티비티는 onCreate에서 View객체를 찾아 변수에 (EditText)로 저장하고 이것을 text View로 따로 저장한다. 만약 intent가 NULL이면 위의 intent 관련 변수를 기정값으로 text View에 text를 놓는다. 이후 EditText 변수에 TextChangedListener(TextWatcher watcher)로 EditText의 이벤트를 받아오며 afterTextChanged(), beforeTextChanged(), onTextChanged() 들로 사용자의 입력을 받을 수 있게 한다. 이외에 종료하는 quit(), 해당 EditText를 저장하는 save() 메소드를 가지고 있다.

- 6 -

Preference 이름그대로 Preference 액티비티이며 onCreate() 메소드는 Preference관련 addPreferencesFromResource(), findPreference(), onPreferenceClick()를 사용하는 구조이다. 이외에 뒤로가기 버튼을 눌렀을 경우 처리하는 onBackPressed()도 가지고 있다.

RestoreDbActivity는 restore관련 액티비티다. registerForContextMenu()로 ContextMenu 를 어느 위젯(View) 에 연결시킬지 세팅하고 AlertDialog.Builder로 객체를 생성하고 이 객체의 메소드들을 호출해서 속성을 지정하고 생성한다. 이 객체안에 인자들을 부여하고 onClick()메소드로 dialog를 cancel한다. 이외에 Dialog를 생성하는 onCreateDialog(), Context Menu 생성하는 onCreateContextMenu(), Context Menu 클릭시 수행할 내용 구현할 onContext- ItemSelected(), List 클릭하는 onListItemClick() 메소드 등이 있다.

storage를 다루는 액티비티는 RestoreDbActivity이며 해당 액티비티 안에 있는 a()메소드에서 앱에 제공되는 외장 디렉토리 파일들의 정보를 가져온다. getExternalStorageState() 메소드도

- 7 -

첫번째 외장 스토리지 패스의 상태를 돌려주며, 해당 storage를 저장하되 경로를 따라 정보를 추출하여 다른 경로로 저장하거나 전송하는 코드는 발견되지 않았으므로 악성으로 판단하기에 충분하지 않다.

해당 APK를 Virustotal에 업로드해 확인하였다. 61개의 백신이 모두 정상으로 분류했다.

2.악성 앱 동작 방식 분석-1

Androidmanifest.xml을 열어 확인하였다. 인텐트 필터의 action.MAIN과category.LAUNCH- ER 옵션이 있는 “com.android.root.main” 액티비티가 가장 먼저 실행됨을 알 수 있다.

APK 2d486501dcf635a5ca58bb82d3dd3539329a276d.apk

위험 권한 요청 READ_PHONE_STATE

악성 행위 여부 O

- 8 -

또한 스마트폰의 상태를 읽는 권한인 READ_PHONE_STATE 권한을 요청함을 확인할 수 있는데, 이는 안드로이드 개발자 홈페이지에 명시된 위험한 권한이다.

“com.android.root.main” 액티비티의 시작과 함께 onCreate 메소드가 실행, Setting 서비스를 시작시킨다.

getApplicationContext 메소드를 이용해 현재 프로세스의 context를 추출하여 ctx에 저장한다. crypt 메소드는 비트 연산을 통해 암호화 하는 기능을 갖는다. u 배열에는 개발자가 정의한 데이터가 담겨있는데, cyrpt 메소드를 거치면 특정 Url이 생성되는 구조다. adbRoot.crypt(c)를 이용해 Url주소를 생성하고, Url과 ctx를 파라미터로 주어 postUrl 메소드를 호출한다.

- 9 -

getIMEI, getIMSI 메소드를 사용해 스마트폰의 중요한 정보인 IMEI, IMSI를 추출한다. 이후 In/OutpuStream을 생성하여 통신하는 전형적인 소켓 프로그래밍이다. 추출한 IMEI, IMSI를 함호화 후 Url로 전송하므로 악성 앱으로 판단하기 충분하다.

해당 APK를 Virustotal에 업로드해 확인하였다. 59개 백신 중 45개, 약 76%가 악성 앱으로 분류했다.

3.악성 앱 동작 방식 분석-2

APK 03f9fc8769422f66c59922319bffad46d0ceea94.apk

위험 권한 요청

SEND_SMS

RECEIVE_SMS

ACCESS_COARSE_LOCATION

ACCESS_FINE_LOCATION

READ_PHONE_STATE

WRITE_EXTERNAL_STORAGE

악성 행위 여부 O

- 10 -

Androidmanifest.xml을 열어 확인한다. 인텐트 필터의 action.MAIN과 category.LAUNCHER 옵션이 있는 “com.sms.bg.ui.FakeLauncherActivity” 액티비티가 가장 먼저 실행됨을 알 수 있다. 또한 SMS를 송신/수신하는 권한인 SEND/RECEIVE_SMS와 스마트폰의 상태를 읽어오는 권한인 READ_PHONE_STATE, 위치 정보를 받아오는 ACCESS_FINE/COARSE_LOCATION, 외부 저장소에 쓰기 권한을 부여하는 WRITE_EXTERNAL_STORAGE 권한을 요청함을 확인할 수 있는데, 이들은 안드로이드 개발자 홈페이지에 명시된 위험한 권한이다.

FakeLauncherActivity의 onCreate 메소드가 호출되면 getInstance 메소드를 통해 SettingManager의 인스턴스를 생성한다.

setSMSTempBlockNumAndTimes 메소드가 전달받은 파라미터로 num은 SMS를 차단할 번

- 11 -

호, count는 메시지 차단 횟수를 나타낸다.

SMS가 수신될 때 마다 PrivilegedSmsReceiver 클래스의 onReceive 메소드에 의해 처리되고, 이 클래스는 트로이 목마에 의해 SMS 수신기로 등록된다. 결과적으로 사용자가 아닌 다른 사람이 사용자의 메시지 정보를 볼 수 있게 된다. 따라서 악성 앱으로 판단하기에 충분하다.

해당 APK파일을 Virustotal에 업로드해 확인하였다. 60개 백신 중 37개, 약 62%의 백신이 악

- 12 -

성 앱으로 분류하였다.

4.악성 앱 동작 방식 분석-3

Androidmanifest.xml을 열어 확인한다. 인텐트 필터의 action.MAIN 옵션이 있는 “.SMSReplicatorSecret” 액티비티가 가장 먼저 실행됨을 알 수 있다. 또한 SMS를 송신/수신하는 권한인 SEND/RECEIVE_SMS와 연락처 정보를 읽어오는 READ_CONTACTS 권한을 요청함을 확인할 수 있는데, 이 셋은 안드로이드 개발자 홈페이지에 명시된 위험한 권한이다.

APK 005d5f6e94321de473d62706a94fbecf67c9f5f3.apk

위험 권한 요청SEND_SMS

RECEIVE_SMS

악성 행위 여부 O

- 13 -

SMSReceiver class에서 데이터를 CONTENT_FILTER_URI 필터링을 하여 연락처 정보를 가져온다.

SMSReplicatorSecret 에 onClick 부분을 보면 shadyDB의 객체가 생성하여, 사용자가 입력한 phone_no, activate, ui_pass과 같은 중요정보를 sdb로 update하므로 악성 앱으로 판단했다.

해당 APK를 Virustotal에 업로드해 확인하였다. 62개 중 38개, 약 61%의 백신이 악성으로 분류했다.

- 14 -

Ⅱ.정상/악성 판단 기준 1.Permission 정상/악성을 구분하기 위한 가장 근본적인 접근 방식이다. 안드로이드 개발자 홈페이지의 시스템 권한 항목을 보면, 안드로이드의 보안 아키텍처는 기본적으로 앱이 다른 앱, 운영 체제 또는 사용자에게 악영향을 미칠 수 있는 작업을 수행할 권한이 없다는 것을 바탕으 로 디자인되어 있다. 안드로이드 앱은 각각 하나의 프로세스 샌드박스에서 작업하기 때문 에 사용하는 자원 및 데이터를 명시적으로 공유해야 한다. 그러므로 앱은 기본 샌드박스에 서 제공하지 않는 추가 기능에 대해 필요한 권한이 필요하다. 악성 행위는 사용자의 개인 정보나 디바이스의 시스템 정보와 같이 민감한 정보에 접근하여 사용자 혹은 시스템에 영 향을 주는 것이므로, 악성 앱은 민감한 정보에 접근하기 위하여 그에 대응하는 권 한을 요청한다. 따라서 본 과제에서는 안드로이드 개발자 홈페이지에 명시되어 있는 위험 한 권한 목록을 참고하였다. 제공받은 데이터셋의 악성 앱 대부분이 민감한 정보를 인터 넷, 외부 저장소에 쓰기, SMS 전송하는 행위를 한다는 사실을 중점으로 하여 INTERNET, WRITE_EXTERNAL_STORAGE, SEND_SMS 권한을 요청한 경우에 다른 위험 권한을 추 가로 요청하는지 여부를 판단 기준으로 삼았다. 아래 그림은 안드로이드 개발자 홈페이지 에서 명시하는 위험한 권한 목록이다.

- 15 -

2.인증서 해시 APK의 장점이자 단점은 누구나 쉽게 디컴파일하여 분석이 가능하며, 개인이 원하는 기능 을 추가하거나 삭제한 후 다시 컴파일하여 사용하는 리패키징이 가능하다는 점이다. 만약 해커가 악성 행위를 목적으로 정상 앱에 악성 행위를 하는 기능을 추가하여 배포하기 쉽 다는 것이다. 이를 방지하기 위하여 모든 APK파일은 인증서로 서명되어야 하며, 앱의 작 성자를 식별하는 데 사용된다. 인증서의 개인 키는 개발자가 가지고 있다. 개발자 인증서 는 언패킹 과정에서 추출할 수 없게 되어있으므로 리패키징 시 인증서로 서명해야 한다. 시스템은 인증서를 이용해 앱에 서명 레벨 권한에 대한 액세스를 부여하거나 거부할 수 있으며, 다른 앱과 동일한 ID를 부여해달라는 앱의 요청을 수락하거나 거부할 수 있다. 인증서의 확인은 APK의 무결성을 보장하므로, 악성 앱 인증서의 해시값을 DB에 저장해 두어 분석하고자 하는 APK의 인증서 해시값을 비교하여 악성 앱을 탐지할 수 있다. 실제 안랩에서도 사용하고 있는 악성 앱 탐지 기법 중 하나이다. 그러나 인증서에 다시 서명하 는 리사이닝을 통해 인증서 변경이 손쉽게 가능하며, 이미 데이터셋이 정해져 있는 본 과 제의 취지와는 맞지 않는다고 판단해 인증서 기반 탐지기법은 구현하지 않았다. 아래는 APK 인증서 정보가 APK마다 서로 다름을 보여준다.

- 16 -

Ⅲ.악성 앱 분석 자동화 프로그램 1.알고리즘 개요 제공받은 데이터셋의 악성 앱 대부분이 민감한 정보를 인터넷, 외부 저장소에 쓰기, SMS 전송하는 행위를 한다는 사실을 중점으로 하여 INTERNET, WRITE_EXTERNAL_ STORAGE, SEND_SMS 권한을 요청한 경우에 다른 위험 권한을 추가로 요청하는지 여부 를 판단한다. 위 3가지 권한 외에도 다른 위험 권한을 2가지 이상 요청할 경우 악성으로 분류하여 정상과 악성 APK의 이름 및 요청 권한을 각각의 csv 파일로 저장하는 알고리즘 이다.

2.알고리즘 설명

doDetection 메소드에서 파일 디스크립터를 이용해 정상과 악성 APK의 이름 및 권한을 저장할 csv파일을 생성하고, DetectionManager 클래스 인스턴스의 doSaveAll 메소드를 호출하며 전달한다.

- 17 -

DetectionManager 클래스에 위험 권한 목록을 입력해 두었다. self.Permission_dangerous_1리스트에는 WRITE_EXTERNAL_STORAGE, INTERNET, SEND_SMS 권한을, dangerous_2 리스트에는 위 3가지를 제외한 나머지 위험 권한을 입력했다.

DetectionManager 클래스의 doSaveAll 메소드이다. APK에서 요청한 권한을 중복 제거 후 저장해 둔 self.Permission_final 리스트를 순회하며 패키지 이름을 떼어내고 권한 이름만을 tmp_lst에 저장한다. 그 뒤, 인터넷, 외부 저장소 쓰기, SMS전송 권한이 담긴 dangerous_1 리스트와 tmp_lst를 교집합 메소드를 호출하여 temp_p에 저장한다. 이때, temp_p에는 현재 분석 중인 APK의 요청 권한 중 dangerous_1과 교집합인 권한만이 담겨있으며 다음과 같은 3가지 경우의 수를 거쳐 분류한다.

1) temp_p가 빈 리스트일 경우

- 18 -

: 데이터를 외부로 쓰거나 전송하지 않으므로 정상으로 판단한다. APK이름과 요청 권한 목록을 benign_res.csv에 저장하고 파일 디스크립터를 닫는다.

2) temp_p가 빈 리스트가 아니고 다른 위험 권한 요청의 개수가 2개 미만일 경우 : tmp_lst와 dangerous_2 리스트의 교집합을 구해 temp_p 리스트에 저장한다. len 메소드를 통해 temp_p 리스트의 원소 수를 구하고, 0으로 선언되어 있던 count에 원소 수를 더한다. count가 2 미만이라면 정상으로 판단하여 APK 이름과 요청 권한 목록을 benign_res.csv에 저장하고 파일 디스크립터를 닫는다.

3) temp_p가 빈 리스트가 아니고 다른 위험 권한 요청의 개수가 2개 이상일 경우 : tmp_lst와 dangerous_2 리스트의 교집합을 구해 temp_p 리스트에 저장한다. len 메소드를 통해 temp_p 리스트의 원소 수를 구하고, 0으로 선언되어 있던 count에 원소 수를 더한다. count가 2 이상이라면, 디바이스의 정보나 데이터, 위치, 연락처 등을 외부로 전송할 가능성 이 있으므로 악성으로 판단하여 APK 이름과 요청 권한 목록을 mal_res.csv에 저장하고 파일 디스크립터를 닫는다.

- 19 -

Ⅳ.실험 결과 및 분석 정상과 악성 앱 각각 100개씩에 대하여 실험하였으며, 다음과 같은 결과를 얻었다.

1) 정상 앱 100개에 대하여 : 100개 중 87개를 정상 앱으로, 12개를 악성 앱으로 분류하였다.

파일 중 하나는 “File is not a zip file” 이라는 에러메시지와 함께 디컴파일되지 않아 분 류할 수 없었다.

2) 악성 앱 100개에 대하여 : 100개 중 30개를 정상 앱으로, 70개를 악성 앱으로 분류하였다.

정상을 정상으로 분류 87개(좌) 정상을 악성으로 분류 12개(우)

악성을 정상으로 분류 30개(좌) 악성을 악성으로 분류 12개(우)

- 20 -

Ⅴ.논의 과제에서는 권한만을 이용하여 간단한 형태의 백신을 구현하였지만, APK의 구조와 동작 원리 및 악성 앱 탐지 기법들에 대하여 공부할 수 있는 좋은 기회였다. 실제로 적용 가능한 악성 앱 탐지 기법들은 고려할 사항이 매우 많고 애매해서 높은 탐지율을 보이는 것이 힘들 것이라는 생각이 든다. 판단 기준을 세우는 것이 가장 힘들었으며, 안드로이드에 대하여 무지하였음은 물론이고 자바 언어에 익숙하지 않았던 어려움도 있었다.

Confusion Matrix True False

Positive87

(True Positives)

30

(False Negatives)

Negative12

(False Positives)

70

(True Negatives)