Research on Secure Coding and Weakness for Implementation of Android-based Dynamic Class Loading

안드로이드 동적 클래스 로딩 기법을 이용한 개발단계에서의 보안약점 및 시큐어 코딩 연구

Abstract

Android application is vulnerable to reverse engineering attack. And by this, it is easy to extract significant module from source code and repackage it. To prevent this problem, dynamic class loading technique, which is able to exclude running code from distributed source code and is able to load running code dynamically during runtime can be used. Recently, this technique was adapted on variety of fields and applications like updating pre-loaded android application, preventing from repacking malicious application, etc. Despite the fact that this technique is used on variety of fields and applications, there is fundamental lack on the study of potential weakness or related secure coding. This paper would deal with potential weaknesses during the implementation of dynamic class loading technique with analysing related international/domestic standard of weaknesses and suggest a secure way for the implementation of dynamic class loading technique. Finally, we believe that this technique described here could increase the level of trust by decreasing the weakness related to dynamic class loading technique.

1. 서 론

안드로이드 어플리케이션은 이식성이 높은 자바로 개발단계에서 구현되며, 자바의 특성 상 역공학에 의한 소스코드 추출이 쉽다. 소스코드 추출 이후에는 정적분석이 가능하고, 중요한 연산을 수행하는 모듈을 도용하거나 악성코드를 삽입하여 리패키징하는 등의 공격에 취약하다. 안드로이드 어플리케이션이 저작권 및 경제적 손실과 직접적으로 연관되는 민감한 연산 모듈을 포함하고 있을 경우 이를 역공학으로부터 보호할 수 있는 방법이 필요하다. 또한 악성코드의 삽입 및 리패키징으로 배포한 소스코드가 위변조되는 것을 방지할 수 있는 효과적인 방법 또한 고려되어야 한다.

이를 위해서 자바에서 제공하는 동적 클래스 로딩이라는 기법을 활용 할 수 있으며, 이 기법은 런타임에 소프트웨어 컴포넌트를 동적으로 로딩할 수 있도록 하는 강력한 메커니즘이다[1]. 자바에 기반하고 있는 안드로이드 환경에서도 역시 배포되는 소스코드에는 실행 코드를 포함하지 않고, 런타임 시점에 코드를 동적으로 로딩하여 사용할 수 있는 동적 클래스 로딩 기법의 적용이 가능하다. 이 기법을 통하여, 배포되는 어플리케이션의 역공학 및 정적분석으로 유출될 수 있는 중요한 연산 모듈에 대해 런타임에만 동적으로 로딩하여 보호할 수 있다. 이를테면, 저작권에 민감한 모듈의 경우 서버로부터 해당 모듈을 APK 파일 형태로 수신하고 런타임 시점에 로딩하여 정적분석으로 인한 소스코드 유출로부터 보호할 수 있다. 또한, 악성코드의 삽입 등으로 배포한 소스코드가 위변조되는 것을 방지하기 위한 무결성 검증에도 동적 클래스 로딩 기법이 사용된다[2,3].

최근 이렇게 동적 클래스 로딩 기법이 개발단계에서 많이 사용되고 있지만, 개발단계에서 이 기법을 사용할 때 잠재된 보안약점이나 관련 시큐어 코딩에 대해서는 연구가 부족한 실정이다. 개발단계에서의 보안약점은 곧 취약점으로 연결되며 동적 클래스 로딩은 다양한 안드로이드 어플리케이션 개발에 활용되기 때문에 이에 대한 연구가 필요하다.

본 논문의 구성은 다음과 같다. 2장에서는 배경지식에 대해 소개하고, 3장에서는 동적 클래스 로딩 기법을 사용하여 안드로이드 어플리케이션의 위/변조 방지 및 무결성 검증을 제공하는 대표적인 기법에 대해 소개하고 보안약점으로부터 안전한지와 취약점에 대해 소개한다. 4장에서는 개발단계에서 동적 클래스 로딩 기법을 적용하였을 때 발생할 수 있는 보안약점에 대해 살펴보고, 실제 공격 예시와 해당 보안약점 관련 국내외 표준에 대해 분석하고 알아본다. 5장에서는 안전한 동적 클래스 로딩 기법 구현 방안을 제시하고 관련 공통 공격 벡터로부터 안전한지 살펴보며 요약과 함께 결론을 맺는다.

 

2. 배경지식

본 장에서는 안드로이드 동적 클래스 로딩 기법을 이용한 개발단계에서의 보안약점을 도출하기 위한 배경지식을 소개한다. 또한, 국내외 보안약점 연구에 대한 동향과 표준에 대한 배경지식을 소개한다.

2.1. 동적 클래스 로딩 기법(DexClassLoader)

DexClassLoader 클래스를 사용하면, classes.dex 파일을 포함하는 외부의 .jar 또는 .apk 파일로부터 런타임에 실행 코드를 사용할 수 있다. DexClass Loader 클래스에 대한 상세는 Table 1과 Table 2에서 확인할 수 있다.

