'안드로이드 앱 취약점 진단/인시큐어뱅크'에 해당되는 글 7건

1. 취약점 소개

개발자 백도어는 개발자가 편하게 사용자처럼 인증이 가능하고 여러 가지 업무를 수행하기 위해 자신만이 들어갈 수 있는 계정, 인증 우회방법을 말한다. 개발자 본인에게는 편할 수 있지만 추후에 배포용 어플리케이션, 서버 코드에 개발 백도어 코드가 삽입되면 어플리케이션 보안에 매우 취약할 수 있다.

2. 취약점 진단

[그림 2-1] devadmin 계정

DoLogin.java 파일을 열고 소스코드를 보면 httppost2를 선언해 username이 devadmin이면 별다른 암호 인증 처리 없이 로그인이 가능하다는 걸 추측할 수 있다.

[그림 2-2] devadmin 로그인 화면

인시큐어뱅크 앱을 실행시켜 devadmin, 123123으로 계정을 입력하고 로그인을 시도한다.

[그림 2-3] 로그인 성공

로그인 시도 결과 devadmin 계정은 아무 비밀번호나 입력해도 인증이 우회되어 로그인 되었음을 확인할 수 있다.

[그림 2-4] Transfer 실행

로그인이 완료되고 Transfer을 실행시켜 Get Account를 클릭하면 값이 전혀 입력 되지 않는다. 이는 개발자 계정으로 로그인 했기 때문인데 인시큐어뱅크 앱에서는 중요 정보 값이 실행 되지 않지만 실제 앱에선 개발자 계정으로 로그인해도 중요 정보 값이 실행 되는 경우가 많다.

3. 대응 방안

[그림 3-1] DoLogin.java 파일

Dologin.java 파일의 코드이다. If else 구문에서 devlogin 부분의 username을 그대로 받고 있다. Password 부분은 따로 없기 때문에 어떠한 숫자를 입력해도 로그인이 가능하다. 이런 이유로 if else 구문을 주석처리를 하면 취약점 방어가 가능하다.

[그림 3-2] app.py 파일 코드

서버 코드인 app.py를 보면 devlogin 부분이 있는데 서버쪽에서도 devlogin을 실행시키고 있음을 볼 수 있는데 별다른 검증 없이 username만 허용되면 어떠한 패스워드를 입력해도 로그인이 가능하다. 이 부분을 주석 처리하면 취약점 방어가 가능하다.

[그림 3-3] devadmin 로그인 화면

주석 처리한 코드들을 저장하고 앱을 다시 빌드하고 실행한다. 인시큐어뱅크 앱 서버도 다시 실행한 후 devadmin, 123123을 입력하고 로그인을 시도하면 로그인이 되지 않음을 확인할 수 있다. 이로써 개발자 백도어 취약점이 방어되었다.

1. 취약점 소개

사용자가 안드로이드 앱을 사용하기 위해 로그인을 시도한다. 이 때 입력되는 파라미터 값들이 보호되지 않으면 공격자가 파라미터 정보를 수정해 악용할 경우, 개인 신상 유출, 신용카드 도용, 가격 변조 등과 같은 피해가 발생할 수 있다. 안드로이드 앱에서도 웹과 똑같이 요청하는 중간에서 값을 가로채 매개변수값을 변조해서 전송한다. 이 공격을 통해 본래 요청값이 변조된 값으로 수정되고 민감한 정보가 포함된 요청이면 정보 유출 위험성이 존재한다. 웹에서는 인증 우회 취약점으로 분류하기도 한다.

2. 취약점 진단

2.1) 가격 조작

[그림 2-1] 요청 패킷

프록시 설정 완료 후 인시큐어뱅크 파라미터 조작 취약점을 진단한다. 인시큐어뱅크 서버 IP와 포트를 지정한 후 로그인을 시도한다. 로그인 시도 후 Transfer 버튼을 클릭해 버프스윗으로 요청 데이터 값들을 인터셉트한다. 인터셉트 한 파라미터 값으론 로그인 계정 파라미터를 포함해 5개가 존재한다.

[그림 2-2] DB 확인

인시큐어뱅크 서버 DB인 mydb.db 파일을 sqliteBrowser 도구를 이용해 확인해보면 555555555의 금액은 777994437로 저장되어 있고 888888888의 금액은 98403이 저장되어 있음을 확인할 수 있다.

[그림 2-3] 가격 조작

