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

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

Hex-Rays ARM Decompiler v1.0 Comparison Page

======================================================================================================

리눅스에서는 바이너리 실행파일의 형식으로 ELF(Executable and Linking Format) 형식을 사용한다.
리눅스 커널에서 ELF형식의 바이너리가 메모리에 로드되는 방식은 binfmt_elf.c에 들어있다.
binfmt_elf.c 에 보면 메모리 구조는 대략적으로 아래의 그림과 같이 4가지의 영역으로 구분 된다.

우선 텍스트(Text) 영역은 프로그램의 어셈블리 코드가 저장된다.
텍스트 영역은 공유라이브러리와 기계어 코드가 저장 된다.
데이터(Data) 영역은 전역(Global) 데이터들이 저장된다.
힙(Heap) 영역은 동적 변수가 사용하는 영역으로 C 언어에서
malloc()과 같은 시스템 호출을 통해서 할당되는 메모리는 힙 영역에 할당된다. 스택 영역은 지역변수(local)가 사용하는
영역이다.

스택은 사용자 주소 공간의 최상위 부분에 위치하며, LIFO(Last In, First Out) 모델에 따라 동작한다.
함수가 호출될 때마다 지역 변수와 함수의 인자, 리턴어드레스 등을 위한 새로운 프레임이 스택에 생성되는데
CPU는 값을 집어넣는 push 연산과 값을 꺼내는 pop 연산을 통하여 스택을 제어한다. 

======================================================================================================

예전에 어떤 논문을 보고 잠시 기록해놨던 내용인데, 정확히 어떤 논문이었는지를 모르겠네요.. -_-;
암튼 깔끔하게 잘 정리되어 있어서 스크랩했던 부분입니다. 참고하시길 바라겠습니다.

예전 hackerleon님꼐서 굉장히 수고하셔서 만드신 표입니다.
오늘 이거를 참고 안하고 운을 믿고 brute force하다가 화가 많이 날뻔했습니다.
-_-;

시스템 내에서 bfd.h가 없을 경우 다음을 따르시길 바랍니다.

apt-get을 사용하여 binutils-dev를 설치하시면 됩니다.

컴파일 시에는 gcc에서 -l 옵션을 붙여 bfd 를 참조하겠끔 하면 됩니다.

ex)
gcc -o test test.c -lbfd
(bfd.h 소스)

http://lapackpp.sourceforge.net/html/bfd_8h-source.html

void printchar(unsigned char c)
{
     if(isprint(c))
             printf("%c",c);
     else
             printf(".");
}
void dumpcode(unsigned char *buff, int len)
{
     int i;
     for(i=0;i<len;i++)
     {
             if(i%16==0)
                     printf("0x%08x  ",&buff[i]);
             printf("%02x ",buff[i]);
             if(i%16-15==0)
             {
                     int j;
                     printf("  ");
                     for(j=i-15;j<=i;j++)
                             printchar(buff[j]);
                     printf("\n");
             }
     }
     if(i%16!=0)
     {
             int j;
             int spaces=(len-i+16-i%16)*3+2;
             for(j=0;j<spaces;j++)
                     printf(" ");
             for(j=i-i%16;j<len;j++)
                     printchar(buff[j]);
     }
     printf("\n");
}
/*
ohhara 님께서 작성하신 dumpcode.h 입니다.
아마 쓰신다면 굉장히 유용하게 쓰일거라고 장담할 수 있습니다.. 본인도 유용히..;;
*/