Security. unlimited possibilities

취약점 분석을 수행할 때, 가장 중요한 것이 수행 단계를 설정하고 단계별 이슈분석 및 결과물을 정리/확인하는 것이다. 하지만 실제로 단계를 설정하고 단계별 이슈를 체크하고 결과물을 생성하는 일이 생각만큼 단순하지만은 않다. (너무어렵다고 생각 ㅜㅜ)

아래에는 PTES(Penetration Testing Execution Standard)에 기재된 취약점 분석 주요주제를 잘 정리해 놓았다. 이를 참고하여 취약점분석하는데 참고한다면 보다 누락된 정보없이 업무를 수행할 수 있을 것이다.

PTES: http://www.pentest-standard.org/index.php/Main_Page

< Vulneability Analysis MiniMap >

아래에는, 취약점을 분석하기 위해 사용 가능한 오픈소스 모의해킹 도구목록이다. (일부 무료이기도 함)

<Open Source Automatic PT(Penertration Test) Tools>

2개 이상의 서로 다른 바이너리 분석해 취약점 진단 가능

이 방법으로 엔씨소프트에서 사용하는 카뮤즈 프로그램 취약점 발견

[보안뉴스=이승진 GrayHash 수석] 최근 PC 사용자들이 대부분 사용하는 각종 소프트웨어의 제로데이 취약점을 악용한 보안위협이 끊임없이 발생하고 있다. 이에 여기에서는 ‘바이너리 디핑(Binary Diffing)’이라는 기술을 활용해 제로데이 취약점을 찾을 수 있는 기법에 대해 살펴보도록 한다.

정보보안 분야에서는 2개 이상의 서로 다른 Binary를 비교하여 분석하는 기술을 Binary Diffing이라고 부른다. Binary Diffing 기술이 실제 언더그라운드 해커들 사이에 알려진 것은 대략 10년 전부터로 지금까지 꾸준히 연구되고 있는 분야라고 할 수 있다. 이 기술은 정보보안 분야의 다양한 이슈를 해결하기 위해 사용되고 있는데, 잘 알려진 Binary Diffing 기술의 활용분야는 다음과 같다.

1. Patch Analysis

Binary Diffing은 보안 패치가 적용되지 않은 Binary와 적용된 Binary와의 차이점을 비교(Diffing)해 이전 버전과 비교했을 때 어떤 점이 달라졌는지 알아내는 목적에 사용될 수 있다. 가령, 마이크로소프트(MS)는 주기적으로 보안 패치를 실시하는데 패치된 Binary와 그렇지 않은 Binary를 비교함으로써, 보안 문제점의 원인이 무엇인지 빠르고 정확하게 알 수 있다. 이렇듯 이 방법은 패치 분석을 위해 보안전문가들에게 많이 활용된다고 볼 수 있다.

2. Identifying Symbols, Platform-independent Difference Analysis

리버스 엔지니어(Reverse Engineer)들에게 많이 활용되는 분야로, Binary Diffing 기술을 이용하면 스트립(Strip)된 Binary의 함수 정보를 알아낼 수 있다. 또한, 서로 다른 아키텍처에서 컴파일된 Binary를 비교 분석해 유용한 정보를 도출해내는 것도 가능한데 대표적으로 ARM용으로 컴파일된 Binary와 x86용으로 컴파일된 Binary를 비교해볼 수 있다. 즉, 많은 시간을 들이지 않아도 디핑(Diffing)을 통해 유용한 정보를 비교적 손쉽게 알아낼 수 있는데 이 경우 리버싱(Reversing) 작업시간을 획기적으로 단축시킬 수 있다.

3. Automatic Malware Detection

다양한 변종들로 인해 악성코드는 하루에도 수십 만개 이상이 쏟아져 나오고 있다. 그러나 사실 이 변종들은 비슷한 알고리즘을 쓰는 경우가 많다. 가령, 샘플의 개수가 수백 만개여도 핵심 알고리즘은 같을 수 있다는 얘기다. 여기서 Binary Diffing 기술을 활용할 경우, 알고리즘 비교를 통해 바이러스들을 분류할 수 있다. 이러한 기능을 수행하는 제품은 현재는 구글에 인수된 Zynamics 사의 VxClass가 있다.

4. License Check

