#3 취약점 항목별 상세 실습 part 2. - 안드로이드 모바일 앱 모의해킹

3.11. 안전하지 않은 로깅 메커니즘

3.11.1. 취약점 소개

-

안드로이드의 커널 공간 안에 있는 로거(Logger)라는 커널 드라이브는 main, radio, event, system 이라는 네 가지 종류의 버퍼를 관리하고 있다.

또한 사용자 공간에 있는 앱들은 보안 정책에 의해 커널의 버퍼에 접근할 수 없기 때문에 “/dev” 디렉터리에 리눅스 디바이스 노드들을 제공하여 앱이 로그를 읽고 쓸 수 있도록 하고 있다.

-

각 버퍼에 저장되는 내용은 아래와 같다.

Main : 메인 앱 로그로서 앱이나 플랫폼 내부에서 android.util.Log 클래스로 기록된 로그

Event : 시스템에서 발생하는 이벤트 정보를 위한 로그

Radio : 이동통신망과 관련된 이벤트 로그

System : 안드로이드 플랫폼 내부의 하위 레벨에 있는 시스템이나 디버깅을 위한 로그

-

Liblog 라는 네이티브 라이브러리에서 디바이스 노드를 읽고 쓸 수 있도록 API 를 제공하고 있다.

C 로 작성된 네이티브 앱 혹은 라이브러리에서 제공된다.

앱들은 로그 시스템에 직접 접근하지 못하고 android.util.Log, android.util.EventLog, android.util.Slog 클래스들을 통해 사용할 수 있으며, 내부적으로는 liblog 를 사용한다.

* ADB 를 통한 로그 확인

-

logcat [option] [filter]

-c : 모든 로그를 지운 후 종료

-d : 지정된 로그를 화면에 덤프하고 종료

-f fileName : 로그를 지정한 파일 이름으로 저장하고, 파일 이름을 지정하지 않을 경우 표준 출력

-g : 로그 버퍼의 크기를 출력하고 종료

-b bufferName : main/radio/event 버퍼 중 원하는 것을 선택

-r kbytes : 지정한 용량 만큼의 로그 파일을 생성, 기본값은 16kb. -f 와 함께 쓰임

-s : 기본 필터 조건을 silent 등급으로 지정

-v format : 사용자가 출력할 로그의 포맷을 지정 ( format : breif, process, lag, thread, raw, time ,threadtime, long )

-

ex)

logcat -b main -b system -v threadtime -d *:v

* DDMS 를 통한 로그 확인

3.11.2. 취약점 진단 과정

3.11.3. 취약점 대응 방안

3.12. 안드로이드 키보드 캐시 이슈

3.12.1. 취약점 소개

-

키보드 캐시 이슈는 사용자가 중요 정보를 클립보드에 저장하면 제삼자가 이러한 정보를 획득할 수 있는 취약점이다.

이 기능은 사용자에게 상당히 많은 편의를 제공하지만, 별도의 제삼자 또한 이 기능을 이용하여 사용자가 복사한 내용을 불러올 수 있다.

3.12.2. 취약점 진단 과정

3.12.3. 취약점 대응 방안

-

중요 정보는 마스킹 처리를 통해 사용자가 복사하지 못하도록 하거나 사용자가 복사할 수 없도록 조치해야 한다.

사용자가 복사할 수 없도록 조치하는 방법은 EditText 뷰의 값을 복사, 붙여넣기 할 수 없도록 android:editable 속성에 false 값을 입력하여 사용자가 수정 및 복사할 수 없도록 하는 것이다.

3.13. 앱 디버깅 기능

3.13.1. 취약점 소개

-

Debuggable 취약점은 안드로이드 디버깅 모드의 설정 여부에 따라 발생한다.

AndroidManifest 의 속성이다.

기본적으로 디버깅 모드는 앱이 제작되는 과정에서 주로 사용된다.

완성된 앱을 배포할 떄는 기본적으로 false 로 지정되어 있어 디버깅이 불가능하도록 설정되지만, 개발자들이 개발 중에 편의상 디버깅 옵션을 true 로 지정하여 테스트에 이용한다.

3.13.2. 취약점 진단 과정

