사설 게임 서버를 막기 위한 방법들

(Private Game Server, 더 이상은 Naver!)

NHN NEXT

구승모

발표자 소개

* 2005년 WOW가 인생을 바꿔놓음 * WOW 오리지널 풀파밍 * 전투사령관 캐릭터 둘 그 이외 게임 업계 활동 * China GDC 2010 발표: “How to Support an Action-Heavy MMORPG from Angle of Server Architecture” * Game Developer Magazine 2012. 5월호 특집 게재: “Evolving MMORPG Combat”

* 2006~ Server Programmer, L3, NCSOFT * 2007~ Gameplay Programmer, Server Architect, TERA, Bluehole * 2012~ Professor, Game Track, NHN NEXT

강연 개요

Agenda

• 사설 서버란? – 사설 서버의 영향

– 사설 서버가 생기는 경로

• 사설 서버 방지를 위한 노력과 방법 – 직접 탈취로부터

– 서버 에뮬레이터 제작으로부터

강연 범위

• 강연 대상 – 온라인 게임 프로그래머 (서버, 플랫폼)

– 게임 서버 보안에 관심 있는 사람 (프로듀싱, 서비스)

• 다루지 않는 것 – 전반적인 서버 보안 방법 (DDOS, SQL Injection, …)

– Reverse engineering 방지 관련 테크닉

사설 게임 서버에 특화된 내용을 다룸

사설 서버 이야기

사설 게임 서버란?

• 게임 서버를 ‘탈취’하거나 ‘제작’하여 (원작자 동의 없이) 서비스 – Private server, Gray shard, Free server, Server emulator [1], …

– 대부분의 경우 영리를 목적으로 함

• 주로 2가지 방법으로 생김 – 해커들이 직접 탈취한 것을 기반으로

• (예) AEGIS (Ragnarok Online) [2]

– 서버 에뮬레이터 제작을 통하여

• 실제 정식 서버를 흉내(모방) 내도록 제작

• (예) WOW MaNGOS [3]

사설 서버의 악영향

• 직접적으로는 Profit-share 감소

• 간접적으로는 (더 무서운 것) – 게임 자체에 대한 신뢰 하락

– 유저들이 존중(respect)받지 못한다는 느낌

• Nexon, Blizzard, Ncsoft의 사설 서버에 대한 소송 예 – 북미 1등(?) 메이플스토리 사설 서버인 OdinMS [4]

– WOW 부분유료화 형태의 사설 서버인 Scapegaming [5]

– 5만 사용자를 거느린 리니지2 사설 서버인 L2Extreme [6]

왜 사설 서버를?

• 돈을 벌기 위해 – 꽤 많은 인력들이 사설 서버 구축을 위해 노력

– 생각보다 많은 사람들이 플레이 함 꽤 짭잘(?)

– CIS 관련 국가 및 중국 내륙

• (예) 한 때, 러시아 시장 1위는 리니지2 사설 서버 [7]

• 교육적인(?) 목적

– 서버 에뮬레이터 제작의 경우, 해커들의 도전 의식 자극 + 재미

– “게임 서버 프로그래밍 공부하기 정말 좋다”는 함정

직접 적인 유출(leak)로부터 사설 서버가 생기는 경우

• 개발사에서 직접 유출되는 경우 – 대부분의 경우 트로이 목마를 통한 유출

• 개발실 소스코드 유출 괴담: “출근 해보니 전부 체크아웃 되어 있더라?”

• (예) 밸브의 하프라이프2 소스코드 유출 [8]

• 우리 나라의 몇몇 회사들도 이렇게 털린 경우가 많음 (카더라 통신)

• 퍼블리셔측에서 유출되는 경우

– 서비스 네트워크 또는 배포선에서의 탈취

• (예) 뮤 온라인의 해외 유출 [9]

– IDC 근무자에 의한 인위적인 서버 바이너리 탈취

서버 에뮬레이터 제작을 통하여 생기는 경우

• 해커들은 미리 서버 에뮬레이터 제작을 준비 – 폐쇄형 커뮤니티(private IRC, phpBB 등)를 통해 정보 공유 및 수집

• 패킷 구조, 클라이언트 보안 메커니즘 등

– CBT와 동시에 클라이언트 입수 후, 해당기간 중 다양한 실험 및 공유

• 서버 프로그래머: “어?! 이상하다. 이런 패킷이 올 수가 없는데?”

• Non-Client Bot과 같이 만들어 짐

– 서버 에뮬레이터와 비슷한 시기에 (약간 먼저) 등장

• Non-client bot이 있다는 말은? 어딘가에서 서버 에뮬레이터가…

• 사실상 한 뿌리: 서버를 흉내 내느냐 클라를 흉내 내느냐의 차이

