Anow's Opportunities - 언제나 진실되게

뜬금없이 한 코너를 시작하려고 합니다.
그 이름은 바로 <보안사건사고>!!
(대책이 없다.. -_-;)

(사실 <보안사건노트> 로 할까 <보안사건사고> 로 할까 고민을 많이 했는데 <보안사건사고> 가 그나마 편하게 보여서 이걸로 정했습니다.)

평소 보안에 대한 이슈를 직접 정리해보면 아무래도 생각도 많이 할 수 있고 사건에 대해서 깊게 알게 되어서 꼭 언젠가 해보고 싶었기도 했고 앞으로 블로그를 하면서 무언가 꾸준히 진행해야하는 소재가 있어야 탄력적으로 블로그를 할 것 같다는 생각도 들어서(...)
이 <보안사건사고> 코너를 진행하려고 마음을 먹었습니다. (이 포스팅을 쓰면서 대책을 구상중.. -_-;)

<보안사건사고> 코너에서는 비정기적으로(정기적으로 할 수 있을 것이라 제 스스로가 믿지 않습니다. -_-;;) 각종 보안에 대한 사건사고에 대해 읽기 편하게 정리하여 사건사고를 소개하고, 제 생각을 담아내는 등의 내용이 주를 이룰 것 같습니다.

특별히 <보안사건사고> 라고 해서 단순히 기술적 측면에만 치우쳐 작성하는 것이 아닌 두루두루 폭 넓게 다룰 수 있도록 노력할 생각입니다.
그리고 현재 문제화 되고 있는 이슈들, 또 쉽게 간과할 수 있는 이슈들, 심각하고 민감한 이슈들부터 황당하고 재미있는 이슈들까지
최대한 읽기 편하고 이해되기 쉽게 작성할 생각입니다. 이러한 이슈들은 현재 진행 중인 이슈일 수도 있고, 한참 전 과거의 이슈일 수도 있습니다.

이제 시간도 조금 나고 하니깐 차근차근 써서 나름대로 재미있는 자료집을 만들어내도 좋을 것 같네요.
제가 블로그에 조금 더 맛을 들인다면, 이러한 코너를 하나 둘 추가해낼지도 모르겠습니다만은
여태까지 게으른 블로그 생활을 해 온 결과(...) 별로 자신이 있지는 않네요.

그래도 유익한 컨텐츠를 담아내기 위해 노력하겠습니다.

이 코너에 포스팅이 올라오면 @anow_null 트위터에 한글 트윗이 올라와 Blog Post 를 링크해줄 겁니다.
뭐 그래봐야 얼마나 읽기야 하겠냐만은 -_-;

하루에 평균 10명 꼴로 구글 검색으로 들어오는 이 블로그에 차곡 차곡 자료 쌓아나가는 재미로 시작하려고 합니다.
소리 없는 아우성도 언젠가는 남이 들어줄 수 있을 것이라 믿습니다.(?)

혹여나 제 포스팅에 문제가 있거나 다른 곳으로 펌을 하려고 하신다면 덧글이나 공지사항의 연락처로 알려주세요.

이 코너의 저작물 사용 허가 기준은 아래와 같습니다.

무엇보다도 위에서 언급한 바 대로 펌을 하시려고 하면 포스팅의 덧글이나 공지사항의 연락처로 알려주시면 감사드리겠습니다.

Anow Russell
(@anow_null)

2010년 8월 말, DLL Hijacking 기법을 이용한 Exploit 이 유행할 때
웬지 DLL Hijacking 취약성이 있을 법하여 노트북에 설치 된 소프트웨어들을 상대로
취약성 Auditing 을 해보았다. 그 결과 이스트소프트 사의 알씨 제품에서 취약성을 발견했고,
wireshark, Adobe CS3 Flash 등 유명한 제품들에서 해당 취약성이 발견되었다.

