이전 게시물과 이어지는 내용입니다!
[Insecure Bank] 설치방법&환경셋팅 부터 취약점 진단까지 모아보기! (Part 1)
> 우선 Insecure Bank 를 설치하기 위해선 3가지가 필요합니다.Nox 앱플레이어Miniconda (python2 사용을 위해)Insecure APK (Github 에서 다운로드)만약 Nox 앱플레이어가 설치 안되어있으시면 아래 링크로 이
jamesbexter.tistory.com
애플리케이션 패칭 취약점
['애플리케이션 패칭' 취약점 이란?]
> 현재 배포되고 있는 안드로이드 모바일 악성코드들은 정상적으로 서비스되고 있는 앱을 조작하여 사용자들을 유인합니다. 아이콘만 다른 앱에서 가져온 후 간단한 기능만 포함해 배포하는 사례도 있고, 공격자들도 앱을 처음부터 개발하는 것이 아닌 개발된 앱에다가 사용자의 개인정보를 빼내는 코드를 삽입후 재배포 하는 경우가 많습니다. 이런 행위를 위해 기존의 앱을 변질시켜서 피해자가 변질된 앱을 기존앱으로 착각하게끔 사용하는 공격이 '애플리케이션 패칭' 취약점 입니다!
1. 취약점 탐색
1. 앱을 디컴파일링 하여 살펴보시면 소스코드가 난독화 없이 그대로 노출되는 것을 보실 수 있습니다. 이러면 앱의 흐름을 따라가기 쉬울뿐더러 공격자가 원하는 조작을 위해 어느 부분을 수정해야하는지 파악하기 쉽기때문에 이 점을 취약점 포인트로 잡을 수 있습니다!
2. 그러면 앱의 코드를 수정후 리패키징 하여 Rooted Device!! 라는 문자를 Mooner Flag!! 라는 문자로 바꿔보겠습니다.
2. 공격과정
1. 우선 해당 링크를 통해 앱의 디컴파일링 파일을 추출 하는 APK Tool 과 추출된 파일을 서명하기 위한 방법이 나와있으니 해당 내용을 참고하셔서 따라오시면 됩니다!
https://ejxousiva.tistory.com/30
APK 디컴파일 & 리패키징(APK Tool)
이번에는 디컴파일 후 파일을 수정하고 리패키징까지 할 수 있는 방법을 사용해보려고 한다. 이 방법은 smali 라는 어셈블리 파일을 수정해야 하기에 조금 어려울 수 있고, 이를 통해 수정한 APK를
ejxousiva.tistory.com
2. 우선 해당링크에서 다운받은 apktool.bat 파일과 apktool.jar 파일을 Windows 폴더에 넣어주었습니다. 이러면 cmd창에서 어느 디렉토리에 있더라도 해당 기능들을 쓸 수 있기 때문에 넣어준 것입니다.(원래는 이 파일들이 있는 디렉토리로 직접 이동해야만 사용가능하지만 Windows 폴더에 넣으면 그럴 필요가 없음!)
3. 이후 위에 링크 내용대로 서명키를 생성하게 되면 이와같이 keystore 라는 파일이 생성이 되게 됩니다. 저는 repak 이라는 폴더에 InsecureBankv2.apk(원본파일) 를 넣어주고 keystore 파일을 만들어주었습니다. 이렇게 셋팅하면 리패키징을 할 준비가 완료되었습니다!
4. 해당 명령어를 통해 앱을 디컴파일 추출할 수 있습니다!
> apktool d InsecureBankv2.apk -o EditsecureBank
(InsecureBankv2.apk 앱을 디컴파일링 하여 추출한 파일을 현재 디렉토리에 EditscureBank 라는 이름의 폴더에 저장한다)
| 명령어 실행 후 | 디컴파일된 추출 파일 확인 |
 |
 |
5. EditsecureBank 폴더를 들어가보시면 저희가 Jadx로 봤던 소스코드 파일들이 그대로 들어있는 것을 확인하실 수 있습니다. 리패키징에서 수정하는 코드는 smail 을 통해 수정을 해야합니다. smail 폴더로 들어가보죠!
Smali 이란? (Jadx로 Smali 코드 살펴보기)
인시큐어 뱅크앱을 통해 앱 모의해킹을 공부하다가 Smali 코드란 것을 변경하여 기존의 앱의 코드를 수정한 후 앱을 재설치 하는 "리패키징" 이란 과정을 거치는 것을 여럿 보았습니다. 그래서 Sma
jamesbexter.tistory.com
6. smail > com > android > insecurebankv2 경로로 이동하셔서 PostLogin.smail 파일을 메모장으로 열어주세요!
7. 메모장 검색 기능으로 Smail 파일에서 저희가 수정해야할 "Rooted Device!!" 부분을 찾았습니다! 이 부분을 Mooner Flag!! 로 바꿔주겠습니다.
8. 해당 명령어를 통해 수정된 디컴파일 폴더를 다시 apk 파일로 변환시켜줍니다. (리패키징)
> apktool b [리패키징 할 폴더명] -o [리패키징 후 만들어질 어플명]
9. 다시 폴더로 돌아가보시면 리패키징된 EditsecureBank.apk 파일을 확인하실 수 있습니다.
10. 리패키징을 하게되면 원래있던 서명이 사라지게 됩니다. 이 서명은 앱을 다운로드하는데 있어서 필수적인데 Insecure bank 앱을 다운로드 받을때 따로 요구되는 서명은 없기 때문에 저희가 임의로 서명key를 만들어서 서명을 해도 다운로드가 가능해집니다. 실제로 아래 사진에서 왼쪽은 원본파일이고 오른쪽이 리패키징한 파일인데 META-INF 라는 서명키가 적힌 파일이 리패키징한 파일엔 없는것을 확인하실 수 있습니다!
실제로 서명을 안하면 아래와 같이 녹스에 설치하려 해도 어플설치 실패라고 뜹니다!
| 드래그 앤 드롭으로 리패키징 어플 설치 시도 | 어플설치 실패 문구 확인 |
 |
 |
