웹해킹과 시스템해킹에 대해 지루함을 느낄때 공부를 시작 한것이 리버스엔지니링이다.

예전에는 소프트아이스나 PC-tools, 게임위저드 같은 툴이 다였는데

어느순간 부터 ollydbg나 ida-pro가 등장하기 시작했다. 2005년 부터 한 4개월 정도 게임핵 을 접하기 시작 했다. 당시 유행하던 p2p나 총쏘는 게임이 주로 타겟이였다.

irc에서도 많이 유행하기 시작했고, 홈페이지도 붐비였다. 그리고 듀*님 블로그가 엄청난 조회수를 기록하기도 하였다.

게임핵은 어떻게 만드냐? 종류가 크게 3가지 정도로 본다. 계정탈취, 오토봇, 게임조작

아래에서는 계정탈취나 오토봇은 다루지 않겠다.

그럼 게임조작을 어떻게 하느냐? 

메모리조작과 EXE실행파일(엔진) 조작이 가능한 부분이다.

주로 총쏘는 게임을 많이 조작했는데 총쏘는 게임의 구조는 가장 좋은 PC를 서버로 두고

모든 유저가 그 서버에 접속을 하여 소켓통신으로 게임이 진행된후 게임결과를 다시 서버로 전송하는 방식이다.  웹하드의 스트리밍 서비스와 비슷하게 서버에 최대한 부하를 줄이고 유저들에게는 빠른 타격감을 느끼도록 제작된것이다.

다만 저런 구조다 보니 해킹에 취약할수 밖에 없는 구조다. 초창기에는 메모리해킹이나 엔진파일이 바로 변조가 되었는데 메모리해킹은 어느정도 막히고, 엔진파일에 대한 조작만 활발하게 되었다. 그래서 해당 엔진파일이 조작되면 용량도 바뀌고, 주소값에 대한 시그니처도 바뀌고 무결성이 침해된다.

그래서 엔진파일의 무결성을 위해  보장하기 위해 여러가지 보호기법이 등장하기 시작한다.

그게 바로 런처다. 런처는 흔히 쉽게 설명하여 canary와 비슷하다 bof에서도 RET가 변조되면 해당 프로그램이 종료 되듯이 해당 엔진파일이 변조되면 프로그램이 종료되거나 다시 엔진파일이 다운로드 되어 실행되게 되어있다.

이 런처를 뚫기 시작한것이다. 처음엔 단순한 패킹으로 우리들의 아마추어적인 실력으로 뚫리다. 이게 점점 어려워지기 시작하고, 2중 3중 방어막이 생기게 되었으나 이것 마져 뚫으니 전문적인 업체에 런처를 외주를 주기 시작 하였다. 그 전문적인 업체는 우리보다 뛰어난 기술을 보유하고 있었고, 더욱 더 몇몇 유저들이 몇만원에 파는 게임핵을 구매하여 패치하는 치밀함까지 보였다.

그래서 어디서 시작되었는지 모르겠는데 중국애들이 런처를 뚫기 시작했다. 물량 대 물량싸움이 되었다. 그리고 그렇게 뚫린 런처는 비싼 가격에 몇몇 유저만 사용되기 시작했다.

초창기에는 무반동, 연막무시, 무한수류탄, 무한총알, 무한체력 등이 있었지만 나중에 중국애들이 뚫었던 런처에서는 유료 풀템을 차면 이동속도가 10%정도 증가되는 아주 미묘한 성능 향상만 있었다. 만약 상대방이 왜 이렇게 빠르냐고 물어보았을때 풀템이라고 우기면 되는식;;

하지만 아직도 큰 구조는 벋어나지 못하는거 같고, 엔진파일을 조작한 핵은 존재할거라 믿는다. 다만 걸리지 않게 사용중인거 같다.

엔진파일을 조작하는 게임핵은 어떻게 막을것 인가? 요즘은 리플레이 기능이 있다. 그리고 소켓통신 중에 실시간으로 결과를 남기기는 힘드나 한판이 끝나면 그 게임 내역에 대해 전송받아서 분석하는건 가능하다. 후행적으로 FDS를 적용한다고 생각하면 쉬울것이다.

게임핵을 만드는곳과 방어하는곳은 해킹분야나 악성코드 분야와 비슷하듯이 뚫고 뚫리는 관계이다.

게임핵의 방어기술이 날로 발전하길 바라며 몇자 주절거러 본다.

허가 받지 않는 리버스엔지니어링은 절대 하지 말길 바라며 4개월 뒤 외국을 1년정도 다녀왔는데 같이 공부하던 친구들은 다 경찰서에 한번식 다녀 왔었다.

연락이 그뒤로 한명도 안되는데 다들 잘먹고 사는지 모르겠다.

홈페이지 취약점 점검 업무를 하면서 Appscan을 꽤나 많은 댓수를 운영하고 그곳에 대한 통계에 대한 데이터 검증을 하였다.

해당 업무를 하다보면 발생되는 행위에 대해서 정리해야 될 부분이 너무 나도 많다.

1] 패턴 업데이트 비용이 너무 나도 비싸다.

    예를 들어서 만약 도입비용이 정가  1억이라면 판매측에서 마진을 줄여서 5000만원에 1식을 도입한다. 그런데 월에 200만원의 패턴 업데이트 비용을 달라고 한다.

    200만원*24개월 = 4800만원?

    2년만에 솔루션 1식에 대한 비용을 뽑는다.

    글로벌한 회사이고, BMT에서 이길 상대도 없고, 그 노하우나 탐지 능력은 출중하다.

    하지만 팔로알토나 체크포인트와 같은 UTM형식의 방화벽도 저정도까지 비싸지는 않을것   이다.

