티스토리 뷰

새로운 미션~

오늘의 미션은 "LNK와 CPL과 USB" 관계를 밝혀라..... ^^*

CVE-2010-2568  제로데이 취약점

 

음.. 머릿속의 조각들이 헝클어져서 먼가 잘 맞춰지지 않군요... T.T

아무래도 정리가 필요할 듯... 먼가 써 내려가다보면 아귀가 맞아떨어지려나......

 

이번 취약점은 LNK 파일이 존재하는 폴더를 탐색기로 열어보는 순간!!!!

LNK에 명시된 DLL 파일이 로딩됩니다.. 

실제 필드에 돌아다니는 공격은 로컬이 아닌 USB 경로가 매핑되어 제2의 USB를 통한 전파방법으로 사용되어질 것을 우려하고 있습니다...

 

이번 취약점은 BOF나 기타 메모리 오류는 아니고, 디자인상의 오류라고 하니, 그럼 우회??? 먼가 필터를 해야했는데 그렇지 못한 것.....???

특히, LNK 파일에 저장된 CPL(Control Panel Applet) 경로정보가 LoadLibrary 파라미터로 전달되어 실행된다고 합니다...

 

 

제 1장

 

그렇다면, 우선 CPL이 몰까 ... LNK와는 어떤 관계일까...궁금해지는 군요...

 

LNK는 모두 다 아시는 바대로 Windows 바로가기 파일이지요...

CPL은 Control Panel Applet, 말 그대로 제어판을 의미하고 제어판을 열어보면 보이는 아이콘들 하나하나가 cpl 확장자로 system 폴더에 저장되어 있다.....

Applet들은 DLL, 폴더 또는 CPL이라는 파일이 될 수 있고......

실제로 시스템 폴더 밑에 존재하는 cpl 파일을 열어보면 "MZ"로 시작하는 PE 파일이더군요..

 

자, 그럼 이제 CPL에 대해서는 대충 알았고, 그럼 LNK에 저장된다는 CPL 정보를 확인하기 위해서는 LNK 파일의 포맷을 좀 알아야겠네요.. 


포맷 공부를 좀 해서 눈에 익혀 두어야 실제 PoC  LNK를 보아도 눈에 쏙~ 쏙~ 들어오겠죠....

 

[포맷파일] 

http://download.microsoft.com/download/B/0/B/B0B199DB-41E6-400F-90CD-C350D0C14A53/[MS-SHLLINK].pdf

 

ShellLinkHeader  
+ HeaderSize
+ LinkCLSID : 고정 (00021401-0000-0000-C000-000000000046)
+ LinkFlags
+ FileAttributes
+ CreateTime | Acces Time | WirteTime
+ FileSize
+ IconIndex
+ ShowCommand
+ Hotkey
+ Reserved
LinkTargetIDList
+  IDListSize :
+ IDList : ItemIDList
                   +  ItemIDSize + Data
                   + TerminalID


특히, 이 CPL에 대한 속성 정보는 ItemIDList라는 구조체 안에 저장된다고 하네요...
 
그럼, 이제 눈에 좀 익으셨으면 PoC 파일에 대입시켜가면서 확인해 볼까요???? ^^* 



일단 ShellHedaer.LinkFlags 값은 각 비트별 설정에 따라 데이터 파싱 및 데이터 처리가 결정됩니다. 


 iF Shellheader.LinkFlags  Of  PoC = 81 00 00 00(1000 00001) :

    A = HasLinkTargetIDList  

     H = IsUnicode

 

Flag 값을 보니, 우리가 찾아야 하는 ItemIDList 구조체를 품고 있는 LinkTargetIDList 구조체가 존재한다는 의미이고, 데이터는 유니코드로 표현된다는 것을 의미하고 있군요.


따라서, 전체적인 PoC 구조체는 다음과 같이 여러개의 ItemIDList를 갖는 구조가 되는 군요... 


  [ShellHeader] + [IDListSize] + [ItemIDList].....[ItemIDList][TerminalID] + [Extra Data]

 

 

그러나... 핫~ 여기서 장애물 발생.......!!!!

CPL 데이터를 담고 있는 ItemIDList 구조체의 실제데이터 구조는 SHLLINK 포맷에서는 안 알려준다는 거..... 쩝쩝..--;;;

 

 

제 2장

 

 

일단, ....  .... 취약점 분석할 때 좋은 방법은 "정상"과 "비정상"을 비교해보는 것~~~~~

필자의 경우에는, 제어판 바로가기와 제어판 안에 있는 다른 CPL에 대한 바로가기를 만들어서 POC 와 비교해보았지요......... 여러분은????

이제 대충 어느 부분이 일정하고, 어느 부분이 고정이고.. 이것저것 대충 감이 오셨나요.. ^^;;

 

ShellHeader 와 ItemIDList 2개는 고정이고. 그 뒤에 이어지는 나머지 하나의 ItemIDList에 실행될 CPL 경로가 포함되어 있군요...


그렇다면, 도대체 ItemIDList 에 들어 있는 요상한 값들은 도대체 멀까.. 궁금해지네요...

구글 신께 빌어보는 중, 쉘이 사용하는 Namespace와 ItemID의 관계를 알려주는 MSDN 문서 발견~

 

http://msdn.microsoft.com/en-us/library/cc144090(VS.85).aspx

 ; Shell Namespace는  파일시스템과 다른 오브젝트들을 단일 트리구조로 구성

 ; 각 오브젝트들은 파일시스템에서 폴더나 파일의  이름과 같은 역할을 수행하는 itemID를 갖음.

   그 오브젝트 구조체는

 

typedef struct _SHITEMID {
    USHORT cb;  구조체 사이즈
    BYTE   abID[1]; 오브젝트 ID
} SHITEMID, * LPSHITEMID;

 

