MSB ASCII obfuscation

MSB ASCII Obfuscation 취약점 분석

By bdr@a3security.com
(A.K.A Dear.Tom)
kerz@a3security.com
(A.K.A k3rz)

I. 취약점 개요

연구 대상	MSB ASCII Obfuscation 취약점
문서 작성일	2009.07	문서 버전	V1.0

 

가. SecurityFocus 권고문

(1) 개 요

이 취약점은 Network와 실제 Data가 Internet에서 사용되는 단위의 차이로 인하여 발생하는 것 입니다.ASCII로 인코딩되는 문자는 모두 7bit(Web Browser 에서 쓰이는 ASCII의 사용 Data의 bit는 7bit)이지만,Network 에서 Data 전송에 사용하는 단위인 Octet은 8bit 입니다. 만약, ASCII로 인코딩 되어 전송되면 MSB(Most Significant Bit)는 무시됩니다.

Fireforx 1.5, Opera 8.5 and InternetExplorer 6에서 테스트 결과, IE 6, IE 7 에서 취약점이 발생하였습니다.
웹 페이지 작성자는 페이지의 보여지는 부분을 변경하지 않고, 임의 문자로 설정할 수 있습니다. 그러나 바이러스 스캐너나 콘텐츠 필터는 완벽히 다른 문자로 보기 때문에 이러한 프로그램들은 바이러스나 스팸을 막을 수 없습니다.

결론적으로 이것은 스패머나 바이러스 작성자에게 스팸 설치나 바이러스 필터를 우회할 가능성을 제공해줍니다.


(2) 영 향

IE는 오직 7bit 인 ASCII로 인코딩 된 웹 페이지를 보여줍니다. 다양한 하드웨어 라우터와 안티바이러스 솔루션으로 체크한 결과, 모두 웹페이지 안에 삽입된 악성 자바스크립트를 막는데 실패했습니다.

(3) Bug 개요 및 대응방안

필터나 스캔 APP 이 분석하기 전에 ASCII로 인코딩 된 웹 페이지의 MSB를 제거합니다.


(4) 샘플페이지

URL) http://www.iku-ag.de/ASCII (IE 6에서 동작)
URL) http://www.iku-ag.de/sicherheit/ascii-eng.jsp (IE 6에서 동작)



II. 취약점 분석


가. MSB 변환 프로그램

(1) 일부 소스
    - 전체 소스는 공개하지 않으며, 일부 소스만 공개하겠습니다.

.. 생략   int main(int argc, char *argv[]) { char *in_file_name, *out_file_name; FILE *inf, *outf; struct stat statbuf; long long size, i; size_t read_len; char buf[BUF_MAX]; if(argc != 3) { printf("Usage: %s Src Dst", argv[0]); return -1; } in_file_name = argv[1]; printf("input is %s\n", in_file_name); if (stat(in_file_name, &statbuf) == -1) { perror("fstat"); return 1; }  .... 생략 for (i=0; i<size;) { size_t len; char *p_buf=buf; len = fread(buf, sizeof(char), BUF_MAX, inf); i += len; while (len) { fprintf(outf, "%c", (*p_buf)|0x80); p_buf++; len--; } } fclose(inf); fclose(outf); return 0; }

(2) 소스 분석

현재 읽어온 Data의 1byte와 0x80(즉, 1000 0000)을 OR 연산을 수행합니다. 이것은 모든 byte의 MSB를 1로 수정하는 것 입니다. 이렇게 함으로써 웹 상에 보여질 때는 변형된 문자가 보여집니다. 하지만, web browser가 해석할 때는 변형된 1bit를 제외한 나머지 변형되지 않은 7bit만을 가지고 해석하기 때문에 문제가 발생합니다.

for (i=0; i<size;) { size_t len; char *p_buf=buf; len = fread(buf, sizeof(char), BUF_MAX, inf); i += len; while (len) { fprintf(outf, "%c", (*p_buf)|0x80); p_buf++; len--; } }

(3) 프로그램 사용 결과
Usage) program_name input_file output_file

  [그림 1] 프로그램 사용법

다음은 XSS 평문을 MSB ASCII obfuscation을 이용한 인코딩한 화면입니다.

[그림 2] 프로그램 사용 결과

(4) 취약한 환경 테스트
IE 버전별 테스트 결과 아래 표와 같이 나왔습니다.
[표 1] 테스트 결과

Vendor	Version	Result
MS Internet Explorer	6.0	취약함
	7.0	취약함
	8.0	취약하지 않음

다음은 IE 6.0에서 테스트 결과 성공한 화면입니다.

[그림 3] IE 6.0 및 7.0 스크립트 실행 화면

다음은 IE 8.0에서 테스트 결과 실패한 화면입니다.

[그림 4] IE 8.0 스크립트실행 실패화면

나. 조건 분석

(1) 전제 조건

이 취약점을 이용한 공격에 성공하기 위해서는 다음과 같은 메타태그가 설정되어 있거나, 존재하지 않아야 합니다.

<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">

이러한 특징이 이 취약점을 이용한 공격의 한계점이 될 수 있습니다.


(2) 한계점 우회 방안

이러한 한계점을 극복하기 위하여 다음과 같은 해결방안을 생각해 볼 수 있습니다.
- Iframe 혹은 Div 태그 안에 메타태그를 삽입하여 적용하도록 함

