1. 서론

진단 환경 구성을 말씀드려 보려고 합니다..

가장 먼저 시작하고 갔어야 하는 부분이었는데 지금에야 생각나서 올립니다.

환경 구성은 따로 없습니다만 각각의 툴들을 연결하기 편하고 더 빠르게 진단하기 위해서 준비해 놓는다면 부드럽게 진단하실 수 있을 것입니다.

 

저의 경우에는 쓰는 빈도가 많은 툴은 있지만 대부분 비슷하게 많이 쓰는 것 같습니다.

 

2. 필요 도구 및 프로그램

NOX(단말기 구성도 가능하지만 SSL Pinning과 같은 부분은 에뮬레이터가 편함),

ADB, 파이썬 2.7 버전, Astro(저는 이게 좋았습니다.),

APK easy tool (물론 dex2jar같은 툴들도 존재합니다.),

notepad++(smali파일 분석 시 가독성이 좋습니다.),

frida, frida-server, fridump

(도구 사용 방법은 순차적으로 글을 써서 올려드리겠습니다.)

 

3. 디바이스 구성 방법

Nox는 처음 설치하면 Android 5.1.1 버전의 가상 환경으로 만들어져 있습니다. Multi-drive를 이용해서 다수의 가상 환경을 만드는 것도 가능하며 Android 7 버전까지 만들 수 있습니다.

 

 

위 사진에서 많이 쓰게 될 부분은 root 켜기입니다. Android 진단에서 루팅이 된 단말기를 탐지하지 못하는 것은 많은 위협을 받을 수 있다는 말과 같습니다.

사용하는 부분은 루팅 우회를 시도할 경우 많이 쓰입니다.

 

 

최근의 어플은 서버와 통신을 통해 정보를 받아오는 경우가 많습니다.

이런 경우 IMEI와 번호가 설정되어 있지 않다면 접속할 수 없는 경우도 많습니다.

 

설명 링크: https://namu.wiki/w/IMEI

 

여기까지 구성을 하셨다면 환경설정을 들어가셔서 개발자 모드를 해제해주셔야 합니다.

 

빌드번호는 빠르게 연타 마구 눌러주시면 개발자 모드가 열렸다는 문구를 볼 수 있습니다.

 

 

 

위의 사진에 개발자 옵션이 열린 것이 보입니다.

 

개발자 옵션에서 USB 디버깅을 체크해 주시면 이제 설정 부분의 준비가 된 것입니다.

 

4. 윈도우 구성

윈도우 구성은 진단을 하기 위해 기본적은 환경설정을 해 놓아야 할 부분이 많습니다.

디바이스 연결 시 가장 많이 쓰이는 툴은 adb입니다. adb를 사용하기 위해 안드로이드 SDK를 설치해야 합니다. (adb 이외에도 많은 툴이 존재합니다.)

 

안드로이드 SDK는 현재 https://developer.android.com/studio에서 설치하실 수 있습니다.

또한 이를 사용하기 위해서는 JDK를 다운로드해야 하는데 https://library1008.tistory.com/19로 가시면 다운로드하는 방법이 자세하게 쓰여 있습니다.

 

이 툴을 설치했다면 이제 환경변수라는 것을 설정해주어야 합니다.

내 컴퓨터를 우 클릭하여 속성을 들어갑니다.

 

 

위와 같이 나오면 고급 시스템 설정을 들어간 후 환경설정으로 들어가 줍니다.

 

 

환경변수를 들어가면 위의 사진과 같이 뜨는데 아래의 목록에서 path를 찾아서 들어가면 됩니다.

 

 

 

위와 같이 떴다면 이제 환경변수를 새로 만들기로 추가해 줄 것인데 추가해줄 목록은 아래와 같습니다.

 

sdk : C:\Users\<윈도우 유저 명>\AppData\Local\Android\android-s\platform-tools;

Python : C:\Python27; C;\Python\Scripts;

 