오늘의 진짜 주제와 결론

• 100% 막는 방법은 없습니다 – (작정한) 인원에 대한 보안은 정말 어렵기 때문

– 클라이언트는 이미 적의 수중에 있기 때문

• 그래서, 이미 버린 몸(?)이니 포기? – 어차피 털릴텐데 아무것도 안하기?

• 그렇지만, 노력대비(?) 효과를 볼 수 있는 방법들은 있음 – 오늘의 핵심 주제

사설 서버 방지를 위한 방법들 1

(직접 탈취를 막기 위한 노력)

개발사에서의 직접 유출

• 트로이 목마(Trojan Horse)를 통한 유출이 대부분 – 개발 관련툴 크랙 버전에 심어서 토렌트 등으로 배포

• (예) V-Asst, I-Bld, A-CS, …

– 개발자의 컴퓨터에서 실행되는 순간

• 백도어 생성후 해커에게 리포팅

• 리포팅 받은 해커는 바로 털어가지 않고, 지속적으로 감시 및 백도어 강화

• Windows Domain Admin 권한을 갖는 컴퓨터에 설치되는 순간 게임 오버

– 계속 지켜보다가 (어느 정도 완성되면) 순식간에 털어감

HOW-TO

• 정품 개발 툴만 사용 – 검증되지 않은 프로그램 사용 금지

• 최신 소프트웨어로 업데이트

– 특히 OS의 경우, 구 버전의 취약점을 공략

• 보안에 자신 없으면

– 개발망을 인터넷으로부터 물리적으로 분리 (가장 확실)

• Source repository, Issue tracking system 등

인원 보안 문제

• 그럼에도 불구하고, 내부 사람에 의해 털릴 수 있음 – 가장 무서운 적은 내부의 적

– 퇴사시 별 생각 없이 습관적으로 가져가는 경우도 있음 • 악의적인 의도가 아닌 경우: (열정이 넘쳐?) 집에 가져와서 일하는 경우

• HOW-TO – 개발망 분리 후, 비인가 저장장치 사용 금지

– 회사에서의 작업물에 대한 교육(개념 주입) 필요

– 개발자들에게 잘해줘서 회사 떠나지 않게 하는 것 (가장 확실) • 개발자 괴롭히면? 복수심에 싹 다 들고 제 3국가 가서 서비스 할 수도.. (농담)

퍼블리셔측에서의 유출

• 배포선(release process) 또는 IDC에서 유출되는 경우 – 내부 인원에 의한 유출

• 운영 인원의 권한 최소화 및 2-way 인증 필요 (뻔한 이야기)

– 직접 해킹 당하는 경우 • 해킹 방어는 광범위한 영역 (본 강연 주제를 벗어남)

– 100% 유출 막는 것은 불가

• 서버 바이너리의 유출 여부를 아는 것이 중요 – 어떤 버전이 어디를 통해 유출 되었는지 아는 것이 필요

– 탈취된 서버가 정상적으로 동작하지 않도록 하는 장치 도입

HOW-TO: 기본적으로 해야 할 것

• 인가된 채널로만 배포 – 급한 patch라고 메일 등으로 전송 금지

• 서버 프로그램 유효 기간 설정 (Time-bomb) – (예) 현재 실행 시각이 빌드 시점(__DATE__)로 부터 얼마 지났는지 체크

• Binary Fingerprint – 인증된 머신 정보를 서버 바이너리에 삽입

• (예) .data 영역을 확보 해놓고, 배포시에 인가된 머신 MAC주소로 교체

– 서버 실행시 해당 영역 정보와 머신 정보 비교

HOW-TO: 서버 실행 여부를 통지 받기

• 서버 시작시 80번 포트로 서버 정보 보내기 – 버전, 인가된 머신 번호, 퍼블리셔 코드 등을 암호화해서 전송

– Outbound 80번 포트(http)를 막는 경우는 거의 없음

– 리포팅은 제 3지대(Amazon EC, GAP 등) 서버에서 받기

• 리포팅 받은 것을 주기적으로 모아서 메일로 통보 받으면 편함

{NX_KOR, VER, IP, MAC, …}

via HTTP/80

Reporting

e-mail

이것저것 다 귀찮은 경우…

• 돈(?)으로 해결 할 수 있음

• 하드웨어 보안 모듈이 설치된 서버에 배포 – TPM[10]을 통한 디스크 암호화 등

• 라이선스 서버 솔루션 사용 – 인터넷을 통한 실시간 인증을 받아야 서버 실행이 가능

사설 서버 방지를 위한 방법들 2

(서버 에뮬레이터 제작을 방해하기 위한 노력)

서버 에뮬레이터의 경우