오픈소스 라이선스 위반은 대기업들에게도 골치가 아픈 문제다. 의도적으로 라이선스를 위반하려는 것이 아니라, 개발시 사용한 라이선스에 대한 표기를 누락하는 경우가 발생할 수도 있기 때문이다. 일부 기업의 경우 라이선스 위반을 검사하는 프로그램 개발을 준비 중인데, 일반적으로 이런 경우 개발팀 소속이 아니기 때문에 소스코드에 접근할 수 없다. 즉, Binary 레벨에서 목적을 달성해야 하는데 Diffing 기술을 이용하면 Binary 레벨에서 오픈소스 라이선스 코드를 검출해낼 수 있다.

앞서 설명한 것은 Binary Diffing 기술이 기존에 활용된 케이스이며, 다음에는 Diffing 기술을 활용해 소프트웨어 취약점을 발견해내는 방법에 관한 것이다. 기본 원리는 다음과 같이 단순하다.

“취약한 함수의 패턴을 대상 Binary에 비교하여 유사도를 평가한 후 취약성 존재여부를 판단”

즉, 취약점이 발생할 수 있는 유형의 패턴이나 취약점이 존재한다고 증명된 함수를, 취약점을 찾을 Binary와 비교하는 방식을 통해 취약점을 찾아내자는 것이다. 기본적인 아이디어는 단순하지만 실제 제대로 작동하기 위해서는 해결해야 하는 많은 문제점이 존재한다. 먼저, 이해를 돕기 위해 Binary가 아닌 소스코드 레벨에서부터 예를 들어보겠다. 다음 2개의 소스를 비교해보도록 한다.

- func_1

1: void vuln_sample1(char *str) {

2: char buf[256];

3: strcpy(buf, str);

4: printf(“%s\n”, buf);

5: }

- func_2

1: void vuln_sample3(char *str) {

2: char buf[256];

3: printf("test\n"); // <-- added

4: strcpy(buf, str);

5: printf("%s\n", buf);

6: }

위 2개의 함수들에는 strcpy() 함수의 오용으로 인해 전형적인 스택 오버플로우(Stack Overflow) 취약점이 존재한다. func_2의 3번째 라인에는 func_1에는 없는 printf 함수가 추가되어 있다. 함수 하나만 추가됐기 때문에 두 함수를 컴파일하여 비교해보면 크게 다르지 않다.

실제로 Binary Diffing 프로그램 중 보안업계에서 가장 많이 쓰이는 Zynamics 사의 BinDiff를 이용하여 실행하면 유사도 평가 결과값이 높다. 즉, 만약 우리가 func_1에 대한 패턴을 확보하고 있다면, 소스코드가 조금은 다른 형태지만 취약점이 발생하는 부분은 같다고 할 수 있는 func_2를 취약하다고 판단할 수 있다는 것이다. 그러나 아쉽게도 다음 예제 소스와 같은 경우에는 조금 다른 결과가 나온다.

- func_3

1: void vuln_sample2(char *str) {

2: char buf[256];

3: char *p; // // <-- added

4: printf("this is func_3\n"); // <-- added

5: strcpy(buf, str);

6: p=strstr(buf, "beist\n"); // <-- added

7: if(p) // <-- added

8: printf("beer\n"); // <-- added

9: else // <-- added

10: printf("crying\n"); // <-- added

11:}

func_3는 func_1과 비교했을 때 5라인이 더 추가됐지만 버그 헌터의 관점에서 봤을 땐, ‘의미적으로는’ 여전히 func_1과 동일한 취약점이 존재한다고 할 수 있다. 그렇지만 BinDiff를 이용하여 func_1과 func_3를 Diffing 해보면 유사도 평가에서 결과값이 굉장히 낮다. 즉, BinDiff는 이 두 개의 함수에 대해서 ‘차이가 많이 난다’고 말하고 있는 셈이다.

왜 이러한 결과값이 나오는지 알기 위해서 Binary Diffing에 사용되는 알고리즘을 간략히 알아보자. Binary Diffing 프로그램들의 알고리즘은 조금씩 다르지만 전체적인 개념은 같다고 할 수 있다. 여기에서는 대표적인 툴인 BinDiff의 알고리즘에 대해 다루어본다.