Table 1.DexClassLoader Constructor details

Table 2.DexClassLoader Parameters details

2.2 동적 클래스 로딩 기법(PathClassLoader)

PathClassLoader 클래스를 사용하면, DexClass Loader 클래스와 마찬가지로 classes.dex 파일을 포함하는 외부의 .jar 또는 .apk 파일로부터 런타임에 실행 코드를 사용할 수 있다.

PathClassLoader 클래스에 대한 상세는 Table 3과 Table 4에서 확인할 수 있다.

Table 3.PathClassLoader Constructor details

Table 4.PathClassLoader Parameters details

2.3 안드로이드 NDK 프로그래밍 기법

안드로이드 어플리케이션은 자바를 기반으로 안드로이드 SDK를 사용하여 개발된다. 이때, 자바 언어가 아닌 C/C++ 등의 다른 언어로 네이티브 라이브러리를 구현하고, 이를 자바 기반의 안드로이드 어플리케이션과 연동하여 사용할 수 있다. 이렇게 연동하여 자바 기반이 안드로이드 소스코드에서 C/C++ 등의 다른 언어로 작성된 네이티브 라이브러리의 특정 메소드를 호출하는 것이 가능하며 또한 그 반대도 가능하다. 이러한 상호 메소드의 호출은 JNI(Java Native Interface)를 이용하여 이루어진다[4]. 이러한 메커니즘을 이용하여 중요한 연산 모듈을 네이티브 라이브러리의 형태로 구현하면 안드로이드 어플리케이션이 역공학 및 정적분석을 당하더라도 보호할 수 있다.

2.4. 개발단계에서의 보안약점과 시큐어코딩

개발단계에서의 보안약점은 소프트웨어(SW) 결함, 오류 등으로 해킹 등 사이버 공격을 유발할 가능성이 있는 잠재적인 보안취약점을 말한다[5]. SW 개발보안은 이러한 보안약점을 최소화하고 사이버 보안위협에 대응할 수 있는 안전한 SW를 개발하기 위한 일련의 보안활동을 의미한다[6]. 즉, 이러한 SW 개발보안은 협의적 의미에서 개발단계에서 보안약점을 배제하기 위한 시큐어코딩(secure coding)을 의미한다. 국내외에서 이러한 SW 개발보안의 중요성을 인식하여 관련 연구를 활발히 진행하고 있고 해당 보안활동 및 절차를 표준화하고 있다[6].

2.4.1 국외 개발단계에서의 보안약점 연구 동향 및 표준

미국의 경우 개발단계에서의 보안약점 연구의 중요성을 미리 인식하여, 국토안보부(DHS)를 중심으로 관련 연구를 활발히 진행하고 있다[7]. DHS는 관련 민간 연구 기관인 MITRE社를 지원하여 SW 보안약점을 다양한 관점에서 분류하고 보안약점 목록인 CWE(Common Weakness Enumeration) 정보를 제공하도록 하고 있다[23]. 또한, 해당 보안약점의 위험도를 표현하기 위한 점수 체계인 CWSS(Common Weakness Scoring System) 정보를 제공하고 있다. CWE의 보안약점 정보는 실제 IT 제품에서 발견된 보안 취약점의 히스토리 기록 정보인 CVE(Common Vulnerabilities and Exposures)의 원인으로 추가 및 갱신되어 지속적으로 관리되고 있다[10].

CWE는 2008년 9월 버전 1.0으로 시작되었으며 2015년 12월에 버전 2.9을 발표하여 총 1,004개의 항목을 제공하고 있다. 2011년에 각 CWE 항목의 점수 체계인 CWSS를 기반으로 SANS社와 함께 SW를 위험하게 만드는 상위 25개의 CWE 항목을 발표하고 있다[9]. 그리고 웹 어플리케이션에 특화된 관련 보안 기관인 OWASP(The Open Web Application Security Project)는 매년 다양한 전문가 의견을 수렴하여 가장 위험한 상위 10개의 웹 어플리케이션에 특화된 주요 보안약점을 발표하고 있다[11]. 2014년 부터는 OWASP에서도 모바일 어플리케이션 특화된 주요 보안약점 상위 10개(OWASP Top 10 Mobile Risks M1∼M10)에 대해서도 발표하고 있다[12].

2.4.2 국내 개발단계에서의 보안약점 연구 동향 및 표준

안전행정부는 한국인터넷진흥원(KISA)와 함께 2009년부터 SW 보안약점을 진단하여 제거하는 SW 개발보안(시큐어코딩) 관련 연구를 진행하였다. 2009년부터 SW 개발보안 제도 도입 및 정착과 안전한 SW 개발을 위해 SW 개발보안 관련 가이드를 배포하고 있다. 관련 연구를 진행하면서 2012년까지 전자정부지원사업 등을 대상으로 KISA가 자체 개발한 SW 보안약점 분석도구를 기반으로 SW 보안약점 시범진단 서비스를 제공하였는데 SW 라인수는 평균 87만라인으로 2010년도의 경우 평균 2,400개의 보안약점을, 2011년도의 경우 평균 1,328개의 보안약점을 진단하여 조치하도록 하였다[10].

