DIVA 앱을 실행하고 2. Hardcoding Issue - Part 1을 선택하면 맨 위 상단에 힌트가 나오는데 어디에 하드코딩된 정보가 있는지 찾으라고 나온다. 하지만 이 앱만 봐서는 하드코딩된 정보를 찾을 순 없다.

중간에 어떤 걸 Access 하는게 있는데 아무런 값이나 대입하고 Access를 실행해보니 Access가 거부되었다는 메시지가 표시된다.

소스 코드를 보면 access 하는 함수 부분에서 사용자가 입력한 값과 vendorsecretkey라는 문자열과 비교하고 있다. 여기서 vendorsecretkey가 Access 할 수 있는 Key 값임을 알 수 있다. 그림 1-3과 같이 코드에 Key 값이 노출되면 매우 위험하다고 판단할 수 있으며 하드코딩 취약점으로 판별할 수 있다.

Diva 앱으로 다시 돌아와 입력값란에 vendorsecretkey를 입력하고 Access하면 성공적으로 Access가 되었다는 메시지가 표시된다.

먼저 cmd 창에 adb logcat을 입력해 DIVA 앱을 실행함으로써 어떤 로그 정보들이 전송되고 있는지 확인한다.

DIVA 앱을 실행하고 7.INPUT VALIDATION ISSUES - PART 1을 클릭하고 diva를 입력하면 그림 1-2와 같이 diva라는 사용자의 계정 정보 및 신용 카드 정보가 앱에 그대로 노출된다.

SQLInjectionActivity 클래스를 보면 SQL 쿼리를 볼 수 있는데 "SELECT * FROM sqliuser WHERE user = \'"사용자 입력"\'" 쿼리를 사용해서 검색을 한다. SQL 인젝션에 대한 대응 방안이 전혀 반영되지 않은 소스 코드라고 판단할 수 있다.

'or '1'='1을 입력해 SQL 인젝션 공격을 진행하면 DB에 저장되어 있는 사용자의 계정 정보, 신용카드 정보들이 앱 화면에 그대로 노출됨을 확인할 수 있다.

로그 캣 전송 정보들을 확인해보면 SQL 인젝션 공격이 그대로 들어가 실행되고 있음도 같이 확인할 수 있다.

DIVA 앱을 실행하고 Insecure Data Storage - 4를 클릭하면 계정 정보 입력란이 나오는데 아이디, 패스워드를 입력하고 SAVE 버튼을 누르면 계정이 앱의 외부 저장소로 전송된다.

소스 코드를 보면 그림 1-1에서 입력된 계정 정보를 외부저장소 위치에 .uinfo.txt이라는 파일을 생성해 저장하고 있음을 확인할 수 있다. 파일명 앞에 .을 붙이면 숨김 파일로 인식되서 탐색기에서 바로 보여지지 않기 때문에 리눅스 상에서 파일을 확인할 땐 ls -al 명령어를 사용해야 한다. 또한 파일에 계정 정보를 저장할 때 따로 암호화 시키는 소스코드는 확인할 수 없어 평문으로 저장되고 있음을 추측할 수 있다. 

 adb shell을 입력해 안드로이드 내에 접속 후 cd /sdcard 명령어를 입력해 외부 저장소로 이동해 ls -al을 입력해 목록을 확인하면 .uinfo.txt를 발견할 수 있다. 이 파일에 계정 정보가 담겨 있다.

cat .uinfo.txt 명령어를 입력해 해당 파일 내의 내용을 보면 그림 1-1에서 입력했던 계정 정보를 확인할 수 있다. 계정 정보가 저장될 때 암호화 되지 않고 평문으로 저장되서 취약점이 발견되었다고 볼 수 있다.

DIVA 앱을 실행하고 Insecure Data Storage - 3를 클릭하면 계정 정보 입력란이 나오는데 아이디, 패스워드를 입력하고 SAVE 버튼을 누르면 계정이 앱의 내부 저장소로 전송된다.