자바는 path내에 추가해줄 부분과 path처럼 기본 환경변수로 새로 만들어 주어야 하는 것이 있습니다.

JAVA :  1) JAVA_HOME : C:\Program Files\Java\jdk-<버전>;

2) Path : %JAVA_HOME%\bin;

위와 같이 설정해 주시면서 JDK, Python2.7(3점대 버전이 깔려있으면 동작하지 않는 경우도 있음), Android SDK를 설치해줍니다.

 

이와 같이 다 설치해주시고 환경설정이 끝나셨다면 이제 제대로 깔렸는지 확인해 보면 됩니다.

 

crtl+r을 누르고 cmd창을 연 다음 adb, java -version을 넣어주면 제대로 설치된 것인지 확인이 가능합니다.

 

 

adb
java

위와 같이 뜬다면 잘 설치해준 것입니다.

 

나머지는 설치 링크를 알려주겠습니다.

간단한 설치 파일로 구성되어 있으므로 어렵지 않게 설치하실 수 있을 것입니다.

 

APK easy tool : https://forum.xda-developers.com/android/software-hacking/tool-apk-easy-tool-v1-02-windows-gui-t3333960

 

notepad++ :

https://notepad-plus-plus.org/downloads/v7.7.1/

 

Astro 어플 :

플레이 스토어에서 설치 가능

 

5. Frida

Frida의 경우 사용법도 다양하며 앞으로 여러 번 언급할 예정이기에 따로 글을 써서 설명할 예정입니다.

 

6. 후기

기본적인 환경 구성을 모르는 분들이 많은 관계로 이렇게 글을 올려봅니다.

누구든 처음 시작은 잘 모를 수 있지만 열심히 해서 보안 전문가가 됩시다!

1. 준비 도구

APK easy tool, astro 어플, ADB, 안드로이드 파일 관리자

 

2. 서론

일반적인 어플은 개발과정을 거치면서 개발자들의 부주의나 실수로 인해 testtest 하려 만들었던 activiti를 남겨놓는 경우가 많습니다.(개발자를 폄하하는 건 절대 아닙니다. 고생이 많은 것은 일하면서 많이 느낍니다.)

이런 경우 일반적으로 apk파일을 제공하지 않을 경우 추출하여 디컴파일을 거치면 드러나는 경우가 많습니다.(꼭 디컴파일하지 않고 찾는 방법도 존재)

 

3. 수행방법

우선 테스트하고자 하는 어플을 깔아 줍니다.(play store에 있다는 가정)

플레이 스토어의 어플을 astro어플을 이용하여 백업해주면 sdcard/backup 디렉터리에 apk파일이 남겨집니다.

 

이를 파일 관리자를 이용하여 mnt/shared/app 디렉터리에 옮겨줍니다.

그러면 윈도우의 C:\Users\<사용자 ID>\Nox_shared에 백업된 apk파일이 옮겨집니다.

 

만약 adb를 이용하여 앱을 추출한다면 adb pull을 이용하여 백업된 apk파일을 윈도우로 옮겨올 수 있습니다.

 

apk파일을 추출했다면 APK easy tool을 이용해 apk파일을 디컴파일 해줍니다. 여기에서 디컴파일을 하는 이유는 apk파일의 개발과정의 불필요한 파일을 찾아본 후 바로 smali파일 테스트를 하거나 manifest.xml파일 등을 점검하기 위해 바로 디컴파일 하는 것입니다.

또한 클래스 파일을 전부 점검하기 위해서는 디컴파일 하는 것을 추천합니다.

 

 

위와 같이 툴을 이용해 apk파일을 선택한 후 디컴파일 해줍니다. (APK easy tool사용법은 구글에도 많습니다.)

 

디컴파일이 완료되었다면 프로그램 하단의 Decompiled APK directory를 들어가면 디컴파일된 apk폴더를 확인할 수 있습니다.

 

이 폴더에 test와 같은 파일명을 검색해 주시면 됩니다.(다른 test삼아 썼을 것 같은 문구도 상관없습니다.)