이러한 SW 보안약점 제거 및 조치 성과에 따라, 2012년 6월에 행정안전부 ‘정보시스템 구축·운영 지침’이 개정·고시됨으로써 전자정부서비스 개발 시 적용토록 의무화되었다[6]. 최근 2013년 8월 해당 지침이 일부 개정되어 ‘행정기관 및 공공기관 정보시스템 구축·운영 지침’４이 고시되면서 안전한 SW 개발을 위해 필수 진단하여 제거해야 하는 SW 보안약점 기준이 개정되어 43개 항목에서 47개 항목으로 조정되었다[5,8,10].

 

3. 관련 연구

서론에서 살펴본 것처럼, 안드로이드 어플리케이션은 자바로 개발단계에서 구현되며 자바의 특성 상역공학으로 인한 소스코드 추출과 악성코드를 삽입하여 리패키징하는 등의 공격에 취약하다. 이러한 정상 어플리케이션에 악성코드를 삽입 및 리패키징하여 안드로이드 어플리케이션을 위/변조하는 것을 방지하는 방법들이 많이 사용되고 있으며, 특히 스마트폰 뱅킹 앱과 같은 민감한 어플리케이션들에서는 필수적으로 이러한 방법들이 적용되고 있다. 이러한 방법들의 세부 항목은 상이하더라도 모두 동적 클래스로딩 기법을 개발단계에서 사용하여 구현된다는 공통점이 있다.

본 장에서는 동적 클래스 로딩을 개발단계에서 사용하여 안드로이드 어플리케이션의 위/변조 방지 및 무결성 검증을 제공하는 대표적인 연구에 대해 소개하고 보안약점으로부터 안전한지에 대해 소개한다. 또한, 해당 보안약점이 기존의 스마트폰 뱅킹 앱 무결성 검증의 취약점으로 활용되어 실제 어플리케이션 위변조 공격이 가능하다는 내용의 관련 연구를 소개한다.

Fig. 1.Summary of MysteryChecker: Unpredictable Attestation to Detect Repackaged Malicious Applications in Android[2].

3.1 안드로이드 리패키징 악성 앱 탐지 연구

J. Jeong 등은 예측 불가능한 검증 알고리즘을 이용해 코드의 변조를 탐지하는 MysteryChecker라는 새로운 소프트웨어 기반 검증 방식을 제안하였다[2]. 해당 연구의 주된 내용은 다음과 같다. 검증 서버는 매번 새로이 생성되는 검증 모듈(attestation module)을 스마트폰 뱅킹 앱과 같은 사용자의 중요한 정보를 다루는 타겟 어플리케이션에 전달한다. 이 때 타겟 어플리케이션은 전달받은 모듈 안에 있는 랜덤 검증 알고리즘에 의해 생성된 올바른 결과 값을 검증 서버로 전달해야한다. 만약 공격자가 전달받은 이전의 검증 모듈을 역공학으로 분석한다 하더라도, 타겟 어플리케이션은 새롭게 생성된 검증 모듈을 검증 서버로부터 전달받아 기존 검증 모듈을 대체한다. 그러면 공격자가 분석했던 기존 검증 모듈에 대한 분석은 무효하게 된다[2].

3.1.1 개발단계에서의 동적 클래스 로딩 기법 관련 보안약점 내재

위의 기법에서 소개하는 검증 서버에서 매번 새로이 생성되는 검증 모듈(attestation module)은 결국 classes.dex 파일을 포함하는 외부의 .jar 또는 .apk 파일이다. 이를 타겟 어플리케이션에서 전달 받아 실행하여 올바른 결과 값을 얻고 다시 검증 서버에 전달하기 위해서는 런타임에 해당 모듈을 실행해야 한다. 이를 가능하게하기 위해서는 개발단계에서 동적 클래스 로딩 기법을 사용해야 한다. 해당 연구에서는 위변조 탐지와 무결성 검증에 대한 훌륭한 기법을 고안하였지만, 실제 이를 개발단계에서 동적 클래스 로딩으로 구현할 때의 보안약점은 고려하지 않았으며 공격자는 이러한 개발단계에서의 보안약점을 통해 여전히 공격을 시도할 수 있다. MITRE社에서 제공하는 Fig. 2를 통해 개발단계에서의 보안약점이 공격자의 Attack point가 되어 보안취약점의 원인이 될 수 있음을 알 수 있다.

Fig. 2.Engineering for attacks summarized by MITRE.

3.2 동적 클래스 로딩 기법 기반 앱 취약점 연구