Transfer 시도 시 이체할 금액을 변조해서 데이터를 보낸다. 금액을 10000에서 1000으로 변조한 후 Intercept is on 버튼을 클릭한다.

[그림 2-4] ViewStatement

ViewStatement 탭을 클릭해서 변조해서 보낸 데이터를 확인하면 금액이 10000으로 이체되었다고 표시된다. 하지만 ViewStatement에서 표시되는 금액일 뿐 실제로는 1000이 이체되었다.

[그림 2-5] DB 확인

sqliteBrowser 도구를 이용해 mydb.db 파일을 확인해보면 [그림 2-2]와 달리 가격이 조금 변동되었음을 확인할 수 있다. 555555555의 금액은 777995437, 888888888의 금액은 97403으로 변동이 되었다. 처음 이체 시도 시 10000을 보냈지만 파라미터 조작을 통해 1000으로 변조해 실제로는 1000이 전송되었음을 확인할 수 있다.

2.2 CSRF 공격

[그림 2-6] 요청 패킷

CSRF는 요청되는 값을 변조해서 공격하는 기법이다. 사용자가 특정 링크나 페이지에 접근했을 때 사용자도 모르게 요청값을 변조해 서버에 전달해서 중요 정보를 임의로 수정한다. Chanegepassword 페이지로 이동해 비밀번호를 변경할 때 패킷을 가로챈다.

[그림 2-7] Submit Form 클릭

만든 코드를 HTML 파일로 저장해 브라우저에서 실행한다. 실행 후 Submit Form을 클릭한다.

[그림 2-8] 비밀번호 변경 확인

Submit Form을 클릭하면 비밀번호가 변경되었다는 결과 메시지가 출력된다.

[그림 2-9] 인시큐어뱅크 서버 로그

인시큐어뱅크 서버 로그에서도 비밀번호가 변경되었다는 결과 메시지가 출력된다.

[그림 2-10] 로그인 시도

변경된 비밀번호인 Jack@123$%로 로그인을 시도한다.

[그림 2-11] 로그인 성공

변경된 비밀번호를 이용해 로그인에 성공했음을 확인할 수 있다.

3. 대응 방안

[그림 3-1] 서버 코드

서버 코드에서 POST 메서드를 이용해 전달되는 매개변수를 처리하도록 코드가 구현 되어 있다. 단순히 데이터베이스 유저 이름과 매개변수의 유저 이름이 같으면 매개변수의 새로운 비밀번호를 저장하고, 변경 성공 메시지를 저장해 다시 응답값이 포함되도록 하고 있다.

[그림 3-2] 클라이언트 코드

ChangePassword.java 파일을 보면 입력 받은 값에 따라 조건을 주고 실행하고 있다. 먼저 httppost 변수에 매개변수를 포함시킬 URL을 입력하고 유저 이름과 새로운 비밀번호를 변수로 저장한다. 이 때 입력된 비밀번호가 복잡한지 검증하고 합당하면 추가 변경 과정을 실행한다. 이 코드에선 비밀번호 복잡성은 검증 진행이 되고 있지만 매개변수를 암호화하거나 변경하는 페이지에 대한 추가 인증에 관련된 코드는 구현되어 있지 않다.

파라미터 조작은 가장 막기 힘든 취약점이다. 소프트웨어에 대한 입력값이 신뢰를 전제로 보호 메커니즘 구현 시 공격자가 입력값을 조작한다면 보호 매커니즘은 무의미하다. 소프트웨어를 개발할 때 기발자들이 모든 입력값에 대해 검증을 수행하는 것이 안전하다. 안전한 소프트웨어 개발을 위해 가장 먼저 모든 입력 값에 대한 검증을 "서버"에서 수행하고 상태 정보, 민감한 데이터, 사용자 세션 정보와 같은 중요한 정보들은 특히 "서버"에서 검증해야 한다.

1. 취약점 소개