11. 초반에 링크에서 만들어 두었던 keystore 파일을 여기서 쓰게 됩니다. 해당 명령어를 통해서 EditsecureBank.apk 파일에 서명을 해줍니다. (좀 복잡해 보이는 것 같아도 막상 해보면 그리 복잡한게 아니니 두려워 말고 해보세요...)
> jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1 -keystore [mooner.keystore] -storepass [keystore 비밀번호] -keypass [keystore 비밀번호] (리패키징할 apk).apk [alias 옵션에 적었던 keytore 별칭]
아래와 같은 문구가 뜨면 서명 성공!
12. 서명을 완료하니 Nox에 드래그 앤 드롭으로 다운로드가 가능해진 것을 확인하실 수 있습니다!!
13. EditsecureBank로 들어와 다시 로그인을 하면 저희가 수정한 문구인 "Mooner Flag!!"를 확인할 수 있습니다!
3. 대응방안
1. 소스코드 난독화
> 난독화 기술을 클래스 , 메서드 , 필드 등의 이름을 악의적인 목적으로 사용하는 것을 방지하고 , 분석을 어렵게 하기 위해 사용합니다. 안드로이드 스튜디오에서는 기본적으로 앱 난독화 도구인 프로가드를 제공합니다!
- 안드로이드 스튜디오에서 Gradle Scripts > build.gradle 파일에 buildTypes 클래스에다가 minifyEnabled="true" 설정을 해주시면 난독화를 적용할 수 있게됩니다!
- 프로가드는 오픈소스이기 때문에 당연히 상용 솔루션에 비해선 일부 기능이 제한되어 있습니다...하지만 무료입니다!.
보안을 더 강화하기 원한다면 덱스가드 라는 상용 솔루션을 통해 한층 더 복잡한 난독화 기능을 사용할 수 있습니다.
2. 무결성 검증
> 앱이 원본파일에서 수정이 되었나 안되었나를 판단하는 무결성 검증과정을 추가해야합니다. 검증방식으로는 CRC(Cyclic Redundancy Check) 체크섬 검증, 개발자 사이닝 키(Developer Sinning Key) Hash 값 검증, 리소스 파일 검증 등이 있습니다. 무결성 검증도 솔루션이 있으니 이런 도구들을 적절히 사용하여 자사의 앱을 보호해야 합니다!
메모리 내 민감한 정보 저장
['메모리 내 민감한 정보 저장' 이란?]
> 메모리는 주 기억 장치라고도 하며 물리적 메모리인 '램(RAM)'을 가리킵니다. 애플리케이션이 실행 중에 필요한 정보들이 여기에 저장기 때문에, 저희가 입력하는 모든 값과 앱의 모든 정보들이 메모리에 적재됩니다. 계속 적재되어 있는것은 아니고 메모리는 휘발성 이기 때문에 앱 종료시 RAM에 저장된 데이터들도 삭제됩니다! 문제는 이 데이터를 삭제전에 추출하기만 한다면 저희가 입력한 값들이 저장되어 있기때문에 보안에 매우 위험할 수 있다는 것입니다!
"메모리 포렌식" 을 통해 획득 가능한 정보
| 분류 | 설명 |
| 프로세스 , 스레드 정보 | 프로그램이나 파일이 실행 중이거나 이미 종료되었지만 메모리에 남아 있는 정보 추출 |
| 모듈, 라이브러리 정보 | 프로그램이나 파일이 실행 중이거나 이미 종료된 프로세스 관련 모듈 라이브러리 정보 추출 |
| 실행된 파일과 소켓 정보 | 실행 중이거나 이미 종료된 파일에 대한 정보와 네트워크 연결을 위해 사용되었거나 사용 중인 소켓 정보 추출 |
| 다양한 데이터 구조 | 메모리에만 존재하는 운영체제, 소프트웨어 및 파일과 관련된 다양한 데이터의 구조 정보 추출 |
1. 취약점 진단
1. 우선 Insecurebank 어플에 접속한 후 로그인을 해줍니다.
2. 그리고 계좌송금 서비스를 이용해 전송을 합니다. 이제 어플을 종료하지 않는 이상 메모리에는 저희가 로그인한 내역 , 송금한 내역이 남아있을 것 입니다.
3. 이후 메모리 덤프 파일을 얻기 위해서 cmd 로 와서 해당 명령어를 통해 인시큐어 뱅크 앱의 PID값을 알아냅니다.
(저의 경우엔 PID 값이 4704라고 뜨네요!)
> nox_adb shell (nox에 명령어창으로 접근)
> ps | grep inse ("inse"로 시작하는 패키지 명을 가진 현재 실행중인 어플의 정보를 출력한다)
4. 이후 해당 명령어를 통해 cmd창에서 nox기기의 sdcard/Download폴더에 메모리 덤프파일을 저장합니다.
> nox_adb shell am dumpheap [대상 어플의 PID값] [저장할 위치]
> exit (nox 창에서 나옴 , 다시 로컬 pc 명령어 창으로 돌아옴)
> nox_adb shell am dumpheap 4704 /sdcard/Download/insecurebankv2_mem
(덤프파일 추출후 NOX 기기내에 /sdcard/Download/insecurebankv2_mem 경로로 덤프파일 저장)
5. 이후 nox_adb shell 로 기기에 접속후 해당 경로로 가보면 메모리 덤프파일이 추출된 것을 확인하실 수 있습니다.
[ 참고로 sdcard 폴더는 사용자가 추가로 SD카드를 구매하여 확장할 수 있는 공간으로, 루팅을 안하더라도 기본적으로 쓰기 권한이 존재합니다! 그래서 이 경로로 메모리 파일 추출후 저장이 가능한 것!]
6. 덤프파일이 잘 저장된 것을 확인했으니 이제 로컬PC로 가져와 보겠습니다. 해당명령어를 통해 nox 기기 내부의 파일을 로컬PC로 가져올 수 있습니다.
> nox_adb pull [가져올 nox내부의 파일 경로] [가져온 파일을 저장할 로컬 PC경로]
> nox_adb pull /sdcard/Download/insecurebankv2_mem "D:\Insecure Bank"
7. 해당 경로로 이동해보면 메모리 덤프파일이 복사된 것을 확인하실 수 있습니다. 하지만 안드로이드 기기로부터 다운로드한 hprof 파일은 안드로이드에서 사용되는 달빅 머신 특유의 포맷으로 생성되기 때문에 분석할 수 있는 포맷으로 변환해줄 필요가 있습니다. 이를 위해서 안드로이드 SDK에 포함되어 있는 hprof-conv.exe 프로그램을 이용해서 포맷을 바꿔줘야 합니다!
8. hprof-conv.exe 파일은 로컬 PC에서 Appdata>local>Android>SDK>Platform-tools 에 hprof-conv.exe 존재합니다.
저의 경우엔 앱개발을 하기위해 Android Studio 를 설치했는데 거기에 hprof-conv.exe 파일이 있어서 그것을 사용해주었습니다!
9. hprof-conv.exe 가 있는 폴더로 오셔서 해당 명령어를 통해 포맷을 변경합니다.
> hprof-conv.exe [변환시킬 파일경로] [변환후 저장할 파일 경로와 이름]
> hprof-conv.exe "D:\Insecure Bank\insecurebankv2_mem" "D:\Insecure Bank\iNew_insecurebank2_mem"
10. 경로에 와보면 덤프파일이 변환 된 것을 확인하실수 있습니다! 이제 이 파일을 Hex_Editor로 분석해보겠습니다!
HxD - Freeware Hex Editor and Disk Editor | mh-nexus
HxD - Freeware Hex Editor and Disk Editor HxD is a carefully designed and fast hex editor which, additionally to raw disk editing and modifying of main memory (RAM), handles files of any size. The easy to use interface offers features such as searching and
mh-nexus.de
11. 포맷이 변환된 파일을 Hex_Editor로 열어서 검색창에 비밀번호 평문을 쳐보시면 보시는 바와 같이 로그인 했던 정보, 송금했던 정보가 평문으로 메모리에 저장되어 있는것을 확인하실 수 있습니다.
| Dinesh@123$ 이라는 비밀번호를 검색 | 메모리 덤프파일에 저장된 것을 확인 |
 |
 |