S. Kim 등은 안드로이드 역공학 분석 기법들을 이용하여 뱅킹 앱의 무결성 검증 기능 취약점을 제시하였다[3]. 또한, 제시한 취약점이 이용될 경우, 실제 뱅킹 앱의 무결성 검증 기능이 매우 간단하게 우회되어 리패키징을 통한 악성코드 삽입 공격이 이루질 수 있으며 그 위험성이 높다는 것을 실험결과로 증명하였다[3]. 해당 취약점은 무결성 검증을 위해 개발 단계에서 APK path 를 얻어오는 구현방식에 따라 우회 방법을 적용하여 APK path를 수정함으로써 발생한다.

Table 5.Variety of ways to modify APK path for each way of implementation[3]

스마트폰 뱅킹 앱은 특히 금융당국에서 관련 법규를 제정하여 무결성 검증 기능을 넣어 역공학과 악성코드 삽입을 통한 리패키징에 대응하고 있지만, 무결성 검증 기능이 반영되어 있다고 하더라도 개발단계에서의 보안약점으로 인해 여전히 취약성이 존재함을 알 수 있다.

 

4. 동적 클래스 로딩 보안약점

동적 클래스 로딩의 보안약점은 신뢰할 수 없는 소스 또는 환경에서 명령을 실행하거나 라이브러리를 로딩하면 공격자의 악성코드를 실행할 수 있다는 내용의 CWE-114 : Process Control과 관련이 깊다[14]. 안드로이드에서 동적 클래스 로딩 구현 시 보안 약점은 다음과 같다.

Table 6.Extract smali from apk by using dex2jar program(saving at test-out folder)

4.1 DexClassLoader 및 PathClassLoader의 dexPath 파라미터 보안약점

DexClassLoader 및 PathClassLoader 클래스를 사용할 때, 첫 번째 파라미터인 dexPath는 DEX 코드를 포함하는 .jar파일이나 .apk 파일의 경로를 의미한다. 이 경로는 반드시 현재 실행 중인 안드로이드 어플리케이션에서만 접근 가능한 경로(application-private, writable directory 이하 APK path)이어야 한다.

만약 이 파라미터에 해당하는 경로가 SD Card와 같은 어떤 프로세스에서나 접근 가능한 경로라면, 공격자가 DEX 코드를 악성코드로 교체할 수 있다.

APK path는 안드로이드 API에서 제공하는 getPackageCodePath(), getApplicationInfo(), getDir() 메소드 등을 통해서 얻을 수 있다. 즉, 해당 DEX 코드를 담고 있는 .jar 또는 .apk 파일을 서버로부터 다운로드 받아 getPackageCodePath() 등을 통해 APK path를 얻어 해당 경로에 저장하고 dexPath 파라미터에 해당 경로를 지정한다.

만약, 공격자가 이러한 경로를 얻는 메소드를 오버라이딩하여 SD Card와 같은 공격자가 접근 가능 한 경로로 수정한다면, DEX 코드를 공격자가 원하는 코드로 변조할 수 있다[13].

Fig. 3.DexClassLoader related implementation code in smali.

4.2. ODEX(optimized DEX) 보안약점

DexClassLoader를 사용하여 DEX 코드를 런타임에 로딩하면, ODEX(Optimized DEX)라는 해당 디바이스에 최적화된 버전의 DEX 코드가 생성되며 optimizedDirectory 파라미터에 지정된 경로에 저장되어 사용된다. 이 파라미터 또한 APK path로 지정되어야한다.

이 파라미터에 지정된 경로가 SD Card 등 공격자가 접근 가능한 경로로 수정된다면 역시 DEX 코드를 공격자가 원하는 코드로 변조한 것과 같은 효과를 가진다[13].

optimizedDirectory는 getCodeCacheDir()를 통해 얻은 경로로 지정할 수도 있다. 하지만, getCode Cache Dir() 메소드 역시 공격자가 오버라이딩하면 공격자가 접근 가능한 경로로 수정하고 공격할 수 있다.

4.3 동적 클래스 로딩 기법의 보안약점을 이용한 공격 예시

동적 클래스 로딩 기법을 사용하고 있는 안드로이드 어플리케이션의 경우에는 역공학을 통해 이를 정적분석하고, 악성코드 삽입과 리패키징하여 배포하는 공격이 가능하다. 본 절에서는 개발단계에서 DexClassLoader를 사용하여 동적 클래스 로딩 기법을 구현한 어플리케이션에 대해 역공학하고 악성코드를 smali 코드를 통해 삽입하는 시나리오를 소개한다.

4.3.1 안드로이드 어플리케이션 역공학 및 smali 코드 분석

안드로이드 스마트폰에 설치되어 있는 특정 APK 파일을 분석을 위해 PC 환경으로 복사한다. 관련 공개 도구인 dex2jar 프로그램을 사용하면 해당 APK 파일으로부터 smali 코드를 추출할 수 있다[15].

이후, 각 smali 코드에 분석을 위한 로그를 삽입하여 리패키징 후 실행하면, 이후 로그를 분석할 수 있다[3]. 동적 클래스 로딩 기법을 사용하여 어플리케이션의 무결성을 검증하는 기능이 반영되어 있다면, 실행 직후 위변조/무결성 관련 메시지와 함께 어플리케이션 종료될 것이다.