여기까지 말씀드리면 이게 무슨 취약점 점검이야!!!!’ 하시는!!!!’ 분들이 가끔 계신데 물론 어려운 방법으로 뚫는 것도 중요하고 그런 방법을 많이 쓰지만 이렇게 쉽게 뚫리는 것이 더 위험한 법입니다.

 

무튼! 이렇게 찾아서 파일명에 test와 같이 시범 삼아 만든 activity가 있다면 지금부터는 이 activity가 실제로 작동하는가를 알아보는 것이 중요합니다.

activity의 동작 여부를 확인하는 것에 있어 명령어는 am명령어를 쓰면 쉽게 알아볼 수 있습니다.

그에 앞서 am 명령어 즉 activity manager에 대해 간단한 사용법을 설명하겠습니다.

 

1) 많이 쓰는 am 명령어

 

- am start -a android.intent.action.MAIN -n 패키지명/액티비티 경로명

 

- am startservice -n 패키지명/서비스경로명

 

- adb shell am broadcast -a "브로드캐스트명"

 

위의 명령어를 통해 서비스 확인과 activity 실행 및 broadcast 테스트도 진행할 수 있습니다.

 

am 명령어는 adb를 설치하여 사용하실 수 있습니다.

 

2) 액티비티 실행하는 방법

adb shell am start -a android.intent.action.MAIN -n 패키지명/액티비티 경로명

하지만 여기에서 중요한 것은 위의 명령어를 줄여 사용할 수도 있습니다.

adb shell am start -n 패키지명/액티비티 경로명

이렇게 사용할 수도 있습니다.

 

3) 서비스 실행하는 방법

adb shell am startservice -n 패키지명/서비스 경로명

 

4) broadcast 테스트하기

adb shell am broadcast -a "브로드캐스트명"

 

5) 점검

adb shell am start -n 패키지명/액티비티 경로명

위의 명령어를 사용하여 어플 에뮬레이터 혹은 단말기에서 액티비티를 하나씩 실행시켜보시면 됩니다.

 

점검 중 test 액티비티나 불필요한 액티비티를 찾아 실행할 수 있다면 그것은 취약점으로 간주됩니다.

 

이유는 불필요한 액티비티에 보안 적용을 하지 않은 생태에서 provider노출이나 그에 따른 불완전한 퍼미션 적용이 이루어진 상태라면 공격자에 의해 정보를 갈취당할 가능성이 존재하기 때문에 이는 취약점으로 간주될 수 있습니다.

 

하지만 보안 적용을 모두 한 상태에서라도 저런 불필요한 페이지를 굳이 남겨놓을 필요는 없을 것입니다.

결론 : 파일 이름 잘 바꾸면 우회가 가능하다!

1. 환경

어플 에뮬레이터 프로그램을 이용하여 rooting환경을 구성하고 어플이 이를 탐지하는가 안 하는가를 점검해 보겠습니다.

이번 들은 로컬 파일 변경 즉, SU파일 변경을 통한 우회를 알려드릴 생각입니다.

 

우선 단말기 혹은 에뮬레이터의 환경을 루팅 하는 것이 중요합니다.

기본적인 안드로이드 루팅은 녹스 에뮬레이터는 환경설정에서 변경이 가능하며 단말기는 루팅 어플(Kingroot, magisk, SuperSU 등등)을 이용하여 루팅하고 각각의 진단 환경을 구성해 줍니다.(안드로이드 루팅은 구글에 많습니다.)

 

단말기의 경우는 root explorer를 자주 사용하는 것으로 알고 있습니다.(굳이 언급한 어플이 아니더라도 파일 이름을 변경할 수 있는 어플은 정말 많습니다.)

 

2. 방법

이 방법은 정말 간단하지만 백신이 적용되어 있지 않거나 없는 경우에 가장 많이 발생하는 취약점입니다.

 