2. 대응방안
> 메모리 내에 모든정보를 암호화 하기는 어려운 문제가 있을뿐 더러 메모리에 데이터를 저장 안할수는 없기에 100% 안전한 방법은 없습니다.
금융권에서는 '스마트폰 보안 안전 대책 이행 실태 점검 체크리스트' 항목 중에 "스마트폰 앱과 금융회사 전자 금융 서버 간의 종단 간 암호화 적용 여부" 점검에서 좀 더 확장하여 "확장 E2E(End to End)를 권고하고 있습니다.
이는 키보드로 입력하는 순간부터 암호화되어 최종적으로 체크하는 서버까지 암호가 되는 형태로 메모리 값을 가로채더라도 암호화 되어있기때문에 추가피해를 막을 수 있습니다.
안전하지 않은 로깅 메커니즘
['안전하지 않은 로깅 메커니즘' 이란?]
> 로그란, 서버에서 운영되는 서비스들이 실행되는 상태나 특정 프로그램을 사용한 사용자의 행위나 흔적을 파일이나 출력을 통해 남기는 행위를 말합니다. 그런데 이런 로그에 사용자의 개인정보 가령 비밀번호,아이디,계좌번호 등이 출력이 되버리면 정보가 유출될 수 있기 때문에 필요없는 로그정보는 남기지 말아야 합니다.
1. 취약점 진단
1. 우선 인시큐어 뱅크 어플을 로그인해줍니다.
2. 이후 nox_adb shell 로 녹스기기에 접근하셔서 해당 명령어를 통해 특정 어플의 log를 확인하실 수 있습니다. 사진을 보시면 로그인한 아이디&패스워드가 평문으로 저장되어 있는것을 확인하실 수 있습니다.
> nox_adb shell (녹스 기기에 접근)
> logcat -f [진단할 앱의 패키지명]
| 로그인 정보 로그저장 |
 |
3. 비밀번호 변경 기능에서도 이전 비밀번호와 바꾼 비밀번호의 평문이 로그에 저장되는 것을 확인하실 수 있습니다.
| 비밀번호 변경 | 변경 내역 로그저장 |
 |
 |
4. 계좌이체기능을 통해 송금후 로그를 확인해 보셔도 평문으로 저장된 것을 확인하실 수 있습니다.
| 계좌이체 기능 사용 | 송금내역 로그에 저장 |
 |
 |
5. Jadx로 인시큐어 뱅크앱을 디컴파일 해준후 소스코드 검색을 통해 "Log.d" 라는 문구를 검색하시면 사진 속 표시된 부분으로부터 로그에 로그인정보를 남기고 있다는 것을 확인할 수 있습니다.
6. Log.[옵션] 명령어 외에도 로그에 기록을 남기는 명령어로는 system.put.print 가 있습니다. 이 또한 마찬가지로 검색창에 써보시면 위에서 확인했던 송금내역을 출력하는 소스코드를 확인하실 수 있습니다!
2. 대응방안
> 이건 사실 개발 마무리 과정에서 개발중간에 쓰였던 Log 소스코드들의 점검이 미흡했기 때문에 발생한 일입니다. 그러니 Log.d 나 system.put.print 를 쓰는 경우를 웬만하면 다 지워주셔야 하고, 만약 꼭 필요하다면 중요한 정보는 평문으로 저장되는것이 아닌 암호화 처리를 하여 저장해야합니다!
안드로이드 키보드 캐시 이슈
['안드로이드 키보드 캐시 이슈' 란?]
> 키보드 캐시 이슈는 사용자가 중요 정보를 클립보드에 저장하면 제삼자가 이러한 정보를 획득할 수 있는 취약점입니다. 키보드 캐시란, 안드로이드 TextView와 같은 컴포넌트에서 사용자가 중요 정보를 클립보드에 복사할 수 있을때 임시로 복사한 데이터를 저장하는 곳입니다. 이 기능을 상당히 편하지만 , 공격자 또한 이 기능을 악용하여 중요 정보를 붙여넣을 수 있으므로 다른 사용자의 인증 정보를 활요하여 별다른 인증 절차 없이 공격자도 인증에 성공할 수 있습니다.
1. 취약점 진단
1. 우선 NOX기기에 Clipper 라는 어플을 다운로드 받아주세요. 그냥 구글스토어에서 받을 수 있으니 검색한 후 다운로드 받으시면 됩니다! 앱을 설치한 후 중요정보를 복사할 시 Clipper앱에서 보이는지 확인할 것입니다.
2.인시큐어 뱅크 어플에 로그인 해주시고 거래기능 액티비티에서 계좌번호를 복사해주세요.
| 인시큐어 뱅크 로그인 | 거래 기능에서 복사 |
 |
 |