4.3.2 smali 코드 삽입 및 리패키징을 통한 검증 우회 및 공격 성공

로그 분석을 통해 smali 코드에서 동적 클래스 로딩 기법을 사용하는 코드를 찾을 수 있다. 해당 코드는 DexClassLoader를 통해 동적 클래스 로딩 기법을 사용함을 알 수 있다.

위 smali 코드에서 ⓑ와 ⓒ는 DexClassLoader를 이용한 동적 클래스로딩 기법의 구현에 해당하며, ⓐ의 getPackageCodePath()를 통해 DEX 코드를 포함하는 .jar파일이나 .apk 파일의 경로를 지정함을 알 수 있다. 만약 getPackageCodePath()를 오버라이딩하여 SD Card와 같은 어떤 프로세스에서나 접근 가능한 경로를 리턴하도록하는 smali 코드를 삽입한다면 공격에 성공하게 된다.

Table 7.Weakness related to binary planting attack and recent attack cases

위의 Fig. 4의 코드에서 ⓓ는 어떤 프로세스에서나 접근 가능한 경로인 SD Card의 경로를 리턴하는 smali 코드이다. Fig. 4 처럼 공격자가 해당 smali 코드를 삽입함으로써 동적 클래스 로딩 사용 시 입력되는 DEX 코드를 포함하는 .jar파일이나 .apk 파일의 경로를 SD Card와 같은 어떤 프로세스에서나 접근 가능한 경로로 수정할 수 있다. 수정된 경로에 공격자의 악성코드를 포함하는 DEX 코드를 위치시키고, 어플리케이션에서 이를 로딩 한다면 공격에 성공하게 된다.

Fig. 4.Smali code of returning APK path by overriding getPackageCodePath() method.

4.4. 관련 국제표준 OWASP Mobile Top 10, CWE, CAPEC, 국내표준 매핑 및 분석

동적 클래스 로딩 기법 사용 시 발생할 수 있는 보안약점과 매핑되는 OWASP, CWE 와 그에 연결된 공통 공격 패턴(CAPEC)을 알아보면 잠재된 다양한 취약점과 그에 대한 실제 공격 패턴 정보를 확인할 수 있다.

동적 클래스 로딩 기법을 이용한 개발단계에서의 보안약점은 OWASP 분류체계에 따르면 Binary planting 공격에 해당한다[16]. Binary planting 공격은 공격자가 악성코드를 포함하는 바이너리 코드를 로컬이나 원격 시스템에 주입하여 취약성을 가진 어플리케이션이 이를 로딩하고 실행하도록 하는 공격을 의미한다[17]. 안드로이드 어플리케이션 환경에서는 classes.dex 파일을 포함하는 외부의 .jar 또는 .apk 파일이 바로 바이너리 코드에 해당하고, 동적 클래스 로딩의 개발단계에서의 보안약점을 보유한 어플리케이션은 Binary planting 공격을 받을 수 있다는 의미가 된다. 특히 OWASP에서는 Binary planting 공격을 CWE-114 : Process control(프로세스 제어)에 매핑하고 있다[16]. OWASP에서 분류하는 Binary planting 공격 관련 보안약점 및 최근 취약점 공격 사례는 다음과 같다.

이러한 동적 클래스 로딩 기법을 이용한 개발단계에서의 보안약점을 국내외 표준에 매핑하면 Table 8과 같다.

Table 8.Mapping binary planting attack with related items among MOPAS legislated 47 weakness(Domestic Standard), OWASP Top 10, CWE, CAPEC, CWSS and CVE

OWASP Top 10 Risk 2014 M7은 Client Side Injection에 해당하는 내용으로 SQL Injection, Java Script Injection (XSS), Local File Inclusion, Intent Injection/Fuzzing 항목을 포함한다[12].

CWE-114는 프로세스 제어(Process Control)와 관련된 보안약점으로서 신뢰되지 않은 소스나 신뢰되지 않은 환경으로부터 라이브러리를 적재하거나 명령을 실행하면, 악의적인 코드가 실행될 수 있다는 내용이다[6,14]. 이는 정확히 동적 클래스 로딩의 파라미터를 APK path가 아닌 SD Card 등 공격자가 접근 가능한 경로로 수정하여 악의적인 코드를 실행할 수 있다는 보안약점에 해당된다

Table 9.Related weakness to CAPEC-108:Command Line Execution through SQL Injection

Fig. 5.Parent-Child relationship among CWEs related to CAPEC-108.

4.4.1 CWE-114와 연결된 CAPEC 개선 필요

CWE-114는 CAPEC-108:Command Line Execution through SQL Injection 한 가지 항목에만 연결되어 있다[14]. CAPEC-108은 SQL Injection 에 대한 공통 공격 패턴으로서 Binary planting 공격과는 직관성이 떨어진다. 물론, 공격자가 Binary planting 공격을 통해 악의적인 코드 실행에 성공하고 SQL 인젝션 공격을 할 수 있지만 직관성은 떨어짐을 알 수 있다. 실제로 CAPEC-108과 연결되어 있는 CWE 항목을 찾아보면 아래와 같이 CWE-89, CWE-74, CWE-20, CWE-78, CWE-114가 존재함을 알 수 있다.

