금일(5일), 라인은 경기창조경제혁신센터에서 글로벌 마켓 게임 런칭 시 중요한 '보안'을 주제로 '라인 게임, 보안 어떻게 하나?' 세미나를 개최했다.
이번 세미나에는 라인의 이명재 개발자, 전상훈 라인 게임 시큐리티 리드 개발자 등이 연사로 나서 현업 개발자들을 대상으로 모바일 해킹에 대응하기 위한 라인 게임의 솔루션 소개부터 글로벌 런칭 시 유의할 보안 사례, 실제 모바일 위협과 대응 등 각종 '보안'과 관련된 이야기를 들려줬다.
보안과는 떼려야 뗄 수 없는 관계에 있는 게임 업계다. 대내외적으로 호평받은 게임이 해킹으로 인해 실제론 별다른 매출을 올리지 못했다는 얘기도 심심찮게 들려오는 이때, 과연 라인 게임은 이러한 사례에 어떻게 대응하고 있을지, 이날 세미나에서 나온 얘기들을 간략하게 정리했다.
■ 모바일 시큐리티 비젼
현재 라인 게임은 전 세계적으로 84종의 게임을 서비스 중이다. 하루 평균 1,500만 명에 달하는 유저가 즐기고 있으며, 쌓이는 보안 이슈 로그는 매일 200기가 정도다. 여기에 iOS와 안드로이드 각기 다른 플랫폼 환경에서 문제가 발생하기에 이를 해결하려면 단순 계산으로 배에 달하는 노력이 필요하다.
결국, 라인 게임은 이러한 각종 보안 이슈를 수월하게 해결하기 위한 솔루션을 구축할 필요가 있었다. 물론, 쉽지는 않았다. 2014년 처음 솔루션 구축의 필요성을 느끼고 접근했을 때만 해도 어떻게 접근할 지도 몰랐다. 그래서 아예 처음부터 솔루션을 구축했고 지금에 이르러선 가시적인 성과를 보이고 있다.
라인 게임은 그럼 보안과 관련해 어떤 솔루션을 구축한 걸까. 우선 기존의 보안 이슈에 대한 대응을 보자. 지금까지는 패시브적인 대응으로 사건이 터지면 후속조치를 취하는 방식이었다. 문제는 이 방식은 너무 느렸다. 로그를 살피는데 시간이 너무 걸려서 추적도 대응도 어려웠다. 그래서 라인 게임은 이런 패러다임을 바꾸고자 했다.
이를 통해 새롭게 구축한 보안 기술을 라인 게임은 AIR(Active Incident Response)라 명명했다 이슈가 발생하기 전 사전에 이슈를 원천 차단하는 방식으로 이를 위해 AIR는 취약점 제거, 난독화 검증, 눈에 띄지 않는 모니터링 세 가지에 집중했다.
전상훈 라인 게임 시큐리티 리드 개발자를 이어 단상에 오른 정명주 AIRGO 리드 개발자는 AIR에 대해 자동화된 보안 이슈 분석 시스템이라 말했다. 라인은 모든 앱을 배포 전에 보안 검수를 한다. 이때 거의 대부분은 반복작업이기에 이 부분을 효율화한 거다.
난독화의 경우 가장 기본적인 보안 방법이다. 크게 코드 난독화, 바이너리 난독화로 나뉘는데 코드 난독화는 클래스, 변수 등을 의미 없는 걸로 치환하거나 더미 데이터를 넣는 식이고 바이너리 난독화는 리버스 엔지니어링을 원천 봉쇄하는 방식이다.
라인 게임은 AIR를 통해 배포하는 앱의 ELF 파일, String, Symbol, PE 파일 등의 난독화를 검증하고 이를 개발사에 제공해 보안을 높이고 있다.
취약점 검증을 하기 위해선 해커가 공격하기 좋은 취약점이 우선 어떤 건지 알 필요가 있다. 이런 취약점을 진단하기 위해 라인은 CVE나 구글 플레이 스토어 가이드를 이용하고 있다. AIR를 통해서는 dex find api, dex strings 등 다양한 취약점을 파악할 수 있는데 이렇게 나온 취약점들을 개발자들에게 전달해 꼭 수정하길 권하고 있다.
한편, AIR에서는 오픈소스 라이선스를 분석하는 기능도 제공하고 있다. 보통 영세 게임사의 경우 이런 오픈소스 라이선스를 검증하기 위한 법률팀을 꾸리기가 어렵다. 그래서 일단 썼는데 나중에 성공한 후에 이른바, 태클이 들어올 수 있다. 이런 법률적 문제를 사전에 방지코자 해당 기능을 넣었다.
오픈소스 라이선스 검증은 취약점 검증과 유사하다. Github, sourceforge 등을 분석해 메소드, 함수가 어떤 라이선스를 가졌는지 검사하고 이를 DB에 업데이트 한 후 DB와 앱을 참조해 라이선스를 진단한다. 물론 완벽하진 않다. 하지만 꾸준히 업데이트하고 있으며 다양한 방법을 이용해 라이선스 오진률을 최소화하고 있다.
■ 모바일 클라이언트 프로텍트
어뷰저(=해커)들은 보통 어떻게 클라이언트를 해킹할까? 흔히 말하는 것처럼 소스 코드를 하나부터 끝까지 다 뜯을까? 그렇지 않다. 이런 어뷰저들에게 있어서도 최후의 수단이다. 대부분은 이보다 훨씬 낮은 수준의 작업이 이뤄진다. 즉, 처음부터 대비한다면 수월하게 막을 수 있다. 그렇기에 정상민 AIRARMOR 리드 개발자는 개발자들이 어뷰저들의 공격을 막는 일은 보안 부서, 솔루션의 역할로만 생각지 않길 바란다고 말했다.
실제로도 재화를 복사하는 등 치명적인 이슈를 몰고 오는 어뷰저는 극히 일부고 대부분은 이미 변조된 파일을 사용하는 부류인 만큼, 개발자들이 처음부터 그들을 막기로 마음먹으면 더 효과적으로 차단할 수 있기 때문이다. 적극적인 어뷰저 가운데서도 이를 사업적으로 이용하는 해커는 더 적다. 대부분은 취미거나 자신의 기술을 과시하고자 하는 경우가 많다.
특히 문제가 되는 건 사업적으로 앱을 파는 부류로 이렇게 앱이 한 번 변조되면 이후 패치를 하고 강화된 로직을 넣어도 재차 뚫리는 경우가 않은 만큼, 처음부터 보안을 철저히 하는 게 중요하다.
어뷰저들은 보통 처음 앱을 해킹할 때 구조적인 취약점을 건드린다. 네트워크 패킷이나 기기의 시간을 바꾸는 방식이다. 이렇게 했는데 취약점을 발견하지 못한다면 다음으로는 툴을 이용하는 작업으로 넘어간다. Xposed, Xline Bypasser, XLINE Games, GameGuardian 등을 이용하는 방법. 만약 여기서도 막힌다면 본격적으로 앱을 분석하는 작업으로 넘어간다. 앱의 구성요소를 확인하고 리소스 상에서 정보를 찾거나 게임의 버그를 이용하는 방식이다.
그리고 여기서도 못 찾으면 마침내 리버싱 단계에 들어간다. 이건 해커에게도 힘든 단계다. 여러 툴을 이용해 하나하나 분석하는 작업. 그래서 지루하지만 불가능하진 않다. 그리고 만약 이 과정에서 해커가 필요한 부분을 발견하면 그 부분만 집요하게 파고들어 이득을 취한다. 결과적으로 해커에게 있어선 생각만큼 시간이 걸리는 작업은 아니다.
한편, 이런 치명적인 보안 이슈 외에 대부분의 보안 이슈는 사소한 실수에서 비롯되는 경우가 많다. 이미 알려진 방법을 쓰면 해커들은 금방 그에 대응하는 파훼법을 들고 온다. 그러니 해커들이 알 수 없도록 커스텀 인코더를 만들어서 사용하길 바란다.
여기에 네트워크 통신을 할 때 Curl을 많이 쓰는데 디버그할 때 임의의 도메인을 쓰기에 인증서 검증을 빼는 경우가 많다. 그런데 문제는 이걸 깜빡하고 그대로 출시하는 경우가 더러 있다. 이런 코드상의 실수는 없는지 출시 전에 꼭 확인하길 바란다.
■ 실제 모바일 위협과 대응 사례
라인 게임은 출시 전, 출시 후, 서비스 종료 크게 세 파트로 나뉘어 모바일 위협에 대응하고 있다. 출시 전에는 흔히 범하기 쉬운 취약점 등을 파악해 사전에 해킹 위협을 원천 차단하는 방식이다. 대표적으로는 유니티로 만든 앱들을 들 수 있다. 유니티로 개발이 쉬워진 만큼, 많은 앱들이 유니티로 나오고 있는데 문제는 디컴파일이 쉽다는 거다. 신경 쓰지 않으면 소스코드도 전부 볼 수 있다. 그래서 라인 게임 플랫폼으로 낼 경우 IL2CPP를 필수로 하도록 하고 있다. 이것만 해도 DLL 파일에 해커들이 접근하기 굉장히 어려워진다.
여기에 해커 입장에서 클라이언트, 통신구간, 로컬 전부의 보안을 점검하기도 한다. 이를 통해 통신변조, 과금우회 등 치명적인 보안 이슈 문제가 발생하지 않도록 하고 있다.
하지만 완벽한 대책은 아니다. 전문지식을 갖고 어떻게든 해킹하고자 하면 뚫릴 가능성이 있는 만큼, 이러한 일련의 대응에 대해선 보험적인 대책 및 모니터링으로 봐야 한다.
출시 후에는 각종 모니터링을 통해 이상 유저(=어뷰저)가 없는 지 탐지하고 밴 대응 및 경고를 한다. 라인에서는 한 판에 얻을 수 있는 스코어, 재화 등의 임계치를 정해서 그걸 넘는 유저를 찾는 방식의 임계치 베이스와 정규 분포를 기준으로 얼마나 떨어져 있는지 게임요소에 스코어를 부여해 이상 유저를 탐지하는 방식의 스코어 베이스를 기준으로 이상 유저를 탐지한다.
임계치 베이스의 경우 게임 내 재화를 점검할 때 효과적이며, 스코어 베이스는 게임 요소에 의존하지 않기에 두 요소를 적절히 섞어서 이용하고 있다.
하지만 이렇게 해서 어뷰저를 찾는다고 해도 일괄적으로 밴을 할 순 없다. 국가별로 법률이 다르기 때문에 각 상황에 맞게 다르게 대응해야 한다. 일례로 대만의 경우 소비자 보호가 투철해 영구 밴을 하면 과징이라고 할 정도다. 그래서 처음부터 밴을 하기보다는 우선 경고를 하고, 또 문제가 발생하면 기간 밴을 하는 식이다.
한편, 최근에 특히 문제가 되는 게 바로 치팅 상품을 파는 경우다. 한국에선 생소하겠지만 해외에선 해킹하면 치팅 상품을 팔아서 금전적 이익을 얻는 게 상식화됐다. 문제는 이 역시 직접적인 대응이 어렵다는 부분이다. 판매 대행을 하는 것부터 판매 사이트 역시 이득을 얻기에 상품 삭제 조치 등에 대한 제재가 어려운 편이다.
지금까지가 출시 전, 출시 후에 나온 대표적인 보안 사례 및 대응이었는데 서비스 종료 시에도 보안 문제는 발생한다. 구글 환불 대행 이슈와 서비스 종료 시 해커들이 환불을 노리고 재화를 해킹하는 사례다. 둘 다 서비스 종료 시점을 노린 경우로 최근에는 이에 대비해 기업들이 구글과 협의해 환불을 기업이 관리하는 식으로 바뀌고 있다.
Nowl@inven.co.kr
페이지 구독하기
다른 기사 보기
기사 제보하기