그 중, 한글과컴퓨터 제품군인 한컴오피스 2010의 제품들이 취약한 것으로 추정되어
Exploit 을 작성하였고, 그 결과 한컴오피스 2010의 3가지 제품(한글, 한셀, 한쇼) 모두 취약하다는 것을 확인하였다.
한글 2007도 마찬가지였다. 2002 버젼과 2005 버젼은 주변에 쓰는 사람을 못보고 또 하드 용량상 마땅히 테스트할
공간도 없어 2002 버젼과 2005 버젼은 테스트하지 못하였으나, 2010 버젼과 2007 버젼에 이러한 DLL Hijacking 취약성이
존재하고 Exploit 이 가능하다는 것을 고려한다면, 충분히 2002 버젼과 2005 버젼에도 취약성이 존재할 가능성이 매우 높다고 생각한다.

참고로, 밑 영상에는 나오지 않았지만 한컴사전도 해당 DLL Hijacking 에 취약하다.

아래 영상은 Windows7 에서 한컴오피스2010 제품들이
DLL Hijacking 에 취약하다는 것을 보여주는 PoC Exploit 시연 영상이다.

<영상1> 한글2010 DLL Hijacking PoC Exploit 시연
(영상 다운로드 - 클릭)
(서버 환경에 따라 속도가 느리거나 다운로드가 불가할 수 있습니다.)
(2010-12-12 기준 다운로드 가능하며 불가능 할 경우 댓글 남겨 주시길 바랍니다.)

영상에서는 악의적으로 조작 된 DLL 파일 명을 보여주지 않기 위해
DLL Loading 순서에 포함되어 있는 system 16bit 디렉터리에 위치 시키고 시연하였다.
한글/오피스 제품이 설치 된 경로에 DLL 파일을 위치시켜도 Exploit이 되는 것을 확인하였다.

반드시 명심해야 할 것은, DLL Loading 순서에 CWD 도 포함되어 있다는 것이다.
CWD 란 Current Working Directory 로, 즉 가나다라.hwp 와 같은 위치에
악의적으로 조작된 DLL 파일을 위치시키면 임의의 공격코드가 실행 된다는 뜻이다.
즉, 기업/개인 간의 공유 폴더 운용 시, 악의적인 DLL 파일에 의하여 피해를 입을 수 있다.

여기서는 단순한 MessageBox 가 뜨게 되고 계산기가 실행되는 DLL 파일을 컴파일하여 사용했다.

해당 취약성을 이용하면, 공격자가 피해자의 시스템에 특정 DLL 파일을 DLL Loading 경로에 비치 시키고
피해자가 어떤 문서던 상관 없이 한컴 오피스를 사용하여 문서를 열 때 악의적으로 조작된 DLL 파일이 Loading 되면서
공격자가 의도한 임의의 명령이 피해자의 시스템에 실행된다.

대부분의 공기관과 일반 유저들이 한글 제품을 쓰고 있고, 기업들도 한글 제품을 쓰고 공유 문서에 한글 문서를
비치하는 경우가 많다는 것을 고려한다면, 해당 취약성이 악성코드로 발전하게 된다면 공격자의 시나리오 대로 이루어 질 것이며
어떠한 상황이 일어날 지 모른다. DDoS 가 발생할 수 있고, 수 많은 PC가 좀비 컴으로 전락할 수 있다.
임의로 조작된 DLL 파일은 백신에서도 감지하기가 어렵다. 즉 한글과컴퓨터 Application 단에서 수정되어야 할 문제점이라는 것이다.

만약, 이 DLL 파일이 아래와 같이 시스템 종료를 호출하게 하는 DLL 파일이었다고만 생각하면..
글쎄다. 문제점이 해결되지 않는 한 이에 대해 잘 모르는 사람들은 포멧까지 하는 웃지 못할 상황까지도... -_-;

<영상 2> Winodws XP SP3 에서 한글2007 제품을 상대로 구현해 본 Shutdown Scenario
(영상 다운로드 -  클릭)
(서버 환경에 따라 속도가 느리거나 다운로드가 불가할 수 있습니다.)
(2010-12-12 기준 다운로드 가능하며 불가능 할 경우 댓글 남겨 주시길 바랍니다.)

상황의 심각성 파악은 이쯤에서 마치고, 발견 된 취약성을 2010년 8월 29일 날짜로 한글과컴퓨터에 기술문의 센터에 제보하였다.
(사실 기술문의 센터밖에 취약성을 제보할 만한 곳이 없더라. -_-;)