이를 부모-자식(Parent-Child relationship) 관계로 나타내보면 다음과 같이 모두 CWE-20 : Improper Input Validation의 자식 노드인 것을 알 수 있다. CWE-114는 CWE-20의 자식 노드이기 때문에, CWE-20의 대표적인 공통 공격 벡터인 SQL과 관련된 항목을 매핑 할 수 있지만 직관적인 공격 벡터로 보기 어렵다.

Table 10.List of MOPAS legislated weaknesses(Domestic Standard) related to CWE-89,79.74,78, and 114 in JAVA

행정안전부 제정 47개 보안약점 목록에서도 상기 CWE 항목들은 CWE-74를 제외하고는 모두 별도의 항목으로 다루어 각각 시큐어코딩 가이드를 지침하고 있다[6].

따라서, Binary planting 공격 및 Process control과 보다 직관적인 CAPEC을 CWE-114에 반영하는 것이 필요하다. 현재 등재된 CAPEC 항목 504개 중에서 Binary planting 공격 및 Process control과 직관적인 항목을 Table 11에 정리하였는데, 이는 ACROS 연구소에서 OWASP를 통해 연구하고 발표한 Binary planting 연구 자료의 항목과 일치하는 CAPEC 항목을 추린 것이다[16,17].

Table 11.The list of CAPECs that should be mapped to CWE-114

4.4.2 CWE-114와 연결된 CVE 및 CWSS 개선 필요

앞에서 언급한 CWE-114와 연결된 CAPEC이 직관적으로 개선됨에 따라 해당 CAPEC과 연결된 CVE를 추려 CWE-114에 반영할 수 있다. 또한, ACROS 연구소에서 OWASP를 통해 발표한 Binary planting 연구 자료에도 공격 벡터가 이미 확보되어 있어 이중 누락된 것은 CVE와 CAPEC에 반영하고 CWE와 연결하는 것이 가능하다. 아직까지는 Binary Planting 공격에 대한 CVE와 CAPEC이 Windows의 DLL과 관련된 내용이 많지만, 안드로이드 어플리케이션 상에서 동적 클래스 로딩 기법을 활용할 때의 CVE와 CAPEC 내용의 반영이 필요하다.

CWE-114는 OWASP Top 10 Risk 2014 M7과 매핑되고, OWASP의 An Overlooked Vulnerability Affair, The Forgotten Vulnerability Affair에서 다루어졌으며 ACROS 연구소에서는 www.binaryplanting.com 이라는 사이트를 운영하여 위험성과 관련 개발 가이드를 배포할 정도로 위험성이 높은 보안약점이다[17,18,19]. 이러한 위험도를 정량적으로 게시하기 위해 해당 CWSS 계산되어 기재되어야 한다. 또한, 모든 각 CWE 항목의 CWSS가 기재되어 있지 않고 상위 25개에 대해서만 공개하고 있는데 모든 CWE에 대해 CWSS를 알 수 있도록 개선이 필요하다[9].

4.4.3 국내표준 Android-JAVA 시큐어 코딩 가이드에 CWE-114 반영 필요

앞에서 언급한 것처럼, CWE-114는 OWASP Top 10 Risk 2014 M7과 연결되는 위험도가 높은 보안약점임에도 불구하고 국내 안전행정부의 Android-JAVA 시큐어 코딩 가이드에는 CWE-114 건의 반영이 되어 있지 않다[20]. 안정행정부의 JAVA 시큐어 코딩 가이드에는 반영되어 있지만, 안드로이드에 특정된 가이드인 Android-JAVA 시큐어 코딩 가이드에는 CWE-114 항목이 반영되어 있지 않다. Android-JAVA 시큐어 코딩 가이드에 CWE-114 항목과 Table 12의 안전하지 않은 코드의 예에 대한 시큐어 코딩 가이드가 반영되어야 한다.

Table 12.Example of insecure android code related to dynamic class loading implementation

 

5. 안전한 동적 클래스 로딩 기법 구현

DexClassLoader 또는 PathClassLoader 클래스를 사용하여 동적 클래스 로딩을 구현할 때의 보안약점은, 반드시 APK path로 지정되어야하는 dexPath, optimizedDirectory 등의 파라미터 값이 공격자에 의해 변조될 수 있다는 것이다. 본 장에서는 서버와 세션키를 안전하게 공유한 상태의 안드로이드 어플리케이션이 네이티브 라이브러리(NDK)를 사용하여 안전하게 동적 클래스 로딩 기법을 적용하고 앞서 설명한 보안약점을 극복하는 방안을 기술하였다.

5.1 최초 실행 시 인증 및 정당한 APK path 저장

