2013년 4월 18일 목요일

Dadong’s JSXX 0.44 VIP 분석 Part 1



q  Gongda Pack ?
1.    History
1)  Dadong’s JSXX 0.XX VIP 내부 공격 코드 중 중국어로 ‘공격’ 을 의미하는 ‘공다(gongda)’ 
   라는 변수명(gondad) 이 상당 부분 사용되는 점을 특징으로 이름이 지어졌으며, Gongda 
   Pack 또는 Gongda Exploit Kit 으로 알려져 있다

2) 2010 Dadong’s JSXX 0.39 VIP 를 시작으로 잠시 등장했던 Dadong’s JSXX 0.41 VIP 
   버전을 지나 Dadong’s JSXX 0.44 VIP 버전이 2012 4월부터 현재까지 등장하고 있다

2.    Gongda Pack 0.44
1) 주석 스크립트 변화 과정
    - Gongda Pack 0.44 주석 스크립트 부분이 변화되는 원인은 고정적인 문자열을 이용한
      패턴탐지를 우회하기 위해 변화되는 것으로 판단된다



[그림 2] Gongda pack 0.44 주석 스크립트 변화 과정


q  Dadongs 0.44 구조

※ 여기서는 Dadongs 0.44의 난독화를 해제하는데 중점을 두겠다 취약점을 이용하는 부분과 문서에서 다루지 않는 부분은 아래의 사이트를 참조하기 바란다
[참고 1] 'GongDa'의 무차별 웹 공격이 시작됐다

1.    전체 구조
  1)     난독화된 Dadong’s 0.44은 아래 그림처럼 크게 3부분으로 나누어 진다

[그림 2] Dadong’s 0.44 전체구조

 ①    번째 부분플래시자바 관련 스크립트 삽입  쿠키 값을 이용하여 중복 실행을 방지하는 부분이다
        ☞ 해당부분은 [참고 1] 상세히 설명되어 있다
 ②    번째 부분난독화된 데이터 부분으로  부분을 복호화하면 실제 공격코드가 된다

 ③    번째 부분난독화된 데이터를 복호화하는 스크립트 부분으로  부분을 중점적으로 분석 한다


2.    복호화 스크립트 정리 ( 번째 부분)
1)     복호화 스크립트에서 불필요한 부분 제거 및 일차원적 난독화 부분에 대해 정리 
[그림 3복호화 부분 스크립트 정리



2)     정리 후 복호화 함수의 구조
         - 보기 어렵게 작성된 부분 및 제거되는 코드를 정리하면 아래 그림처럼 된다

[그림 4복호화 스크립트 정리 결과


3)     이 복호화 부분은 함수변조방지 기술로 묶여져 있기 때문에 위와 같이 정리 후 Key값을 찾아도복호화가 정상적으로 이루어 지지 않는다

q  난독화 풀이

1.    ‘alert’ 이용한 데이터 부분 복호화  
1)     복호화 시 일반적으로 ‘alert’이나 ‘document.write’ 등을 사용하여 실행되는 스크립트를 문자로 확인한다 여기서는 ‘alert’을 이용하여 데이터를 복호화 시도하였다

[그림 6. [그림 5]의 스크립트에서 Key값을 alert으로 복호화 시도]

2)     ‘alert’을 이용한 난독화 결과
         - 복호화 부분의 문자열을 나누었기 때문에 구조가 변화면서 오류가 발생하였다 

[그림 7] 변조방지 기능에 의한 오류 발생

    - 수정된 스크립트부분을 처음 구조와 동일하게 변경 후 실행해도 오류가 발생하였다


3)     복호화 실패 원인
제작자는 복호화를 어렵게 하기 위해 함수를 문자열로 묶어놓았고문자열을 변경할 경우 함수의 변수 값이 변하여 원래 데이터를 얻을 수 없도록 만들었다 (변조방지기능)

             
[그림 8] 변조방지기능의 역할을 하는 부분

4)     해결 방법
값의 길이와 문자를 이용하여 변수를 구하는 부분이 변경되지 않게 하기 위해 [그림 5]의 정리된 복호화 부분 위에 원래 복호화 부분을 추가하여 함수들이 참조할 수 있도록 한다

             

[그림 9] 변조방지를 우회하기 위해 복호화 부분을 추가 삽입



     5)     데이터 복호화 
        - 수정된 복호화 부분을 이용하여 데이터를 복호화 시 공격 스크립트를 확인 할 수 있다
             