BinDiff는 서로 다른 2개의 함수에 대해서 차이점을 찾기 위한 알고리즘을 수행한다. 각 함수의 CFG(Control Flow Graphs)를 기반으로 차이점을 평가하는데, CFG는 CG(Call Graphs)에 비하여 세부적으로 표현한다고 이해할 수 있다. Call Graphs는 함수와 함수간의 연결 관계를 표현한다면 CFG는 하나의 함수 안에 있는 기본 블록(Basic Block) 간의 연결 관계까지 표현하기 때문이다.

즉, BinDiff는 두 함수에서 사용된 어셈블리 명령(Assembly Instruction)의 차이 그 자체에 대해서는 크게 의미를 두지 않고, 구조적 매칭(Structural Matching)을 시도하고 있다. BinDiff는 먼저 함수들 간에 비교한 후 기본 블록(Basic block)들 간의 비교를 수행한다. 차이점 파악을 위해 여러 알고리즘이 사용되고 있지만 이해하기 쉬운 알고리즘 3개만 간략히 설명하면 다음과 같다.

1. Hash Matching

말 그대로 함수의 raw 바이트를 비교함으로써 두 함수의 매칭을 시도하는 것이다. raw 바이트가 같다면, 당연히 내용도 같다고 볼 수 있기 때문에 두 함수의 유사도 평가값은 높게 나타난다.

2. Prime Signature Matching

컴파일러에 따른 명령 재배치(Instruction re-ordering)의 차이로 인한 매칭 실패를 방지하지 위해 사용되는 알고리즘이다. Small Prime Product라고 불리며 명령(Instruction)마다 고유의 값을 부여하고, 해당 명령(Instruction)이 나올 때마다 값을 더하는 방식이기 때문에 명령(Instruction)이 재배치되더라도 매칭 시킬 수 있다.

3. String References

함수나 기본 블록(Basic Block) 안에서 사용되는 문자열을 비교하여 같다면 긍정적인 점수를 주는 방법이다.

추가적으로, BinDiff는 이외에도 약 10여개 이상의 휴리스틱 알고리즘을 사용하고 있다. 가령 기본 블록(Basic Block)의 개수나 호출하고 있는 함수의 개수 또한 매칭 평가에 영향을 주는데, 자세한 내용은 BinDiff의 매뉴얼에 기술되어 있다. 각 알고리즘마다 평가점수가 다른데, 예를 들어 Hash Matching일 경우 바이트 값을 이용해 비교를 하기 때문에 평가 점수가 매우 높다.

func_1과 func_3의 가장 큰 차이점 두 가지를 꼽자면, func_3에는 func_1에는 없는 분기문이 존재하고, 함수가 더 많이 호출됐다는 점이다. 그래서 이 함수의 유사도 평가가 낮게 평가된 것이라고 할 수 있다.

정리를 해보면, 일반적인 Binary Diffing은 취약점을 찾는데 사용하기가 쉽지 않다. 취약점을 발견하기 위한 Binary Diffing 휴리스틱 알고리즘을 새로 개발해야 우리가 원하는 목적을 달성할 수 있다는 얘기다.

이를 해결하기 위해 몇 가지 알고리즘을 작성하고 시도해봤다. 가령 의미론적으로 서로 같은 코드를 만들기 위한 알고리즘을 작성했다. 예를 들어, func_3 코드에서는 분기문이(if-else) 버그 헌팅 시에는 의미가 없기 때문에 무시했고, printf 함수 역시 프로그램 실행에 의미를 갖지 않기 때문에 printf도 무시했다. 이럴 경우 유사도 평가값이 획기적으로 올라가게 된다.

이외에도 여러 알고리즘을 고안해 적용한 결과, 실제 Kamuse 벤더의 프로그램에서 제로데이 취약점을 찾아낼 수 있었다(해당 취약점에 대해서는 Kamuse 벤더에게 이미 리포트 했다). Kamuse 프로그램은 엔씨소프트의 온라인 게임들에 사용되는 모듈로써, 사용자가 게임 클라이언트를 다운로드할 때 실행된다.

해당 모듈은 P2P 기능을 수행하기 위해 네트워크 포트를 열기 때문에, 만약 Kamuse 모듈이 실행되고 있는 PC라면 해커에게 원격에서 해킹 당할 수 있는 취약점이라고 할 수 있다. 이번 취약점은 사용자 데이터를 부적절하게 처리해 발생하는 버퍼 오버플로우 버그로 지난 ISEC 2012 발표에서 최초로 소개된 바 있다.

