본 글은 HACKERONE에 올라온 Google Play Security Reward Program 글을 바탕으로 작성된 글임을 밝힙니다.

 

얼마 전, 삼성에서도 삼성 제품에 한하여 Bug Bounty를 실시하였다.[1] 최근 삼성은 전 세계적으로 급증하는 해킹과 사이버 공격에 삼성에 이름을 걸고 보안에 투자와 관심을 아끼지 않는다. 이는 거의 국내 대기업의 이름을 걸고 시행하는 첫 Bug Bounty였다. 그리고 드디어 Google Play에서도 Bug Bounty를 실시한다.[2] 전세계 상위 100개, 우리가 흔히 알고 있는 모바일 앱 대부분이 해킹 경험이 있을 정도로 해커들이 날뛰던 애플리케이션 분야였다.[3] 상위 100개 안드로이드 유료 앱 중 97%가 해킹을 당한 적이 있으며, iOS 유료 앱 87%가 해킹을 당한 적이 있다고 한다. 이 중에는 전자상거래, 금융과 관련된 앱도 포함되어 있다. 상거래와 관련된 앱 중 95%, iOS는 70%가 해킹 시도가 있었다고 한다.[4] 아 이 얼마나 해커들이 날뛰고 있는 곳인가. 이런 통계가 2015년 약 2년 전 이야기고, 최근에는 국내 개발사가 제작한 안드로이드 앱에서 악성코드에 약 3,650만대가 감염되었다고 한다. 더하면 더했지 덜하지는 않는다.[5]  Google Play는 이렇게 날뛰는 해킹을 자체적인 검열을 통하여 검열한 후 Android 애플리케이션이 올라가도록 검열 시스템을 도입했다.[6] 이 외에도 Google Play는 자체적인 Bug Bounty를 실시하여 Google Play에 올라온 애플리케이션의 보안을 높이려 한다. 바로, Google Play Security Reward Program이다. 

Google Play는 안드로이드 운영체제에서 사용되는 애플리케이션만 판매 및 배포하는 서비스다. 2008년 10월에 Android Market이라는 이름으로 시작하여 2012년 3월 6일, Google Play 및 Google eBookstore와 통합되면서 Google Play로 개편하고 음악, 동영상, 전자책, 게임, 영화 등 다양한 앱 들을 판매하기 시작했다. 보통 iOS의 애플리케이션만 판매하는 App Store와 자주 비교 대상이 되곤 하는데, 본디 시작은 iOS가 먼저 서비스를 제공했다. 하지만 꾸준히 안드로이드의 애플리케이션의 양을 늘려가면서 결국에는 2012년 기준으로 두 서비스 다 약 60만 개의 개수로 큰 차이는 없다.[7] 아무튼, Android의 Google Play와 iOS의 App Store는 각 운영체제에서 사용되는 애플리케이션을 판매 및 제공한다는 점에서 같은 종류의 서비스를 제공하고 있지만, 상당히 다른 점은 애플리케이션의 사전 심의 제도가 무척이나 부실하다는 점이다. 

Android의 심의 제도가 어떻게 부실한가. Google Play는 앱 소개에서 저작권만 침해하지 않으면 전혀 다른 앱의 이미지를 가져와 올린다 하더라도 올릴 수 있기 때문에 보안 적으로나 프로그램의 질적으로나 검증되지 않는 애플리케이션이 올라오는 경우가 많다. 이 때문에 Google Play에 올라온 악성코드만 해도 무려 70만 개가 버젓하게 올라와 있다는 말이 들리곤 한다. 즉, 개발자 자유롭게 올릴 수 있다는 장점보다 앱의 검증이 제대로 이루어지지 않아 이상하고 위험한 앱이 그대로 Google Play에 올라올 수도 있다는 것이다. 반면, App Store의 경우에는 애플리케이션을 마켓에 올릴 때는 최소 3주 이상 코드를 뜯어 본다고 한다. 또한, 심의 규정에 어긋나더라도 App Store에 올라갈 수 없으며 버그가 발견되면 다시 개발자에게 연락하여 좀 더 완성도 높은 애플리케이션을 사용자에게 제공한다고 한다. 따라서 App Store에서 애플리케이션이 나오기 위해서는 상당한 시간이 주어지지만 좀 더 검증된 애플리케이션이 사용자에게 주어진다는 말이다.[8]