3.13.3. 취약점 대응 방안

3.14. 안드로이드 복사/붙여넣기 취약점

3.14.1. 취약점 소개

-

안드로이드 붙여넣기 보드 취약점(Android pasteboard vulnerability)은 사용자가 개인 정보나 중요한 정보를 복사할 때 클립보드에 저장된 임시 정보를 별도의 권한 없이 허가되지 않은 사용자가 확인할 수 있기 때문에 발생하는 취약점이다.

3.14.2. 취약점 진단 과정

3.14.3. 취약점 대응 방안

-

클립보드에 대한 보안은 보안 솔루션을 이용해 대응할 수 있는데, 클립보드에 존재하는 데이터를 제한된 시간 동안만 유지하도록 설정하고, 설정한 시간이 지나면 삭제하도록 하는 것이 일반적인 대응 방법이다.

3.15. 안드로이드 백업 취약점

3.15.1. 취약점 소개

-

안드로이드 시스템에서는 기본적으로 설치된 앱의 데이터를 백업하고 복구하는 메커니즘을 제공한다.

안드로이드 백업 시스템은 안드로이드 버전 2.2에서부터 공개되었지만, 처음에는 클라우드를 통한 백업만 제공했다.

클라우드 백업의 경우, 구글 클라우드에 사용자 데이터와 앱 데이터를 저장했다가 사용자가 시스템 공장 초기화나 새로운 안드로이드 시스템 변경하는 등의 복구가 필요한 시점에 다시 동기화하여 기존 데이터를 복구해준다.

이후 ICS 버전으로 업데이트 되면서 백업 데이터를 사용자 PC 에 저장할 수 있게 해주는 로컬 백업을 지원하게 되었다.

사용자는 전체 백업을 통해 설치된 앱의 APK 파일 뿐만 아니라 관련 데이터, 저장소의 파일 등을 USB 를 통해 연결된 PC 에 저장할 수 있다.

-

안드로이드 백업 과정 중 클라우드 백업은 안드로이드 시스템에서 동기화 주기를 설정함으로써 자동으로 앱 데이터나 설정 등을 구글 클라우드와 동기화하도록 설정한다. 이때 사용자는 직접 데이터를 관리하지 않지만 구글 클라우드에서 비교적 안전하게 관리해주기 때문에 외부에 쉽게 유출될 위험이 적다는 장점이 있다.

반면, 전체 백업의 경우에는 안드로이드 장치를 PC와 연결하여 수동으로 백업 과정을 진행하며, 클라우드 백업과 마찬가지로 앱 데이터를 저장할 수 있다. 이 경우 사용자가 데이터를 관리할 수는 있지만, 저장된 파일이 유출될 가능성도 있으므로 보안상 취약할 수 있다.

3.15.2. 취약점 진단 과정

-

기본적으로 전체 백업은 manifest 의 allowBackup 속성을 따른다.

값이 아예 설정되어 있지 않거나 false 로 되어 있는 경우, 패키지의 데이터가 추출되지 않으며, true 일 경우에만 백업이 가능하다.

-

adb backup 명령을 사용하여 백업을 할 수 있다.

> adb backup pkgName -f fileName

이 명령을 수행하면 BackupManagerService 에 의해 전체 백업 액티비티를 실행한다.

-

백업 파일은 압축된 형식의 tar 파일로 백업 정보를 담은 매니페스트 파일과 백업 데이터가 포함된다.

파일 자체는 deflate 알고리즘으로 압축되어 있어 일반적인 압축 해제 방법으로는 해제가 불가능하다.

이를 해제하는 데에는 zlib 범용 압축 lib 을 사용하는 방법이 있다.

OpenSSL 에 포함된 zlib 명령으로 압축을 해제할 수 있고, ABE (Android Backup Extractor)라는 프로그램을 통해서도 가능하다.

> java -jar abe.jar unpack backupFileName newFileName

* 취약점 확인

-

안드로이드 시스템은 보안을 위해 각 앱이 각각의 샌드박스에서 실행되도록 독립성을 보장한다.

이를 허용하지 않는 한 앱의 파일에 다른 앱이 접근하지 못한다.