안드로이드 액티비티는 애플리케이션을 구성하는 가장 기본적인 구성 단위 중 하나로 안드로이드 애플리케이션과 사용자 간에 상호 작용에 필요한 기능을 제공한다. 액티비티는 AndroidManifest.xml의 <activity> 요소에 선언하며 하나의 애플리케이션은 하나 이상의 액티비티로 구성된다. 특정 액티비티는 MainActivity, 매니페스트에 메인 액티비티로 선언한다. MainActivity는 애플리케이션 시작 시 나타나는 화면이며, 애플리케이션 실행 후 조건에 따라 설정된 액티비티가 호출된다. 만약 새로운 액티비티 시작 시 기존에 실행된 액티비티는 시스템에서 스택에 저장되고 새로운 액티비티가 실행된다. 다시 기존에 액티비티를 실행하기 위해 뒤로가기 버튼을 누르면 기존에 저장한 스택에서 다시 불러와 액티비티 화면이 실행된다. 애플리케이션 액티비티가 보안적으로 취약하면 로직을 무시하고 공격자가 필요한 액티비티를 강제로 호출해서 권한이 없는 사용자가 특정 액티비티에 접근해서 권한 없이 특정 기능을 활성화 할 수 있다. 예를 들면 로그인 과정을 수행하지 않고 계좌 이체 화면으로 바로 넘어가 사용할 수 있게 되는 취약점이 있다.

액티비티는 AndroidManifest.xml의 <activity> 요소에 선언하며 하나의 애플리케이션은 하나 이상의 액티비티로 구성된다. 특정 액티비티는 MainActivity, 매니페스트에 메인 액티비티로 선언한다. MainActivity는 애플리케이션 시작 시 나타나는 화면이며, 애플리케이션 실행 후 조건에 따라 설정된 액티비티가 호출된다. 만약 새로운 액티비티 시작 시 기존에 실행된 액티비티는 시스템에서 스택에 저장되고 새로운 액티비티가 실행된다. 다시 기존에 액티비티를 실행하기 위해 뒤로가기 버튼을 누르면 기존에 저장한 스택에서 다시 불러와 액티비티 화면이 실행된다.

애플리케이션 액티비티가 보안적으로 취약하면 로직을 무시하고 공격자가 필요한 액티비티를 강제로 호출해서 권한이 없는 사용자가 특정 액티비티에 접근해서 권한 없이 특정 기능을 활성화 할 수 있다. 예를 들면 로그인 과정을 수행하지 않고 계좌 이체 화면으로 바로 넘어가 사용할 수 있게 되는 취약점이 있다.

2. 취약점 진단

[그림 2-1] adb 명령어 실행

adb shell am start –n com.android.insecurebankv2/.ChangePassword 명령어를 실행하면 그림 1-1과 같이 패스워드 변경 액티비티가 실행된다. 하지만 adb 명령어로는 패스워드 변경 권한이 있는지 없는지에 대한 여부는 알 수 없다.

[그림 2-2] 노출된 액티비티 목록

드로저를 실행해 run app.activity.info –a com.android.insecurebankv2 명령어를 실행하면 현재 노출된 액티비티 정보 목록을 검색해 볼 수 있다. 액티비티에선 exported 속성이 존재하는데 true로 선언이 되있으면 [그림 1-2]와 같이 외부에서 실행 가능한 상태로 노출되며 false로 선언이 되있으면 외부에서 실행할 수 없다. 맨 마지막 줄에 ChangePassword 액티비티가 있는데, 이미 노출되고 있음을 파악할 수 있다.

[그림 2-3] 드로저 명령어 실행

드로저 창에서 run app.activity.start--component com.android.insecurebankv2 com.android.insecurebankv2.ChangePassword 명령어를 입력하고 실행하면 그림 1-3과 같이 ChangePassword 액티비티가 실행된다.

[그림 2-4] 아이디 값 노출

드로저 창에서 run app.activity.start--component com.android.insecurebankv2 com.android.insecurebankv2.ChangePassword --extra string uname jack 명령어를 입력하면 [그림 2-4]와 같이 아이디 값이 들어가 있는 상태로 액티비티가 실행된다.

[그림 2-5] 소스 코드

ChangePassword 액티비티를 실행하는 경우 가장 먼저 수행되는 onCreate()를 볼 수 있다. 액티비티를 실행할 때 uname에게 사용자 이름을 전달하고 이 값을 textView_Username.setText(uname)을 통해 화면에 표시된다. 비밀 번호를 입력한 후 Changepassword 버튼을 누르면 ChangePassword.RequestChangePasswordTask가 실행된다. 이후 코드는 입력된 값을 서버로 전송한다.

[그림 2-6] 패스워드 변경

기존의 비밀번호를 변경해본다. 패스워드는 대, 소문자, 특수문자가 섞여야 변경되기 때문에 최대한 어렵게 변경한다.

[그림 2-7] 로그인 성공