그러나 이 방안 또한, 태그가 막혀있지 않다는 점에 기초하기 때문에 한계가 있을 수 있고, 만약 태그를 쓸 수 있다면 우회할 필요없이 바로 공격이 가능할 것이기 때문에 이러한 방안은 실용성이 떨어진다고 판단할 수 있습니다.


(3) 문제점

7bit 였던 문자가 16bit의 문자로의 변환은 UTF-8을 기준으로 합니다. 하지만, UTF-8 문자표에는 할당되지 않은 값들이 존재하고, 이러한 값들로 인해 공격문이 올바르게 동작하지 않을 가능성이 많습니다.

다음은 UTF-8에 비포함된 문자열 화면입니다.

[그림 5] UTF-8에 할당되어 있지 않은 문자

다음은 깨짐 현상이 발생하는 예제 화면입니다.

[그림 6] 예제 소스

다음은 평문 소스를 인코딩한 화면입니다.

[그림 7] 소스 Encoding

다음은 문자열 깨짐 현상으로 공격이 실패한 화면입니다.

[그림 8] 깨짐 현상 발생

UTF-8 문자와 대칭되지 않는 문자들에 대한 처리 문제가 해결되어야만 Webshell 등을 정상적으로 동작시킬 수 있을 것입니다.



III.위험 분석

가. MSB ASCII obfuscation 취약점을 이용한 Webshell 업로드

MSB ASCII obfuscation 취약점으로 인하여 Webshell 내용을 인코딩 한 후, 업로드시 방화벽을 우회하는 가능성이 생깁니다. 뿐만 아니라 파일 내용을 검사하는 경우 취약점을 이용한 공격이 가능합니다. 실제 테스트 경우 Webshell 내용 일부가 인코딩 되면서 손실되어 불가능 했지만, Webshell 내용을 변경하여 손실을 방지한다면 가능 할 것 입니다.

다음은 인코딩을 위한 Webshell 소스 화면입니다.

[그림 9] Webshell 소스 코드

다음은 Webshell을 인코딩하여 우회를 시도한 화면입니다.

[그림 10] Webshell 인코딩 결과

다음은 정상적인 Webshell 화면입니다.

[그림 11] 정상적인 Webshell 결과 화면

다음은 인코딩한 Webshell 화면입니다.

[그림 12]인코딩 된Webshell 결과 화면

나. 메일 필터링 우회

메일 전송중 스크립트 필터링 과정에서 취약점을 이용하여 스크립트를 스팸메일 등의 악성코드를 삽입할 수 있습니다. 특히 일반 메일 서비스 경우 스팸메일 대책으로 "sex, s*x, fuck, promo, rate, save, shop, money"등의 spam filter word를 적용하는 경우 인코딩으로 우회가 가능 합니다.


다. 악성코드 인코딩을 파일이름으로 적용한 파일을 업로드하여 악성코드 실행 가능성

일반적인 경우 파일 업로드시 파일이름 또한 명시되는 것을 이용하여 파일이름을 인코딩하여 업로드하여 명시 결과 악성코드가 실행할 수 있습니다. 예를 들어 “숍訊昱穿刷奄剔㎬炡筌㈊섞昌侄從풅.xxx”와 같은 파일 이름으로 업로드 시도를 하여 파일이름이 디코딩되면서 실행될 수 있습니다.


IV.결 론

ASCII가 2번째부터 8번째 bit만을 사용한다는 것을 이용하여 MSB를 1로 변경시킴으로서 전혀 다른 문자열이 된다는 것이 MSB ASCII obfuscation 취약점의 초점이며, 인코딩을 통해 필터링을 우회 할 수 있으며, 2006년부터 2007년정도에 실제 공격이 유행하였습니다. 그러나 이 취약점은 Meta 태그의 charset속성 값이 us-ascii으로 정해져 있어야 실행이 가능하며, 상위 Meta 태그의 charset 속성 값이 정해져 있는 경우 하위 Meta 태그의 charset은 적용되지 않습니다. 실제 대부분 국내 웹 사이트인 경우 <meta http-equiv="Content-Type" content="text/html; charset=euc-kr">로 설정된 부분이 많기 때문에 이 취약점은 제한적으로 사용됩니다.

이번 MSB ASCII obfuscation 취약점 분석을 통해 쓸모없는 bit 값을 변경하여 공격에 적용한 창의적인 생각을 다른 방향에도 복합적으로 이용한다면 또 다른 새로운 공격이 도출될 가능성이 있으므로 일반적으로 스쳐갈 수 있는 부분에도 생각하는 능동적인 생각을 해야하며 적용하는 습관을 가져야 합니다.

 

V.참고 자료

○ Bypassing of web filters by using ASCII
(http://www.securityfocus.com/archive/1/437948/30/0/threaded)

○ High-bit ASCII obfuscation
(http://blogs.msdn.com/dross/archive/2006/10/01/780339.aspx)

○ Malformed ASCII bypasses filters
(http://ha.ckers.org/blog/20060621/malformed-ascii-bypasses-filters/)

○ Bypassing XSS web filters by using US ASCII encoding
(http://blog.kassaras.com/?p=37)

○ 자바스크립트 난독화 이해하기 / 안철수연구소 ASEC

○ US-ASCII 방식의 악성 스크립트 분석 하기
(http://totoriver.egloos.com/562258)

○ UTF-8 코드표