• 처음부터 보안에 신경을 써야 함 – 해커들은 최초의 외부 테스트(FGT, CBT)부터 클라이언트 분석

– 오픈 전에 서버 sandbox가 등장하는지 여부를 결정

• Sandbox? – 월드 접속 및 이동만 되는 일종의 더미 서버로 해커들의 첫 번째 목표

– 서버-클라이언트간 핵심 동작 메커니즘이 분석 당했음을 의미

• 두 측면에서 공략 – 패킷 분석 및 클라이언트 역공학(reverse-engineering)

클라이언트 역공학

• 동작 메커니즘 분석 – DLL injection등을 통해서 send/recv API 부분을 hooking

– 서버-클라이언트간 어떤 데이터를 어떻게 주고 받는지 파악

• 시간과 노력이 많이 들지만 암호화 관련 로직 우회 가능

• 게임 데이터 추출 – 아트 리소스 뿐만 아니라 게임에 필요한 각종 데이터시트 정보들

• (예) 스킬 공격력, 아이템 스탯 테이블 등

HOW-TO: Anti-Reverse Engineering

• 광범위한 주제 – 기초적인 것만 해도 해야 할 것이 많음 [11]

• 해커들의 속도를 따라잡기 힘든 부분

– 개발자가 일일이 적용하는 것은 비용대비 효과 측면에서 비추

• 클라이언트 바이너리 난독화 전문 툴 사용을 추천

– Themida (WinLicense) [12] 등 (의외로 싸다)

– 지속적으로 최신의 반-역공학 방법들이 업데이트 됨

HOW-TO: 꼭 필요한 데이터만 패키징

• 클라이언트에서 꼭 필요한 (client-only) 데이터만 넣기 – 의외로 서버에서만 필요한 데이터도 같이 넣는 경우가 많음

• (주로 귀차니즘 때문에) 통합 데이터시트로 하는 경우

– 배포 툴에서 패키징 자동화하는 것을 추천 • 데이터 항목에 서버/클라/공용 태그 넣기

• [참고] 서버 에뮬레이터 제작시 가장 더럽고(?) 귀찮은 부분 – 실 서버와 같은 데이터 값(밸런싱 정보 등)을 수집하여 입력하는 것

– 클라이언트에 해당 정보가 있다면, 손쉽게 추출해서 사용하게 됨 • (예) W모 게임의 경우, dbc파일 추출 후 그대로 읽어서 사용

패킷 분석

• 서버-클라이언트간 패킷 수집(capture) – 어떤 내용이 오가는지 알면, 서버/클라이언트 모두 흉내낼 수 있기 때문

– 암호화 하지 않는 경우 클라이언트 역공학을 시도할 필요도 없음

• 패킷 암호화 – 아무리 잘해도 언젠가는 파악당함 (클라이언트 역공학)

• 개발자가 덜 귀찮도록 하는 방식으로 관리하는 것이 핵심

• 패킷 내용들이 파악되어도 조금만 수정하면 시간을 또 벌 수 있도록

– 패킷 수집(감청)으로부터 최소한 유저들의 정보를 보호하기 위함

• Raw data 그대로 수집되면 위험한 것들 (ID, PIN, 메일주소, 채팅내용 등)

HOW-TO: 패킷 암호화시 주의할 점

• 직접 설계하거나 구현하지 말 것 – 이미 검증되고 리뷰 많이 받은 잘 만들어진 코드를 사용 [13]

• (예) AES256, RC4, …

• 아무리 독창적인(?) 암호화 알고리즘을 만들더라도 파악됨

• 결국, key를 잘 관리하는 것이 핵심

• 절대로 key를 클라이언트에 박지(?) 말 것

– 사실상 암호화 하지 않는 것과 같음

– Key는 세션을 맺을 때마다 무조건 새로 생성해서 교환해야 함

HOW-TO: 암호화 통신을 위한 Key 교환

• Diffie-Hellman Key Exchange [14]

– 세션 성립시마다 새로운 키로 암호화하기 위함

– 각종 공격(예: MITM)에 안전한 구현체를 사용할 것 (예: SRP) Client Server

소수 p, g

a b

crypto-key

Client Server

감청 당해도 crypto-key 파악 불가

Transport

K = B^a mod p B = g^b mod p

a b

B A

A = g^a mod p K = A^b mod p

Secure Remote Password Protocol

• SRP [15]

– 스탠포드 대학에서 제작 (현재 버전은 SRP-6a)

– 인증 + 키 교환 + 패스워드 암호화를 한방에 해결!

– 인증에 사용되는 비밀 정보가 일부 털려도 안전

– 사전 공격 및 MITM 공격 등으로부터 안전