ItemID는 단독이 아닌 시스템 경로를 의미하는 iTemID 목록의 부분으로 사용되고, 문자열 대신 itemID 리스트 구조체를 사용.  그 List 순서가 namespace 안에서 경로의 계층을 의미....

 

typedef struct _ITEMIDLIST {
  SHITEMID mkid;
} ITEMIDLIST

 

iTemID 구조체의 오브젝트 ID 중

전통적인 Control Panel은 다음과 같은 GUID 값을.....
explorer /root,::{20D04FE0-3AEA-1069-A2D8-08002B30309D}\::{21EC2020-3AEA-1069-A2DD-08002B30309D}

My Computer 는 다음과 같은 GUID 값을...
explorer /root,::{20D04FE0-3AEA-1069-A2D8-08002B30309D}

 

이 값들은 우리가 본 LNK 의 첫번째와 두번째 ItemIDList 에 들어 있는 값.....

이제 먼가 아귀가 맞아질라고 하네요... ^^

 

그리고, 남은 마지막 itemIDList 구조체값은 앞선 iTemIDList의 하위 구조체로 CPL의 경로 즉 Path 정보가 담겨지게 됩니다..

사실 이 부분은 MS에서도 밝히고 있듯이 문서화된 정보가 거의 없다고 하는 군염.. 

이부분은 그냥 얻은 정보를 고대로 활용....

살다보면, 이렇게 남의 도움이 필요할 때도 있는 법이지 않겠습니까... ㅋㅋㅋㅋ

 

이제 LNK 데이터에 대한 정체는 어느 정도 밝혀진 것 같습니다..

그렇다면, 시그니처 작성이 필요하거나 파일기반 진단이 필요하신 분들은 아래 내용을 고려하시면 될 듯... ^^

 

 1) ShellHeader를 보고 LNK 파일을 판단한다

 2) ItemIDList 를 보고 CPL 인지 확인한다.

 3) path 경로에 의심스러운 파일경로가 들어가는 지 확인한다.

 

다음으로 구렇다면 임의로 만든 CPL 바로가기에서 경로를 다른 놈으로 바꾸면 바로 원하는 파일이 실행되어야 할 것 같은데.. 막상 테스트 해보니 그렇지 않더군여..

 

핫~ 여기서 또 한번 장애물 발생.......!!!!

 

 

제 3장

 

경로정보를 담고 있는 ItemIDList  구조체 안에는 idIcon이라는 값이 있습니다. 

왠지 이름이 Icon 관련????  

int    idIcon;

이 값은 사용할 아이콘과 관련....

 

실제로 위의 Control Panel GUID는 카테고리 형식으로 보여줄때와 Icon 형식을 보여줄때의 값이 다릅니다. 따라서 지금 세팅된 값은 Icon형식으로 보여줄 때 사용하는 GUID 입니다.

흠.. 먼가 Icon 관 관련된 이슈일 것 같다는 감이 팍팍 오는 군염...

 

실제 임의로 만든 LNK 의 idIcon과 POC.iTemIDList.idIcon 값을 비교해 본 결과 정상인 경우 특정값이 세팅되어 있고 이런 경우 해당 프로그램에 대한 아이콘이 보여지고... PoC에는 NULL 값이 채워져 있고 설정된 디스플레이되는 아이콘이 없더군요...

 

그럼 저도 idIcon 값을 저도 NULL로 밀었습니다....

흠... 드뎌 경로부분에 제가 채워넣은 DLL이 로딩되는 군요.. ^^V

 

 

제 4장

 

우리가 해당 LNK 파일이 있는 폴더를 탐색기를 통해 열어보게 되면, 쉘은 Display를 위해 해당 파일의 아이콘 정보를 찾게 되어 있습니다. CPL에 대한 LNK 파일을 보여주기 위해 Icon 정보를 획득하는 과정에서 CPL에 대한 정보를 찾는 모듈을 타게 되고 이 과정에서 LoadLibrary 루틴을 타게 되는 거죠......

 

자세한 내용이 WebSense 블로그에 잘 도식화되어 있네요... ^^;;

http://community.websense.com/blogs/securitylabs/archive/2010/07/20/microsoft-lnk-vulnerability-brief-technical-analysis-cve-2010-2568.aspx?cmpid=sltw

 

난 리서치도 잘 해주고.. 정보도 잘 올려주는 WebSense가 참 좋더라... 하하하하...

저는 코드레벨로 세세하게 따라가 보진 못했지만,,,,

아이콘 이미지를 로딩하기 위해 LoadImage를 하게 되는 데, 이 때 넘겨질 모듈 핸들값을 얻기 위해 LoadLibrary를 한다고 합니다... 쩝쩝...

이미지를 직접 로딩하지 않고도 핸들을 얻을 수 있는 방법이 있다고 하니.. 그 방법을 썼어야 한는....

 

 

 


 

 

지난 MS10-044 MS Access 관련 ActivX 취약점에서도

개발자가 내부적으로 EXE 파일을 LoadLIbrary로 로딩하는 바람에 ...

IAT 테이블이 세팅되지 않아 취약점이 발생했었습니다.

그래서 패치에서는

LoadLibrary 대신 GetModuleHandle을 사용하도록 고쳤더군요..

취약점도 유행을 탄다고 하는데..

최근 요런 디자인 오류들에 대한 보고가 많습니다.. 

아무래도 누군가 집중적으로 파고 있지 않을까.....

--.---++++

이번 거짓말은 여기까지..

이번에는 코드 레벨로 깊숙히 따라가 보지 않을 것 같습니다..

거짓말이 맘에 드시나요???


댓글
댓글쓰기 폼