Upgrade to Pro — share decks privately, control downloads, hide ads and more …

[NDC07] 게임 개발에서의 클라이언트 보안 - 송창규

[NDC07] 게임 개발에서의 클라이언트 보안 - 송창규

ChangKyu Song

April 28, 2013
Tweet

More Decks by ChangKyu Song

Other Decks in Programming

Transcript

  1. 목 차 위기의 시대 위기의 시대 클라이언틔 해킹의 종류 해킹

    둘러보기 해킹 툴 기본 지식 둘러보기 세상 믿을놈 하나없다 대안 피해야 할 것들 클라이언트 해킹의 기술적 대안 안전한 클라이언트 만들기 The Attacker’s Advantage and the Defender’s Dilemma
  2. 위기의 시대 - 이젠 익숙한 단어들 프리서버, 오토클라이언트, … 오토마우스,

    매크로, … 스피드핵, 메모리핵, 맵핵, … 노딜핵, 무한핵, 투명핵, … 돈버그, 무한버그, 시체버그, 무적버그, … RMT (Real Money Trading), Gold Farms, …
  3. 위기의 시대 - Hack 2.0 Hack 2.0 - 더 이상

    과거의 해킹이 아니다 Rootkit 발견되지 않도록 은닉하는 형태의 해킹 툴 Hooking API Hooking, Winsock Hooking, System Hooking Virtualization 환경 제어가 강력해짐 Hacking Earns Money Every Computer is Connected Hackers goes Web 2.0 (Collaborate)
  4. 게임 해킹(cheating)의 종류 Reflex Augmentation (반응 향상) 인간이 해야할 역할을

    도움 – 오토마우스, aimbot, 매크로, 자동반응 등 Authoritative Clients (힘자랑 클라이언트) 하지 말아야 할것을 하게 함 – 텔레포트, 능력치 올리기, 제한 풀기 등 Information Exposure (정보 노출) 알지 말아야 할것을 알게 함 – 맵핵, 스탯핵, 투명벽 등 Bugs and Design Loopholes (Exploits) (버그) 기존 로직의 버그를 이용 Others Compromised Servers Environmental Weaknesses Social Cheats Identity Theft Reverse Engineering
  5. 클라이언트 해킹의 기술적 분류 데이터 파일 조작 데이터 메모리 조작

    실행 파일 조작 코드 메모리 조작 패킷 조작 환경 조작 네놈도 조작해주마
  6. 해킹 툴 데이터 파일 조작 – WinHex, UltraEdit, … 데이터

    메모리 조작 – TSearch, Cheat Engine, … 실행 파일 조작 – OllyDbg, Resource Hacker, … 코드 메모리 조작 – OllyDbg, Loader, … 패킷 조작 – WPE, Proxy, … 환경 조작 – Microsoft Windows, VMWare…
  7. 해킹 툴 – More 모니터링 – ProcExp, FileMon, RegMon, Iris,

    … 실행압축 – UPX, ASPack, ASProtect, PECompact, … 은둔 – HxDef (Hacker Defender) 방어무력화 – “가드내려”, nProtect Bypassing, … 키로거 Reverse Engineering – IDA, HBGary Inspector, ...
  8. 해킹 툴 OllyDbg 현재 크래커들이 가장 많이 쓰는 유저모드 디버거

    유저 친화적 인터페이스 강력한 코드 분석 기능 C Runtime (strcpy, rand, …) Reference Analysis Call Graph 알아보기 쉽게 친절한 가이드 API Stack 분석, 안내
  9. 해킹 툴 OllyDbg 현재 크래커들이 가장 많이 쓰는 유저모드 디버거

    유저 친화적 인터페이스 강력한 코드 분석 기능 C Runtime (strcpy, rand, …) Reference Analysis 알아보기 쉽게 친절한 가이드 API Stack 분석, 안내 “CreateMutexA” API 도 파라메터와 함께 친절하게 “strstr” C Runtime도 파라메터와 함께 친절하게 References 특정 코드를 역참조
  10. 해킹 툴 OllyDbg – Plugins PDK 제공 다양한 플러그인 HideDebugger

    UniversalHooker CallGraph View Dialogs FindCrypt OllyScript String Access Finder
  11. 해킹 툴 TSearch 현재 크래커들이 가장 많이 쓰는 치팅 툴

    치트 양산화의 주범 추이를 입력하여 데이터 추적 5  3  1 늘었다  줄었다  줄었다 Data Freeze + 핫키 저장 / 공유 유사품 Cheat Engine ArtMoney
  12. 해킹 툴 TSearch – AutoHack 1.6 부터 등장 일종의 특화된

    Debugger Data Breakpoint 를 이용하여 데이터 변경 코드를 추적 데이터 치트 양산화에서 코드 치트 양산화로 Cheat Engine 등은 로더 제작기능도 있다
  13. 기본지식 – Process & Memory Process & Memory Process A.exe

    0x0136000 stack 0x03d0000 heap 0x0400000 A.exe 0x6400000 MyDll.dll 0x7c80000 kernel32.dll Memory Address Space 0x0136000 stack 0x03d0000 heap 0x0400000 A.exe 0x6000000 A.dll 0x6400000 MyDll.dll 0x7c80000 kernel32.dll Process B.exe 0x0136000 stack 0x03d0000 heap 0x0400000 A.exe 0x6400000 MyDll.dll 0x7c80000 kernel32.dll Memory Address Space 0x0136000 stack 0x03d0000 heap 0x0400000 B.exe 0x6400000 Mama.dll 0x6500000 MyDll.dll 0x7c80000 kernel32.dll  프로세스마다 Adress Space를 갖는다 (같은 포인터값이라도 프로세스마다 다른 데이터)  EXE 는 보통 0x0400000 에 위치  같은 DLL 는 보통 같은 주소에 위치  특히 OS 기본 DLL 은 같다고 봐도 된다  하지만 같은 프로세스의 두 DLL 의 주소영역이 겹칠 수 있다 !  Relocating / Rebasing
  14. 기본지식 – API 함수를 호출하려면: CALL 0x12340 두 프로세스의 서로

    다른 DLL 이 같은 주소를 쓰려고 하면? OS 는 DLL 의 주소를 동적으로 바꿀 수 있게 해준다  Relocation / Rebasing DLL 호출하는 코드는 어떻게 바꾸지? DLL 의 함수를 import 했을 경우 아래와 같은 코드 생성 CALL [0x43210] IAT (Import Address Table)
  15. 기본지식 – API Hooking IAT 를 수정하면 API Hooking 이

    가능 IAT 가 가리키는 주소의 코드를 직접 수정하는 방법도 있다 코드영역을 수정하기 위해서는 VirtualProtect 이용 PAGE_EXECUTE_READ  PAGE_READWRITE 하나의 API 에는 여러가지 gateway 가 있다. TextOutA  TextOutW OpenProcess  NtOpenProcess / ZwOpenProcess kernel32.dll  ntdll.dll  ntoskrnl
  16. 기본지식 – 코드 해킹 방법 해커가 코드를 실행하는 방법 코드

    가로채기 CreateRemoteThread SetWindowsHookEx Buffer Overflow Many more in Kernel Mode 해커가 코드를 가로채는 방법 Code patching IAT patching Breakpoint DLL hijacking SEH (Structured Exception Handling) Access Violation Division By Zero Many more in Kernel Mode
  17. 기본지식 – Kernel, IA32 architecture Kernel, IA32 architecture Kernel mode

    - 권한 제약이 없다 Driver 를 개발하면 Kernel mode 에서 동작하는 프로그램을 만들 수 있다 Filter Drivers – No Hooking Necessary IA32 Debug Register (Data Breakpoint) Trap (Interrupt)
  18. 기본지식 – Buffer Overflow Buffer Overflow "Today's Denial of Service

    is Tomorrow's Code Execution.“ 데이터만으로 코드 실행 가능 대부분 c string 처리에서 발생 c string 을 그냥 쓰는길은 자폭의 길 String Class 로 wrapping 해서 쓸것 정 써야할곳에는 strcpy_s, strcat_s 를 쓸것 Buffer Max Size 와 Size 를 검사할것
  19. 해킹, 어느정도까지 왔나 스타크래프트 해킹 맵핵 외에 스타 자체 버그를

    잡아주는 유틸리티 등장 Reverse Engineering - 맵핵을 발견해주는 유틸리티 등장
  20. 해킹, 어느정도까지 왔나 한스타 – 한글 스타크래프트 자체 Text Out

    함수를 교체 비트맵 처리, 캐싱, 팔레트 처리, … 맵핵 방지 기능 (無맵핵 인증 기능)
  21. 해킹, 어느정도까지 왔나 보안 솔루션도 믿을수 없다 강력하지만, 맹신은 금물

    많이 사용할 수록 많이 공격당한다는 법칙에도 가장 부합됨 전세계의 수많은 해커가 노리고 있다 타 프로세스가 메모리 읽지 못하게 막아주는 보안 솔루션 PrevX 를 이용하여 nProtect 가 메모리를 읽어서 검사하지 못하게 함
  22. 창과 방패, 그 무한한 싸움 클라이언트의 보안은 한계가 있다 해킹과

    보안 기술은 결국 하위 레벨에서의 동작을 같은 레벨이나 상위 레벨에서 감시/조작하는 기술 가장 상위 레벨(Kernel mode)까지 올라가면 결국 먼저 떠서 상대방의 코드를 가로채고 조작할 수 있는 쪽이 승리
  23. 세상 믿을놈 하나없다 코드를 믿지 말라 라이브러리를 믿지 말라 OS

    를 믿지 말라 컴퓨터를 믿지 말라 보안 솔루션을 믿지 말라 서버를 믿지 말라 (?)  서버와의 커뮤니케이션을 믿지 말라 사실 유일하게 믿어야 하는 존재는 서버이다.
  24. 대안 피해야 할 것들 클라이언트 해킹의 기술적 대안 안전한 클라이언트

    만들기 The Attacker’s Advantage and the Defender’s Dilemma
  25. 피해야할 것들 XOR 암호화 맨눈으로 훑어봐도 보이는 XOR 은 암호화가

    아니다. 일반적인 데이터에는 “0” 이 압도적으로 많음 – 패턴과 키가 쉽게 노출됨 일부 데이터 추적기는 XOR 데이터까지 찾아준다.
  26. 피해야할 것들 즉각적인 액션 빠른 리액션은 역추적의 지름길 특히, MessageBox

    를 띄우는 로직은 가장 쉽게 드러난다 서버를 경유하거나 비동기적 로직과 임의의 딜레이와 함로 처리
  27. 피해야할 것들 즉각적이지 않은 액션 “당신은 한달 전에 해킹툴을 사용하였으므로

    계정이 영구 블럭되었습니다“ 대응까지의 시일이 많이 걸리면 역효과 – 학습 효과도 없고 유저가 이탈한다 운영과 기술의 중간적 이슈
  28. 피해야할 것들 String Data Display 목적이 아닌 String 은 모두

    주의 특히 String 을 Key 로 쓸 경우 주의 - ScriptKid 도 쉽게 해킹가능
  29. 피해야할 것들 중요한 데이터를 Client 가 그냥 처리 서버로 처리하거나

    다른 Peer 를 통해서도 처리하거나 유효성 검사를 하라
  30. 클라이언트 해킹의 기술적 대안 서버가 결정 Server Based Computing /

    Thin Client Model 빠른 반응성이나 클라이언트 데이터(메시 등)가 요구될 경우에는 한계가 있음
  31. 클라이언트 해킹의 기술적 대안 유효성 검사 검사 후 결과를 보내지

    말고, 보낸 데이터를 서버가 검사하라 클라이언트도 Double Check 정교한 동기화를 사용한다면 클라이언트끼리 검사 ex) Starcraft 는 서로의 데이터가 기대된것과 틀리면 즉시 멀티플레이에서 drop 시킨다 다양한 타이밍 / 방식으로 할 수록 좋다 ex) 매번 총을 쏠때마다: 이전 발사와의 시간간격 게임 종료후: 총 발사한 총탄/총 시간 내가 가한 대미지 수 : 발사한 총탄의 총 대미지
  32. 클라이언트 해킹의 기술적 대안 “대세는 낚시” – Honeypot In computer

    terminology, a honeypot is a trap set to detect, deflect or in some manner counteract attempts at unauthorized use of information systems – wikipedia 실제 데이터는 암호화, honeypot plain data 를 둔다. 걸려들 경우 100% cheating ! (no false positive)
  33. 클라이언트 해킹의 기술적 대안 원인과 결과의 연결고리 차단 클라이언트의 중요한

    정보는 서버를 경유해서 처리 중요한 로직을 비동기 로직으로 처리 ex) Window Message, Command Queue Multithreading 활용
  34. 클라이언트 해킹의 기술적 대안 매번 다른 동작을 요구 인증 또는

    데이터 유효성 검사시에 활용하면 좋다. ex) 서버의 랜덤을 활용한 확률 기반 검사 요청 if (rand() % 100 == 0) { if (rand() % 100 == 0) { if (rand() % 100 == 0) send_req_verify_A() // 1/1000000 else send_req_verify_B() // 약 1/10000 } else send_req_verify_C() // 약 1/100 } else send_req_verify_D() // 99/100
  35. 클라이언트 해킹의 기술적 대안 Online 대처 시스템 평소에는 사용하지 않다가,

    보안 위협 발생시 사용할 수 있는 시스템 ex) 서버측에서 커맨드를 내리면 특정 윈도 타이틀 / 프로세스명을 검색하여 새로 발견된 치트 프로그램 사용자 제재 처리 평소에 사용하지 않는 것이 핵심  해커에게 노출/공격당할 가능성이 적음 온라인상에서 클라이언트측으로 DLL 을 내려줄 수 있다면 더욱 좋다. (denial of service 공격을 감안하여 DLL 로부터 “실패” 메시지를 받아 제재하지 말고 DLL 로부터 “성공” 메시지를 받지 못하면 제재)
  36. 클라이언트 해킹의 기술적 대안 정보는 최소한으로 노출하라 디버깅 정보나 로그는

    최소화 시켜라 PDB 절대 배포 금지 데이터 파일은 암호화
  37. 클라이언트 해킹의 기술적 대안 서버가 결정 유효성 검사 “대세는 낚시”

    – Honeypot 원인과 결과의 연결고리 차단 매번 다르게 동작 보안 솔루션 활용 Online 대처 시스템 정보는 최소한으로 노출하라
  38. 안전한 클라이언트 만들기 기획/설계시 해킹을 고려하라 Thin Client Model 의

    경우, 기획시 클라이언트 판단 여지나 비중을 최소화 ( 액션 처리, 미니 게임 등 ) 설계시 데이터의 흐름과 중요한 데이터를 검토 ( 서버에서 할 수 있는 처리는 서버가 한다 ) ex) Mabinogi, Kart Rider
  39. 안전한 클라이언트 만들기 언제나 불리한 위치에 있음을 자각하라 “The Attacker’s

    Advantage and the Defender’s Dilemma” (뒤에 나옴) DON’T UNDERESTIMATE THE DARK SIDE OF THE FORCE HACKERS ARE YOUR FATHER
  40. 안전한 클라이언트 만들기 전문가와 상의하라 보안은 단순히 구현하는 영역이 아니다

    직접 막는다고 하지만, 모르는 부분의 보이지 않는 구멍이 수두룩하다 전문가와 상의하면 보다 현명한 솔루션을 얻을 수 있다
  41. 안전한 클라이언트 만들기 아무것도 완전히 믿지 마라 기획/설계시 해킹을 고려하라

    모든 소스가 공개되었다고 생각하라 언제나 불리한 위치에 있음을 자각하라 전문가와 상의하라 책임감을 가져라
  42. The Attacker’s Advantage and the Defender’s Dilemma The defender must

    defend all points; the attacker can choose the weakest point. 방어자는 모든 지점을 다 막아야 하지만 공격자는 한 곳만 골라 공격할 수 있다. The defender can defend only against known attacks; the attacker can probe for unknown vulnerabilities. 방어자는 알고 있는 범위만을 막을 수 있지만 공격자는 모르는 취약점을 찾아낼 수 있다. The defender must be constantly vigilant; the attacker can strike at will. 방어자는 언제나 늘 지키고 있어야 하지만, 공격자는 원하는 아무때 공격할 수 있다. The defender must play by the rules; the attacker can play dirty. 방어자는 원칙을 지켜 행동해야하지만, 공격자는 비열하게 공격할 수 있다.