3. Clipper 앱을 확인하시면 복사한 계좌번호 정보가 키보드 캐시에 저장된 것을 확인하실 수 있습니다. 계좌번호같은 민감한 개인정보는 복사하기 기능을 금지하여 키보드 캐시에 저장되는 일이 없게 만들어야 합니다.
2. 대응방안
1. android:editable = "false"
> 중요 정보는 마스킹 처리를 통해 사용자가 복사하지 못하도록 해야합니다. 조치하는 방법은 EditText 뷰의 적혀있는 값을 복사 붙여넣기 할수없도록 android:editable 속성에 "false" 값을 입력하는것입니다!
1.1. 디컴파일된 파일에서 res > layout > activity_do_transfer.xml 파일로 접근합니다.
1.2. 계좌번호를 적는 EditText 속성값에 android:editable="false" 속성을 부여합니다
<EditText
android:id="@+id/editText_from"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:layout_marginLeft="0dp"
android:layout_marginRight="20dp"
android:layout_weight="1"
android:editable="false" #추가해준 부분/>
디버깅 취약점 & 런타임 조작 취약점
['디버깅 취약점' 이란?]
> Application Debuggable 취약점은 안드로이드 디버깅 모드의 설정 여부에 따라 발생합니다. AndroidManifest.xml 에 포함되는 속성인데 기본적으로 디버깅 모드는 앱이 배포될때 "false" 로 지정되어 있습니다. 하지만 개발중에 편의상 디버깅 옵션을 "true"로 해놓는 경우가 있는데 이 경우 앱의 중대한 보안 결함이 발생할 수 있습니다.
['런타임 조작' 이란?]
> 앱이 실행되는 도중 메모리상에 악의적인 행동을 하는 취약점입니다. 메모리상에 올라가는 변수값이나 함수의 조작을 공격자가 원하는 값으로 바꾸어 동작흐름을 바꾸고 악의적인 동작을 할 수 있게 만드는 취약점입니다. 대표적으로 Frida 를 통한 방식이 있고 이번시간에는 자바에서 지원하는 jdb를 이용하여 디버깅하는 방법을 실습해보겠습니다!
1. 취약점 탐색
> 인시큐어 뱅크 어플을 Jadx로 디컴파일링 한뒤 AndroidManifest.xml 파일을 열어보시면 debuggable="true" 설정이 되어있는 것을 확인하실 수 있습니다. 디버깅 취약점이 발견이 되었으니 이 점을 이용하여 런타임 조작까지 이어보겠습니다!
2. 공격과정
2.1. 우선 런타임 조작을 위해선 메모리상에 함수나 값들이 올라가야하기 때문에 인시큐어 뱅크 앱을 실행합니다!
2.2. 이후 가상머신에서 인시큐어뱅크 앱을 사용하고 있는 포트정보 확인을 위하여 해당 명령어를 입력합니다. 현재 녹스에서 돌아가고 있는 어플은 인시큐어뱅크 앱 뿐이므로 4538이 인시큐어 뱅크가 사용하고 있는 포트번호가 됩니다.
> nox_adb jdwp
2.3. 이후 nox_adb 를 통해 디버깅 포트를 로컬 포트로 포트포워딩을 해준 후 , jdb 명령어를 통해 로컬 디버깅 포트로 연결할 것입니다. 포트포워딩을 위하여 아래의 명령어를 입력합니다.
> nox_adb forward tcp:11111 jdwp:4538
2.4. 그리고 jdb사용을 위해서 jdb가 있는 폴더로 이동합니다. 주로 C:\Program Files\Java\jdk-23\bin 경로에 존재합니다. 이동을 하셨으면 해당 명령어를 통해 nox와 포트포워딩 되어있는 로컬포트인 11111을 로컬 디버깅 포트로 연결해줍니다.
<JDB 명령어 표>
| 명령어 | 사용법 | 설명 |
| Next | >next | 다음 라인 실행 |
| Local | >local | 현재 로컬 영역 변수 보기 |
| threads | >threads | 현재 실행 중인 스레드 확인 |
| methods | >methods 클래스 명 | 해당 클래스가 사용하는 모든 메서드 출력 |
| stop in | >stop in 메서드 | 특정 메서드에 브레이크 포인트 설정 |
| >print 특정변수 | 특정 변수의 값 출력 | |
| eval | >eval 자바코드 | 자바코드를 실행시킴. |
| run | >run | 현재 브레이크 포인트 무시하고 실행 |
2.5. 이제 JDB를 사용해서 무단으로 비밀번호를 바꿔볼 것입니다. 우선 해당 명령어를 통해 ChangePassword 액티비티를 강제 실행해봅니다! 아래 표에서 보시다시피 정상적으로 실행하면 Username 값이 디폴트로 적혀있어야 하는데 강제 실행을 하게되면 Username 칸이 비게됩니다. 이를 JDB를 통하여 동적으로 dinesh라는 글자를 채워넣어주겠습니다.
> nox_adb shell am start -n com.android.insecurebankv2/.ChangePassword
| 강제실행 했을때 결과 | 정상실행 했을때 결과 |
 |
 |