기본적인 SU파일은 루트 디렉터리의 system/bin과 system/xbin에 존재하며 비슷한 이름으로 감추어져 있는 경우도 있습니다.(system 디렉터리에 대부분 존재하므로 찾아보시면 발견하실 수 있습니다.)

 

우선 파일의 위치를 찾아가는 방법은 크게 두 가지로 말씀드릴 수 있습니다.

1) 안드로이드 파일 관리자

2) adb tool

 

1) 안드로이드 파일 관리자

파일 관리자는 루팅된 환경에서 권한은 높이는 작업이 필요하다.

대부분이 su파일의 이름을 바꿀 경우 rootroot 권한보다 높은 권한을 요구하지만 이는 권한을 허용해 주는 것으로 변경이 가능하다.

위의 그림의 su파일의 이름에 다른 문자를 붙이거나 이름을 변경하는 것 만으로 우회가 가능하다.

 

2) adb tool

adb의 커서 위치를 위에 말했던 system 디렉터리로 옮기고 rename을 통해 su파일의 이름을 변경해 주면 됩니다.

 

최근의 어플은 대부분 이 방법을 막아 두었지만 아직도 백신이 적용이 되어있지 않거나 백신이 없는 앱은 되는 경우가 많은 취약점이기도 합니다.

1) 선행

드로저를 사용하기 위해서는 선행되어 설치해야 할 프로그램들이 조금 있다.

ADB, Python27, JAVA가 있다.(설치법은 인터넷을 찾아보시길)

필요에 따라 에러 발생 시 PIP를 이용한 부수적인 설치가 필요하다.

 

2) 드로저 설치

https://labs.mwrinfosecurity.com/tools/drozer/ 접속 후

APKMSI를 다운로드한다

APK는 단말기에 설치해준다(APKAgent이다)

MSI는 그냥 깔아도 되지만

환경변수의 Path를 Python27 폴더로 지정하여 깔아준다.(Python3점대 버전이면 코드를 읽지 못하는 경우가 발생할 수도 있다(:COMMAND Error))

 

3) 드로저 연결

(NOX 환경)

우선 디바이스의 개발자 모드 변환과 USB 디버깅을 허용해주어야 한다.

물론 USB 디버깅 시에 일반 사용자 모드여도 괜찮지만 앱 테스트를 하기 위해서는 rooting을 한 Device를 사용하는 것을 추천한다.

adb devices

디바이스의 연결 여부를 확인할 수 있다.

만약 실제 단말기를 이용한다면 USB 디버깅 설정 시에 이 명령어로 디바이스 연결 여부를 확인할 수 있다.

adb connect 127.0.0.1:62001 (NOX환경)

녹스 환경의 기본적인 Device127.0.0.1:62001로 지정되어 있다.

연결이 되지 않는다면 뒤의 포트번호를 62025, 62026 등으로 변경해서 시도한다면 연결이 되는 것을 확인할 수 있다.

adb forward tcp:31415 tcp:31415

드로저 Agent를 디바이스에서 실행한 후 Embedded ServerON으로 설정하여 준다.

이는 포트를 포워딩함으로써 드로저의 동적 분석을 하기 위한 선행 작업이다.

drozer console connect

포트가 연결이 되었다면 이 명령어로 드로저를 실행시켜주어야 한다.

만약 저 명령어가 실행되지 않는다면 Python의 경로를 환경변수에 등록했는지 확인해보면 된다. (내 컴퓨터 우클릭 – 고급 시스템 설정 – 환경 변수 Path값에 Python27 Python27/Scripts 경로 추가)

이후 드로저 실행 시에 오류가 생길 수 있는데 이는 JAVA미설치, Python 미설치 혹은 3점대 버전 설치가 있으며 가장 많이 일어나는 오류로는 모듈이 설치되지 않은 경우가 대부분이다.

pip install protobuf

pip install pyOpenSSL

pip install twisted

pip install service_identity

위의 명령어를 사용하면 대부분의 문제점은 해결이 된다.

 

4) 패키지 확인