2]  취약점 점검 운영에 대한 표준이 없다.

   Appscan과는 좀 다른 내용인데 우선 홈페이지 취약점 점검 가이드는 엄청나게 많다. 행자부, 국정원, 미래부,KISA도 여러개 된다. 이게 많기도 하고, 방법도 조금식 다르기도 하다.

예를 들어서 http Method같은 경우도 어떤곳에는 PUT, DELETE를 지우라고 하고 어떤곳에는 POST, GET만 허용하라고 하는곳도 있다. option? trace? 어떻게 하라는건가?

그래서 취약점 점검 메뉴얼만 만들지 말고, 통계에 대한 운영에 관한 메뉴얼도 제작 되면 좋곘다. 이런 이런 부분까지는 관리가 되어야된다. 최소 점검도구 H/W 사양이나 . 1 식에 대한 케파에 대한 부분과 이행점검 조치확인 프로세스에 대한 부분도 마찬가지다.

큰 대기업이나 금융권 공공기관 통전이나 각 센터에 취약점 점검도구는 필히 다 있을것이다.

그런 점에서 운영에 대한 가이드도 하나 만들었으면 좋겠다. 점검만 하는 비슷한 가이드는 이제 보기도 싫다. 정말 필요한걸 주면 좋겠다.

3] 통계 시스템이 너무 비싸다.

IBM통계 시스템은 약 10억 정도 한다. 그래서 몇몇SI회사에서 통계 시스템을 솔루션 형태로 만드는데 항목에 대한 부분이나 패턴등 그닥 좋지가 않다.

 과거 우리나라에서도 패닉시큐리티나 기타 다른 회사에서 취약점 점검 도구를 만들었다 하지만 외산에 밀리고, Appscan의 성능을 따라잡기 힘들어서 다들 접은걸로 알고 있다.

현재 트리니티에서 만  계속 진행중인걸로 알고 있다.

물량이 어마 어마 한거에 대해 처리할 방법이 없으니 자동점검을 좋아하게 되는데 분석가가 하는 수동점검과 차이가 계속 발생되게 되면 아마 국내 점검 도구와 통계 시스템이 각광 받을수도 있지 않을가 하는 생각도 든다.

4] 점검 도구 H/W 사양에 따라서 성능이 천차 만별

단순 1식 운용이 아닌 사이트가 많아서 여러대를 운용할 경우다. 오래된 스펙 8코어 12램 정도면 3프로세스 정도 돌릴수 있다. 16코어에 64램이면 5프로세스 정도 가능하다.

신규도입할 비용으로  성능을 향상시켜서 해결할수가 있다.

도입 비용보다 패턴 업데이트 비용이 엄청비싸다.

그래서 댓수를 늘리는것보다 다수를 운영중이라면 H/W를 클라우드 방식으로 임대하여 계속 스펙을 올리는게 더 효율적이다.

몇년 뒤에는 램디스크에서 돌리지 않을까 한다. 그렇게 되면 신규 도입할 필요성이 없어진다.계속 H/W 사양을 업그레이드를 하는게 훨신 효율적이다.

S/W 유지보수 비용이 10%이하 인데 참 이건 도입비용이 비싸서 그걸 절감하면 또 비율이 이상하게 된다. 패닉시큐리티 제품이 계속 성능이 좋아져서 우리나라에서 대다수 사용되고 글로벌로 수출이 가능하게 되었다면 또 하나의 경쟁력있는 제품이 되지 않았을까 하는 안타까움도 있다. 한때 정말 잘나가는 제품이였는데 아쉽다.

보안 분야만 일해본것도 아니고 여러가지 일을 해보았는데 Appscan처럼 이상한 구조를 가진 방식은 처음 본다. 먼가 정상은 아닌거 같은데 독점이라 답은 없어 보인다.

이 글은 나의 주관적인 소견이다.

다른 분의 관점에서 다르게 생각할수도 있다.

큰 관점에서 취약점 점검이 합집합이고 그중 부분집합이 모의침투라 생각한다.

모의해킹? 모의침투는 같은 의미로 보면 된다.

자 그럼 취약점 점검은 어떻게 하고 모의 침투는 어떻게 하느냐?

취약점 점검

- 홈페이지 점검(OWASP , 국정원 8대)

- 서버 스크립트(주요정보통신기반시설 기술적 취약점 점검 항목)

- nessus, openvas

- 웹서버 설정 점검(사용자정의 에러페이지, 관리자페이지 접근 제한,취약한 파일 존재,불필요한 Method 활성화,구글 검색을 통한 중요정보 노출, 웹 서버 전용 호스트 구성(DMZ),관리자 및 시스템 파일 접근 제한,O/S 최신 버전 패치, 웹 서버 최신 패치)

웹서버 설정 점검은 스크립트 만으로 확인할수 없는 항목이나 유동적인 항목에 대해서 점검을 실시 하는것이다.

그리고 점검 전 웹방화벽, 서버보안 등 보안장비에 White List처리를 하고 점검을 실시 한다.

소스 코드 단의 문제점을 파악하기 위해 실시 한다.

실제 웹방화벽의 운영 실수나 장애로 인해 해킹사고가 발생된 경우도 있다.

다음은 모의 침투다.

실제 운영 환경과 동일한 환경에서 침투 한다.

웹방화벽이나 IPS등 실제 운용 중에서도 우회를 하거나 탐지 되더라도 계속 시도를 하여 본다.

권한우회나 xss를 16진수나 유니코드를 짬뽕시켜서 조합을 한다던지 sqli도 파라메터를 정말 적게 줘서 시도 해 본다. 성공을 못하더라도 나온 취약점들에 대한 보고서는 충분히 가치가 있다.