2.6. ChangePassword 액티비티가 실행될때 Username 변수값을 dinesh로 바꾸면 되는것이니, 강제실행 하는 중간에 동작을 멈춘후 Username 값을 넣어주어야 합니다. 브레이크 포인트를 잡기 위해서 우선 Jadx에서 ChangePassword 액티비티의 Smali 코드를 확인해봅시다. 우선 액티비티를 시작하는 함수인 oncreate 함수를 찾아서 브레이크를 걸어보도록 하죠!
사진을 보시면 75번째 라인이 onCreate 가 시작하는 지점이라고 표시되어 있습니다!
2.7. 이제 아래 명령어를 통해 onCreate 부분에서 브레이크포인트를 걸어줍니다.
> stop in com.android.insecurebankv2.ChangePassword.onCreate
2.8. 이제 다시 액티비티를 강제 실행시키면 해당 문구가 뜨면서 중간에 브레이크가 걸린것을 확인하실 수 있습니다! 위에 Smali 코드에서 확인했듯이 75번째 라인을 가르키고 있습니다.
> nox_adb shell am start -n com.android.insecurebankv2/.ChangePassword (액티비티 강제실행)
2.9. Smail 코드를 다시 살펴보시면 uname 이라는 변수가 설정되는 라인은 85번째 라인이라는 것을 알 수 있습니다. 그러면 next 명령어를 써서 85번째 라인까지 진행해보도록 하겠습니다.
2.10. 86번째 라인까지 next 명령어를 통해 진행시켜 주었습니다. 왜냐하면 uname 이라는 변수가 선언이 되어야 메모리상에 올라간 뒤 변수값을 JDB를 통해 조작할 수 있기 때문입니다.
2.11. 현재 uname 값을 확인하는 명령어로는 "print this.전역 변수 이름" 를 사용하면 됩니다. 이제 해당 명령어를 통해 차례대로 uname 값이 조작하고 조작된 것을 확인하실 수 있습니다!
> print this.uname (현재 uname 이란 전역변수의 값 확인)
> set this.uname = "dinesh"(uname 변수값으로 dinesh 라는 문자열 넣어주기)
> print this.uname (변경된 uname 값 확인)
2.12. 이제 uname 값이 바뀐것도 확인했으니 run 명령어를 입력하여 중단했던 액티비티를 진행시켜줍니다.
2.13. 실행된 액티비티의 dinesh 라는 Username이 삽입된 것을 확인하실 수 있습니다. 이제 Password를 바꿔보겠습니다.
2.14. 성공적으로 패스워드가 바뀌었다는 문구를 확인하실 수 있습니다. 이를통해 디버깅 취약점을 통한 런타임 조작이 얼마나 위험한 공격으로 이어지는지 실습을 통해 확인해보았습니다!!
3. 대응방안
1. Android:debuggable="false" 설정
> 제가 이 공격을 시도하게된 궁극적인 포인트는 Android:debuggable="true" 설정이 되어있음에서 시작되었습니다. 그러니 이 설정을 false 로 바꿔서 동적 디버깅이 불가능하도록 만들어야 합니다.
2. 소스코드 난독화
> 소스코드 난독화를 코드의 적용하면 제가 Smali 코드를 손쉽게 따라가는 것을 방지할 수 있습니다. 즉 위의 실습처럼 흐름을 쉽게 파악하여 공격 포인트를 바로 잡아내지 못하게 됩니다.
이 동적디버깅을 완벽히 100% 막을수 있는 방법은 현재로서는 없습니다.. 따라서 심층 보안 개념을 적용해 공격자가 쉽게 공격하지 못하도록 겹겹이 보안을 적용하는 것이 바람직합니다!
안드로이드 백업 취약점
['안드로이드 백업 취약점' 이란?]
> 안드로이드 에선 백업 데이터를 사용자 PC에 저장할 수 있게 해주는 로컬백업을 지원하게 되었습니다. 이로인해 사용자는 전체 백업을 사용하여 설치된 어플의 apk 파일뿐만 아니라 관련 데이터,저장소의 파일 등을 USB를 통해 연결된 pc에 저장할 수 있게되었습니다. 하지만 android:allowBackup 속성 값이 'true'로 되어있을 경우 공격자 또한 백업데이터를 추출하는게 가능해지고 이 데이터를 분석하여 민감한 개인정보를 얻는것이 가능해집니다.
1. 취약점 탐색
> 인시큐어 뱅크를 디컴파일하여 AndroidManifest.xml 소스코드를 살펴보면 android:allowBackup="true" 설정값을 확인하실 수 있습니다. 백업이 가능한 것을 확인했으니 이 어플의 데이터를 백업해보겠습니다.
2. 공격과정
2.1 우선 adb를 사용하여 백업을 진행하겠습니다. 해당 명령어를 통해 insecurebankv2 앱의 데이터를 백업합니다. 명령어를 입력하면 백업 화면으로 이동하게 됩니다.
> nox_adb backup com.android.insecurebankv2 -f insecurebankv2.ab
2.2 비밀번호를 입력하여 백업을 진행할 수 있지만 지금은 실습상황이니 굳이 암호화는 하지않고 데이터 백업을 진행하겠습니다. 아래의 데이터 백업 버튼을 눌러주시면 됩니다!
2.3 백업이 완료되었다는 문구를 확인합니다. 이때 백업파일이 저장되는 위치는 adb 명령어를 실행시킨 경로에 설치가 됩니다.
2.4 무사히 설치가 된것을 확인하실 수 있습니다. 이제 이 백업파일을 압축 해제를 해야합니다. 근데 백업파일은 일반적인 압축 해제방법으로는 해제가 불가능하기때문에 ABE(Android Backup Extractor) 이라는 응용프로그램을 사용하여 압축을 해제하겠습니다. ABE 프로그램은 아래 링크에서 다운로드 받으실 수 있습니다.
https://sourceforge.net/projects/android-backup-processor/
android-backup-processor
Download android-backup-processor for free. Android adb backup extractor and packer. None
sourceforge.net
2.5 이제 제가 위에 달아놓은 링크에서 받은 폴더중 android-backup-tookit-20221220\android-backup-tookit\android-backup processor\executable 경로로 가보시면 abp.jar 파일이 있을것 입니다. 찾아보니깐 abe 라는 이름을 이제 abp 라고 바꿧다고 공식 사이트에 나와있었습니다. executable 폴더로 오셧으면 insecurebankv2.ab 파일을 폴더에 붙여넣기 해주세요.
2.6 이후 해당 명령어를 진행하시면 tar 파일로 압축이 변환되었을 것입니다. 이제 tar 명령을 이용하면 파일 추출이 가능합니다!
> java -jar abp.jar unpack insecurebankv2.ab insecurebank.tar
2.7 이제 명령어창에서 아래의 명령어를 입력하시면 tar 파일 내용을 추출하여 apps 라는 폴더에 저장합니다.
> tar -xvf insecurebank.tar
2.8 이제 apps\com.android.insecurebankv2\sp 경로로 와보시면 mySharedPreferences.xml 이라는 어플 고유의 저장 데이터가 들어있는 파일이 있을것입니다. 이 파일을 열어보도록 하겠습니다.
2.9 암호화 되어 있는 비밀번호와 아이디값을 찾았습니다. 이 값은 충분히 소스코드 분석을 통해 디코딩 할 수 있다는 것을 이전 게시글을 통해 확인하였습니다.
[Insecure Bank] 로컬 암호화 이슈 취약점
이번 포스팅에선 Insecure Bank 앱을 통한 '로컬 암호화 이슈' 취약점에 대하여 알아보겠습니다. [로컬 암호화 이슈 취약점 이란?]> 안드로이드 애플리케이션은 편의성을 위해 실행 도중에 저장해야
jamesbexter.tistory.com
3. 대응방안
1. android:allowBackup="false" 설정
> 제가 이 공격을 해봐야겠다 라고 보았던 포인트는 allowBackup 속성값이 true로 설정되어 있어서 였습니다. 이 속성을 false 로 바꿔주시면 백업에 의한 정보 추출을 방지하실 수 있습니다!
안전하지 않은 SD카드 저장소
['안전하지 않은 SD카드 저장소' 란?]
> 애플리케이션이 SD 카드 저장소에 중요한 정보나 파일을 저장하여 발생하는 취약점으로 "OWASP Mobile Top 10 M2: Insecure Data Storage"에 해당합니다. 안드로이드는 데이터를 저장할 때 크게 내부 저장소 , 외부저장소로 나눌수 있습니다. 내부 저장소에 파일을 저장하는 것까지는 문제가 없지만 파일 저장시 암호화를 제대로 안하게 되면 중요 정보가 누출될 수 있고, 외부 저장소에 중요 정보를 저장하게 되면 어느 어플이던지 외부 저장소에 접근이 가능하기 때문에 이 또한 민감한 정보가 유출될 수 있습니다.
- 내부 저장소
> 안드로이드 플랫폼, 시스템 등에서 사용되는 공간으로 안드로이드 API에 의해 권한이 통제됩니다. 쉽게말하자면 어플 마다 가지고있는 내부저장소 폴더가 있습니다.
- 외부 저장소
> 애플리케이션 간 데이터 공유가 가능하고 , WRITE_EXTERNAL_STORAGE 권한을 갖고 있는 애플리케이션은 설정에 따라 데이터를 읽고 쓰는 것이 가능합니다!
↓ 안드로이드 데이터를 저장하는 방법
| 항목 | 설명 |
| Shared Preferences | 원시 데이터를 저장하는 XML 파일, boolean , float , int , long , string 을 지원 |
| 내부 저장소 | 각 앱이 가지고 있는 고유 공간.디렉터리 명이 본인의 패키지 이름과 같음 |
| 외부 저장소 | 앱 간의 데이터 공유가 가능한 디렉토리, 어디서든 읽고 쓰기가 가능 |
| SQLite 데이터베이스 | 로컬 데이터베이스로 .DB 로 끝나는 팔일. /data/data"애플리케이션 패키지명"/databases경로에 생성됨. 실제 디바이스의 경우 보안상의 이유로 접근이 불가능하며 , 주로 서버와 통신하지 않는 간단한 앱을 만들때 사용 |
| Network Connection | 네트워크로 데이터를 저장하거나 불러오는 방법으로 , SQLite 데이터베이스와 간단한 텍스트 파일 등을 보낼 수 있음 |
1. 취약점 진단 과정
1.1 sdcard(외부저장소) 진단
1. 우선 adb를 사용하여 NOX기기에 명령어창을 접속을 합니다.
2. sdcard 디렉토리에 접근후 ls 명령어를 통해 파일들을 살펴보자 기본 설치파일 이외에 Statements_dinesh.html 이라는 낯선 파일이 보입니다. 이 파일을 열어보겠습니다.
3. 보아하니 이 파일은 송금 내역을 저장하는 파일인 것 같습니다. 해당 파일엔 제가 송금했던 내역과 xss 공격을 시도했던 흔적들이 그대로 남아있습니다. sdcard 디렉토리는 외부앱에서도 접근이 가능하기 때문에 이런 정보를 저장해서는 절대 안됩니다.
1.2 내부 저장소 진단
1. 인시큐어 뱅크의 패키지명인 디렉토리 경로로 접근해주세요. 해당 디렉토리 폴더는 다음과 같습니다.
** cache , code_cache , databases , files , no_backup , shared_prefs
> cd /data/data/com.android.insecurebankv2
2. SharedPreferences 파일 확인을 위해 shared_prefs 폴더로 이동했습니다. 보아하니 xml 파일 두개가 존재하는데 저는 mySharedPreferences.xml 파일이 열어보고 싶네요. cat 명령어로 살펴보겠습니다.
3. mySharedPreferences.xml 파일은 계정의 아이디와 비밀번호를 암호화하여 저장한 파일이였습니다. 이 암호화같은 경우는 하드코딩 취약점이나 로컬 암호화 취약점 이슈로 복호화가 가능하다는 것을 지난번 포스팅에서 보여드렸습니다.
[Insecure Bank] 로컬 암호화 이슈 취약점
이번 포스팅에선 Insecure Bank 앱을 통한 '로컬 암호화 이슈' 취약점에 대하여 알아보겠습니다. [로컬 암호화 이슈 취약점 이란?]> 안드로이드 애플리케이션은 편의성을 위해 실행 도중에 저장해야
jamesbexter.tistory.com
1.3 SQLite DB 진단
1. /data/data/com.android.insecurebankv2 경로로 오셔서 databases 폴더에 들어가시면 mydb , mydb-journal 이라는 DB파일 두개가 보일 것입니다. 저는 mydb 를 살펴보겠습니다.
2. db 파일이 있는 경로에서 sqlite3 [살펴볼 DB 명] 명령어를 사용해서 SQLite를 실행해줍니다.
> sqlite3 mydb
3. 사진을 보시면 아래의 명령어들을 순차적으로 입력하여 DB명 , 테이블 명 , DB내용 까지 추출한 것을 보실 수 있습니다. 보니깐 로그인한 내역을 저장하는 db인것 같습니다. 물론 기기에서 직접적으로 database 디렉토리에 접근이 불가능해서 이 자체로는 문제가 안되겠지만 앞서 배웠던 콘텐츠 프로바이더 취약점 과 연계가 된다면 충분히 위험할 수 있는 사항이니 DB에 비밀번호나 아이디 저장시 반드시 암호화를 진행한 후 저장해야 합니다.
> .database (DB명 출력)
> .tables (테이블 명 출력)
> select * from names; (names라는 테이블의 내용 출력)
2. 대응방안
1. "setStroageEncryption" API 이용
> 내부 저장소에 저장할 때 "setStroageEncryption" API 를 이용하면 내부 저장소에 저장되는 파일을 강제로 암호화 할 수 있습니다.
2. 암호화 알고리즘 사용
> SD카드에 저장해야 할 경우 반드시 AES같은 대칭키 암호화 알고리즘을 이용해 암호화 해야합니다.
3. SharedPreferences 모드설정
> SharedPreferneces 를 사용할때 모드를 설정해 줄 수 있습니다. 총 3가지의 모드가 있으며 다음과 같습니다. 특별한 경우가 없다면 보통 MODE_PRIVATE 를 사용하시는게 좋습니다.
| MODE_PRIVATE | 앱 내부에서만 접근 할 수 있는 권한 |
| MODE_WORLD_READABLE | 다른 앱에서의 접근을 허용 (읽기 권한) |
| MODE_WORLD_WRITEABLE | 다른 앱에서의 접근을 허용 (쓰기 권한) |
안전하지 않은 HTTP 통신 , 파라미터 조작 취약점
[안전하지 않은 HTTP 통신이란?]
> 안드로이드 에서도 앱과 서버간의 데이터 통신을 할 때 HTTP통신을 사용합니다. 하지만 HTTP는 보안을 고려하지 않기 때문에 공격자의 스니핑/스푸핑 공격을 이용하여 계정 아이디/비밀번호, 개인 정보를 탈취할 수 있습니다. 중요 정보는 SLL/TLS 통신이 적용된 HTTPS로 안전하게 전송하여야 합니다.
[파라미터 조작 취약점이란?]
> 안드로이드 앱에서 요청하는 값을 중간에서 가로챈 후 매개변수값을 변조하여 전송합니다. 웹해킹에서도 주로 다루는 내용으로 사용자의 개인 정보 수정, 다른 사용자의 게시물 삭제 및 수정 등이 해당합니다. 예를들어 제가 제 게시물을 삭제한다는 버튼을 누르면 전달되는 파라미터가 작성자:Mooner&게시물 번호:23 라고 했을때 이 값이 나가기 전에 작성자:doldol&게시물 번호:42 라고 바꿔버리면 타인의 게시물을 삭제할 수 있는 방식입니다.
1. 환경셋팅
> 이번 실습을 위해선 대표 프록시 툴인 BurpSuite로 NOX기기에서 보내는 패킷을 잡아낼 수 있어야 하는 환경셋팅이 필요합니다. 아래 내용대로 차근차근 따라오시면 됩니다!
1. 우선 BurpSuite 로 들어오셔서 Proxy setting 을 눌러주세요.
2.Proxy 셋팅에서 본인의 내부아이피 주소로 셋팅해주시고 ok 해주세요.
3. 설정한 내용이 들어간 것을 확인한 후 NOX 기기로 이동합니다.
4. NOX 기기에서 WI-FI로 들어오셔서 네트워크 수정 버튼을 눌러주세요.
5. 설정에서 프록시는 '수동' 으로 해주시고 프록시 호스트 이름 = BurpSuite에서 설정한 내부아이피 , 프록시 포트 : 8080 으로 설정해주시고 나갑니다.
6. 이제 Nox에서 인터넷을 키신후 주소창에 http://burp 라고 입력하시면 인증서를 다운로드 할 수 있는 창이 뜹니다. 표시한 CA Certificate 를 누르시면 Download 폴더로 인증서가 다운로드 됩니다.
7. 이후 Download 폴더로 오셔서 cacert.der 파일을 cacert.cer 파일로 이름을 변경해주세요.
| Download 폴더 | 파일명 cacert.cer로 변경 |
 |
 |