가장 먼저 분석할 앱의 package를 알아야 하는데 이는 드로저를 실행하여 확인할 수 있다

run app.package.list

위의 명령어를 사용하면 모든 package를 볼 수 있지만 분석하고자 하는 앱을 정확이 알고 있다며 더 쉽게 찾을 수 있는 방법이 있다.

run app.package.list -f <분석할 앱에 꼭 들어가는 간단한 단어>

<분석할 앱에 꼭 들어가는 단어> <------ 이 부분을 알고 있는 단어로 고쳐주면 된다.

: run app.package.list -f insecure

이렇게 쓸 경우 insecure가 들어간 package는 모두 찾는 것이다.

 

5) 앱의 퍼미션 확인 및 간단한 정보 수집

run app.package.info -a <package>

이 명령어로 앱의 process이름, 디렉터리, APK경로, UID, GID, 공유 폴더 및 공유 ID, 사용 중인 퍼미션 등을 알 수 있습니다.

run app.package.manifest <package>

이 명령어를 이용하여 앱의 manifest파일을 읽는 것도 가능하다.

위의 정보를 이용하여 앱의 설정 정보를 알 수 있습니다.

 

6) attacksurface확인

run app.package.attacksurface (package)

위의 명령어를 통해 앱의 activity exported, broadcast receivers exported, content providers exported, services exported의 액티비티를 확인할 수 있습니다.

상황에 따라 명령어의 결과 값 하단에 is debuggable이 포함되어 출력될 수도 있습니다.

is debuggable에 포함되어 출력되는 경우 개발 앱이 아닌 릴리즈 버전이라면 큰 취약점이 될 수 있다. 앱의 코드에 임의의 코드를 주입하여 실행시킬 수 있으며 코드를 변조한 공격에 취약할 수 있다.

 

7) 액티비티 확인 및 점검

run app.activity.info -a <package>

attacksurfaceactivity exported에 포함된 액티비티를 점검하기 위해 액티비티 경로 및 간단한 정보를 알아보는 과정이다.

run app.activity.start --component <package> <activity>

activity의 알아낸 정보를 통해 실행 가능한 activity를 실행시켜 불필요한 activity의 존재 여부나 취약한 부분을 점검한다.

 

8) broadcast확인

run app.broadcast.info -u -f <package>

attacksurface를 통해 알아낸 broadcast의 수를 알아내고 그 리시버를 테스트한다.

(체크하는 부분이나 취약한 부분은 하는 사람이 알아냄에 따라 다르다. 설정 사항이나 소스 및 리시버의 사용 형태에 따라 새롭게 나뉠 수 있다.)

 

9) Provider확인

앱이 사용하는 정보 혹은 DB를 공유하기 위해 사용하는 부분이다. 전체가 아니라 일부분의 정보만을 공유하고자 사용한다.

run app.provider.info -u -a <package>

위의 명령어를 활용해 현재 어플의 provider를 확인하고 노출된 provider의 존재 여부를 확인할 수 있다.

예로 contentprovider가 노출이 되었다면 이건 알아볼 가치가 충분한 경우이다.

 

지금부터는 가정을 전제하여 설명을 이어가도록 하겠습니다.

만약 취약한 provider 혹은 의심이 가는 provider의 존재를 확인했을 경우에는 URI정보를 확인해 봄으로써 DB정보를 공부하는 방식을 알아볼 필요가 있다.

 

run app.provider.finduri <package>

위의 명령어로 활용 중인 URI의 정보가 나오면 이 정보를 통해 packageprovider부분을 점검해 볼 수 있다.

 

run scanner.provider.sqltables --uri <URI 한 줄 전체 삽입>

: run scanner.provider.sqltables --uri content://com.android.insecurebankv2.TrackUserContentProvider

위의 명령어를 입력하면 provider와 관련된 테이블 정보를 보여줍니다.

 

run scanner.provider.sqltables -a <package>

모든 URI에 대해 감색하고 싶다면 위의 방법을 쓰는 것도 좋습니다.

 