그러나 백업 기능을 이용하면 루팅되어 있지 않더라도 특정 앱의 데이터나 저장소에 저장된 파일까지 접근이 가능하다.

사용자가 시스템을 잠가 놓지 않았거나 암호가 유출된 경우, 사용자 정보가 유출될 위험이 있다.

-

원래 시스템에 변조된 파일을 포함하여 복원시키기 위해 백업했던 형태 대로 파일을 다시 변환한다.

이 과정을 추출 과정의 역순으로, 가장 먼저 tar 아카이브 파일을 생성한다.

> tar -c -v -f newFileName -no-dirslash list=extractedListFileName

다음 복원 파일로 다시 압축한다. (deflate 압축)

> java -jar abe-all.jar pack tarFileName newFileName

이후 restore 명령으로 복구시킨다.

> adb restore backupFileName

3.15.3. 취약점 대응 방안

-

allowBackup 속성을 false 로 하거나, allowBackup 항목을 삭제한다.

3.16. 런타임 조작

3.16.1. 취약점 소개

-

debuggable 일 때 앱이 실행되는 도중 메모리상에 악의적인 행동을 하는 취약점이 있다.

3.16.2. 취약점 진단 과정

-

jdb 에 사용할 디버깅 포트를 찾기 위해서는 다음과 같은 명령어를 사용한다

> adb jdwp

위의 명령어를 사용하면 사용하고 있는 포트 정보가 나타난다.

포트들을 디버깅할 수 있도록 체크되어 있는 앱들이 표시된다.

앱을 실행하기 전과 후의 port # 차이를 통해 특정 앱의 port # 를 찾아낼 수 있다.

-

> adb forard tcp:11111 jdwp:portNumber

> jdb -connect com.sun.jdi.SocketAttch:hostname=localhost, port=11111

-

jdb 명령어는 다음과 같다.

next : 다음 라인 실행

local : 현재 로컬 영역 변수 보기

threads : 현재 실행 중인 스레드 확인

methods : 해당 클래스가 사용하는 모든 메서드 출력

stop in : 특정 메서드에 브레이크 포인트 설정

print : 특정 변수의 값 출력

eval : 자바 코드를 실행시킴.

run : 현재 브레이크 포인트 무시하고 실행

-

ex)

stop in pkgName.className.functionName // 함수에 breakpoint 걸기

print this.username // 변수 값 출력

set this.username = “gamza” // 변수에 값 할당

3.16.3. 취약점 대응 방안

-

debuggble 을 false 로 만든다.

3.17. 안전하지 않은 SD 카드 저장소

3.17.1. 취약점 소개

-

Insecure SDCard storage 는 앱이 SD 카드 저장소에 중요한 정보나 파일을 저장하여 발생하는 취약점이다.

안드로이드는 데이터를 저장할 때 크게 내부 저장소(Internal storage)와 외부 저장소(External Storage)로 나눌 수 있다.

-

내부 저장소는 안드로이드 플랫폼, 시스템 등에서 사용되는 공간으로, 안드로이드 API 에 의해 권한이 통제된다.

반면, 외부 저장소는 앱 간 데이터 공유가 가능하고, WRITE_EXTERNAL_STORAGE 권한을 갖고 있는 앱은 설정에 따라 데이터를 읽고 쓰는 것이 가능하다.

-

외부 저장소는 일반적으로 SD 카드를 말한다.

외부 저장소는 앱 간의 데이터 공유가 가능하며, 저장되는 파일들은 어디서든 읽고 쓰기가 가능하다.

외부 저장소는 데이터를 저장할 때 앱 고유 영역과 공용 영역으로 나누어진다.

공용 영역의 경우 사진, 비디오 등의 파일을 저장할 때 사용하고, 삭제 시 앱에 영향을 받지 않는다.

내부 저장소는 안드로이드 플랫폼, 시스템 도구, 앱 그리고 앱에서 사용하는 데이터가 저장되는 공간이다.

안드로이드 보안 모델에 따라 보호받는 공간으로, 각 앱은 자신의 패키지 이름과 일치하는 디렉터리를 생성하여 해당 디렉터리 안의 파일을 읽고 쓸 수 있다.

