중국 해커 그룹 ph4nt0m 에서 3번째로 발행한 웹진 주소입니다.
http://www.ph4nt0m.org-a.googlepages.com/pstzine_0x03
제가 중국어에는 능통하지 않아 번역해드리기는 힘듭니다.^0^);
관심 있는 분이시라면 많은 도움이 될거라 생각합니다.
아래 보시면 이제까지 발행했던 링크들이 있습니다.
http://www.ph4nt0m.org-a.googlepages.com/ph4nt0mwebzine
DBMS별 SQL Injection Cheat Sheet 입니다.
다양한 공격방법들이 정리되어 있으며 심화학습하는데 도움이 되시기 바랍니다.
http://pentestmonkey.net/blog/oracle-sql-injection-cheat-sheet/
http://pentestmonkey.net/blog/mssql-sql-injection-cheat-sheet/
http://pentestmonkey.net/blog/mysql-sql-injection-cheat-sheet/
▷ 작성자 : nohpro (nohpro@a3security.com)
▷ 편집자 : nohpro (nohpro@a3security.com)
Internet Explorer 8의 교차 사이트 스크립트 필터 기능
IE8에서 교차 사이트 스크립팅 필터라는 이름으로 XSS(Cross Site Scripting)을 브라우저단에서 필터링 시키는 기능이 추가되었네요. 인터넷 옵션에 “XSS필터 사용/사용 안 함” 항목이 추가되어 XSS공격으로부터 client를 보호하기 위한 기능이군요
다음과 같이 “XSS 필터 사용” 옵션을 사용할 경우 XSS 필터기능에 의해 XSS공격을 브라우저에서 차단시키도록 설정이 가능합니다.
[그림 1] XSS 필터 옵션
XSS공격 시 다음과 같이 차단메시지가 보여지면서 스크립트 실행을 제한하게 되는군요
[그림 2] 스크립트 실행 차단
현재 공개된 IE8의 XSS 필터는 Type-1에 의한 XSS공격만을 필터링 시키고 있습니다.
Type-1 XSS 공격은 파라미터로 값이 전송될 경우 존재하는 XSS 취약점인데, Get 형태로 파라미터가 전송될 경우에는 다음과 같이 XSS필터 기능에 의해 스크립트 실행이 차단됩니다. Type-1 XSS 공격을 시도할 경우 이미 알려진 다양한 패턴은 대다수 차단이 되고 있더군요.
ex)http://www.a3sc.co.kr/a3sc.php?a3sc=<script>alert(1)</script>
[그림 3] 파라미터를 통한 XSS 공격 시 스크립트 실행 차단
하지만 아직까지는 Type-1 XSS 공격에 대해서만 필터링이 적용 되다보니, 게시판이나 자료실 등과 같은 곳에서 시도되는 XSS 공격에 대해서는 필터링이 적용이 안되고 있습니다.
다음은 IE8에서 게시판에 스크립트를 입력하는 화면입니다.
[그림 4] IE8 에서 스크립트 입력
다음과 같이 IE8에서 XSS 필터 기능을 사용함에도 불구하고 스크립트가 실행된 화면입니다.
[그림 5] IE8에서 스크립트 실행
IE8에서 추가된 client 보호기능 중 하나인 “XSS필터” 기능은 client입장에서는 상당히 유용한 보안옵션일 수 있습니다.
스팸메일이나 게시판, 메일 등을 통해서 XSS를 이용한 공격이 이루어지고 있습니다. 이때 확인되지 않은 URL에 대해서 client가 접근을 하더라도 “XSS 필터”를 통해 차단이 되기 때문에 비교적 안전하게 사이트 이용이 가능합니다.
하지만 위에서 설명한 대로 아직까지는 파라미터를 통해 시도되는 XSS 공격(Type-1)에 대해서만 필터링이 이루어지고 있습니다.
추후에 MS에서 업데이트를 진행하겠지만 아직까지는 IE8의 “XSS필터” 기능에 너무 의존해서는 안될 것 같네요.
“XSS 필터” 기능이 적용된 IE8을 사용하는 client 일지라도 아직까지는 XSS 공격에 100% 안전할 순 없을 것 같습니다..
참고) http://en.wikipedia.org/wiki/Cross_site_scripting#Attack_vectors
http://blogs.msdn.com/dross/archive/2008/03/10/xss-focused-attack-surface-reduction.aspx
▷ 작성자 : indra (indra@a3security.com)
▷ 편집자 : indra (indra@a3security.com)
Winamp =< 5.541 Overflow 취약점 보안 권고안
By indra@a3security.com
(A.K.A 1ndr4)
I. 취약점 개요 연구 대상 Winamp 5.541 버전의 Skin 오버플로우 취약점 문서 작성일 문서 버전 V0.1 벤더 Winamp 벤더 URL http://www.winamp.com
1. 요 약
Winamp는 Windows OS에서 동영상 및 음원 파일을 재생할 수 있게 해 주는 소프트웨어로,
1. 적용 대상 시스템
|
- Winamp 5.541 버전을 포함한 하위 버전 |
1. 분석 내용
공개된
다음 그림은 PoC Code를 이용하여 생성한 Skin파일의 일부 내용이다.
위 그림과 같이 Skin파일은 바이너리 파일로 만들어져 있으며, 해당 파일은 “MAKI Script” 라는 스크립트 언어를 컴파일 하여 얻어낸 결과물이다.
MAKI Script와 Compiler에 대해서는 다음의 URL을 참조할 수 있다.
MAKI Script - http://dev.winamp.com/wiki/Modern_Skin:_Skin_Scripting
MAKI Script Compiler - http://forums.winamp.com/showthread.php?threadid=168310
MAKI Script는 Syntax가 C/C++과 매우 흡사한 형태를 지니고 있다.
다음 그림은 MAKI Script의 예제 코드를 나타낸 화면이다.
[그림 2] MAKI Script의 예제코드
dkrdml 파일에서 “getRuntimeVersion” 문자열 뒤에 문자열의 종료를 뜻하는 NUL 문자가 삽입되어 있지 않은 채 “\x41” 문자가 나열되어 있다. 이것은 명백히 의도적인Overflow를 일으키려는 시도로 생각할 수 있다.
다음의 프로그램은 컴파일 된 MAKI Script를 Pseudo-Code로 재 구현 할 수 있다.
MAKI De-Compiler - http://www.rengels.de/maki_decompiler/
다음 그림은 PoC Code에서 생성된 악의적인 Skin파일을 De-Compile 한 화면이다.
[그림 3] 악의적인 Skin파일을 De-Compile 한 화면
본래의 PoC Code는 “getRuntimeVersion” 문자열 뒤에 문자열 종료 코드가 존재하지 않는 형태로, De-Compile이 되지 않아 공격코드 부분을 지우고 De-Compile 한 화면이다. De-Compile 된 형태를 보아 어느 부분에서 취약점이 존재하는지 알 수 있다.
공개된 PoC Code를 분석해 보면 공격에 필요한 Payload는 다음과 같이 구성되었다는 것을 알 수 있다.
>>> --snip--
[ 314 bytes ] => “AAAA…”
[ 4bytes ] => 0x414112EB /* JMP 0x12 */
[ 4bytes ] => 0x14F01011 /* Common Module Routine (Return Address) */
[ 8bytes ] => 0x90909090… /* NOP */
[ 4bytes ] => 0x120199F8 /* JMP ESP */
[ 12bytes ] => 0x90909090… /* NOP */
[ 338 bytes ] => SHELLCODE
[ 128 bytes ] => “AAAA…”
>>> --snip--
[ 314 bytes ] => “AAAA…”
[ 4bytes ] => 0x414112EB /* JMP 0x12 */
[ 4bytes ] => 0x14F01011 /* Common Module Routine (Return Address) */
[ 8bytes ] => 0x90909090… /* NOP */
[ 4bytes ] => 0x120199F8 /* JMP ESP */
[ 12bytes ] => 0x90909090… /* NOP */
[ 338 bytes ] => SHELLCODE
[ 128 bytes ] => “AAAA…”
>>> --snip--
위와 같은 Payload를 참조하며, OllyDBG를 이용해 로드 한 Winamp에 PoC Code를 적용하여 보았다.
아래의 그림은 실행된 PoC Code에 의해 SEH 값이 변경된 화면이다.
[그림 4] PoC Code 실행에 의해 SEH값이 변경 된 화면
위 그림에서 SEH는 0x14F01011, Pointer to next SEH는 0x414112EB로 변경되었다. SEH는 Structured Exception Handler의 약자로, 예외처리 핸들러를 의미한다. 해당 SEH핸들러를 변조할 수 있다면, 고의적으로 Exception 에러를 발생시켜 원하는 데이터 영역을 실행 할 수 있다.
다음 그림은 Exception 에러가 발생 한 화면이다.
[그림 5] Exception 에러가 발생 한 화면
위 그림에서 실행되는 코드는 PUSH DWORD PTR DS:[EDI+4] 이나 EDI 레지스터의 값이 0x00000000로 되어 있다. 코드는 DS:[0x00000004] 에 접근을 시도하지만, 접근할 수 없는 메모리 영역이므로 이에 의해 Exception 에러가 발생하게 된다.
다음 그림은 고의적인 Exception 에러에 의해 실행되는 상황을 캡쳐 한 화면이다.
[그림 6] Exception 핸들러에 의해 shellcode가 실행되는 화면
위 코드의 동작을 조금 더 자세히 살펴보면 현재 실행되고 있는 주소는 0x7C9332A6이며, ECX 레지스터에 저장되어 있는 주소에 대해 CALL 명령을 실행한다. ECX 레지스터에는 0x14F01011 주소가 저장되어 있으며, 0x14F01011 주소는 POP을 두 번 실행하여 ESP 레지스터에서 (32bit OS 기준) 0x08 만큼을 Subtraction 한 후, return 한다. 이 후, Next SEH로 잡혀 있는 0x00B4B354 주소로 이동하여 해당 영역의 코드를 실행하는데 0x00B4B354 영역에는 Encoding 된 shellcode를 Decoding 하여 수행하는 코드가 존재한다.
참고로 0x14F01011 주소에 대해 정리하면 해당 주소는 aacPlusDecoder.w5s라는 Winamp의 시스템 파일에 맵핑되는 주소로, Winamp에 종속성을 가지는 주소라는 점을 기억해야 한다.
aacPlusDecoder.w5s 파일의 0x14F01011 에 해당하는 코드 영역은 static 하게 정의되어 있고, 이러한 내용은 Winamp가 설치되어 있는 모든 환경에서 동일한 코드 영역의 주소로 동일한 코드의 실행을 보장한다는 것을 의미한다. 따라서 위 코드를 이용하여 코드의 흐름을 변경하고, shellcode를 실행 할 수 있다는 것은 exploit 주석 문에도 쓰여진 것처럼 플랫폼 및 Service Pack, Language Pack 등에 구애 받지 않고 Universal 하게 shellcode를 실행 할 수 있다는 것을 증명할 수 있다.
다음 그림은 위 취약점을 공격하고 공개되어 있는 Reverse Shellcode를 이용하여 Connect-Back을 수행 한 화면이다.
[그림 7] 취약점으로 공격당한 PC의 관리권한을 Connect-Back으로 연결 한 화면
2. 위험 분석
현재 공개된 exploit은 Universal shellcode의 실행을 가능하게 하기 때문에 플랫폼 등의 환경에 관계없이 취약점에 노출될 경우 공격의 실패 가능성이 없으며 공격자의 의지대로 권한을 빼앗기거나 기밀자료가 유출될 수 있는 가능성이 높다.
III. 대응 방안
1. 보안 대책
가. 공식 패치
본 취약점과 관련하여 현재 winamp 공식 홈페이지에서 배포되고 있으며, 패치된 버전은 5.551 버전이다.
Winamp 공식 홈페이지 : http://www.winamp.com
Internet Explorer 8이 정식 발표가 되었습니다. 아래 URL에서 다운로드 받으시면 됩니다.
http://www.microsoft.com/korea/windows/internet-explorer/default.aspx
주요 강화된 보안기능에는 아래 3가지 정도로 요약하면 될거 같네요.
이중에서 "교차 사이트 스크립팅(XSS) 필터 기능" 부분이 제일 관심이 가지는 부분일거라 생각합니다.
예전부터 클라이언트측에서의 완벽한 보안을 적용할려고 많은 시도를 할려고 하였고, 이 기능도 역시 브라우저단에서의 완벽한 보안기능을 원했을겁니다.
http://nchovy.kr/forum/2/article/189
IEBlog의 글 일부를 번역한 부분이 있습니다. 이 글에서도 XSS 필터링 기능에 대한 기능 한계 및 문제점에 대해서 말해주고 있습니다.
TeamCR@K에서도 이 부분에 대해서는 꾸준한 연구가 필요할것이고 결과가 나올때마다 포스팅을 하도록 하겠습니다.
학습 참고 URL)
http://www.microsoft.com/korea/windows/internet-explorer/default.aspx
주요 강화된 보안기능에는 아래 3가지 정도로 요약하면 될거 같네요.
| 1) 웹 검색 등에 흔적을 남기지 않게 하는 InPrivate 브라우징 기능 http://www.microsoft.com/korea/windows/internet-explorer/features/browse-privately.aspx?tabid=2&catid=1 2) 안전하지 않은 사이트에 방문한다고 판단될때 필터링을 해주는 SmartScreen 필터 기능 http://www.microsoft.com/korea/windows/internet-explorer/features/stay-safer-online.aspx?tabid=2&catid=1 3) 악성 스크립트 삽입에 대한 위험성에 보호하는 교차 사이트 스크립팅(XSS) 필터 기능 http://www.microsoft.com/korea/windows/internet-explorer/features/stay-safer-online.aspx?tabid=2&catid=1 |
이중에서 "교차 사이트 스크립팅(XSS) 필터 기능" 부분이 제일 관심이 가지는 부분일거라 생각합니다.
예전부터 클라이언트측에서의 완벽한 보안을 적용할려고 많은 시도를 할려고 하였고, 이 기능도 역시 브라우저단에서의 완벽한 보안기능을 원했을겁니다.
http://nchovy.kr/forum/2/article/189
IEBlog의 글 일부를 번역한 부분이 있습니다. 이 글에서도 XSS 필터링 기능에 대한 기능 한계 및 문제점에 대해서 말해주고 있습니다.
TeamCR@K에서도 이 부분에 대해서는 꾸준한 연구가 필요할것이고 결과가 나올때마다 포스팅을 하도록 하겠습니다.
학습 참고 URL)
Winkey 쌤과 꼬알라의 Windows 7 만담 시리즈 1편! - 소개
Winkey 쌤과 꼬알라의 Windows 7 만담 시리즈 2편! - UX
Winkey 쌤과 꼬알라의 Windows 7 만담 시리즈 3편! - Internet Explorer 8 (상편)
Winkey 쌤과 꼬알라의 Windows 7 만담 시리즈 4편! - Internet Explorer 8 (하편)
Winkey 쌤과 꼬알라의 Windows 7 만담 시리즈 5편! - 라이브러리~
Winkey 쌤과 꼬알라의 Windows 7 만담 시리즈 6편! - HomeGroup~
Winkey 쌤과 꼬알라의 Windows 7 만담 시리즈 7편! - BitLocker, BitLocker to Go