비밀번호를 변경하고 로그아웃 해서 변경된 패스워드로 다시 로그인한다. 변경된 패스워드로 로그인이 되면 [그림 2-7]과 같은 화면이 나온다.

3. 대응 방안

[그림 3-1] 코드 변경

Android Manifest.xml을 확인한 후 Android:exported=”true”를 false로 변경한다. exported는 외부 application 에서 launch 가능 여부를 나타내는 속성이다. 해당 속성이 true면 다른 애플리케이션에서 액티비티를 실행할 수 있고 false인 경우엔 동일한 애플리케이션에서만 실행할 수 있거나 같은 사용자 ID를 가진 애플리케이션만 실행이 가능하다.

[그림 3-2] 권한 거부

run app.activity.start --component com.android.insecurebankv2 com.android.insecurebankv2.ChangePassword --extra string uname jack 명령어를 드로저 창에 입력하면 권한이 거부되었다는 메시지가 나오게 된다. 권한이 거부되면 바로 ChangePassword 창에 접근을 할 수 없게 된다.

[그림 3-3] 권한 목록 확인

run.app.activity.info –a com.android.insecurebankv2 명령어를 드로저 창에 입력해 권한 목록들을 확인해보면 ChangePassword는 없는 것으로 확인된다. 이제 ChangeActivity에 접근하려면 정당한 절차를 거쳐야 실행할 수 있다.

1. 취약점 소개

웹 뷰는 앱을 개발할 때 웹 브라우저에서 보이는 화면을 표시하거나 웹 애플리케이션 등을 만들 때 자주 사용한다. 웹 뷰는 안드로이드 내부 모듈의 웹 킷 렌더링 엔진을 사용해 자바스크립트를 사용할 수 있다. 하지만 자바스크립트가 악의적인 목적으로 사용되면 XSS 공격이 가능하고 다른 사용자의 중요 정보를 탈취할 수 있는 취약점이 된다. 현재 인시큐어뱅크 앱에서도 XSS 공격이 가능하기 때문에 어떻게 취약점을 방어할 수 있는지에 대해 알아본다.

2. 취약점 진단

[그림 2-1] XSS 공격 스크립트

인시큐어뱅크 앱에 로그인 한 후 Transfer 버튼을 클릭한다. XSS 취약점이 발생하는 곳은 계좌번호를 보내는 칸이다. To Account 칸에 <script>alert(“Test”)</script>를 입력한 후 Amount를 지정하고 Transfer 버튼을 클릭해 정보를 ViewStatement에 전송한다.

[그림 2-2] XSS 공격 결과

Transfer에서 보낸 정보들을 확인하기 위해 ViewStatement를 확인하면 그림 4‑2와 같이 XSS 공격이 되었음을 확인할 수 있다. XSS 공격은 몇가지 종류가 있다. XSS 공격 종류는 Stored XSS 공격, Reflected XSS 공격이 있다. 두가지 공격은 성격이 조금씩 다른 공격인데, Stored XSS 공격은 공격자가 악성코드를 웹 서버에 저장하고 사용자가 악성스크립트를 심어 놓은 게시글을 실행하기를 기다리지만 Reflected XSS 공격은 URL주소에 악성스크립트를 삽입해 사용자를 유도해서 의도하지 않은 URL로 이동되어 피해를 준다. Reflected XSS 공격도 쇼핑몰에서 사용자가 원치 않은 가격 결제, 바이러스가 있는 사이트로 이동될 수 있는 피해가 발생할 수 있다. 일반 공격스크립트로 작성하면 사용자가 유심히 보면 금방 알아챌 수 있기 때문에 URL 인코딩 방법으로 작성하는 공격이 일반적이다. 모바일 진단에서도 XSS 공격은 웹과 거의 유사한 성격을 띤다.

[그림 2-3] sdcard 목록

adb shell 명령어를 입력해 단말기 내부에 접속한다. 경로를 외장 메모리인 sdcard로 경로를 바꾼다. ls -l 명령어를 입력해 파일 목록을 확인해보면 Statements_jack.html 파일이 있다. 여기에 Transfer에서 보낸 정보들이 저장되어 있다. Cat Sta* 명령어를 입력해 확인하면 XSS 공격을 하기위해 사용했던 자바스크립트를 확인할 수 있다. 이제부터 XSS 공격을 막기 위해 시큐어 코딩을 할 것이다. 만약 시큐어코딩이 성공한다면 XSS 공격은 더 이상 할 수 없고 Statements_jack.html 파일에도 평문 스크립트가 아닌 특수 문자로 처리된 스크립트를 볼 수 있다.