8. 기기에서 설정 > 보안 > SD 카드에서 설치 를 클릭하여서 방금 다운로드 받은 인증서 등록을 진행해주세요.
| 보안 > SD 카드에서 설치 클릭 | cacert.cer 파일 클릭 |
 |
 |
9. 인증서 이름 지정창이 뜰텐데 저는 그냥 burpca 라는 이름으로 지정해주었습니다.
10. 마지막으로 NOX_ADB를 이용하여 저희가 등록한 사용자 자격증을 시스템 자격증명서로 바꿔줘야 합니다. 해당 명령어를 순차적으로 입력하면 인증서 등록이 완료됩니다.
> nox_adb shell
> cd /data/misc/user/0/cacerts-added
> mount -o rw, remount /system
> mv 9a5ba575.0 /system/etc/security/cacerts
11. 이제 NOX 기기에서 인터넷을 접속합니다.
12. 녹스기기에서 네이버로 접속하자 BurpSuite로 요청패킷,응답패킷을 확인 가능한 모습입니다.
| NOX에서 NAVER접속 | BurpSuite에서 패킷 확인 가능 |
 |
 |
2. 취약점 진단
2.1 안전하지 않은 HTTP 통신
1. 우선 위에 환경셋팅을 마친후 인시큐어 뱅크 어플에서 로그인을 합니다.
2. 방금 보낸 로그인 패킷을 잡아서 보면 로그인 정보가 평문 그대로 전송되는 것을 볼 수 있습니다. 물론 비밀번호가 암호화가 안되고 평문으로 전송되고 있는것 자체도 문제가 되는데 더 문제는 위에 NAVER로 보낸 요청패킷은 https:// 주소로 보내지만 이 요청은 http:// 프로토콜로 보내고 있습니다. 이렇게 되면 중간에 패킷을 가로채는 스니핑 공격에 당할 시 로그인 정보가 그대로 노출 될 수 있다는 문제점이 있습니다.
2.2 파라미터 조작 취약점
1. 인시큐어 뱅크 앱에서 비밀번호 변경 액티비티로 들어가 변경패킷을 요청합니다. 일단 Dinesh@123$ 로 설정한 후 요청을 하였습니다.
2. 보내기 전에 Intercept on 을 해준후 패킷을 중간에 막아보도록 하겠습니다.
3. 사진과 같이 패킷이 중간에 잡혔습니다. 이제 newpassword 인자값을 Admin@159$ 로 바꿔준 후 보내겠습니다.
4. Admin@159$로 인자값을 바꾼후 Forward 를 눌러 보내줍니다.
5. 응답 패킷에 성공적으로 비밀번호가 변경되었다고 뜹니다.
6. 바뀐 비밀번호로 로그인을 시도하자 성공적으로 로그인이 되는것을 확인할 수 있습니다!!
| 바꾼 비밀번호로 로그인 시도 | 로그인 성공! |
 |
 |