그렇다면 Google Play에서 발견된 악성코드가 무엇이 있을까. 보안 회사인 Check Point는 Play Store에서 약 50개의 숨겨져 있는 Expensive Wall이라는 악성코드를 발견했다. 이 악성코드는 100~420만 번의 다운로드가 되었고, 애플리케이션 제공자가 앱을 삭제하였음에도 비슷한 코드의 애플리케이션이 5,000건이 넘게 발견되었다고 한다.[9] 또한, 보안 업체인 ESET의 연구원은 9월 초, Google Play의 BankBot 악성코드 제품군의 악성 애플리케이션을 발견하기도 했다. ‘Real Gift Card’와 ‘Bubble Shooter Wild Life’와 같은 이름을 가진 악성코드가 직접 설치되어 있었고 설치 후에 악의적인 응용프로그램을 조용히 다운로드 하기 위해서 제작되었다고 한다.[10] 그렇다면, Google Play는 이러한 통계와 사례로 보이는 무방비한 곳임을 알고도 가만히 있던 것일까. 꼭 그런 것만은 아니다. 구글은 Google Play의 스캐닝 방어를 강화하여 보호하려 노력했다. 하지만 가지각색의 애플리케이션은 다양한 공격방법과 보호방법으로 끊임없이 Google Play를 침투하였다. 바로, ‘Play Protect’을 통한 스캐닝은 ‘잠재적이고 해로운 앱’을 차단하는 데 꾸준한 진전을 보였다.[11]

그럼에도 여전히 부족한 것이 사실이다. 따라서 Google Play는 HackerOne 및 인기 있는 Android 앱 개발자와 협력하여 Google Play도 Bug Bounty를 실시하게 되었다.[12] 해커, Android 개발자, 사용자 등의 도움으로 Google Play의 보안을 더욱 향상하고, 더욱 안전한 애플리케이션을 사용자에게 제공하려 함이다. 어떻게? 이미 알고 있지 않은가. 애플리케이션의 버그, 취약점이 발견되면 현재 취약점 공개 프로세스를 통해 앱의 개발자에게 직접 보고하고, 취약점이 해결되면 Google Play Bug Bounty 프로그램에서 보상을 요청하면 된다. 발견된 취약점을 검사하고, 보상과 기준에 따라 각 제출물을 평가한다. 이 기준에 맞는 문제는 1,000달러, 약 백만 원 돈의 보상이 주어지고, 모든 보상 결정은 궁극적으로 Google Play Bug Bounty 프로그램 재량에 따라 결정된다. 물론 나중엔 진행자의 결정에 따라 다른 취약점도 기준에 추가될 수도 있다.

특정 인물이라면 취약점을 찾는 사람 중에서도 이번 Bug Bounty의 대상에 제외되기도 한다. 바로 미국 제재 목록에 있거나 미국 제재 목록에 있는 국가라면 보상을 제공할 수 없다고 한다. 예를 들어, 크림, 쿠바, 이란, 북한, 수단 및 시리아 등 사람들에겐 해당하지 않는다. 또한, 거주한 국가 및 시민권에 따라 세금에 대한 영향이 있을 것이며 현지 법률에 따라 추가 제한이 있을 수도 있다고 한다. 

하지만 Google Play에 등록된 애플리케이션은 한두 개도 아닐뿐더러 듣보잡 애플리케이션도 상당히 많잖아요? 그래서 Google Play에서 Bug bounty에 해당하는 애플리케이션을 정해놨다. 해당 애플리케이션은 아래에서 확인하자. 