3. 대응 방안

[그림 3-1] 시큐어 코딩 – 1

XSS 취약점 공격을 방어하기 위해 시큐어 코딩을 한다. DoTransfer.java 파일에서 getText() 함수가 있는 곳에 XSS 공격에서 주로 쓰이는 문자열들을 필터링 하는 코드를 추가한다. 주로 >,<,\\ 등의 문자열이 있다. 코드를 추가한 후 아래에서 출력해주는 변수 값도 바꿔줘야 코드가 정상적으로 작동한다.

[그림 3-2] 시큐어코딩 – 2

DoTransfer.java 파일에서 아래로 내려와 JSONObject 함수, makeText() 함수를 찾아 그림 1-4와 동일한 XSS 공격에서 주로 쓰이는 문자열들을 필터링하는 코드를 추가한다. 이 때, 출력되는 함수값도 같이 변환해야 정상적인 값이 출력된다.

[그림 3-3] XSS 공격

시큐어 코딩을 한 파일을 다시 실행시켜 녹스플레이어에 인시큐어뱅크 앱을 설치한다. 인시큐어뱅크 앱이 설치된 후 로그인해서 DoTransfer에 XSS 공격 스크립트를 넣고 Transfer 버튼을 클릭한다.

[그림 3-4] 공격 결과

ViewStatement를 실행해 결과를 보면 XSS 공격 문자열이 필터링 되서 공격이 불가능하다. 공격성 문자열이 필터링되서 참조 문자로 인코딩됐기 때문이다. 주로 사용되는 XSS 공격 문자는 [표 1-1]과 같다.

[표 1-1] 가장 많이 쓰이는 위험 문자

[그림 3-5] sdcard

adb shell 명령어를 입력해 단말기 내부에 접속한다. 경로를 외장 메모리인 sdcard로 경로를 바꾼다. ls -l 명령어를 입력해 파일 목록을 확인해보면 Statements_jack.html 파일이 있다. 여기에 Transfer에서 보낸 정보들이 저장되어 있다. Cat Sta* 명령어를 입력해 확인하면 XSS 공격을 하기위해 사용했던 자바스크립트를 확인할 수 있다. 단말기 내부의 메모리 확인 결과 XSS 공격 문자열이 필터링 됨을 볼수 있다. XSS 공격은 모바일 뿐만 아니라 웹에서도 같은 방법으로 차단이 가능하다.

1. 취약점 소개

안드로이드 애플리케이션은 실행이 되는 도중에 중요한 정보들을 저장할 때가 많다. 하지만 중요한 정보들을 저장할 때 제대로 암호화 되지 않은 상태에서 저장되게 된다면 제 3자에게 중요 정보, 민감한 정보 등이 유출될 수 있다. 암호화는 됐지만 디코딩 도구들로 해독이 되어도 문제가 된다. 취약점 점검에 앞서 암호화 할 때 크게 2가지로 나눌 수 있는 대칭키와 공개키가 있다.

[표 1-1] 대칭키와 공개키의 비교

대칭키는 암호화 키와 복호화 키가 같다. 즉, 하나의 키로 암호화와 복호화를 한다. 이런 이유로키를 보내지 않으면 수신자는 수신한 암호문을 복호화 할 수 없게 된다. 그래서 대칭키의 최대 단점이 키 배송 문제가 있다. 또한 하나의 키로만 사용해서 키가 노출될 경우 모든 암호문을 복호화 할 수 없다는 단점도 존재한다. 반면 공개키는 암호화 키와 복호화 키가 서로 다르기 때문에 키 배송문제가 발생하지 않는다. 주로 비밀 경로를 통해서 키가 전달되게 된다. 하지만 공개키도 단점은 있다. 중간자 공격에 매우 취약하며 비용이 비싸다.

2. 취약점 진단

[그림 1-1] 인시큐어뱅크 로그인 페이지

인시큐어뱅크 앱을 실행하면 로그인 화면이 보인다. 여기서 Autofill Credentials를 클릭하면 자동으로 아이디, 패스워드를 생성한다. 이는 아이디, 패스워드가 앱 내부 데이터에 저장되어 있을 가능성이 크다. 실제 금융권 앱을 사용하다 보면 [그림 1-1]과 같이 자동으로 아이디, 패스워드를 생성해주는 기능이 있다.