이번 연구는 아이디어의 실현 가능성을 봤다는 점에서 의미를 찾을 수 있지만, 아직 해결하지 못한 문제점들이 많이 존재한다. 대표적으로 컴파일러의 종류에 따른 코드 제너레이션, 최적화 강도에 따른 코드 변화 등을 위해 해결해야 할 부분이 많다. 또한, 버그 헌터의 입장에서 봤을 때 의미론적으로 같은 함수 집합(예를 들어 strcpy, memcpy, sprintf 등)을 그룹화해 처리하는 등의 작업이 필요하다.

무엇보다 이 연구가 지금보다 많은 발전을 거두기 위해서는 로우레벨에서 진행되어야 하는 리버싱 오토메이션 작업이 필요하다. 이를 이루어내기 위해서는 대단히 많은 작업시간이 필요할 것으로 보인다. 아직 많은 연구가 필요한 분야이지만, 이와 관련해서는 필자가 속해 있는 고려대학교 IAS lab에서 지속적인 연구를 진행할 계획이다.

참고로 이번 기고는 지난 9월 ISEC 2012에서의 발표내용을 정리한 것으로, ISEC 발표 이후 해외의 해커들에게 좋은 피드백들을 많이 받았다. 그 가운데 한 소식에 의하면, 해외의 몇몇 보안전문가들에 의해서 10년 전쯤 Binary 레벨에서 패턴을 검사하여 취약점이 존재하는지 알아보는 시도를 했던 것으로 전해졌다. 그러나 당시는 지금처럼 리버스 엔지니어링 (Reverse Engineering) 프로그램이 다양하지 않았고, 기술수준도 지금보다는 낮았기 때문에 별다른 성과를 거두지 못한 것으로 알려졌다.

[글_이 승 진 고려대학교 정보보호대학원 IAS 랩 석·박사과정/BoB 멘토/GrayHash 수석(beist@grayhash.com)]

방통위·KISA, 제5기 민관합동조사단 전문가 모집...12일 접수마감

[보안뉴스 권 준] 방송통신위원회와 한국인터넷진흥원에서 정보통신망에 중대한 침해사고 발생시 민관합동조사단 전문가로 활동 가능한 정보보호 전문가를 모집한다.

이는 정보통신망법 제48조의 4(침해사고 원인분석 등) 및 동법 시행규칙 제59조(민관합동조사단의 구성 등)에 근거해 인터넷 침해사고에 관한 전문지식과 경험이 있는 전문가를 구성해 위촉하기로 한 데 따른 것이다.

제4기 전문가의 임기가 지난 9월 30일 만료됨에 따라 모집하는 제5기 민관합동조사단 전문가는 방송통신위원회에서 위촉하며, 전문가의 자격은 2년간 유효하다.

이번 전문가 모집인원은 중대한 침해사고 발생시 민관합동조사단 부단장, 검증분석반장, 정책발언 등이 가능한 임원급 전문가 10여명과 중대한 침해사고 발생시 원인조사 및 검증분석, 정책자문 등이 가능한 실무자급 전문가 80여명 등 약 90명 내외다.

전문가는 전문성, 인지도 및 평단, 활동실적 등을 평가해 선정하며, 방송통신위원회, 한국인터넷진흥원, 4기 전문가 풀 운영위원 및 분과위원장, 소속기관 대표 등의 추천서를 제출할 경우 심사를 통해 최대 10점의 가점을 부여할 것으로 알려졌다.