그림 1-2의 소스코드를 보면 tmp 폴더에 uinfo로 시작하는 파일 명으로 파일이 생성되는데 이 파일 안에 그림 1-1에서 보낸 계정 정보들이 담긴다는 것을 추측할 수 있다. 또한 소스코드에서 따로 암호화 처리를 하는 코드는 없어 계정 정보가 저장될 때 암호화 되지 않고 그대로 저장된다는 것도 추측해볼 수 있다.

adb shell을 입력해 안드로이드 쉘로 들어간 후 cd /data/data/jakhar.aseem.diva를 입력해 해당 앱 내부로 들어가서 ls -al을 입력해 목록을 확인하면 uinfo-502312121tmp라는 파일이 있는데 이 파일에 그림 1-1에서 입력했던 계정 정보들이 저장된다.

cat uinfo-502312121tmp 명령어를 입력해 파일 내의 내용을 확인하면 그림 1-1에서 입력했던 계정 정보들을 확인할 수 있다. 이 때 파일에 암호화되지 않고 평문으로 전송된 것이 취약점이라고 판단할 수 있다.

DIVA 앱을 실행하고 Insecure Data Storage - 2를 선택하면 그림 1-1과 같이 계정 정보 입력 창이 나온다. 아이디, 패스워드를 넣고 Save 버튼을 누르면 계정 정보들이 앱의 내부 저장소에 저장된다.

해당 앱의 소스 코드를 확인하면 Databases 폴더의 ids2 파일에 계정 정보를 전송하고 있음을 볼 수 있다. 현재 소스 코드를 보면 데이터베이스에 계정정보가 저장될 때 아무런 암호화 조치도 없이 그대로 저장되고 있음을 확인할 수 있다.

adb shell을 실행해 cd /data/data/jakhar.aseem.diva 폴더에 접근해 목록을 확인하면 중요 정보들이 저장되는 폴더들을 확인할 수 있다. 그림 1-2에서 본 것과 같이 Databases 폴더에 입력한 값들이 저장되고 있기 때문에 cd databases를 입력해 databases 폴더에 접근한다. databases 폴더에 접근하면 ids2 파일이 있는데 ids2 파일에 그림 1-1에서 입력한 계정 정보가 저장되고 있는 것이다.

데이터베이스 정보를 확인하기 위해 SQlite를 실행한다. 리눅스 환경에서도 실행이 가능하기 때문에 sqlite3 ids2를 입력한다. 이 때 ids2는 정보가 담긴 파일이다. sqlite3가 실행되면 .tables를 입력해 테이블 정보들을 확인한다. 테이블 정보를 보면 myuser이 있는데 이 테이블에 접근한다.

myuser 파일을 덤프해서 확인해보면 데이터베이스에 그림 1-1에 입력했던 계정 정보들이 들어가는 것을 확인할 수 있다. 하지만 여기서 취약점은 암호화 되지 않은 상태로 계정 정보가 데이터베이스에 저장되고 있다는 것이다. 

DIVA 앱에서 3번째인 Insecure Data Storage - 1을 선택하면 그림 1-1과 같이 아이디, 패스워드를 입력하는 화면이 나오는데 여기서 아이디, 패스워드를 입력하면 앱의 내부 저장소에 중요 정보들이 저장된다.

윈도우 cmd 창에서 adb shell을 입력해서 nox의 내부로 접근한다. cd /data/data/를 입력 후 ls 명령어를 입력하면 현재 설치되어 있는 앱의 정보가 담겨있는 목록들이 나오는데 여기서 jarhar.aseem.diva에 접근한다. 마찬가지로 cd jarhar.aseem.diva를 입력한다.

 jarhar.aseem.diva를 입력한 후 ls -al 명령어를 입력하면 해당 목록들이 나오는데 shared_prefs는 중요 정보를 저장해 놓는 장소다. cd shared_prefs를 입력해서 해당 폴더에 접근한다.