[그림 10] 복호화에 성공한 화면

2013년 3월 28일 목요일

A태그 해킹(하이잭킹)

최근에 해외 웹사이트에서 <A> 태그의 href 속성을 동적으로 변경하는 기법이 소개됐다.
그 기법을 악용하면 악성코드 제작자들이 정상 링크를 조작하여 악성 URL로 리다이렉션 시킬 수 있다.
따라서 일반 사용자들은 네이버로 접속될 줄 알았는데, 악성 URL로 리다이렉션 되어 악성 파일에 감염될 수 있는 예가 생길 수 있다.

해당 기법을 소개하기 위해서 JQuery 언어를 이용했으며, 예제는 다음과 같이 작성되었다.
( HTML, JQuery 문법은 구글링하여 찾아보기 바랍니다).

위 예제에는 “test”라는 ID가 부여되었으며, href 속성이 “http://www.naver.com/” 라는 값을 가진 A태그가 있다. 해당 태그는 “Let’s go Naver.com” 링크를 클릭하면 Naver 웹사이트로 이동하게 한다.

다음으로 자바스크립트로 작성된 부분을 볼 수 있는데, JQuery 문이 사용되었다.
“test”라는 링크를 클릭하는 이벤트가 발생하면 특정 함수를 실행시킨다.
특정 함수는 “test”라는 ID를 가진 링크의 href 속성 값을 “http://www.google.com/”으로 동적으로 변경시킨다.
소위 말하는 하이잭킹(가로채기)기법이다.

이러한 기법은 악성코드 제작자들이 충분히 악용하여 특정 웹페이지를 변조할 때 정상 링크를 악성 URL 링크로 동적으로 변경하는데 사용될 것으로 보인다.

2013년 2월 18일 월요일

Node.js 와 BlackHole 2.0 Exploit

BlackHole 2.0 Exploit 샘플을 Node.js를 이용하여 분석할려고 합니다.

Node.js를 사용하여 분석한 이유는 인터프리터 방식이기 때문에 자바스크립트 코드를 한줄 한줄 실행해가며 결과를 볼 수 있는 장점이 있기 때문입니다. 비록 브라우저가 아닌 콘솔 환경에서 결과물을 보기 때문에 사용에 불편함이 있지만 사용해볼 가치가 있습니다.

이 글에서는 Node.js를 설치하는 방법은 다루지 않겠습니다. 그 방법은 구글링 해보시기 바라며, BlackHole 2.0 Exploit 샘플을 분석해보겠습니다.

해당 샘플은 다음과 같이 3가지 부분으로 이루어져 있습니다:
[그림 1] BlachHole 2.0 Exploit 샘플

