안드로이드 어플리케이션 보호 솔루션에 대한 소고

지금 현재, 한국에서 매년 열리는 POC 컨퍼런스에서 발표된 Theori사의 Project BAOBAB 발표 결과에 대해서 많은 논란이 일어 나고 있습니다. 이에 잠시 시간을 내어서 도대체 Project BAOBAB이 무엇이고, 논점이 되는 부분이 무엇인지에 대해서 간략하게 정리를 해 보았습니다.

티오리사의 입장은 다음에 정리 되어 있습니다.

에버스핀 ‘허위사실 유포로 인한 명예훼손에 대한 경고’ 경고장에 대한 공개 답변

에버스핀 공개검증 요청에 대한 Theori의 공식 입장문

에버스핀사의 공식적인 입장은 아직까지 존재하지 않는 것으로 보이고, 다만 대표자의 페이스북 글들이 공유 되고 있으나, 한 업체의 공식 입장으로 보기에는 너무 난삽해서 링크는 생략하기로 했습니다.

이 문제에는 기술적인 측면, 비 기술적인 측면의 여러가지 문제들이 복합적으로 얽혀 있습니다. 많은 문제 중에 가장 핵심적인 몇가지 문제에 대한 생각을 밝혀 보겠습니다.

어플리케이션 난독화

먼저 어플리케이션 난독화에 대해서 논의해 보기로 합니다. 스마트폰은 PC에 비해서 엔드포인트 안전성이 어느 레벨 이상으로 담보된 디바이스로 취급되는 것이 지금의 추세이며, 멀티 팩터 인증이나 기타 뱅킹 서비스등의 높은 레벨의 보안을 요하는 서비스들은 스마트폰이 PC 보다는 안전하다는 가정하에서 작동하는 경우가 많습니다.

하지만, 단말에서 직접 실행 되는 어플리케이션의 특성상, 설치 되는 코드를 추출하여 리버스 엔지니어링이 가능하다는 치명적인 문제를 안고 있습니다. 리버스 엔지니어링을 통해서 공격자가 알아서는 안되는 여러 내용들을 추출해 내거나 악의적인 코드와 명령 그리고 패킷의 삽입을 통한 가짜 트랜잭션, 크리덴셜 수집 등의 행위가 가능해지게 됩니다.

따라서 이러한 코드들의 리버스 엔지니어링을 방지하기 위해서 코드 난독화라는 개념이 등장하게 됩니다. 이러한 기술의 원천은 PC 시대로 거슬러 올라 가며, 나열하기도 힘들만큼 여러가지 기술들이 등장하게 됩니다. Project BAOBAB에 언급된 여러 보안 제품들의 난독화 기술들의 기원은 엄밀히 따지면, 이미 윈도우즈 시대 때부터 악성 코드 제작이나 DRM 구현등을 위해서 즐겨 사용되던 기법들이 대부분입니다.

어플리케이션의 난독화로 인해서 여러 분석툴들이 작동되지 않는 경우는 흔히 발생하는데, Project BAOBAB에서는 이러한 케이스들을 처리하기 위해서 기존의 여러 툴들에 패치를 가한 것으로 보입니다.

Project BAOBAB에서는 또한 이러한 어플리케이션의 해독을 위해서 에뮬레이션과 코드 간략화 등의 여러가지 수동적이거나, 자동, 반자동의 기법들을 사용한 것으로 보입니다. 난독화는 절대 풀리지 않는 기법이 아니며, 이론적으로 적당한 시간과 리소스가 주어지면 항상 풀릴 수 밖에 없는 차원의 문제에 해당합니다.

루팅 디텍션

또 한가지 Project BAOBAB에 언급된 테스트 항목이 루팅 디텍션입니다. 루팅 디텍션은 사실 그 자체로서 이미 아이러니한 속성을 내포하고 있습니다. 이미 루팅이 된 시스템에서는 공격자가 이미 루트 권한을 가지고, 타겟 어플리케이션의 여러 동작들을 마음대로 조정이 가능하기 때문입니다.

많은 경우 루팅 디텍션은 시스템의 루팅과 관련된 특정 파일 존재 여부를 체크하거나 마운트 정보, unix 소켓 정보 등의 여러 환경들을 체크함으로써 이루어집니다. 공격자는 단지 이러한 오퍼레이션들에 대해서 가상의 결과값을 주는 것으로 이러한 디텍션들을 모두 우회할 수 있는 것으로 보입니다.

실제로 Project BAOBAB에는 루팅 디텍션 우회의 방법으로 Frida를 사용한 API 리턴값 조작을 제시하고 있습니다. 어떤 제품의 경우 Frida 디텍션 기능이 있는데, 이 디텍션 또한 Frida를 사용하여 우회가 가능하다라고 합니다. 결과적으로 이미 루트 권한을 빼앗긴 시스템에서의 이러한 디텍션 기능들은 무의미해지는 것으로 보입니다.

해당 논란이 되는 제품의 경우, 스크린샷으로 판단하건데, 시스템에 존재하는 su 명령어와, Superuser.apk 등의 루팅 패키지 파일들의 존재 여부를 통해서 루팅을 탐지하는 것으로 보입니다.

MITM

MITM은 엔드포인트와 서버 사이의 중간 구간에서 트래픽을 하이재킹하는 방법으로 인가 되지 않은 페이로드 등을 삽입하거나 원치 않는 결과를 일으키는 것을 의미합니다.

이론적으로 MITM은 간단하게 클라이언트와 서버 간의 상호 인증을 통해서 쉽게 해결 가능합니다. MITM 공격 시나리오에서 대부분의 경우 클라이언트는 침해를 당하지 않은 상황을 가정하므로 클라이언트의 인증서 정보를 바꿔치거나 조작하는 경우는 배제하고 생각할 필요가 있습니다.