이 영역에 저장된 데이터는 앱이 삭제될 때 함께 삭제된다.

-

/system/app/appName.apk : 시스템 앱들의 공간. 최적화된 dex 코드는 .odex 로 저장된다. 세이프 모드로 부팅될 경우 이 파일 디렉터리에 있는 앱들만 실행된다.

/data/app/appName.apk : 미리 등록되는 사용자 앱들의 공간. 최적화된 dex 코드는 data/dalvik-cache/appName.odex 에 저장된다.

/data/app/pkgName-1.apk : 사용자가 다운로드한 앱들의 공간. 최적화된 dex 코드는 data/dalvik-cache/data@app@pkgName-1.apk@classes.dex 로 저장된다.

/mnt/secure/asex/pkgName-1.asec : SD 카드에 숨어 있는 앱들의 공간. 최적화된 dex 코드는 /data/dalvik-cache.nbt@asex@pkgName-1@pkg.apk@classes.dex 로 저장된다.

3.17.2. 취약점 진단 과정

-

외부 저장소에는 어떤 정보이든 서비스에 중요한 역할을 하는 정보를 저장해서는 안된다.

내부 저장소에 저장이 되더라도 암호화되어 안전하게 저장되어야 한다.

3.17.3. 취약점 대응 방안

-

내부 저장소에 데이터를 저장할 때는 setStorageEncryption API 를 이용해 내부 저장소에 저장되는 파일을 강제로 암호화 할 수 있다.

-

SD 카드에 저장할 때는 javax.crypto lib 을 사용해 암호화할 수 있으며, AES 와 같은 대칭키 암호화 알고리즘을 이용해 암호화한다.

-

중요한 정보를 저장할 때는 하드코딩된 암호화 또는 암호화키에 의존하지 않는다.

-

SharedPreferences 를 사용할 때는 모드 설정에 유의해야 한다.

MODE_PRIVATE 이 가장 안전하다.

-

중요한 정보는 경우에 따라 운영체제에서 제공하는 기본 암호화 메커니즘 이상의 암호화 메커니즘을 고려한다.

3.18. 안전하지 않은 HTTP 통신

3.18.1. 취약점 소개

-

HTTP 를 이용한 데이터 전송은 Insufficient Transport Layer Protection 에 해당하는 취약점으로, 데이터 통신 시 중요 정보를 평문으로 전송할 때 발생한다.

3.18.2. 취약점 진단 과정

3.18.3. 취약점 대응 방안

-

SSL/TLS 암호화를 적용한다.

적절한 키 길이와 산업 표준 암호화 방식을 사용하며, 민감한 데이터를 전송할 때는 최소한 128비트 이상의 키를 이용해야 한다.

암호 알고리즘은 DES 와 같은 취약한 알고리즘을 사용해서는 안 되며, AES 와 같은 안전성이 검증된 알고리즘을 선택해야 한다.

3.19. 인자 전달값 조작

3.19.1. 취약점 소개

-

Parameter Manipulation 은 파라미터 조작 취약점이다.

안드로이드 앱에서 요청하는 값을 중간에서 가로챈 후 매개변수값을 변조하여 전송한다.

이 행위를 통해 본래의 요청값이 변조된 값으로 수정되고, 민감한 정보가 포함된 요청이라면 정보 유출의 위험이 존재한다.

이 취약점은 웹에서도 자주 발생한다.

3.19.2. 취약점 진단 과정

-

CSRF (Cross Site Scripting Request Forgery) 가 요청되는 값을 변조하여 보내는 공격 기법이다.

3.19.3. 취약점 대응 방안

-

이 취약점이 발생하는 이유는 서버에서 입력값에 대한 검증을 하지 않기 때문에 잘 발생한다.

또한 파라미터에 대한 암호화 과정 없어 공격자가 매우 다양한 취약점 테스트를 할 수 있다.

-

파라미터 조작은 개발 단계에서 가장 막기 힘든 취약점 중 하나다.

개발자들이 자주 착각하는 쿠키값이나 환경 변수 등의 입력값은 얼마든지 클라이언트에서 조작할 수 있으므로 소프트웨어를 개발할 때 모든 입력값에 대한 검증을 수행하는 것이 안전하다.