(1)  인코딩된 URL 로딩(특정 자바 취약점을 일으키는 JAR 파일 로딩 )
인코딩된 URL(N0b0909041f3131041a43431a001a223844213219353c3a350931003509353809193104431a323a2211351e28171a44000c283505323a3a323a052223173a320917443c040b043d2c2c391c2908181c3e1c3e1c1a020a35391c3408081c081c3e0842082b1c291c271c271c280217391c2702430a3905022c2c3928)이 Param태그("uid"로 네이밍)의 value에 할당된것을 볼 수 있습니다. 인코딩된 URL은 특정 키 값에 의해 해제할 수 있으며, 해당 키값을 얻으려면 특정 URL 정보가 필요합니다.
해당 샘플의 경우에는 특정 URL 정보(http://pallada-cruise.net/detects/plain-keyboard_beginning-monitor.php?fpdz=073809090a&lxrpa=4547&ryz=chh&bxkrc=ruuwzhkb) 존재하기 때문에 디코딩된 URL 을 다음과 같이 얻을 수 있습니다.
Secret Decoder Ring 툴을 이용했습니다.
[그림 2] URL 인코딩

(2) 난독화된 데이터
이 데이터는 디코딩 로직에 의해 풀려서 실행됩니다.
다수의 자바 취약점에 의해 사용자 PC에서 악성파일을 다운로드 및 실행시켜 악성 행위를 합니다.

(3) 디코딩 로직
디코딩 로직은 자바스크립트로 작성됐습니다. 해당 로직을 Node.js를 이용하여 관련 코드를 한줄 한줄 실행해 보겠습니다.

- 1. 각각의 변수에 필요한 함수 객체를 할당하였습니다.
[그림 3] 변수 할당(함수 객체)

- 2.  "google" 이라는 아이디를 가진 U 태그의 각 변수( d[0~94] 형식 )에 난독화 데이터를 할당했습니다.
95개의 변수에 난독화 데이터를 할당하는 일은 노가다성(?)이 짙기 때문에 분석을 위해서는 변수 하나에 할당하도록 하겠습니다(Node.js에서는 콘솔 환경이라서 난독화 데이터 할당후, 데이터가 일부만 보입니다).
[그림 4] 변수 할당(난독화 데이터)

[그림 5] 변수 할당(난독화 데이터)

- 3. 난독화 데이터에서 영문소문자(a-z ) 와 숫자(0-9)를 제외한 나머지 문자를 제거했습니다.
[그림 6] 특정 문자 제거(난독화 데이터)

- 4. 난독화 데이터의 각 문자(유니코드숫자)를 두자리씩 끊어서 28진수 데이터로 변환한 다음, String.fromCharCode 함수를 이용하여 문자로 변환하여 난독화 데이터를 디코딩합니다. 이 부분은 BlackHole 2.0 Exploit 샘플마다 다릅니다. 하지만 변환후 eval 함수를 통하여 실행 시키는 방식은 동일합니다.
때문에 BlackHole 2.0 Exploit 샘플을 볼 때, 난독화 디코딩 코드만 유의하여 보면 난독화 해제하기가 쉽습니다.
[그림 7] 난독화 데이터 디코딩

디코딩 코드에서 난독화를 해제한 다음 s 변수에 저장한것을 볼 수 있습니다.
해당 변수를 eval함수를 이용하여 실행하면 취약점이 있는 웹브라우저에서는 악성코드를 다운로드 받음 다음 실행됩니다. 따라서 Node.js에서 디코딩 코드를 볼려면 eval 함수를 console.log 함수로 변환하여 실행하면 됩니다.
[그림 8] 난독화 데이터 디코딩 결과

이러한 방법으로 우리는 Node.js를 이용하여 BlackHole 2.0 Exploit 샘플을 분석할 수 있었습니다. 아마 해당 샘플을 대략적으로 이해하는데 도움이 되셨으리라고 생각됩니다 :-). 이 글을 읽으시는 분들이 다른 샘플도 저와 같은 방법으로 분석해보면 난독화 샘플의 로직을 이해하는데 도움이 될것으로 생각됩니다.

2013년 2월 15일 금요일

Blackhole Toolkit 흐름도

q  개요

2012 9 Blackhole Exploit Toolkit의 최신버전인 Ver2.0에 대한 정보가 해외 보안사이트에서
확인 되었습니다. 그리고 9월 말 국내에서 Blackhole Exploit Toolkit 2.0을 이용한 악성코드 유포로
의심되는 이벤트가 발생되어 전체적인 흐름을 파악하기 위해 작성하였습니다. 오늘날까지 조금씩 변종되어
툴킷은 지속적으로 발생하고 있습니다.


q  악성코드 유포 흐름

1.    악성코드 유포 흐름도
- 해커가 Webhosting 업체를 장악 후 서비스를 받는 하위 웹사이트들을 이용하여 악성코드 유포 행위 포착

[그림 1. 악성코드 유포 흐름도]
√ 해커가 웹 호스트 업체 서버 장악 및 악성코드 유포지 선점
√ 사용자가 해당 업체에서 서비스 받는 웹사이트 접속 시 악성코드 유포지로 이동 (302 Redirection)
√ 악성코드 유포지로부터 악성파일이 설치되어 개인정보 유출
 
2.    확인된 악성코드 유포지 LIST (2012 10월 기준)

[그림 2. 악성코드 유포지 현황]


q  악성코드 분석

1.    요약

[그림 3. 악성코드 흐름도]
   사용자가 위/변조된 사이트(gxxxxx.co.kr/index.html) 접속 후 Blank.php 페이지 접속
   blank.php 코드의 특정조건(port:80 )에 맞으면 악성코드 유포지(Index_old.php) 302 redirect  
   시키고, 다르면 정상페이지로 이동
  paros 등을 사용하여 분석 시 어렵게 하기 위한 행위로 추정
   Index_old.php 코드에 의해 navigator.useragent 환경을 체크하여 복호화 수행
   Index2.php 코드는 러시아 성인사이트로 접속과 동시에 다양한 취약점을 내포하고 있는 main.php (blackhole exploit toolkit) 코드로 이동
   main.php 코드는 Java, PDF 취약점 존재 시 최종 악성파일을 다운받아 실행되도록 구현
   최종 악성파일(info.exe) 감염 시 외부로 SMTP 트래픽을 발생