최초 실행 시 인증 및 정당한 APK path를 서버에 저장하는 방법은 Fig. 6과 같다. 최초에 어플리케이션을 이용할 사용자가 로그인 정보를 입력(①)하고, 안드로이드 달빅 가상머신에서 서버로 로그인 정보(①)와 OTP 코드 요청(②)을 전송한다. 서버로부터 OTP 코드를 SMS와 같은 다른 채널로 받고(③), 안드로이드 어플리케이션에 입력(④)한다. 서버는 APK path를 제공하는 메소드를 담고 있는 DEX 코드를 미리 교환된 세션키 κ로 암호화하여 전달한다(⑤). 이러한 DEX 코드를 서버에서 미리 여러 개를 생성하여 무작위로 선택하여 전달하며, 어플리케이션만 알고 있는 정보를 조합하여 서버에 보내는 Attestation Module를 포함한다[2]. 즉, 전송하는 DEX 코드는 Table 13와 같이 Application functions와 Attestation Module로 구성된다.

Fig. 6.Authentication and saving qualified APK path for an initial invoking application[22].

Table 13.Details of Application functions and Attestation Modules in DEX code

서버에서 DEX 코드를 보낼 때 Freshness와 Man-In-The-Middle Attack 방지를 위하여 Nonce값 R을 함께 생성하여 보낸다(⑤). 이후 역공학과 정적분석이 어려운 네이티브 라이브러리를 이용하여 DEX 코드의 복호화(⑥) 및 해쉬를 생성(⑦)한다. 복호화된 DEX 코드로 동적 클래스 로딩(⑧)을 하고 네이티브 라이브러리에서는 JNI를 이용하여 APK path(⑨,⑩)를 얻는다[3]. 또한, Attestation Module을 실행하여 Attestation Value를 얻는다(⑨,⑩). 이후 APK path와 APK path에 위치한 .apk 파일, 수신한 DEX 코드, OTP Code, Attestation 결과 등의 검증에 필요한 값을 해쉬 및 암호화하여 서버에 전달(⑪,⑫,⑬,⑭)하고, 서버는 이를 검증(⑮)하여 통과할 경우 해당 사용자의 APK path를 저장(⑯)한다. 또한, Pause-and-Resume Attack을 방지하기 위하여, 최초 서버가 사용자로부터 로그인 정보와 OTP 코드 요청을 받을 때의 Timestamp T1과 검증 시 Timestamp T2의 차이인 ΔT = T2 - T1가 미리 지정한 임계치 Threshold 값 보다 작은지를 최종 검증한다.

5.2 최초 인증 후 검증 및 동적 클래스 로딩

Fig. 7에는 최초 인증 후 검증 및 동적 클래스 로딩에 대해 표현이 되어 있다. Fig. 6의 최초 실행 시 인증 및 정당한 APK path 저장 프로세스에서의 순서와 번호는 같지만 내용이 변경된 부분은 ❺',❻',❼',❽',⓰'으로 표시하였다.

Fig. 7.Validating after an initial invoking and Getting dynamic class loading[22].

Fig. 7와 같이 최초 인증 이후에는 서버로부터 Nonce R, 암호화된 DEX 코드와 저장된 어플리케이션 경로를 수신하고(❺') 네이티브 라이브러리에서 이를 복호화(❽')한다. 복호화된 DEX 코드를 APK path' 경로 위치에서 동적 클래스 로딩 한 후, 최초 인증 때와 마찬가지로 네이티브 라이브러리에서 JNI를 이용하여 어플리케이션 경로와 Attestation Value 값을 요청(⑨)하여 얻는다(⑩)[3]. 이후 검증에 필요한 값을 해쉬 및 암호화하여 서버에 전달(⑪,⑫,⑬,⑭)하고 검증을 요청하여(⑮,⓰') 통과 할 경우, 해당 DEX 코드를 동적 로딩하여 사용한다. 물론 이 단계에서도 Pause-and-Resume Attack을 방지하기 위하여, 최초 서버가 Nonce R, 암호화된 DEX 코드와 저장된 어플리케이션 경로를 송신할 때의 Timestamp T1과 검증 시 Timestamp T2의 차이인 ΔT = T2 - T1가 미리 지정한 임계치 Threshold 값보다 작은 지를 최종 검증한다.

5.3 제안 기법의 증명

제안 기법은 앞선 설명에 따라 Pause-and-Resume Attack와 Man-In-The-Middle Attack를 방지하기 위한 내용이 반영되어 있다. 또한, 서버에서 Attestation Module을 무작위로 생성하여 보냄으로써 Brute-Force Attack도 방지할 수 있다[2]. 제안 기법을 기반으로 어플리케이션의 무결성을 검정하여 Replication Repackaged Malapp 공격도 방지할 수 있다[2].

본 절에서는 이러한 보안성 분석 이외에 4.4.1.절과 Table 11에서 설명한 CWE-114와 관련된 여러 CAPEC 항목에서 제시하는 개발단계에서의 가이드(Solutions and Mitigations)를 알아보고 제안 기법이 준수하는지를 분석하였다.