[그림 1-2] adb shell

인시큐어뱅크 앱을 실행한채로 cmd 창을 실행해 adb shell 명령어를 입력해 가상 디바이스 내부로 접속한다.

[그림 1-3] 인시큐어뱅크 데이터 저장

adb shell 명령어를 실행한 후 cd /data/data/com.android.insecurebankv2를 입력해 인시큐어뱅크 앱의 데이터가 저장되는 장소를 확인한다.

[그림 1-4] 데이터 저장 장소

cd com.android.insecurebankv2를 입력해 데이터가 저장되는 장소로 이동 후 ls -l 명령어를 입력해 어떤 정보가 저장되어 있는지 확인한다.

[그림 1-5] adb pull 명령어

C 드라이브에 tmp 폴더를 하나 생성하고 tmp 폴더로 경로를 이동해 adb pull /data/data/com.android.insecurebankv2 .\를 입력해 인시큐어뱅크 앱에 저장된 데이터들을 로컬로 가져온다. 성공적으로 명령어가 실행되면 7 file pulled. 0 files skipped 라는 메시지가 나온다. 각각의 데이터 경로에 저장 되어 있는 파일 중에 Insecurebankv2_preferences.xml는 사용자 아이디를 포함한 EncryptedUsername을 포함하고 비밀번호를 포함한 superSecurePassword 문자열 변수가 있다. com.android.insecurebankv2_preferences.xml는 서버의 아이피와 포트 정보가 포함되어 있다. 또한 Shared_Preferences는 초기 설정값과 자동로그인 정보들이 애플리케이션 저장 공간 안에 파일 형태로 저장된다.

[그림 1-6] 데이터베이스

로컬로 가져온 데이터들 중 데이터베이스 폴더에 있는 mydb 파일을 sqliteBrowser 도구를 활용해 연다. 파일이 열리고 Browse Data 탭의 테이블에서 names를 선택하면 인시큐어뱅크 앱에서 로그인했던 아이디 정보가 나온다. 하지만 아이디 정보만 나오고 비밀번호는 나오지 않아 원하는 정보를 얻을 수 없다.

[그림 1-7] 계정 정보

com.android.insecurebankv2_preferences.xml 파일을 인터넷 익스플로러로 연다. 인터넷 익스플로러로 열면 파일 내용이 브라우저에 나오는데 인시큐어뱅크 앱에서 로그인했던 정보들이 암호화가 되어 있는 상태로 있다. Base64 Decorder 도구를 활용해 아이디, 패스워드를 해독한다.

[그림 1-8] 아이디 암호 해독

암호 해독을 위해 Fiddler 도구를 활용한다. Fiddler를 실행해 TextWizard 탭을 클릭하면 암호를 해독할 수 있는 텍스트가 출력된다. From Base64로 옵션을 지정하고 그림 3‑7에서 Encrypted Username의 내용을 입력해 복호화한다. 복호화가 되면 jack이라는 메시지가 출력된다. 이는 인시큐어뱅크 앱에서 로그인 했던 아이디 값임을 알 수 있다.

[그림 1-9] 비밀번호 암호 해독

[그림 3‑8]과 같은 방법으로 이번엔 superSecurePassword의 내용을 입력해 복호화한다. [그림 3‑8]과 달리 해독 내용이 알 수 없는 문자들로 출력된다. Base 64 옵션 외에 다른 옵션을 지정해도 결과는 같다. 패스워드는 확실하게 암호화가 되어 있다는 사실을 확인할 수 있다.

3. 대응 방안

인시큐어뱅크 앱에서 데이터를 저장하는 방식이 가장 큰 문제점은Base 64 방식으로 암호화를 한 것이다. 하지만 Base 64 방식은 특정 알고리즘에 의해 치환되는 형태기 때문에 암호 해독 도구를 이용하면 쉽게 디코딩 될 수 있다. 아이디 부분도 패스워드와 같이 AES 형태를 적용해야 한다.

[표 1-2] 해외 및 국내 암호화 방식

[표 3‑2]는 KISA에서 제공해주는 암호화 방식 가이드 라인이다. 인시큐어뱅크 앱에서 사용한 AES-256비트는 강력한 암호 방식에 속한다. 하지만 암호키 값을 동일하게 유지하면 다른게 보안이 잘 되어 있어도 쉽게 뚫릴 수 있는 소지가 있기 때문에 늘 암호키 값을 바꿔 줘야 한다. 그래서난수라는 기술을 적용한다. 암호키는 탈취되서 해독되면 2차 피해가 발생할 가능성이 높기 때문에 가장 강력한 암호 기술을 적용해야 한다.