2. 상세 분석

1) index.html (gxxxxx.co.kr/index.html)
- 해커가 삽입한 페이지로 추정되며 악성파일 다운로드를 유도하는 "blank.php" 와 정상 사이트의
  메인 페이지인 "main.php" 로 이동되게 구성



[그림 4. index.html 소스코드]

2) blank.php (gxxxxx.co.kr/blank.php)
- 특정조건(Port:80) 에 의해 맞으면 302 Redirection 기법으로 “index_old.php” 페이지로 이동

 
 [그림 5. Blank.php 접속화면]


3) index_old.php (wkxxxk.in/index_old.php -> wkxxxk.in/blank.php)
- index_old.php 코드에 의해 이동된 blank.php 파일은 난독화된 페이지로 “index2.php” 페이지로
접속을 유도하는 역할
- “navigator.useragent” 함수에 의해 분석자의 환경이 조건에 맞지 않는 경우 동작하지 않음
실제 분석 시 일부 코드를 수정하여 난독화 진행

[그림 6. Index_old.php 난독화]

4) index2.php (wkxxxk.in/index2.php)
- “blank.php” 와 동일한 방식으로 난독화된 페이지로 다양한 취약점을 내포하고 있는 “main.php”
   페이지로 접속을 유도하는 역할

[그림 7. index2.php 난독화]

5) main.php (wkxxxk.in/main.php)
- Blackhole Exploit Toolkit 2.0 Main으로 세 부분의 코드로 구분하여 확인
첫 번째 부분: “frame1.php” 페이지로 이동시키는 부분
두 번째 부분: PDF 취약점을 이용한 악성파일 다운로드 시도
세 번째 부분: java 취약점을 이용한 악성파일 다운로드 시도

첫 번째 부분 분석

 ≫ “blank.php” 와 동일한 패턴으로 난독화되어 있으며, “frame1.php” 페이지로 유도
A. 난독화 코드의 key 값을 찾은 후 “docment.write”를 이용하여 난독화 해제
    - “%(HEX) %(HEX)… “ 형태의 쉘코드 값을 확인
[그림 8-1. main.php 첫 번째 부분 난독화]

B. A에서 얻은 결과값에서 “%”를 모두 제거 후 malzilla Tool을 이용하여 XOR 연산
 - malzilla Tool을 사용하여 “http” 문자열의 Key 값을 찾아 XOR 연산
   - iframe 태그로 “wkmyk.in/frame1.php?src=14…” 연결 확인

[그림 8-2. main.php 첫 번째 부분 난독화]

≫ frame1.php 분석: “frame1.php”특정페이지로 접속을 시도하는 부분과 취약점을 이용하여  쉘코드를 실행하는 두 부분으로 이루어져 있다
A. iframe 태그를 이용하여 “frame2.php”으로 연결을 시도
  ⇒ “frame2.php접속 시 해당페이지는 존재하지 않음 (404 Not Found)

[그림 9-1. frame1.php 소스]

B. 취약점을 이용하여 쉘코드를 실행시키는 것으로 추정되지만, 코드가 손상되어 재현되지 않음

[그림 9-2. frame1.php 소스]

두 번째 부분 분석 (PDF 취약점)
 PDF 취약점을 이용한 ~/content/ap2.php (e8a11.pdf) 파일이 실행되어 악성코드에 감염
 A. PDF 파일에 삽입된 난독화 코드 복호화
[그림 10. ap2.php 복호화 과정]

▶ 세 번째 부분 분석 (Java 취약점)
- Java 취약점이 존재할 경우 Gam.jar 파일과 value 값을 이용하여 악성코드 유포지로 이동
- 제작자가 자신만의 키 값을 이용하여 value 값을 난독화
- “Secret Decoder Ring” Tool을 사용하여 악성코드 유포지 확인

[그림 11. main.php 세 번째 부분 난독화]


6) info.exe (wkxxk.in/g.php?f=952f5)
- Call 함수 내부 반복문 실행을 통하여 URL정보를 획득
악성코드 감염 시 사용자 정보를 수집하여 “http://wkxxxk.in/data/1209291325-2b51c555ec/590”에 전송 후
  응답에 따라 추가 행위를 할 것으로 추정되나 재현되지 않음
 


[그림 12. URL 정보 호출]