3. 대응방법
3.1 안전하지 않은 HTTP 통신
1. SSL/TLS 암호화 적용
> SSL/TLS 암호화를 적용하여 HTTPS 통신을 해야 중간에 스니핑이 되더라도 패킷이 난독화가 되어있어 공격자가 무슨내용인지 알 수 없습니다. 암호 알고리즘은 DES 같은 취약한 알고리즘 말고 AES 같은 안정성이 검증된 알고리즘을 선택해야 합니다!
2. 전송되는 정보 암호화
> HTTP 통신으로 보내는 패킷들이 암호화가 되어있지 않을경우 요청하는 정보들이 그대로 노출됩니다. 여기서 개인정보같은 민감한 정보가 있다면 그대로 노출되는 것이기 때문에 반드시 전송과정에서 Hash 암호화같은 과정을 한번은 거쳐서 패킷이 노출되도 안에 내용은 알아내기 힘들게 만들어야 합니다.
3.2 파라미터 조작 취약점
1. 입력값 검증
> 악성 스크립트나 비정상적인 파라미터값을 방지하기 위해 서버측에서 입력값에 대한 검증이 필요합니다. 상태정보 , 민감한 데이터 , 세션 정보같은 중요한 정보는 반드시 서버에서 검증하는 방식이 존재해야 합니다.
2. 개인정보를 이용한 2차인증
> 위에서 예시를 들었던 비밀번호 변경같은경우 이전 비밀번호를 추가로 요구하여 인증과정을 서버에서 거친다면 파라미터 값을 조작하더라도
사실 파라미터 조작같은 경우는 막는방법이 없습니다.. 따라서 서버에서의 검증과정 강화를 통해서 막는 방법이 가장 추천드립니다.
하드코딩 취약점 & 사용자 정보 목록 이슈화 취약점
[하드코딩 취약점 이란?]
> 하드코딩이란 , 객체를 사용하지 않고 코드를 재사용할 수 없도록 코드 안에 변수를 상수로 사용하거나 코드를 다시 컴파일하지 않고서는 바꿀 수 없는 형태로 코딩하는 것을 말합니다. 이렇게 상수값 그대로 코드에 적어버리면 여러 문제점들이 발생하는데 예를들어 관리자 패스워드나 중요정보 , 암호화키 등이 코드에 노출이 될 경우 디컴파일을 통해서 정보가 노출될 수 있습니다!
[개발자 백도어 란?]
> 백도어란 정상적인 프로그램에 자신만이 들어갈 수 있는 코드를 삽입하여 정당한 인증 절차를 거치지 않고 들어갈 수 있는 뒷문입니다. 개발자들이 보통 유지보수나 디버깅 시 시간단축을 위하여 만드는경우가 있는데 이때 이 부분이 공격자에게 발견되면 시스템에 큰 위험을 초래할 수 있습니다.
1. 취약점 진단
1.1 하드코딩 취약점
1. Jadx를 통해 인시큐어 뱅크 앱을 디컴파일링한 후 CryptoClass 소스코드를 확인하시게 되면 암호화 키값이 그대로 노출되어 있는것을 확인하실 수 있습니다. 이를통해 이전 취약점에서 얻은 암호화된 아이디&패스워드 값을 복호화 하는것에 성공하였기 때문에 이것이 얼마나 위험한지를 알 수 있습니다!
1.2 개발자 백도어
1. 인시큐어 뱅크 클래스중 DoLogin class 코드를 살펴보게 되면 로그인 과정중 devadmin이라는 값이 ID 값으로 들어왔을때와 일반적인 경우가 나뉘어서 인증이 되는것을 확인하실 수 있습니다. 이를 통해 devadmin 이라는 아이디값으로 로그인을 시도해볼 여지를 주게 됩니다.
2. 그러면 실제로 인시큐어 뱅크 어플에 devadmin 이라는 아이디값을 입력하고 패스워드는 비워둔채 로그인을 진행하여 보겠습니다.
3. 정말 로그인이 되었습니다. 이를 통해 이건 관리자가 개발도중 인증없이 들어오기 위하여 만들어놓은 백도어라는 것을 알아챌 수 있게 되는것입니다!
2. 대응방안
2.1 하드코딩 이슈
>> 이 경우는 개발자의 실수로 인한 취약점이라고 보는게 맞습니다. 따라서 배포하기전 소스코드중 민감한 정보가 그대로 노출되어 있진 않나 체크해야합니다. 암호화키의 경우 , 절대 상수로 명시하면 안되며, 솔트를 사용하여 암호화의 안정성을 높이는 것이 중요합니다. 솔트를 사용할 경우에도 예측하기 어려운 난수를 사용해야 하며, 고정된 값이나 특정한 값을 재사용해서도 안됩니다!
2.2 개발자 백도어
>> 개발과정에서 남아있던 백도어 계정이 노출되어서 문제가 되었던 것이였습니다. 따라서 로그인 인증로직을 devadmin 과 일반 인증으로 나누지말고 정상적인 로그인 로직만 남겨두면 대응이 가능합니다.
긴 글 읽어주셔서 감사합니다!
'모바일 앱해킹(Android) > Insecure Bank' 카테고리의 다른 글
| [Insecure Bank] 설치방법&환경셋팅 부터 취약점 진단까지 모아보기! (Part 1) (0) | 2024.12.18 |
|---|---|
| [Insecure Bank] 하드코딩 취약점 & 개발자 백도어 (0) | 2024.12.15 |
| [Insecure Bank] 안전하지 않은 HTTP 통신 & 파라미터 조작 (0) | 2024.12.14 |
| [Insecure Bank] 안전하지 않은 SD 카드 저장소 (0) | 2024.12.13 |
| [Insecure Bank] 안드로이드 백업 취약점 (0) | 2024.12.12 |