shared_prefs에 접근하면 jarkhar.aseem.diva_preferences.xml 파일이 나오는데 이 파일에 그림 1-1에서 입력했던 아이디, 패스워드 정보가 저장되어 있다.

cat 명령어를 사용해서 해당 파일을 열면 그림 1-1에서 입력했던 계정 정보가 담겨 있다는 것을 볼 수 있다. 여기서 중요한건 계정 정보가 암호화 되지 않고 평문으로 노출되어 있다는 점에서 취약점이라고 판단할 수 있다.

Jadx-Gui 도구를 사용해 해당 앱을 디컴파일해서 열면 InsecureDataStorage | Activity 항목이 있는데 해당 항목 소스코드를 보면 계정 정보를 보낼 때 어떠한 암호화 처리가 되지 않은 채 그대로 계정 정보를 전송하고 있다는 것을 볼 수 있다. 

안드로이드 앱 취약점 중 하나인 안전하지 않은 로깅은 Logcat을 통해 앱 실행 Log들이 보여질 때 아이디, 비밀번호 등과 같은 중요 정보들이 평문으로 노출되어 2차 피해를 입을 수 있다.

안드로이드에 DIVA 앱을 설치하고 1. Insecure Logging을 클릭한다.

임의의 카드 비밀번호를 입력하고 Check out을 누르면 에러메시지가 발생하게 된다. 현재 그림 1-2에선 나와 있지 않지만 임의의 번호를 입력하고 Check out을 누르면 에러메시지가 발생한다. 에러메시지가 발생하고 adb logcat을 통해 Logcat 정보를 보면 된다.

adb logcat을 입력해 Logcat 정보들을 보면 그림 1-2에서 전송했었던 123123이 난독화 되지 않고 평문으로 전송되고 있음을 확인할 수 있다. 

Jadx-gui 디컴파일 도구를 활용해 Diva 앱의 소스코드를 진단해본다. 현재 취약점이 발생되는 곳은 LogActivity쪽인데 전송되는 로그 정보 코드를 살펴보면 어떠한 시큐어코딩도 되지 않은채 사용자가 입력한 값이 그대로 전송되는 취약점이 발생하게 되는 것이다. 대응 방안은 이 코드 자체를 시큐어코딩을 하거나 삭제 하는 것이다.

1. 취약점 소개

사용자가 안드로이드 모바일을 이용할 시 입력했던 인증 정보(로그인, 비밀번호 등), 중요 정보(송금 여부, 액수 등), 민감한 정보들이 백업 파일에 저장된다. 만약 제3자가 획득한 단말기에서 백업 취약점이 발견하면 인증정보, 중요정보, 민감한 정보 등을 획득해 2차 피해가 우려될 수 있는 취약점이다.

2. 취약점 진단

그림 2‑1 인시큐어뱅크 Transfer

인시큐어뱅크에 로그인하고 Transfer을 실행한다. 실행이 되면 계좌번호와 보낼 금액을 입력한다. 현재는 가상에서 진행하기 때문에 랜덤한 숫자를 입력해도 된다. 만약 앱을 실행하지 않으면 백업 취약점에 대한 진단을 할 수 없기 때문에 반드시 실행 후 계좌번호, 보낼 금액을 입력해 실행해야 한다.

그림 2‑2 Transfer 결과

계좌번호와 보낸 금액에 대한 실행 결과다. ViewStatement 탭을 실행하면 그림 2‑2와 같이 보낸 결과 값을 확인할 수 있다.

그림 2‑3 adb backup 명령어

cmd 창을 열고 adb backup 명령어를 실행해 인시큐어뱅크 앱에서 실행한 정보를 백업한다.

표 2‑1 adb backup 명령어 옵션

그림 2‑4 adb backup 실행 결과