– 공인 인증 기관 (CA) 필요 없음

HOW-TO: 패킷 암호화시 주의할 점

• 패킷 전체를 스트림 방식으로 암호화

– (예) W모 게임처럼 패킷헤더만 암호화 하는 경우 raw data 노출됨

HOW-TO: 패킷 셔플링

• 패킷 번호 및 패킷 내용 순서 무작위 치환 (shuffle)

– 패치 때마다 패킷이 바뀌는 효과 해커들 입장에서는 상당히 귀찮음

– SVN revision 번호 또는 GIT tag hash를 key로 활용 가능

– 배포시 자동화 추천: pre-build event로 패킷 코드 생성(emit)할 때

이런 노력에도 불구하고,

• 서버 에뮬레이터 제작을 100% 막기는 불가 – 어차피 클라이언트는 언젠가는 완전히(?) 분석 당함

– 어딘가에서 서버 에뮬레이터가 만들어지고 있는지 아는 것이 중요

• FACT – 서버 에뮬레이터도 결국 (인터넷상의) 일반인 대상으로 서비스

• HTTP 포트(80)를 일부러 닫고 사용하는 유저는 없다는 점을 이용

– 클라이언트는 정식 배포본을 사용한다는 점을 이용 • 플레이어의 클라이언트가 어느 서버에 접속하는지를 직접 리포팅

• 대상 서버 IP가 127.0.0.1, 192.168.x.x 이런 종류라면 제작 중이라는 뜻

접속 대상 서버 정보를 통지 받기

map-reduce & whois

사설 서버

사설 서버 유저 (클라이언트)

Random sampling report via HTTP 클라이언트가 특정 확률로 서버 정보 리포팅

정식 서버 정보는 걸러내고 리포팅

정리

마무리

• 100% 방지법은 없음 – 최소한의 노력은 하자: 언급한 방법들이 난이도 높은 일이 아님

– 어차피 털린다고 손 놓은 것과는 차이가 큼 (방충망이 유무의 차이)

• 관리의 측면으로 접근 – 지속적으로 모니터링 및 수정(자동화)을 통해서 시간을 벌기

– 내가 보안에 쓰는 노력보다 해커가 뚫는 노력이 더 큰 것 위주로 적용 • 숨기는 것 보다 찾는 것이 더 어려운 이치

• 실제로 상당히 효과적이었음

감사합니다.

Any Questions?

References

1. http://en.wikipedia.org/wiki/Server_emulator

2. http://en.wikipedia.org/wiki/AEGIS_(Ragnarok_Online)

3. https://github.com/mangos/MaNGOS

4. http://maplenewsnetwork.wordpress.com/2008/06/18/odinms-vs-nexon/

5. http://www.gamerlaw.co.uk/2010/blizzard-wins-88m-lawsuit-against-wow-private-server-owner/

6. http://www.gamasutra.com/php-bin/news_index.php?story=11786

7. http://www.thisisgame.com/special/page/event/ion/2008/nboard/79/?n=8335

8. http://www.gamespot.com/articles/half-life-2-source-leaked/1100-6076314/

9. http://m.inven.co.kr/webzine/wznews.php?idx=14253

10. http://en.wikipedia.org/wiki/Trusted_Platform_Module

11. http://www.codeproject.com/Articles/30815/An-Anti-Reverse-Engineering-Guide

12. http://www.oreans.com/themida.php

13. http://security.stackexchange.com/questions/2202/lessons-learned-and-misconceptions-regarding-encryption-and-cryptology

14. http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange

15. http://en.wikipedia.org/wiki/Secure_Remote_Password_protocol

뒷이야기

• 수년간 지켜본 입장에서의 개인적인(?) 느낌

• 서버 에뮬레이터 구현 능력 – 프로그래밍 실력?

– 러시아 친구들(잉여력까지 느껴짐) >> 중국 해커들 > 미국 해커들

• 실제 게임(실서버)의 흥망성쇠(?)와 상관 관계 있음 – 서버 에뮬 개발이 활발해지고 있는 추세 ∝ 실서버 사용자 수

– 개발이 중단되거나 관련 커뮤니티가 완전 죽은 경우 • 실서버 사용자 급감 상황

서버 에뮬레이터 제작 커뮤니티

• 서버 에뮬레이터는 다양한 버전이 존재 – Sandbox 이후로 다양한 버전

– 수익금 기부(donation) 문제 등으로 커뮤니티 분열이 잦음

• 누군가 (몰래) 서비스, 핵심 멤버 탈퇴, 원 제작자로부터의 추적 등

– 누군가 기존 작업물을 가져다가(stealing) 새로운 프로젝트로 포장

• 비슷한 이유로 또 분열 반복