[그림 1-10] 수정된 LoginActivity.java

[그림 3‑10]은 암호화와 관련이 있는 LoginActivity.java 코드이다. 상단 부분 코드를 보면 username을 Base64 방식으로 암호화 한 것을 볼 수 있다. 이 부분을 주석 처리 하고 Username_Text 위에 AES 암호화 방식 코드를 추가한다. 이미 Password_Text는 AES 암호화 코드가 적용 되어 있기 때문에 따로 추가할 코드는 없다. 결론적으로 Username_Text에 아이디, 비밀번호가 입력 되서 로그인 되면 String decryptedUsername = crypt.aesDecryptedString(username); 코드에 의해 아이디가 AES 암호화방식으로 앱 내부 데이터에 저장된다.

[그림 1-11] 수정된 DoLogin.java

LoginActivity.java 코드를 수정한 후 DoLogin.java 파일의 코드도 수정한다. 현재 DoLogin.java 파일에서도 username는 Base64 암호화 방식을 사용하기 때문에 해당 코드 부분을 주석 처리 하고 String encryptedUsername = crypt.aesEncryptedString(rememberme_username);을 추가해 AES 암호화 방식으로 변경한다. MYPREFS 변수 윗부분의 데이터 저장 파일 이름이 mySharedPreferences로 정의되어 있다. 파일 생성 후 사용자의 아이디, 패스워드를 저장해 CryptoClass 함수에 의해 암호화 된다. 코드를 추가한 후 다시 디버깅해 인시큐어뱅크 앱을 가상 디바이스에 설치한다.

[그림 1-12] adb pull 명령어

인시큐어뱅크 앱이 가상 디바이스에 설치되면 다시 로그인 한 후 만들어 둔 tmp 폴더 경로를 지정하고 adb pull /data/data/com.android.insecurebankv2 .\를 입력해 인시큐어뱅크 앱에 저장된 데이터들을 로컬로 가져온다.

[그림 1-13] 계정 정보

com.android.insecurebankv2_preferences.xml 파일을 인터넷 익스플로러로 연다. 익스플로로러가 실행되면 인시큐어뱅크 앱에서 로그인했던 정보들이 암호화가 되어 있는 상태로 있다. 아이디 내용을 보면 [그림 1-7]과는 내용이 조금 달라졌다는 걸 추측할 수 있다. 암호를 해독하기 위해 Fiddler 도구를 실행한다.

[그림 1-14] 아이디 암호 해독

TextWizard 탭을 실행해 암호 해독 도구를 실행하고 From Base64 옵션으로 바꾼 후 Encrypted Username의 내용을 입력해 복호화한다. [그림 1-7]과는 달리 아이디 값이 평문으로 출력되지 않고 여전히 암호화 되서 출력됨을 알 수 있다. 다른 옵션으로 바꿔서 실행해도 결과값은 같다.

[그림 1-15] 패스워드 암호 해독

[그림 1-14]와 같은 방법으로 이번엔 superSecurePassword의 내용을 입력해 복호화한다. 패스워드는 여전히 해독 내용이 알 수 없는 문자들로 출력된다. Base 64 옵션 외에 다른 옵션을 지정해도 결과는 똑같다. 이로써 아이디, 패스워드 모두 안전하게 암호화 조치가 완료되었다.

1. 취약점 소개

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

기본적으로 전체 백업은 해당 애플리케이션의 Android Manifest.xml에 포함된 allowBackup 속성을 따른다. 값이 아예 설정 되어 있지 않거나 false로 설정될 경우 추출하려는 패키지의 데이터가 추출되지 않게 된다. 안드로이드 시스템 기본값은 백업값이 설정되어 있지 않으면 백업을 사용하지 않는 것으로 설정된다. 인시큐어뱅크 앱은 allowBackup이 설정되어 있고 전체 백업 수행이 가능하다.

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로 설정해 변환된 백업 데이터에 대한 내용이 노출 되지 않도록 한다.

[그림 3‑1] AndroidManifest.xml

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

[그림 3‑2] adb backup 명령어

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

[그림 3‑3] 전체 백업

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

[그림 3‑4] 파일 생성

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

[그림 3‑5] 알집 파일 실행 결과

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