오늘은 안드로이드를 중심으로, 모바일 보안 취약점 점검 기준에 대한 이야기를 하고자 합니다. 예를 들어, 신규 서비스를 위해 모바일 앱을 배포할 경우 보안담당자라면 취약점 분석평가를 기업 자체적으로 하거나 보안컨설팅 전문업체에 의뢰해서 모바일 보안 취약점을 평가하겠죠. 이 때 점검기준에 의해 결과보고서가 나올 텐데, 보안 담당자는 각 점검기준에 대한 최소한의 이해가 필요합니다. 그래야 취약점분석 결과보고서에 있는 각 이슈에 대해 정확한 이해를 바탕으로 그에 적절한 수준의 대응책을 마련할 수 있을 것입니다.
모바일 보안의 중요성
스마트폰을 이용해서 인터넷뱅킹, 주식투자, 게임 등 못하는 것이 없죠. 어느새 PC보다도 더 많이 사용하는 것 같습니다. 게다가 핀테크 활성화가 시작되면서 간편결제 등 PC로 못하는 것까지 스마트폰으로 하고 있죠. 이렇듯 스마트폰에서 금융거래와 같은 중요정보를 처리하려다보니 NFC기반의 IC태깅기술, FIDO기반의 생체인증, 하드웨어기반의 TEE 등 다양한 보안기술을 도입하여 편의성을 증대하면서도 보안성을 확보하려고 노력하고 있죠. 꼭 이처럼 별도의 하드웨어까지 활용하지 않고 순수 소프트웨어만으로 구현한 간편송금앱 TOSS나 뱅크월렛카카오와 같은 서비스도 점점 많아지고 있습니다. 이렇게 스마트폰의 역할이 중요해질수록 공격대상으로서의 가치는 올라가고, 실제 모바일 악성코드 및 해킹사례들이 늘고 있는 추세입니다. 최근에는 이상거래탐지시스템(FDS)과 같이 백엔드에서도 열심히 보안을 강화하고 있지만 그래도 클라이언트(스마트폰)에서의 보안이 여전히 중요한 건 변함없을 것입니다.
모바일 보안 취약점 점검 기준 파헤치기
전자신문 기사에 의하면, 2013년 금융감독원에서 '스마트폰 금융 안전대책 이행실태 체크리스트'를 배포하면서 금융 모바일앱을 점검하도록 하였습니다.
[기사 일부 발췌]
"11일 당국과 업계에 따르면 최근 금융감독원은 시중 금융 전(全) 업권 80여곳에 `스마트폰금융 안전대책 이행 실태점검 체크리스트`를 발송하고, 점검 결과를 4월까지 반송하라고 통보했다."
물론, 이 기준이 모든 앱에 대해 보안측면의 만병통치약이라고 할 수도 없습니다. 특히 최근에는 보안이슈를 클라이언트에서만 해결하려던 과거의 분위기에서 기업 자율보안체계로 패러다임이 변화되고 있는 추세에서 이 기준을 반드시 만족시켜야 한다는 법은 없다고 생각합니다. 그렇다고 스마트폰에서 모바일앱에 대한 보안이 중요하지 않다는 뜻이 아니며 오히려 자율보안체계에서는 상황에 따라 적절히 필요한 기준을 적용해야할 것이고, 보안담당자는 이러한 기준의 의미를 정확히 알고 있어야 합니다.
점검기준 요약은 아래 표와 같습니다.
위 점검기준 외에도 앱 특성에 따라 적절한 점검기준이 적용될 수 있겠지만 오늘은 금감원에서 배포한 기준을 하나씩 살펴보겠습니다.
백신프로그램 적용
앱 실행 시 백신모듈을 탑재하거나 백신앱을 연동하는지에 대한 내용입니다. 요새는 모바일 보안 패키지에 기본적으로 포함되는 것 같더라구요. 앱 내 백신을 라이브러리 형태로 포함하기도 하고, 안랩의 V3Mobile과 같이 독자 앱을 연동하기도 합니다. 백신앱 구동여부 외에도 앱 사용 도중 백신앱을 강제종료시켰을 때 이를 인지하는지도 포함하여 점검하기도 합니다.
그렇다면, 백신앱은 어떤 의미를 가질까요? 백신앱은 PC환경에서와 마찬가지로 잘 알려진 악성코드(앱)를 탐지합니다. 여기서 '잘 알려진' 이란 누군가가 악성앱으로 인해 피해를 입었고 그것이 백신업체에 신고 및 수집되어 알려지게 되는 것입니다. 최초 알려지더라도, '수집->분석->배포' 단계에 이르기까지 시간이 소요될수밖에 없으니 최신 백신엔진이 배포되기 전까지는 백신이 해결해줄수도 없는 노릇이죠. 그나마 최신업데이트라도 열심히 한다면 배포단계 이후에 최신백신이 바로 적용되겠죠.
여기서 잠깐 안드로이드와 iOS환경에서의 백신얘기를 좀 하자면, 애플앱스토어에는 백신앱을 등록할 수 없습니다. 애플은 앱스토어에 등록대기 중인 앱에 대해 전수조사를 철저히 하기 때문에 백신앱이 필요없고 인정하지도 않습니다. 사실 애플은 앱스토어를 개방하지 않고 애플앱스토어 하나만 인정하며 블랙마켓(애플앱스토어가 아닌 앱스토어)으로부터의 앱 설치를 차단하고 있습니다. 블랙마켓앱을 설치하려면 애플의 통제에서 벗어나기위해 JailBreak를 하죠. 반면, 안드로이드는 어떨까요? 구글도 구글플레이(구글앱스토어)에 등록대기중인 앱을 당연히 검사합니다. 하지만 애플만큼 까다롭지 않고 더 중요한 것은 앱스토어를 개방한다는 것이죠. 우리나라만 해도 각 통신사별, 각 제조사별로 앱스토어가 별도로 있으며 포탈업체도 앱스토어를 운영하니 전세계적으로 Third Party 앱스토어가 엄청 많겠죠. 게다가 설정에서 '알수없는 소스' 항목만 체크하면 아무 URL을 통해서도 다운받은 앱도 설치할 수 있습니다. 이로 인해 안드로이드는 스미싱으로 인한 악성앱 설치유도도 상당히 많죠('알수없는 소스' 체크를 못하도록만 막아도 스미싱은 급격하게 줄 것입니다). 그래서 안드로이드는 백신앱이 많이 있습니다. 참고사항이지만, V3Mobile은 국제인증인 AVT에서도 좋은 결과는 내놓고 있구요.
입력정보 보호대책
비밀번호, 주민번호 등 중요정보를 사용자가 입력 시 노출되지 않도록 가상키패드 등을 적용하는 것입니다. 앱내 단순 텍스트창에서 중요정보를 입력하고 마스킹처리를 하더라도 그것은 UI상에서만 안보일 뿐 실제 실행되는 앱의 프로세스에 할당된 메모리 내에는 평문으로 들고 있을 경우 메모리 덤프 등을 통해 중요정보를 해커가 가져갈 수 있기 때문입니다. 물론 뒤에서 설명할 '루팅' 된 환경에서 입니다. 가상키패드의 역할은 사용자가 입력하는 키값을 종단간암호화(E2E)를 하는 것입니다. 키패드에서 키값 하나 하나를 입력할 때마다 그 값을 즉시 암호화하고 입력 종료 시 전송하면 서버에서 값을 복호화합니다. 당연히 가상키패드는 서버모듈이 있을 테고 둘 사이에 매번 변하는 키값을 사용해야 합니다.
가상키패드를 사용하더라도 유의할 점이 있습니다.
- 가상키패드가 실행 시 매번 자판의 배열이 랜덤하게 변하는지
- 혹시 랜덤하게 변하는 규칙에 대한 설정을 앱내 설정파일에 저장하고 있어 이를 수정할 경우 고정자판이 되는건 아닌지
- 가상키패드에서 열심히 E2E를 하지만, 적용을 제대로 못해서 평문으로도 들고 있어 메모리상에 노출되거나 디버깅로그가 남지 않는지
- 입력값 암호화 키를 고정키를 사용하고 있어 재사용공격이 가능하지 않는지 등
금융정보 종단간 암호화
앞에서도 설명한 E2E암호화에 대한 내용입니다. E2E암호화는 네트워크 암호화 전송보다 조금 더 강한 보안요구사항이지요. 네트워크암호화는 클라이언트와 서버 중간의 네트워크 영역에서 스니핑 등을 통해 중요정보가 노출되는 것을 방지하는 것이지만, E2E는 중요정보가 네트워크로 나가기 전부터 스마트폰 내(클라이언트) 다른 프로세스에 의해서도 중요정보가 노출되는 것을 방지하기 위한 것입니다. 비밀번호부터 개인정보까지 굉장히 중요한 정보를 네트워크 암호화와 별도로 E2E암호화를 요구하는 것입니다.
폰 임의개조 탐지 및 차단
안드로이드의 '루팅', iOS의 'JailBreak' 탐지에 해당합니다. 대부분의 스마트폰OS는 Sandbox개념을 도입하여 보안을 유지하는데 루팅이라는 것은 이것을 깨는 행위입니다.
루팅을 살펴보기 전에, 안드로이드의 보안 아키틱처에 해당하는 Sandbox 개념을 살펴보겠습니다.
<Sandbox 개념>
<출처: 안랩>
스마트폰에 앱을 설치하면 위 그림처럼 앱마다 UID/GID가 다릅니다. 각 앱마다 다른 ID를 부여하고 각 ID별로 서로의 자원에 접근하지 못하도록 통제하는 것이죠. 아래 그림은 서로 다은 앱에 대한 Sandbox 상세 개념도 입니다.
<출처 : IBM>
위 그림에서 서로 다른 앱의 ID는 12345, 54321 이고 각 앱별로 File, DB, SMS, Sensors 등을 OS(안드로이드 커널은 Linux커널)에서 제공합니다. 예를 들어, 왼쪽 앱(ID:12345)이 생성한 파일을 오른쪽 앱(ID:54321)이 접근할 수 없도록 안드로이드가 통제를 합니다. 쉽게 말해서 자신만 실행되고 있는 박스에서 각각 실행된다고 생각하면 됩니다. 물론, 필요하면 서로 공유하거나 연동할 수 있도록 OS는 다양한 메카니즘을 제공하지만 기본적인 구조는 박스처리해서 서로 접근이 불가하도록 만드는 것입니다.
이러한 Sandbox가 완벽하게 보장된다면, 사실 앱은 중요정보를 파일에 평문으로 저장해도 되겠죠. 아무도 보지 못하고 해당 앱만 접근이 가능하니까 기밀성은 충분히 확보되는 셈이죠. 하지만 Sandbox가 완벽하게 보장되지 않기 때문에 이러한 보안 요구사항들이 나오게 됩니다. Sandbox를 보장하지 않는 대표적인 것이 루팅입니다. 시스템에는 root라는 계정이 있습니다. 모든 권한을 가진 수퍼유저계정이죠. 루팅이라는 것은 root권한을 획득하는 것을 의미합니다. 예를 들어, 처음 스마트폰을 사면 root권한은 오픈되지 않습니다. 하지만, 스마트폰 사용자는 단말의 제약을 풀기위해(특히, iOS) 루팅도구(테그락 등)를 이용해 루팅을 직접하는 경우도 있고, 악성코드에 의해 본인도 모르게 루팅이 되는 경우도 있습니다.
경우가 어떻든, 루팅이 되면 언제든지 Sandbox의 통제를 벗어나 스마트폰 내 모든 권한을 보유하게 되고 다른 앱들의 저장파일은 물론 디버깅, 메모리덤프 등 원하는 작업을 할 수 있게됩니다. 이처럼 보안 아키텍처가 완벽히 보장되지 않기 때문에 백신도 설치하라고 하고, 가상키패드도 쓰고, 종단간 암호화, 뒤에 나올 앱위변조 등에 대해 대응을 하라는 것이죠.
취약점 점검하는 전문기관에서 진단을 시작하려면 루팅을 가장 먼저 시도할 것입니다. 중요정보를 파일에 저장하는지 점검하려면 점검자부터 root권한이 필요하기 때문이죠. 루팅만 100% 막아도 어느정도 루팅을 전제로 이어지는 공격들을 상당부분 막을 수 있게됩니다. 하지만 루팅을 100% 탐지하는 경우는 드뭅니다. 예를 들어, 최악의 경우 루팅탐지를 아무리 잘하더라도 루팅탐지 모듈을 무력화시키도록 수정 후 동작할 수 있습니다. 이는 앱 위변조에서 막아야 하지만 이것 또한 100% 탐지는 어렵습니다. 창과 방패와 같은 이치라고 보면 됩니다. 그래서 루팅탐지는 진화하는 루팅방법들은 신속하고 지속적으로 대응할 수 있는 체계구성이 중요합니다.
루팅탐지는 다양한 요소를 확인함으로써 탐지합니다. 예를 들어, 루팅도구 앱 설치여부, 관련 프로세스 실행 여부, su파일 존재 여부, adbd의 root권한 실행여부 등으로 탐지하는데 루팅탐지를 우회하며 진화하는 루팅도구들을 효과적으로 탐지하기 위한 노력이 지속적일 수 밖에 없습니다. 몇년 전에 이런 경우도 있었습니다. 어떤 제조사의 안드로이드 단말에 출고시부터 su파일이 포함되어 있었고 su파일을 실행해보니 패스워드가 걸려있었습니다. 해당 제조사는 패스워드가 걸려 있으니 su파일이 있어도 괜찮지 않냐며 유지보수용으로 넣어둔 것이고 했습니다. 이것은 루팅을 위한 대표적 백도어라고 할 수 있죠. 제조사가 악의적 목적이 아니라고 하더라도 언제든지 악의적인 목적으로 사용될 수 있는 백도어이기 때문에 출시부터 루팅단말이라고 할 수 있죠. 제조사에서 루팅에 대한 이해가 부족해서 그러지 않았나 하는 상황이였습니다.
루팅 얘기를 너무 많이 했는데요, 루팅관련 내용은 기회되면 한 번 정리해보도록 하고 다음으로 넘어가겠습니다.
앱 무결성 검증
안드로이드의 앱 무결성에 대한 대상을 열거하면 APK파일, DEX파일, so파일, ODEX파일 등이 있습니다. 여기에 리소스파일(이미지파일 등)도 포함하긴 하지만 리소스파일보다 실행파일이 더 중요한 대상입니다.
안드로이드 설치파일인 APK파일을 이용해서 앱이 설치되면 APK파일이 그대로 시스템에 저장됩니다. 이 파일에 대한 무결성을 확인해야 합니다.
APK파일은 단순히 PKZIP 압축파일일 뿐이고, 압축해제하면 classes.dex파일이 하나 있습니다(경우에 따라 2개 이상일 수도 있습니다만). 이것이 실제 안드로이드 실행파일입니다. JAVA로 구현된 코드가 들어있죠. 앱이 설치되면 실제 단말의 시스템환경에서 빠르게 동작하기 위해 시스템 최적화된 DEX파일인 ODEX파일도 함께 생성됩니다.
공유라이브러리 파일입니다. DEX파일은 Dalvik이라는 가상머신에서 실행되는데 so파일은 가상머신이 아닌 Native환경에서 실행되는 코드입니다. 보통 가상머신에서 동작하는 DEX파일은 리버싱이 너무 쉽기 때문에 암호모듈이나 인증모듈 등 중요한 모듈은 상대적으로 리버싱이 어려운 SO파일로 구현하는 경우가 많습니다.
그리고 가끔 라이브러리를 제공받아 사용하는 경우 JAR파일에 대한 무결성 얘기를 하는 사람도 있는데, JAR파일은 소스레벨에서 의미가 있고 안드로이드 빌드 시 모두 DEX파일에 포함되기 때문에 앱 실행 시 JAR자체에 대한 무결성을 확인하는 것은 불가하고 무의미합니다.
무결성확인도 역시 창과 방패의 이야기입니다. 앱 스스로 자신이 무결한지 확인하는 것 자체가 무리가 있습니다. 무결한지 확인하는 코드 자체가 삭제되거나 무력화될 가능성이 높기 때문에, 앱(클라이언트)뿐만 아니라 서버까지 서로 연결되어 타이트하게 무결성을 확인하는 등 앱 무결성확인을 위해 다양한 기법이 적용되고 있습니다.
<리패키징(Repackaging)>
앱 무결성에서 리패키징 얘기가 빠질순 없죠. 리패키징은 남이 배포한 APK파일을 마치 내가 개발하여 배포하는 것처럼 다시 패키징하는 것을 의미합니다. 안드로이드환경에는 리버싱(역공학) 관련 도구가 상당히 많아(apktool, dex2jar, jd-gui 등) 너무 쉽게 APK파일을 디컴파일하고 원하는 내용 수정 후 다시 컴파일할 수 있습니다.
<출처 : 안랩>
리패키징을 하는 목적을 크게 2가지로 분류하면, 악성코드 삽입 및 지적재산권침해(남이 만든 앱을 이용하여 광고수입 가로채기 등)입니다. 리패키징을 하려면 반드시 APK파일에 서명을 해야하는데 서명에 사용되는 개인키는 유출되지 않는다는 전제로, 리패키징하게 되면 반드시 원본앱(원작자의 서명)과 서명(리패키징한 사람의 서명)이 달라질 수 밖에 없습니다. 따라서 APK파일에 대한 무결성을 확인할 때 APK에 대한 서명부터 확인하는 것이 가장 좋겠지요. 리패키징에 대한 얘기는 너무 길어 이정도로하고 넘어가겠습니다.
코드 모듈 보호
대표적인 것이 코드난독화 및 디버깅방지(역분석방지)겠죠. 난독화는 말 그대도 코드를 읽기 어렵게 만드는 기술입니다. 개발자에게 코드의 가독성이란 엄청 중요한 요소인데 난독화는 오히려 반대개념이죠. 코드 가독성을 떨어뜨려 앱을 디컴파일해서 소스를 보더라도 로직분석이 잘 안되게 만드는 기술입니다. 안드로이드에서는 기본적으로 제공하는 proguard라는 난독화 도구가 있습니다. 다른 상용제품보다 난독화 수준은 조금 떨어지긴 합니다. 참고로, 난독화는 소스코드작성 시에 적용하는 것이 아니라 빌드 시에 적용하는 것입니다. 개발할 때는 가독성 및 모듈성을 고려하여 개발하고 빌드 시 가독성을 떨어지게 만드는 것이죠. 코드난독화는 코드암호화가 아니라 난독화이기 때문에 코드를 열심히 쫓아가면 분석이 가능하다는 한계가 있는 것을 분명히 이해해야합니다. 한 마디로 보조수단이죠.
그리고, 앱을 분석하기 위해 디버깅모드로 실행 후 디버깅을 시도할 수 있습니다. 중요트랜잭션이 발생하는 곳에서부터 디버깅을 시도하여 중요정보를 알아내거나 중요로직을 파악할 수 있죠. 디버깅방지 기능은 디거깅 행위를 방지하기 위해 디버깅이 시도되면 이를 감지하고 앱을 종료시켜 코드를 보호할 수 있습니다.
기타
앱 취약점 점검, 앱 위변조 로그 기록은 별 내용 없네요. 멀티로그인 차단은 동시 로그인을 방지하여 사용자폰에서 알아낸 정보를 즉시 이용하여 해킹할 수 없도록 하기 위한 목적일 수 있겠네요. 스마트폰에 중요정보 저장금지는 역시 루팅 시 또는 백업 시 중요정보가 유출되지 않기 위한 것이고, 금융거리기록 정보보관은 관리적인 절차에 해당한다고 볼 수 있습니다.
결론
지금까지 금감원에서 제시한 모바일 보안 취약점 점검기준에 대해서 기술적인 개념분석을 해보았습니다. 본 기준은 스마트폰에서 실행되는 모바일앱(클라이언트)에 대한 점검기준이며, 이 기준이 항상 정답은 아니라는 것을 다시 한 번 강조합니다. 클라이언트 보안에서 모든 것을 해결하려는 기존 분위기에서 최근에는 서버단에서 함께 보안을 적절히 나누면서(FDS등) 클라이언트의 사용성을 강조하는 경우도 많이 있습니다. 다만, 보안 담당자로서 본 내용을 정확하게 이해한다면, 효율적으로 적절한 대응책을 마련하는데 도움이 될 것입니다. 참고로, 모든 리스크를 완전히 제거하는 것만이 좋은 것은 아닙니다. 위험수준과 발생확률을 감안해서 적절한 수준(때론 리스크 수용)의 대응을 함으로써 효율성을 고려할 수 있을 것입니다.
