8. 안드로이드 앱 진단 실습 (6) - 항목별 진단 실습 3 : 로컬 암호화 이슈

 

 

 

 

[목차]

 

 

Local Encryption issues (로컬 암호화 이슈)

1. 취약점 설명

2. 진단 방법

       - 앱의 전반적인 기능들을 실행해 보고 탐색

       - DB 추출 후 중요정보 암호화 여부 확인

       - DB 외 파일들에서 중요정보 암호화 여부 확인

       - 클라이언트단 소스코드 점검 및 암호화 로직 점검

       - 복호화 시도

3. 대응 방안

 

 

 

---

 

 

[Local Encryption Issus]

 

 

 

1. 취약점 설명

로컬 암호화 이슈 취약점은

중요 정보가 단말기에 저장될 때

암호화되어 있지 않거나 취약한

암호화 체계 사용, 또는 복호화

힌트가 소스코드 내 노출되어 있는

취약점으로

 

인시큐어뱅크 앱에서 사용하는

여러 계정 정보는 암호화를 사용하지

않고 있다.

 

 

---

 

 

 

2. 진단 방법

 

 

(1) 앱의 전반적인 기능들을 실행해 보고 탐색

로그인 시도 후 앱 종료 > 앱 재실행 후

Autofill Credentials 클릭

 

 

자동완성 기능이 가능한 걸로 보아

단말기 어딘가에 계정 정보가

저장되어 있다고 생각할 수 있다.

 

 

---

 

 

(2) DB 추출 후 중요정보 암호화 여부 확인

adb로 쉘에 접속한 뒤 인시큐어뱅크 앱 내

디렉터리 구조를 살펴보면 다음과 같은데

 

 

쉘에서 작업하면 불편한 부분이 있어

위 파일들을 모두 로컬 PC로 옮긴 뒤

진단을 실시한다.

 

 

 

ㄱ. DATA 추출

C:> adb pull /dat/data/com.android.insecurebankv2 .\

 

 

 

추출한 뒤 들어가 보면

 

앱 내 데이터가 정상 추출된 것을 확인할 수 있는데

 

 

디비 내용은

databases 내 mydb 파일을

 

 

 

sqlite viewer을 통해 확인 가능하다.

https://sqlitebrowser.org/dl/

DB 내 중요 정보가 노출되는지 확인

 

 

---

 

 

(3) DB 외 파일들에서 중요정보 암호화 여부 확인

DB 외 살펴볼 파일은

shared_prefs 내 xml 파일로

 

 

이 전 과정인

[안드로이드 백업 취약점]에서

데이터 백업 시 생성된 tar 파일의

압축을 해제하면

 

sp 디렉터리 내 사용자 암호가 저장된

mySharedPreferences.xml

파일이 있었는데

 

 

당연히 shared_prefs 디렉터리 내에도

동일한 파일이 있다.

 

 

내용을 살펴보면

 

 

사용자 이름과 비번이

암호화되어 저장되어 있고

 

아이디는 바로 디코딩이 가능하지만

 

 

비번은 아니다.

 

 

* 참고로

인코딩과 디코딩은 단순

데이터 형식이기 때문에

키가 없이도 바로 변환이 가능하지만

 

암호화와 복호화의 경우는

둘 다 키가 필요하다는

차이점이 있다.

 

이런 시점으로 현재 사용자 아이디와

비번의 저장 방식을 살펴보면

아이디는 encoded user name이고

비번은 encrypted password라

할 수 있겠다.

 

---

 

(4) 클라이언트단 소스코드 점검 및 암호화 로직 점검

현재 점검 중인 대상은 앱 실행 후

Autofill Credentials 버튼을 눌렀을 때

저장되어 있는 계정 정보가

자동으로 입력되는 부분인데

 

 

LoginActivity 클래스 내

fillData_button이 호출되면

 

 

fillData() 함수 내 settings 변숫값

getsharedPreferences 메서드가

mySahredPreferences.xml

파일에 저장되어 있는 암호화된

로그인 데이터를 파싱 해

username / password로

담아주는데

 

 

이때

username / password가

복호화 되어 자동으로 앱에

입력되는 방식을 살펴보면

 

 

username의 경우 base64 방식으로

decoding 되는 것을 알 수 있는데

디코딩 후 UTF-8로 변환 뒤

string으로 만들어 준다.

 

그렇게 변환한 username은

평문 string으로 디코딩 되어

setText를 통해 아이디 란에 입력된다.

 

 

비번에 사용되는 암/복호화 방식은

CryptoClass()라는 클래스를 사용하는데

(해당 클래스는 아래 별도로 살펴본다)

 

 

 

mySahredPreferences.xml 파일에서

파싱 한 암호화된 비밀번호를

CryptoClass()의

aesDecryptedString 메서드로 복호화 한 뒤

setText로 앱 비밀번호 란에 넣어주는 구조.

 

 

복호화 하는 방식을 살펴보았는데

암호화 로직의 경우는 DoLogin 클래스 내

saveCreds 함수에서 살펴볼 수 있다.

 

 

username은 Base64

password는 aesEnctypt 방식

 

 

saveCreds 함수가 호출되는 경우는

 

 

로그인 정보가 맞아

정상적으로 로그인이 되는 경우

해당 data가 서버로 전송되면서

 

 

postdata() 함수 내

saveCreds()라는 메서드가 호출되어

username / password가 전달,

 

 

saveCreds 내

지정된 암호화 방식으로 변환 시켜

editor(mySharedPreferences.xml)에

저장되는 것

 

 

---

 

 

(5) 복호화 시도

password는

aesEncrypt 방식으로 암호화가 진행되었는데

aesEncrypt 함수를 한번 살펴보면

 

 

aes256 방식으로 암호화를 수행한 뒤

base64로 추가 암호화가 진행된다.

 

 

해당 aes256encrypt가 구현된

클래스를 살펴보면 복호화와 마찬가지로

CryptoClass 내에 정의되어 있는데

 

 

특이한 점은 소스코드 내

암/복호화에 사용되는 대칭 키가

하드코딩 되어있다.

 

'This is the super secret key 123'

 

 

암호화 키 + 대칭 키가 모두 있으니

복호화를 시도해 보면

 

 

base64 방식으로 인코딩된 결괏값 확인이 가능하며

이를 다시 디코딩 해보면

 

평문 비밀번호 확인이 가능하다.

 

 

---

 

 

3. 대응 방안

- 중요 정보를 다루는 코드를 검토하여

중요 정보가 암호화될 수 있도록 코드 추가 및 수정

- 암/복호화에 사용되는 대칭 키가 노출되지 않도록

안전하게 저장