보다 자세한 사항은 한국인터넷진흥원 인터넷침해대응센터(http://krcert.or.kr) 공지사항 코너를 참조하면 된다. 이번 전문가 모집의 접수마감은 10월 12일까지다.

[권 준 기자(editor@boannews.com)]

보안담당자의 책임은 어디까지...양벌규정의 실제 적용 사례

‘제74조(양벌규정) ① 법인의 대표자나 법인 또는 개인의 대리인, 사용인, 그 밖의 종업원이 그 법인 또는 개인의 업무에 관하여 제70조에 해당하는 위반행위를 하면 그 행위자를 벌하는 외에 그 법인 또는 개인을 7천만원 이하의 벌금에 처한다. 다만, 법인 또는 개인이 그 위반행위를 방지하기 위하여 해당 업무에 관하여 상당한 주의와 감독을 게을리 하지 아니한 경우에는 그러하지 아니하다. ② 법인의 대표자나 법인 또는 개인의 대리인, 사용인, 그밖의 종업원이 그 법인 또는 개인의 업무에 관하여 제71조부터 제73조까지의 어느 하나에 해당하는 위반행위를 하면 그 행위자를 벌하는 외에 그 법인 또는 개인에게도 해당 조문의 벌금형을 과(科)한다. 다만, 법인 또는 개인이 그 위반행위를 방지하기 위하여 해당 업무에 관하여 상당한 주의와 감독을 게을리하지 아니한 경우에는 그러하지 아니하다.’

위 조항을 양벌조항이라고 하는데 그 의미는 개인정보보호법 위반 사실이 있거나 보안사고가 났을 경우, 보안조치를 직접 실행하는 사람(보안담당자, 조문에는 ‘행위자’라고 함)와 보안담당자의 소속 회사(개인정보처리자)를 동시에 처벌한다는 것이다.

이렇게 행위자인 보안담당자와 회사를 동시에 처벌하는 이유는 회사의 보안담당자에 대한 관리감독을 강화하고자 하는 의도이다. 다만 단서 조항에 의하면 회사의 무한한 책임을 방지하기 위해 회사에 보안담당자에 대한 관리감독을 제대로 했음에도 불구하고 보안사고가 발생한 경우에는 회사는 처벌되지 않고 보안담당자만 처벌된다.

어찌됐든 위 조항에 의해 개인정보보호법 위반 사항이 있거나 해킹사고가 발생한 경우, 회사뿐만 아니라 보안담당자를 같이 처벌할 수 있다. 이 조항 때문에 보안담당자가 회사의 CSO 지위에서 형사처벌에서 자유로운 컨설턴트로 자리를 옮겨 가는 부작용이 발생하기도 한다.

보안담당자의 책임을 중심으로 양벌규정의 실제 적용사례를 살펴보면 다음과 같다.

(1) 영상정보를 처리하는 CCTV 보안담당자가 소속 회사의 감시를 틈타 회사 몰래 CCTV 촬영시에 녹음기능을 사용했다고 가정하겠다. 이 경우 보안담당자(행위자)는 개인정보보호법 제25조 제5항 위반에 해당하여 3년 이하의 징역 또는 3천만원 이하의 벌금에 처해질 수 있다.

한편 소속 회사(영상 정보처리기기운영자)는 보안담당자에 대한 관리·감독을 다하지 않은 경우에만 보안담당자와 함께 7천만원 이하의 벌금으로 처벌된다. 더불어 보안 담당자는 CCTV에 찍힌 개인정보 주체에 대하여 민사책임도 질 수 있다.

(2) 게임회사에 해커가 잠입하여 게임회사 개인정보 서버에 저장되어 있는 개인정보를 빼내 유출시 켰다고 가정하겠다. 이 경우 개인정보 서버의 보안을 책임지는 직원(보안담당자)이 방화벽을 설치하지 않거나 개인정보에 대한 암호화를 하지 않는 등의 기술적인 안전성 확보조치를 다하지 않았다면 그 보안담당자는 개인정보보호법 제29조 위반에 해당하여 2년 이하의 징역 또는 1천만원 이하의 벌금에 처해질 수 있다.

한편 게임회사(개인정보처리자)는 보안담당자에 대한 관리·감독을 하지 않는 경우에만 1천만원 이하의 벌금에 처해질 수 있다. 보안담당자가 고의로 법위반행위를 했다면 처벌의 정당성은 충분하겠지만 문제는 열심히 보안조치를 다하였음에도 불구하고 해킹을 당하였다면 이 경우에도 처벌되어야 하는가이다.

대부분의 보안담당자는 고의의 경우에만 처벌되어야 한다고 주장하지만 현행법의 해석으로는 열심히 보안조치를 다하였으나 해킹을 당한 경우에도 보안담당자를 처벌할 수 있도록 규정되어 있다. 더 많은 논의가 필요한 부분이라 생각된다.

[글_법률사무소 민후 김 경 환 대표변호사(hi@minwho.kr)]

<책소개>

최근 관심이 집중되고 있는 ’현장 포렌식' 분야에서 디지털 조사관들이 중요한 범죄 증거를 수집하고 획득하기 위한 방법을 자세하게 설명하는 실무서다. 특정 운영체제에서 동작하는 특정 도구만 다루는 책이나 원론적인 이론만 다루는 책과는 달리, 멀웨어로 인해 문제가 발생한 시스템에서 악성 코드를 찾아내고 감염에 따른 영향을 파악하기 위해 기술적인 맥락에서 현장 보존부터 사후 분석까지 디지털 포렌식의 전체 주기를 다룬다. 또한 윈도우와 리눅스 운영체제를 대상으로 휘발성 증거 보존과 수집, 물리 메모리와 프로세스 메모리 덤프, 멀웨어와 증거물 추출, 의심스런 파일 식별과 프로파일링, 악성 코드 정적 분석과 동적 분석 기법을 시나리오와 현장 사례 연구를 들어 단계별로 설명한다.

<목차>

01장 멀웨어 사고 대응: 동작 중인 윈도우 시스템에서 휘발성 자료 수집과 검사
개요
실시간 대응 툴킷 제작
휘발성 자료 수집 방법
프로세스 정보 수집
열린 포트를 동작 중인 프로세스나 프로그램과 관련짓기
서비스와 드라이버 파악
스케줄이 걸린 작업 파악
클립보드 내용 수집
동작 중인 윈도우 시스템에서 비휘발성 자료 수집
동작 중인 윈도우 시스템에서 포렌식용 저장소 매체 복제
동작 중인 윈도우 시스템에서 포렌식용 관련 자료 보존
윈도우용 사고 대응 도구 스위트
정리
참고 자료

02장 멀웨어 사고 대응: 동작 중인 리눅스 시스템에서 휘발성 자료 수집과 검사
개요
휘발성 자료 수집 방법
동작 중인 리눅스 시스템에서 비휘발성 자료 수집
정리

03장 메모리 포렌식: 멀웨어 관련 증거물에 대한 물리적 메모리 덤프와 프로세스 메모리 덤프 분석
개요
메모리 포렌식 방법론
구식 메모리 분석 기법
윈도우 메모리 포렌식 도구
활성, 비활성, 은닉 프로세스
윈도우 메모리 포렌식 도구의 동작 원리
동작 중인 윈도우 시스템에서 프로세스 메모리 덤프와 분석
프로세스 캡처와 메모리 분석
리눅스 메모리 포렌식 도구
리눅스 메모리 포렌식 도구의 동작 원리
리눅스 시스템에서 프로세스 메모리 덤프와 분석
프로세스 메모리 캡처와 검사
정리
참고 자료

04장 사후 분석 포렌식: 윈도우 시스템에서 멀웨어 관련 증거물 발견과 추출
개요
보안에 문제가 생긴 윈도우 시스템을 포렌식 기법으로 검사
기능 분석: 윈도우 컴퓨터 복원
윈도우 시스템에서 멀웨어 발견과 추출
서비스, 드라이버 자동 실행 위치, 예약 작업 검사
윈도우 시스템에서 멀웨어 발견과 추출을 위한 고급 기법
정리

05장 사후 분석 포렌식: 리눅스 시스템에서 멀웨어 관련 증거물 발견과 추출
개요
리눅스 시스템에서 멀웨어 발견과 추출
정리

06장 법적인 고려 사항
개요
쟁점 형성
조사 권한의 근원
권한의 법적 제약
자료 수집을 위한 도구
국경을 넘는 자료 수집
법 집행 참여
증거 채택 가능성 높이기
참고 자료

07장 파일 식별과 프로파일링: 윈도우 시스템에서 의심스런 파일의 초기 분석
개요
사례 연구: 화끈한 새 비디오!
파일 프로파일링 과정 개괄
실행 파일을 대상으로 작업
파일 유사성 지수 비교
파일 시그니처 파악과 분류
심볼과 디버그 정보
파일 난독화: 패킹과 암호화 파악
내부에 숨겨진 증거물을 다시 추출
정리
참고 자료

08장 파일 식별과 프로파일링: 리눅스 시스템에서 의심스런 파일의 초기 분석
개요
파일 프로파일링 과정 개괄
리눅스 실행 파일을 대상으로 작업
파일 시그니처 파악과 분류
내부에 숨겨진 증거물 추출: 문자열, 심볼 정보, 파일 메타데이터
파일 난독화: 패킹과 암호화 신원 확인
내부에 숨겨진 증거물을 다시 추출
ELF 파일 구조
정리
참고 자료

09장 의심스런 프로그램 분석: 윈도우
개요
목표
악성 실행 프로그램을 검사하는 지침
환경 기준 수립
실행 전 준비: 시스템과 네트워크 감시
시스템과 네트워크 감시: 파일 시스템, 프로세스, 네트워크, API 활동
내부에 숨겨진 증거물을 다시 보기
악성코드 기능/목적 탐구와 검증
사건 재구성과 증거물 검토: 파일 시스템, 레지스트리, 프로세스, 네트워크 활동 사후 자료 분석
정리

10장 의심스런 프로그램 분석: 리눅스
개요
분석 목표
실행 전 준비: 시스템과 네트워크 감시
난독화 해독: 멀웨어에서 방어막 제거
공격 기능 검토와 비교
추가적인 기능과 위협 범위 평가
다른 고려 사항
정리
참고 자료

“BYOD에 대해서 ‘예’ 라고 대답하세요.”

포티넷코리아가 자사 네트워크 보안 솔루션으로 기업들이 안심하고 BYOD를 도입할 수 있는 환경을 만들겠다고 나섰다. 사내 모든 정보가 네트워크를 통하는만큼, 유연한 네트워크 보안 솔루션을 통해 BYOD 보안 위협을 해결하겠다면서 말이다. 포티넷은 와이파이 엑세스 포인트(AP), 무선 컨트롤러, 모바일 가상사설망(VPN) 클라이언트, 이중 인증을 위한 소프트 토큰 기능을 통해 BYOD 보안에 필요한 기능을 제공하겠다고 설명했다.

“네트워크를 통제해야 BYOD 보안 위협을 해결할 수 있습니다. 모바일 기기 통제뿐만 아니라 모바일 기기가 접속하는 네트워크도 함께 관리해야 합니다. 포티넷은 사내 모든 네트워크 환경에서 사용자를 확인하는 인증제도를 통해 기업이 안심하고 BYOD를 도입할 수 있는 환경을 만들었습니다.”

이상준 포티넷 부사장은 저렴한 비용으로 단순하게 네트워크 환경을 통합해서 사용할 수 있다면서 자사 새로운 보안 솔루션을 소개했다. 차세대 방화벽인 포티게이트300C와 와이파이AP, 이중 인증용 보안토큰, 안드로이드와 iOS 운영체제에 최적화된 포티클라이언트, 포티OS 5.0 등이다.

포티게이트는 통합 무선 컨트롤러 기능을 탑재해 사내 네트워크에 접속하는 사용자가 어떤 기기를 사용하는지를 파악해 제어한다. 또한 해당 사용자가 사내 네트워크를 통해 어떤 애플리케이션에 접속하고 자료를 살펴보는지 로그 액세스 포인트도 탐지할 수 있게 도와준다. 때에 따라선 사용자가 특정 애플리케이션에 접속할 때 대역폭을 낮춰 애플리케이션 사용을 막을 수 있다. 예를 들어 사내 무선랜으로 ‘애니팡’을 하려고 할 때, ‘애니팡’을 인식한 뒤 무선 대역폭을 낮춰 실행 속도를 떨어뜨리는 식으로 직원이 ‘애니팡’을 사내 네트워크 환경으로 실행하지 못하게 만드는 식이다.

와이파이AP는 이중 스트림을 적용해 무선 신호 전달 강도를 높였으며, 이중 인증용 보안토큰을 통해 사내 네트워크 인증 절차를 강화했다. 인터넷뱅킹을 할 때 공인인증서를 입력하고 OTP(일회용 암호)로 한번 더 확인하는 것처럼 말이다. 여기에 특정 모바일 기기에서 트래픽 이상이 발생했을 때 이를 탐지하고 조사해 접근을 차단하는 기능이 추가된 포티OS 5.0에 새로이 추가됐다.

사실 포티넷이 밝힌 BYOD 보안 전략은 새로운 게 아니다. BYOD 의미가 통일되면서 각 기업이 밝히는 BYOD 보안 전략도 점점 비슷해지는 추세다. 이날 포티넷이 밝힌 BYOD 보안 전략은 앞서 아루바네트웍스나 시스코시스템즈 같은 네트워크 업체가 밝힌 전략과 크게 다르지 않다.

사내 네트워크에 접속한 기기 종류가 무엇인지 자동으로 파악하고, 사용자를 인식해서 접속할 수 있는 애플리케이션을 사용 권한을 제어하고, 이를 통합적으로 관리하는 보안 플랫폼 모두 BYOD 도입을 부르짖는 기업이라면 당연히 던지는 공약이 된 지 오래다.

이상준 부사장은 “경쟁은 최대한 피하면서 고객에게 선택을 맡기겠다”라고 하지만 고객도 저마다 비슷한 전략에 어떤 걸 선택하면 좋을지 몰라 갸웃하는 게 현실이다. BYOD 환경이 널리 도입될 수록, 같은 환경 속에서 서로 다른 차별점을 선보이기 위해 네트워크와 보안 업체의 고민도 깊어지지 않을까 싶다.

[GMER]도구는, 제목과 같이 안티 루트킷(Anti-Rookit) 프로그램이다. 죽, 시스템 내에 숨겨진 유해파일(=Rootkit)을 검색하고 복사/제어할 수 있는 도구라고 말할 수 있겠다. 검색되어진 결과에 대해 신뢰도가 아주 높다고는 평가할 수 없으나, 매우 유용한 도구임에는 틀림이없다. (아마도 결과에 대한 신뢰도는 사용자 본연의 능력에 따라 편차가 크다고 하겟다.)

아래에는 [GMER]도구가 검색을 지원하는 기능들이다.

□ hidden processes

□ hidden threads

□ hidden modules

□ hidden services

□ hidden files

□ hidden disk sectors (MBR)

□ hidden Alternate Data Streams

□ hidden registry keys

□ drivers hooking SSDT

□ drivers hooking IDT

□ drivers hooking IRP calls

□ inline hooks

<지원하는 시스템>

□ Windows NT

□ Windows 2000

□ Windows XP

□ Windows Vista

□ Windows 7

<다운르드>

http://www.gmer.net/ ( 현재 최신버전은 GMER 1.0.15.15641 이다 )

<사용방법>

1. 아래의 Main창에서 ">>>"메뉴를 Click

2. 확장된 각 메뉴에서 사용자가 원하는 동작을 수행

WPAD(Web Proxy Auto Discovery)는, ISA서버와 같은 방화벽을 사용하는 환경에서 클라이언트의 브라우저의 프록시 설정을 자동화하는 편리한 기능이나, 구조상의 취약점으로 인해 MITM(man-in-the-middle)공격에 노출될 수 있다.

WPAD에 대해 더 자세한 내용을 알고자 한다면 아래의 Wiki페이지를 참고할 것

-> http://en.wikipedia.org/wiki/Web_Proxy_Autodiscovery_Protocol

<공격방식>

조작된 WPAD파일을 통해, 공격자의 프록시에 사용자의 브라우저를 지정하고, 사용자로 부터 발생되는 웹 트래픽을 모두 차단/수정할 수 있게된다.

아래에는 최근에 보고된 WPAD MITM 공격에 대한 참고자료이다. (Metasploit 활용)

http://www.netresec.com/?page=Blog&month=2012-07&post=WPAD-Man-in-the-Middle

<조치방법>

◆ 개인 PC 사용자의 경우

: Disabling the "Automatically detect settings" checkbox

◆ 다수의 PC를 관리하는 관리자의 경우

: "Automatically detect settings"기능을 쉽게 Enable/Disalble 할수 있게 생성한 레지스트리 키파일과 vbs배치파일을 이용하여 일괄 조치한다. (다수의 클라이언트 시스템에 일괄 조치하기 위해서는 아래의 파일을 이용하는 것이 효과적일 것으로 생각된다.)

[배치파일]

- Check-AutoDectSet.vbs (Enable)

- Uncheck-AutoDectSet.vbs (Disable)

[레지스트리 키파일]

- CheckAutoDetectSet.reg

- UncheckAutoDetectSet.reg

IE Automatically Detect Settings.zip

(위 파일은 암호로 보호되어 있습니다. )