adb back 명령어를 실행하면 녹스플레이어 가상 환경에서 그림 2‑4와 같은 화면이 나온다. 비밀번호란은 비워놓고 전체 백업을 진행하면 암호화된 백업 파일이 로컬에 insecurebank.ad 파일명으로 저장된다.

그림 2‑5 ad 파일 생성

전체 백업을 진행하고 로컬 컴퓨터에서 생성된 파일을 확인해보면 그림 2‑5와 같이 insecure.ad란 이름으로 AD 파일이 생성되었음을 볼 수 있다.

그림 2‑6 백업 추출 라이브러리

Insecurebank.ad 파일을 바로 열게 되면 글자가 전부 깨져서 어떤 내용인지 확인이 불가능하다. 파일 내용 복호화를 위해 백업 추출 라이브러리인 abe-all.jar을 활용해 insecurebank.ad 파일 내용을 복호화해서 알집 파일로 만든다.

그림 2‑7 tar 파일

백업 추출이 성공적으로 완료되면 insecurebank.tar이라는 압축 파일이 생성된다. 이 압축 파일을 해제해서 추출된 정보들을 확인한다.

그림 2‑8 압축 해제 파일

압축을 해제해 추출된 정보들을 확인한다. apps 폴더에서 mySharedPreferences.xml 파일을 연다. mySharedPreferences.xml 파일은 인시큐어뱅크 앱에서 실행한 정보를 저장해놓은 파일이다.

그림 2‑9 계정 정보

mySharedPreferences.xml 파일을 열면 인시큐어뱅크 앱에 로그인하기 위해 입력한 아이디, 비밀번호 값이 Base64 방식으로 인코딩 되어 있다는 걸 볼 수 있다. 복잡한 암호화 알고리즘 방식을 적용하지 않아 간단한 인코딩 방식만 적용하면 쉽게 디코딩 되어 아이디, 비밀번호가 어떤 건지 평문으로 번역해 계정 정보를 획득할 수 있다.

3. 대응 방안

안드로이드 백업 취약점은 AndroidManifest.xml에 android:allowBackup 속성이 true로 설정되어 있기 때문에 발생하는 취약점이다. 민감한 정보, 중요한 정보 등이 노출되지 않도록 하기 위해서는 android:allowBackup 속성을 False로 설정해 변환된 백업 데이터에 대한 내용이 노출 되지 않도록 한다.

그림 2‑10 AndroidManifest.xml

인시큐어뱅크 앱 소스 코드를 열어 AndroidManifest.xml 파일에 구현되어 있는 android:allowBackup 속성을 false로 변경한 후 앱을 다시 빌드한다.

그림 2‑11 adb backup 명령어

앱이 녹스플레이어에 완전히 다시 빌드된 후 adb backup 명령어를 실행해 인시큐어뱅크 앱에서 실행한 정보를 백업한다. 실행된 정보를 백업하기 전에 인시큐어뱅크 앱에 다시 로그인 한 후 계좌정보 등을 다시 보내야 원활한 실습이 가능하다.

그림 2‑12 전체 백업

adb back 명령어가 정상적으로 실행되면 녹스 플레이어에 전체 백업 여부를 묻게 되는데 데이터백업을 실행해 전체 백업을 진행한다.

그림 2‑13 파일 생성

데이터 백업이 성공적으로 완료되면 insecurebank.ad 파일이 생성된다. Insecurebank.ad 파일이 생성된 후 백업 추출 라이브러리인 abe-all.jar을 활용해 insecurebank.ad 파일을 알집 파일로 만든다.

그림 2‑14 알집 파일 실행 결과

인시큐어뱅크 앱의 민감한 정보들을 탈취하기 위해 insecurebank.tar 파일의 압축을 풀려고 시도했지만 압축 파일이 아니라는 메시지가 출력되면서 압축이 풀리지 않는다. 이처럼 백업에 관련된 소스 코드를 변경하면 앱의 민감정보, 중요정보 등의 탈취를 막을 수 있다.