가장 먼저 모든 입력값에 대한 유효성 검증을 서버에서 수행해야 하며, 상태 정보나 민감한 데이터, 특히 사용자의 세션 정보와 같은 중요한 정보는 반드시 서버에서 검증해야 한다.

3.20. 하드코딩 보안

3.20.1. 취약점 소개

3.20.2. 취약점 진단 과정

3.20.3. 취약점 대응 방안

-

소프트웨어 개발 과정이라 하더라도 개발자용 테스트 계정을 주석으로 처리하는 것은 위험한 습관이다.

개발 완료 후 일일이 코드 주석을 제거한다는 것은 매우 어렵기 때문에 주석 처리에 주의를 기울여야 한다.

또한 암호화키의 경우, 절대 상수로 명시하면 안 되며, 솔트를 사용하여 암호화의 안정성을 높이는 것이 중요하다.

솔트를 사용할 경우 예측하기 어려운 난수를 사용해야 하며, 고정된 값이나 특정한 값을 재사용해서도 안 된다.

3.21. 사용자 정보 목록화 이슈

3.21.1. 취약점 소개

-

사용자 계정 목록화란, 시스템의 어떠한 인증 체계에 취약점이 존재하여 공격자가 시스템에 존재하는 사용자 계정 목록을 획득할 수 있는 취약점을 말한다.

사용자 계정은 로그인 시 잘못된 인증 시도를 하더라도 계정의 존재 여부가 알려지는 것은 위험하다.

만약 공격자가 무차별 대입 공격과 같은 유형의 공격을 시도할 경우, 로그인을 하지 않더라도 시스템에 존재하는 계정들을 파악할 수 있다.

3.21.2. 취약점 진단 과정

3.21.3. 취약점 대응 방안

-

공격자가 로그인 시도 시 에러 메시지를 통해 계정 정보를 유추할 수 없도록 에러 메시지를 변환해야 한다.

-

자동화 도구를 통한 공격을 방지하기 위해 로그인 시도 속도와 로그인 시도 횟수를 제한하는 것이 안전하다.

반복적인 로그인 시도는 계정 잠금 기능을 이용해 대응하는 것도 좋다.

또한 자동화 도구를 방지하기 위해 CAPTCHA 프로그램을 이용하는 것도 안전한 대응책 중 하나다.

-

실시간 탐지 솔루션을 이용하여 로그인 시도를 모니터링하고, 비정상적인 로그인 시도를 탐지할 수도 있다.

3.22. 개발자 백도어

3.22.1. 취약점 소개

-

백도어란, 정상적인 프로그램에 자신만이 들어갈 수 있는 코드를 삽입해 정당한 인증 과정을 거치지 않고 접속할 수 있는 통로를 만드는 방법이다.

개발자들이 유지보수나 디버깅 시 인증 및 셋업 시간 등을 단축하기 위한 요소로 만들 때도 있지만, 일부 개발자는 인증을 회피할 목적으로 만들기도 한다.

3.22.2. 취약점 진단 과정

3.22.3. 취약점 대응 방안

-

관련 코드를 제거한다.

3.23. 취약한 패스워드 변경 실행

3.23.1. 취약점 소개

-

취약한 패스워드 변경 실행(Weak change password implementation)은 패스워드 변경 과정에서 발생하며, 개발자의 실수로 불필요한 로그를 남겨 패스워드를 노출하는 취약점이다.

3.23.2. 취약점 진단 과정

3.23.3. 취약점 대응 방안

-

입력단부터 서버까지 전 통신 구간을 암호화하여 전송해야 한다.

패스워드를 암호화하지 않은 텍스트 형태로 저장하는 것은 인증 우회가 가능하므로 주의해야 한다.

로그 파일에 패스워드를 평문으로 저장하면 로그 파일에 접근할 수 있는 사람 모두가 패스워드를 알아낼 수 있다.

패스워드는 높은 수준의 암호화 알고리즘을 사용하여 관리되어야 하며, 쉽게 접근할 수 없는 저장소나 암호화된 상태로 저장해야 한다.

3.24. 마무리하며