5.3.1 CAPEC-38 항목 개발단계 가이드 준수 여부

CAPEC-38:Leveraging/Manipulating Configuration File Search Paths 에서 제시하는 개발단계에서의 가이드는 Host integrity monitoring을 제공하는 것이다. CAPEC-38은 CWE-426, 427, 428, 706과 관련이 있고, 해당 CWE의 개발단계에서의 가이드는 Table 14와 같으며 제안 기법은 이를 모두 만족한다.

Table 14.Solutions and Mitigations of CAPEC-38 at implementation phase

5.3.2 CAPEC-154, 159 항목 개발단계 가이드 준수 여부

CAPEC-154:Resource Location Spoofing는 CAPEC-159:Redirect Access to Libraries와 부모-자식 관계(Parent-Child Relationship)에 있다. CAPEC-154는 연결된 CWE가 없으며, CAPEC-159와 연결되어 있는 CWE-714에는 개발단계 가이드가 제공되어 있지 않다. CAPEC-159에서 제시하는 개발단계에서의 가이드만 제공되고 있으며 해당 내용은 Table 15과 같고, 제안 기법을 적용 후 소스코드에 Proguard 등의 난독화 기법을 적용하면 이를 모두 만족한다.

Table 15.Solutions and Mitigations of CAPEC-159 at implementation phase

5.3.3 CAPEC-234 항목 개발단계 가이드 준수 여부

CAPEC-234:Hijacking a privileged processs에서 제시하는 개발단계에서의 가이드는 제공되고 있지 않다. 하지만 CAPEC-234는 CWE-732, 648과 관련이 있으며 해당 CWE의 개발단계에서의 가이드는 Table 16 와 같다. 제안 기법은 각 CWE에서 제시하는 개발단계에서의 가이드를 모두 만족한다.

Table 16.Solutions and Mitigations of CAPEC-234 at implementation phase

5.3.4 CAPEC-471 항목 개발단계 가이드 준수 여부

CAPEC-471:DLL Search Order Hijacking에서 제시하는 개발단계에서의 가이드는 없지만, 디자인 단계에서의 가이드는 제시하고 있다. Table 17과 같이 2가지 디자인 단계에서의 가이드를 제시한다.

Table 17.Solutions and Mitigations of CAPEC-471 at design phase

위 가이드(Table 17)의 1번에 항목은 Windows 환경에서의 DLL에 특정되어 있어서, 본 제안 기법과는 관련이 없다. 하지만, 2번의 경우에는 본 제안 기법에서의 무결성 검증에 관련된 내용을 포함하여 만족하고 있다.

CAPEC-471은 CWE-427, 706과 관련이 있다. CWE-706의 경우 개발단계 가이드가 제공되어 있지 않다. CWE-471의 경우 Table 14의 CWE-426, 427의 개발단계에서의 가이드와 동일함을 알 수 있으며, 제안 기법이 이를 모두 만족함을 알 수 있다.

 

6. 결 론

본 논문에서는 이상과 같이 안드로이드 어플리케이션 개발 시 주로 사용하는 동적 클래스 로딩 기법의 잠재된 보안약점에 대해 알아보고 이와 관련된 국내외 표준과 개선이 필요한 항목에 대해 정리하였다. 또한, 관련 공통 공격 벡터(CAPEC) 및 CWE에서 제공되는 개발단계 가이드(Solutions and Mitigations)을 만족하는 안전한 기법을 제안하였다.

역공학으로 소스코드 추출이 쉽고 이로 인한 중요한 모듈의 추출과 악성코드의 삽입 및 리패키징으로 인한 위변조가 용이한 안드로이드 어플리케이션의 특성 상, 개발단계에서 동적 로딩 기법의 사용은 필수 불가결이다. 동적 클래스 로딩 기법은 일종의 난독화 기법으로서 정적분석을 어렵게 만들고 중요한 소스코드를 보호할 수 있다. 이 기법의 잠재된 보안 약점을 고려하지 않은 상태로 개발이 이루어지게 되면 이는 곧 어플리케이션의 취약점으로 발전될 수 있다. 개발단계에서 보안약점을 제거해야 이후 배포된 어플리케이션에서의 취약점 발생을 방지할 수 있다.

동적 클래스 로딩은 특히 안드로이드 어플리케이션의 무결성 검증에 많이 사용되는데, 본 논문에서 소개한 보안약점이 그대로 존재할 것으로 생각된다. 향후에는 이러한 동적 클래스 로딩을 이용하고 있는 어플리케이션을 실제로 분석하여 취약점에 대해 연구할 예정이다. DHS에서 2011년 11월에 발표한 “안전한 사이버 미래를 위한 청사진(blueprint for a secure cyber future)”에서도 나타나듯이 어플리케이션의 보안 수준을 높이기 위해서는 개발단계부터 이러한 보안약점을 줄여야함을 인지하고 개발단계부터 이를 고려하여 취약점을 사전에 예방하여야 할 것이다[21].