Alibaba(com.alibaba.aliexpresshd) - 취약점 보고

Dropbox(com.dropbox.android, com.dropbox.paper) - 취약점 보고

Duolingo(com.duolingo) - 취약점 보고

Headspace(com.getsomeheadspace.android) - 취약점 보고

Line(jp.naver.line.android) - 취약점 보고

Mail.Ru(ru.mail.cloud, ru.mail.auth.totp, ru.mail.mailapp, com.my.mail, ru.mail.calendar) - 취약점 보고

Snapchat(com.snapchat.android) - 취약점 보고

Tinder(com.tinder) - 취약점 보고

 

이상 8개 기업의 애플리케이션이 해당되며, 추후 점검 애플리케이션은 추가될 수 있다. 또한, Google에서 개발한 모든 애플리케이션도 해당되며, Google 애플리케이션의 취약점은 Google Vulnerability Reward Program에 보고하면 된다. 또한, Chrome의 경우 Chrome Bug Bounty에서  보상이 제공되며 Google Play Security Reward 프로그램에 다시 취약점을 제출할 필요는 없다.

Google Play의 Bug Bounty 취약점은 RCE (원격 코드 실행) 취약점과 Android 4.4 이상의 장치에서 작동하는 해당 POC(개념 증명)로 제한된다. 이는 공격자가 사용자의 지식이나 권한 없이 사용자의 장치에서 자신이 코드를 실행할 수 있는 RCE 취약점을 의미한다. 예를 들어, 공격자가 네트워크에서 다운로드하여 임의의 코드나, 원시 코드, Java 코드 등 코드를 실행할 수 있는 모든 권한을 가진 취약점이 이에 해당한다. 또한, 트랜잭션을 커밋하기 위해 UI 를 조작하는 것처럼, 은행 애플리케이션이 사용자의 동의 없이 사용자를 대신하여 송금하게 하는 경우도 포함된다. 마지막으로 피싱 공격으로 이어질 수 있는 웹 뷰로 사용자 입력 또는 사용자와의 상호작용 없이 웹 창을 열 수 있는 것도 해당한다. 이때, 한 가지 주의할 점은 다른 애플리케이션과 연결되어 사용되어야 할 취약점이나 다른 애플리케이션을 설치해야 하는 취약점은 범위에서 벗어난 것으로 간주하니 Bug Bounty의 해당 취약점으로 해당하지 않는다. 

중요한 점! 모든 취약점은 Google Play에 제보하기 전 애플리케이션 개발자에게 직접 보고해야 한다. 그리고 개발자가 해결한 문제만 Bug Bounty 프로그램에 제출할 수 있다. 또한, 90일 이내에 패치 된 문제만 해당하며, 취약점이 해결되어 공식적으로 사용된 지 90일이 지난 애플리케이션은 보고서를 보내더라도 자격이 없다. 취약점 제보는 HackerOne의 공개 지침에 따르며, 제출하는 보고서는 보고서 양식에 맞춰 작성하여 제출해야 한다. 필수 정보를 포함하지 않고, 프로그램 기준을 미치지 못한다면 당연한 얘기지만 보상을 받을 수 없다. 취약점 보고서의 중복이 발생할 경우, 첫 번째 보고서만 해당하며, 하나의 취약점에서 파생된 여러 가지 이슈는 하나의 보상으로 보상된다고 한다.

Bug bounty는 경쟁이 아니다. 이는 실제로 서비스되고 있는 애플리케이션의 보안성을 높이기 위한 오히려 실험적인 취약점 보상 프로그램이다. 따라서 Google Play의 Bug Bounty는 언제든 종료될 수 있으며, 보상을 받을지에 대한 여부는 전적으로 Google Play Bug Bounty 결정에 따른다. 더불어, 취약점을 찾는다는 명분 아래에 해킹 테스트가 법을 위반하거나 애플리케이션에서 가지고 있는 데이터를 혼란 시키는 등 손상이 되지 말아야 하므로 조심하자.