10) SQL Injection 분석

먼저 분석하기에 앞서 Query의 사용 방법을 확인할 수 있습니다.

run app.provider.query -h

마지막의 -h--help라 써도 무방하며 이 방법으로 Query의 사용방법을 알 수 있습니다.

dz> run app.provider.query -h

usage: run app.provider.query [-h] [--projection [columns [columns ...]]]

[--selection conditions] [--selection-args [arg [arg ...]]]

[--order by_column] [--vertical]

uri

 

Query a content provider

 

Examples:

Querying the settings content provider:

 

dz> run app.provider.query content://settings/secure

 

| _id | name | value |

| 5 | assisted_gps_enabled | 1 |

| 9 | wifi_networks_available_notification_on | 1 |

| 10 | sys_storage_full_threshold_bytes | 2097152 |

| ... | ... | ... |

 

Querying, with a WHERE clause in the SELECT statement:

 

dz> run app.provider.query content://settings/secure

--selection "_id=?"

--selection-args 10

 

| _id | name | value |

| 10 | sys_storage_full_threshold_bytes | 2097152 |

 

Last Modified: 2012-11-06

Credit: MWR InfoSecurity (@mwrlabs)

License: BSD (3 clause)

 

positional arguments:

uri the content provider uri to query

 

optional arguments:

-h, --help

--projection [columns [columns ...]]

the columns to SELECT from the database, as in "SELECT <projection> FROM ..."

--selection conditions

the conditions to apply to the query, as in "WHERE <conditions>"

--selection-args [arg [arg ...]]

any parameters to replace '?' in --selection

--order by_column the column to order results by

--vertical

읽는 것이 귀찮으실지도 모르지만 읽어두면 도움이 되는 부분이라서 전부 옮겨 두었습니다.

 

11) URI를 활용한 자동 Query분석

run app.provider.query <URI 한 줄 전체 삽입>

URI의 테이블을 확인하는 것에 좋은 명령어입니다.

 

"--selection", "--protection"들의 옵션을 이용하여 master table을 확인할 수 있습니다.

run app.provider.query <URI 한 줄 전체 삽입> --projection "* from sqlite_master where type='table';--"

위의 명령어는 master table을 조회하는 명령어이지만 query를 변경하여 세세한 점검을 진행할 수 있습니다.

 

12) Query분석을 하는 가장 쉬운 방법

앞의 분석은 세세하게 하나하나 살펴볼 수 있다는 장점이 있지만 굉장히 귀찮은 것도 사실이다.

또한 분석이 너무 느리다면 그것도 문제가 될 수 있다고 생각한다.(하나에만 매달려 있을 순 없지 않나요?)

 

run scanner.provider.injection -a <package>

빠르게 분석할 때 굉장히 좋은 방법이다. 취약한 URI Injection 가능한 공격 방법도 자동 분류해준다.

하지만 이 방법을 쓰기 전에 위의 방법을 하나하나 익혀서 기본적인 분석 방법을 익히고 흐름을 익힌다면 상황이 바뀌더라도 적을 하거나 분석하는 것에 수월함이 있을 것입니다.

 

13) Service확인

run app.service.info -u -f <package>

service에 관한 정보를 확인할 수 있습니다. permission을 확인할 수 있습니다. 또한 hidden service를 확인할 수 있습니다.

 

14) 디버깅 가능 앱 분석

run app.package.debuggable -f <package>

디버깅이 가능한 앱은 간단한 디컴파일을 통하거나 디버깅을 통해서 중요 데이터를 노출할 수 있다.

 

15) 모듈 분석

mudule search

module search <단어>

module search <단어> -d exploit

위의 명령어를 통해 단어가 포함된 모듈을 찾을 수 있으며 아래의 명령어로 그에 해당하는 exploit을 찾을 수 있습니다. 만약 해당하는 exploit이 존재하여 다운을 받고 싶다면 module install <module명>으로 다운로드할 수 있습니다.

 

 

+ Recent posts