Theori 측의 주장에 의하면 서버에서의 503 에러 코드를 인젝션해서 내려 보낼 경우 클라이언트 사이드의 보안 모듈 로딩이 이뤄지지 않았고, 어플리케이션은 그대로 진행된 것으로 보입니다. 해당 과정은 다음 유투브 영상에서 확인이 가능합니다.

다만, 통상적으로 어떠한 어플리케이션이 MITM에 취약하다라고 말할 때에는 클라이언트 사이드의 integrity가 깨어지지 않은 상태를 가정하므로, 과연 이 결과만을 가지고 해당 어플리케이션이 MITM에 취약한지 여부는 판단하기는 힘든 것으로 보입니다. 그리고, 또한 해당 모듈 다운로드 커넥션이 과연 HTTP 평문 채널을 통해서 이뤄졌는지, HTTPS를 통한 서버 인증 기능을 포함한 상태에서 이뤄지는지는 판단하기 어려운 것으로 보입니다.

다만, Theori 측의 해당 영상은 어떠한 이유로 서버가 제대로 작동하지 않을시 클라이언트에 보안 모듈이 제대로 로딩 되지 않은 상태에서 어플리케이션이 실행되는 과정을 시뮬레이션해서 보여준 것으로 해석하기에는 무리가 없습니다.

Anti-Tampering

Anti-tampering은 최근에 여러 분야에서 회자 되고 있는 기술중의 하나입니다. 사실 많은 보안 제품들이 스스로를 제대로 보호하지 못하기 때문에 말웨어들은 초기 실행 기반을 얻은 후에 보안 제품 자체를 아예 비활성화 시키거나, 아니면 보안 제품들이 설치해 놓은 후킹 루틴들을 딥 레벨에서 조작해서 작동하지 못하게 하는 행위들을 주로 시도합니다.

논란이 되고 있는 제품의 경우 초기 실행 코드에 “return-void” 코드를 삽입하고 나머지 초기화 코드들을 건너 뛰게 함으로서 tampering에 쉽게 성공하게 됩니다.

사실 anti-tampering은 아주 어려운 주제로서, 마땅한 방법이 존재하는 것은 아닙니다. 하지만, 코드 난독화를 주요 무기로 사용하는 이러한 어플리케이션에서 초기화 루틴이 눈에 보이게 노출된 경우는 드물고, 대부분의 경우 기존의 코드와 심하게 섞여져 있어서 찾아 내기 힘들게 하는 경우가 대부분입니다. 또한 수시로 자기 자신의 self-check 루틴을 돌리는 방식으로 tampering을 일정 시간마다 지속적으로 디텍션하는 것 또한 많이 사용되는 방법입니다.

Anti-tampering의 가장 큰 성공 사례는 사실 KPP 라고 할수 있습니다. 물론 안드로이드가 아닌 윈도우즈 상에서의 구현체이지만, 기본 컨셉은 동일합니다. Windows Vista 이전에는 윈도우즈 플랫폼에 수많은 커널 레벨 루킷들이 창궐해 왔었지만, 이 PatchGuard라고 불리는 이 KPP 메커니즘과 함께 DSE (Driver Signing Enforcement)가 도입 되면서, 윈도우즈 룻킷은 쇠퇴기를 맞았습니다.

하지만, 여전히 anti-tampering은 구현체 자신이 해결하기에는 버거운 문제로 플랫폼 자체의 secure 한 환경이 보장 되지 않는한 의미가 없습니다.

Responsible Disclosure

Responsible disclosure에 대해서는 사실 아직도 의견이 분분하고, 양쪽의 extreme한 생각을 가진 사람들도 많습니다. 하지만, 최근에는 벤더 입장에서 주로 커리어를 쌓아온 입장에서는 어떠한 프러덕에 대한 evaluation 정보가 들어가 있고, 서로간의 비교표가 들어가 있는 보고서나 발표 자료의 경우에는 해당 벤더와 결과에 대해서 상의하고, 실제로 공개된 장소에 공표 되기 전에 결과에 대해서 어느 정도 억셉하는지에 대한 사전 소명 기회와 절차가 필요하다는 것입니다.

필자도 여러 Anti-malware 관련 테스트나 MITRE가 주관하는 EDR 테스트 등에 참여 했지만, 테스트와 시험 결과 도출에는 정확성을 위한 수많은 노력과 함께 최대한 벤더의 입장을 리포트에 반영해 주기 위한 합리적인 노력들이 있었습니다.

이번 Project BAOBAB의 경우, 여러 정황으로 보았을 때에 이 과정이 통째로 생략 된것으로 보이고, 이러한 형태의 발표는 결과적으로 리포트의 공정성에 대한 의문을 제기하는 식으로 돌아 오는 경우가 대부분입니다.

결론: 가짜 보안 vs 진짜 보안

마지막으로 한가지 짚고 넘어 가고 싶은 것들은 과연 이러한 난독화와 루팅 디텍션, 인테그리티 디텍션 등이 어떠한 의미를 가지냐는 것입니다. 어떻게 보면, 특정 어플리케이션을 타케팅하지 않는 일반적인 목적을 가진 여러 말웨어에 대해서는 대증적인 요법으로 작동할 수도 있습니다. 하지만 특정 어플리케이션을 타케팅한 공격자나 악성 코드에 대해서는 좋은 해법이 되지 못합니다.

보다 근본적인 해법은 플랫폼 자체의 무결성이 확보되는 스마트폰 벤더의 노력과 함께, 시큐어 스토리지 등의 하드웨어에 기반한 보안에 더 포커스한 보안 솔루션에 더 집중하는 것이 논리적으로 맞습니다.

댓글 남기기