하지만 한글과컴퓨터 측에서는 이에 대한 안건을 신속히 처리해주지 않았다.
보름이 지나도록 말이다.. -_-; 답변도 없고 패치도 없었다.
무언가 이상하기도 하고.. 그래서 어제(9/15) 제보했던 안건에 대해서 다시 물어보는 문의를 올렸는데 오늘 답신이 왔다.

무언가 굉장히 아쉬운 감이 짙었다.

사실 최초 제보 후 매일 마다 패치 상태와 문의에 대한 답변을 체크했지만,
그 어떤 보안 관련 패치는 커녕 답변도 없었다.
중간에 한글타자연습 프로그램에 대한 패치만 있다 뿐이지...

해당 취약성을 가지고 있었던 이스트소프트사의 비교적 발 빠른 대처와는 상반된 모습이었다.
(뭐 사실 과정이 어땠는지는 잘 모르겠지만, seclist 에 공개적으로 PoC Exploit이 발표되었으니, 
빠르게 대처할 수 밖에 없었을 것이다.)

아무튼, 한글과컴퓨터 측은 패치 작업을 신속히 할 필요성이 있다.
더욱이 우리나라에서 굉장히 많이 쓰는 소프트웨어인데..
분명히 한글2002, 한글2005 버젼에서도 이런 취약성이 있을 것이라 확신감이 든다.
자세한 것은 테스트를 해보아야 하겠지만 프로그래머의 coding style 과 code development 단계에서
이전 소프트웨어에 최신 소프트웨어가 가지고 있을 취약성, 특히 이 DLL Preloading(Hijacking) 취약성이 존재할 확률은 매우 짙다.

물론 회사 내에서 패치를 발표 하기 전 이것 저것 테스트 해야할 작업, 분명히 있을 것이다.
하지만 대체 15일이 넘도록 무엇을 했다는 것인가? 15일이 넘도록 담당부서에 확인만 할 것인가?
상식적으로 이 취약성을 해결하기 위한 패치 작업과 업데이트 작업을 하는데 있어서 15일이 넘도록
시간이 걸린다는 것은 납득하기가 어렵다.

(몇몇 분들에게 의견을 물어보니 "회사마다 사정에 따라 일의 처리 과정이 늦고 빠름이 달라 15일 만으로는 판단하기 어렵다" 라는
 이야기가 있었는데, 공감합니다.. 하지만 이러한 경우를 위한 좀 더 효율적인 일 처리 프로세스가 마련이 되어야 한다고 생각하네요.
 그렇지 않으면 예전 Microsoft LNK 취약성이 20일 넘게 걸려 패치가 되었던 것 처럼, 크래커의 손길이 더욱 넓어질 것이라 생각이 되네요.)

과정이 어찌되었던, 0-day 에 대한 대책이 이렇게 부진하다면..
만약 정말로 사건이 터진다면, 글쎄다.
한글과컴퓨터 회사 만이 아닌 다른 회사들도 0-day 에 대한 효율적인 일 처리 프로세스 시스템을 마련해야할 것이다.

지금와서 패치한다고 하더라도 일반 유저의 시각으로는 `늑장 대처` 라고 밖에 보여지지 않는다.
위험성이 큰 취약성에도 불구하고 말이다. 보안에 관한 인식이 좀 더 강화될 필요성이 보인다.

아무튼 전체적으로 무언가 안일한 태도가 아니었는지, 기대와 달라 아쉬운 감정이 남는다.

Microsoft 에서 이러한 DLL Hijacking 취약성에서 유저를 보호하고자 내 놓은 레지스트리가 있다.
다음의 링크를 참고하면 된다. [ http://support.microsoft.com/kb/2264107 ]
허나 DLL Hijacking 을 완벽히 방어하는 것은 절대 아니다.
정말 중요한 것은 윈도우 구조상의 문제로 Application 단에서 수정되어야 할 문제점 이라는 것이다.

곧 패치가 올라올 것이라 믿으며, 앞으로는 조금 더 변화 된 한글과컴퓨터를 기대해 본다.
 

최근 이슈가 되고 있는 Microsoft의 Shortcut(LNK) 0-day 취약점에 대한 분석 문서입니다.

영문 문서와 한글 문서가 섞여있으니, 이를 참고하시고 좋은 정보되시길 바랍니다.

lnk문서.zip