'전체 글'에 해당되는 글 72건

  1. 2012.12.11 “윈도우 XP, 지원 종료 500일도 안남았다”
  2. 2012.12.11 “백신, 신종 바이러스 탐지 효과 의구심”
  3. 2012.11.30 [backtrack5] How to Fix Metasploit posgresgl & Fast-Track issues
  4. 2012.11.29 네트워크/시스템 취약점 스캔/분석 기술(1)
  5. 2012.11.20 dhcp환경에서 수정한 도메인이 초기화되는 문제
  6. 2012.10.18 [System Tracking] 시스템변경 추적(모니터) 도구소개
  7. 2012.10.16 [스팸메일] 메일 헤더의 Bcc, return-path, Recived 추적
  8. 2012.10.15 [Pack/UnPack]엔트로피 실행 압축 확인&해제 기법 1

“윈도우 XP, 지원 종료 500일도 안남았다”

|

마이크로소프트와 서드파티 업체들은 윈도우 XP 지원 시간이 500일도 남지 않았다고 밝혔다.

마이크로소프트 서버 사용자들은 11년된 OS인 윈도우 XP의 최종 보안 업데이트를 2014년 8월에 마지막으로 받을 수 있을 것이다.

지난 11월 26일, 마이크로소프트와 관련 업체가 제공하는 윈도우 XP 카운트다운 시계가 500에서 499로 넘어갔다. 마이크로소프트는 윈도우 XP에 대한 지원을 2014년 4월 8일에 마지막 보안 업데이트를 발표하며 종료할 예정이다.

역설적인 것은 마이크로소프트의 윈도우 XP 카운트다운 시계는 윈도우 7에서만 실행된다는 것.

이로써 윈도우 XP에 대한 마이크로소프트의 기술 지원은 12년 5개월 동안 유지되며, 이는 마이크로소프트의 일반적인 관행보다 약 2년 반 긴 기간이다. 이전 기록은 11년 5개월 동안 지원된 윈도우 NT였다.

XP의 수명이 길어진 것은 윈도우 비스타가 드라이브 지원 부족과 버그, 느린 속도로 대다수 사용자들이 비스타를 거부하고 XP를 지속적으로 사용했기 때문이다.

웹 통계업체인 넷 애플리케이션에 따르면, 윈도우 XP는 지난달까지 전세계 데스크톱과 노트북 사용자의 40.7%를 차지하고 있다. 윈도우 7은 10월에 44.7%의 사용 점유율을 올렸다.

카운트다운 시계가 나왔음에도 불구하고, 애널리스트들은 XP가 지원이 중단돼도 수많은 사람들이 사용할 것이라고 예상했다. 지난달 가트너 애널리스트인 마이클 실버는 “엔터프라이즈 PC는 2014년 4월 이후에도 XP가 실행될 것”이라며, “10~15% 정도의 시장이 있다”고 말했다.

컴퓨터월드는 XP의 감소를 지나치게 낙관적으로 전망했다. 2011년 중반에 컴퓨터월드는 윈도우 XP가 2012년 3분기에 38%를 차지하면서 최종 수치보다 3% 아래로 떨어졌다고 예상했다. 넷 애플리케이션은 데이터를 기준으로 현재 2014년 4월까지 윈도우 XP는 전세계적으로 27~29% 정도를 차지할 것이라고 전망했다.

editor@itworld.co.kr

 

And

“백신, 신종 바이러스 탐지 효과 의구심”

|

임퍼바, 40개 이상 안티바이러스 솔루션 분석 결과 발표


[보안뉴스 호애진] 안티바이러스 솔루션이 새로운 바이러스를 탐지하는 데 충분하지 않다는 연구 결과가 나왔다.


보안업체 임퍼바(Imperva)는 기존에 목록화되지 않았던 80개 이상의 바이러스를 수집하고, 이들을 통해 40개 이상의 안티바이러스 솔루션을 분석한 결과를 발표했다.


임퍼바에 따르면, 연구가 수행된 안티바이러스 솔루션 중 5% 이하가 기존에 목록화되지 않은 바이러스를 초기부터 탐지할 수 있었고, 많은 솔루션들의 경우 시그니처가 업데이트 되는데 초기 스캐닝 이후 한 달 이상이 걸리는 것으로 나타났다.

▲ 최초 실행에서 발견되지 않은 감염 파일 식별을 위해 필요한 주(week) 수

임퍼바의 CTO 아미차이 슐만(Amichai Shulman)은 “안티바이러스 솔루션은 기업 보안에 중요한 부분을 차지하고 있지만, 새로 발견되는 하나의 바이러스가 이러한 솔루션을 무용지물로 만들 수 있다는 것이 현실”이라며 “특히 특정 프리웨어 솔루션의 경우 유료 솔루션을 능가하는 것으로 나타나, 기업들이 안티바이러스 솔루션에 수십억 달러를 투자한 가치를 보상받고 있지 못한다고 생각한다”고 말했다.


임퍼바는 80가지 이상의 바이러스 수집을 위해 여러 기법을 사용했다. 이번 연구를 통해 수집된, 기존에 보고되지 않았던 82개의 바이러스는 가상 실행 환경에서 테스트 됐고, 비정상적인 행위가 수반됐으며, 컴퓨터 자원에 대한 취약성을 제약하는 것으로 나타났다.


이번 연구를 통해 밝혀진 결론은 다음과 같다.


안티바이러스 솔루션들은 새롭게 제작된 바이러스를 탐지하는 데 일정 시간이 소요된다.

안티바이러스 업체들은 자사의 탐지 매커니즘을 업데이트하기 위해 지속적인 연구를 수행하지만, 이번 연구에서 안티바이러스 솔루션의 신규 바이러스 초기 탐지율은 5% 이하였다.


인터넷을 통해 전파되는 바이러스를 따라잡을 수 없기 때문에, 이번 연구에서 실험된 안티바이러스 솔루션은 완벽한 보호를 제공할 수 없었다.


안티바이러스 솔루션은 시그니처 업데이트에 뒤쳐지고 있다.

이번 연구의 몇몇 사례에서, 바이러스 탐지를 위한 초기 스캐닝 이후 안티바이러스 솔루션들은 4주의 시간이 걸렸다.


안티바이러스를 위한 투자가 제대로 할당되지 못하고 있다.

2011년 가트너(Gartner)는 안티바이러스와 관련해 기업이 29억 달러, 소비자가 45억 달러 등 총 74억 달러 또는 보안 소프트웨어와 관련한 총 177억 달러의 1/3이상의 비용이 지출되고 있다고 분석했다. 게다가 이번 연구에 의하면 특정 프리웨어는 유료 솔루션과 동등하거나 그 이상의 효율성을 입증했다.


이번 연구에서 완벽한 보호를 제공하는 단일 안티바이러스 제품은 없었지만, 2개의 프리웨어 안티바이러스 제품을 연계해 사용한 제품이 가장 안전한 것으로 드러났다.


안티바이러스 솔루션이 불충분하긴 하지만, 아주 불필요하다는 것은 아니다. 보안팀은 허가받지 않은 접근 또는 대규모의 다운로드와 같은 비정상 행동을 탐지하고, 최신 위협을 해결하기 위해 솔루션에 대한 보안 투자를 조율해야 할 것이라고 보고서는 밝혔다.

[호애진 기자(boan5@boannews.com)]

 

And

[backtrack5] How to Fix Metasploit posgresgl & Fast-Track issues

|

How to Fix Metasploit posgresgl & Fast-Track issues in Backtrack 5

 

First Install Postgresql

apt-get install postgresql libpq-dev
y
 
 

Update Ruby config

update-alternatives --config ruby

 

Other code

gem install postgres
/pentest/exploits/framework3/msfconsole
db_driver
 

Create a user in Postgres

Open a new shell in order to create the user

sudo su postgres -c psql
\password
\q

or

/opt/metasploit/config/database.yml (modify)


 

Create postgres database

Back in msfconsole:
db_connect postgres:toortoor@127.0.0.1/metasploit
 
 

Now fix Fastrack

Edit Fastrack’s autopwn.py
vim /pentest/exploits/fasttrack/bin/ftsrc/autopwn.py
Replace this lines 83 to 99
with this:

 

try:
child1 = pexpect.spawn('%smsfconsole' % (metapath))
# load sqlite3
child1.sendline ('db_driver postgresql')
# Destroy database
child1.sendline ('db_connect postgres:toortoor@127.0.0.1/metasploit')
# run actual port scans
child1.sendline ('''db_nmap %s ''' % (ipaddr))
# run actual exploitation
child1.sendline ('db_autopwn -p -t -e %s' % (option1))
child1.sendline ('sleep 5')
child1.sendline ('jobs -K')
child1.sendline ('\n\n\n')
child1.sendline ('sessions -l')
child1.sendline ('echo "If it states No sessions, then you were unsuccessful. Simply type sessions -i to jump into a shell"')

 

Run Fast Track

root@bt: cd /pentest/exploits/fasttrack
root@bt:/pentest/exploits/fasttrack# ./fast-track.py -i
 

 

 Profit

Wuoo I see one session opened!

 

'레퍼런스 > 해킹' 카테고리의 다른 글

웹 해킹 도구들..  (0) 2012.09.17
Hacking Took List (by purpose)  (0) 2012.09.17
And

네트워크/시스템 취약점 스캔/분석 기술(1)

|

1) 취약점 분석의 의미

취약점 분석은 자신의 취약점 데이터베이스(or 지식, 기술, 경험)를 참조해 대상 시스템에 존재하는 취약점을 검색/나열하는 것을 일컫는다.

운영체제마다 사용하는 네트워크 구현 방식이 다르기 때문에 네트워크로 특정 데이터를 보냈을 때의 반응은 각기 다르게 응답하게 된다. 이런 고유한 형태의 응답은 취약점 스캔/분석의 단계를 통해 운영체제 버전 정보, 패치정보 등을 알아내는 데 사용하는 Fingerprint 역활을 하는데 도움을 준다.

여기에 (무료/상용)취약점 스캐너는 주어진 정보를 활요해 원격 시스템 로그인에 필요한 사용자 자격 증명을 설정하거나, 소프트웨어를 오픈하거나, 서비스의 패치 여부까지 판별해 낼 수 있는 수준이 되었다. 취약점 스캐너는 이렇게 얻은 결과로 시스템에서 탐지된 모든 취약점 보고서를 작성할 수 있으며, 이렇게 발견된 취약점 목록은 추후 Penetration Test에 활용되기도 한다.

 

2) 취약점 스캐너를 이용한 취약점 스캐닝

취약점 스캐너는 일반적으로 대량의 네트워크 트래픽(부정한)을 생성하게 된다. 이 때문에 모의해킹을 수행할 때 탐지되지 않아야 하는 테스트가 필요한 경우는 사용하지 않는 것이 좋다. 하지만 숨길 필요가 없는 테스트를 진행할 때에 이러한 취약점 스캐너는 시스템의 패치 수준과 취약점 식별을 수동으로 조사하는 것보다 시간을 절약할 수 있게 해준다.

자동화된 스캐너를 사용하든 수동으로 스캐닝을 진행하든지 간에 스캐닝은 모의 해킹 단계에서 가장 중요한 단계 중 하나이며, 철저하게 수행할수록 고객에게 가치있는 결과를 제공할 수 있게 된다는 사실을 명심하자.

 

# 일반적이 수동 스캐닝방법

가장 기본적인 수준에서 스캔이 어떻게 수행되는지 생각해보자.

예를 들어, nc(netcat)을 사용하여 대상시스템을 배너 그래빙(banner grabbing)하면, 아래와 같은 형태로 정보를 획득할 수 있을 것이다.

( 배너 그래빙: 원격 네트워크 서비스에 접속하고 반환되는 서비스 배너(확인) 문구를 살펴보고 추측 것으로, 웹, 파일 전송, 메일 서버 같은 다양한 네트워크 서비스는 원격으로 접속하자마자 즉시 배너를 반환하거나 특정 명령의 응답으로 배너를 반환하는 성질을 이용한 기술 )

 

- 대상 시스템: metasploitable v2 ( 192.168.100.2 )

- 스캔 시스템: bt5 r3 ( 192.168.100.9 )

위 결과는, TCP PORT 80 웹 서버에 접속하고, 응답으로 원격 서버에서 반환되는 헤더 정보를 확인하기 위해 "GET HTTP /1.1"을 요청한 결과이다.

반환된 정보를 통해 TCP PORT 80을 이용하는 대상시스템은 Apache/2.2.8을 사용하는 Ubuntu 기반의 웹 서버라는 사실을 알 수 있다. 이 정보는 향후 모의 해킹을 시도할 때 도움이 될 수 있을 뿐만 아니라, 자동화된 취약점 스캐닝을 이용할 때에도 상당한 도움이 될 수 있다.

 

다만, 위 내용은 기본적인 수준에서 보여주기 위한 내용으로 실전에서 이와같은 스캐닝은 그렇게 간단하지 않다.

이러한 취약점 스캔은 시스템과 애플리케이션 구성의 미묘한 차이로 인해 생각지 못한 오탐(false positive)와 미탐(false negative)이 발생될 수 있다. 따라서, 수동으로 수행하든 자동으로 수행하든 결국에는 발견된 취약점을 어떻게 확인하고 판단할지는 스캔을 수행하는 담당자의 몫이 아닐까 생각한다.

 

서두는 위의 글로 마치고, 다음에는 실제로 서비스되고 있는 몇 가지 자동화된 취약점 스캐너들을 이용하는 방법과 결과들을 정리하는 글을 써봐야겠다.^^

 

And

dhcp환경에서 수정한 도메인이 초기화되는 문제

|

리눅스 환경을 사용하다보면, 원하는 도메인서버를 지정해서 사용해야하는 경우가 가끔있다. (머 필요에 따라서이지만)

하지만, 이때 dhcp환경을 사용하다보면 주기적으로 사용자가 수정한 resolv.conf 파일이 초기화되어 수정한 정보가 아닌 원래 시스템에서 지정된 도메인으로 초기화되는 경우가 있다.

이런 경우 참 난감하다. svn에서 소스를 다운받다가도 끊기고, 인터넷하다가도 끊기고 정말 난감 그자체 ㅜㅜ

 

그래서, 알아보니 이럴경우에는

/etc/dhcp3/dhclient.conf 를 수정하는 방법이 최선인 것같다.

 

수정전: #prepend domain-name-servers 127.0.0.1;

수정후: prepend domain-name-servers [domain server ip];

 

 

And

[System Tracking] 시스템변경 추적(모니터) 도구소개

|

침해사고가 발생된 시스템의 초기분석 과정에서 빠질 수 없는 것이 공격 후의 시스템내 변경내역을 추적하는 것이다. 이는 곧 공격자의 행위를 파악할 수 있기도 하거니와 피해범위를 산정하기 이한 작업이기도 하다. 하지만, 시스템의 변경을 추적한다는게 말처럼 쉽지는 않다. 다른 분석과정처럼 현 시스템의 어느부분이 변경되었으며 어떻게 악의적인 동작을 하는지 확인하는 방법이 쉽지않기 때문이다.

 

따라서, 여기서는 초기분석 시, 시스템의 변경을 추적하여 분석/접근하는 방법에 사용 가능한 도구를 소개하여 기록하고자 한다.

 

1. [Winalysis 3.1]

: 가장 많이 알려진 도구이기도 하고, 가장 많이 쓰이는 도구이기도 하다. 하지만, 무료 도구가 아닌관계로 트라이얼버전의 사용때문에 불편한 점이 없지 않으며, 시스템에 설치해야 한다는 단점이 있다. 이 도구는, 아래와 같이 [EventLog], [Snapshot], [Users], [Jobs] 기능으로 구성되어 있으며, 각 기능의 역활은 아래와 같다.

<인터페이스 구성>

□ EventLog: 시스템 로그 View

□ Snapshot: 현재 시스템 상태(레지스트리, 파일, 사용자, 등등)를 캡처 ( 이미 저장된 Snapshot과의 비교분석이 가능하다. )

□ Users: 시스템 사용자 View

□ Jobs: 작업 스케줄러 View

 

※ 다운로드: Winalysis v3.1

 

인터페이스

결과 출력 예 

 

 

 

 

 

2. [Regshot 1.8.2]

: 이 도구 역시 레지스티리와 파일의 변경내역을 비교하여 출력 가능한 도구이다. 이 도구의 장점은 매우 빠른 비교분석이 가능하다는 점과, 비교 결과를 텍스트형태뿐만이 아닌, HTML페이지 파일로도 선택하여 볼수 있다는 점이다. 또한 설치과정도 필요하지 않음.

<인터페이스 구성>

□ Compare logs save as: 비교 결과를 저장할 문서의 타입

□ Scan dir..: 검색 대상

□ 1st shot: 비교전 시스템 스냅샷

□ 2st shot: 현재 시스템 스냅샷

□ compare: 비교시작

※ 다운로드: Regshot

 

인터페이스

결과 출력 예 

 

 

 

 

 

3. [InstallWatch Pro v2.5c]

: 이 도구는 위의 [Winalysis]와 유사하며, 이 버전에서의 사용은 무료인 장점이 있다. 또한, All Files, INI Files, Registry 비교 분석이 가능하다.

<인터페이스 구성>

□ install: 비교전 시스템 상태 스냅샷

□ Config: 설정

□ Snapshot: 현재 시스템 상태 스냅샷

□ Analyze: 비교전과 현재의 스냅샷을 비교, 결과출력

※ 다운로드: InstallWatch Pro

 

인터페이스 

결과 출력 예 

 

 

 

 

4. [SystemSherlock Lite v1.0.0]

: 이 도구는 Command Line 인터페이스가 제공되며, 매우 상세한 값비교가 가능하다고 한다. (나도 써보진 않았음)

※ 다운로드 및 매뉴얼은 아래의 URL을 통해 확인 가능.

SystemSherlock Lite

 

위에 설명한 도구외에도 다양한 도구들이 더 존재하며, 여기서 다루지 않는 이유는 그러다보면 끝도없을 까바....(농담입니다.^^)

대략, [InstallSpy v2], [SpyMe Tools v1.5] 등등이 더 있으니 확인하고자 하시는 분들은 직접 검색, 확인해 보시길..^^

And

[스팸메일] 메일 헤더의 Bcc, return-path, Recived 추적

|

메일과 관련된 분석은 자주 발생하지는 않는다. 하지만 메일 역시 공격의 수단으로 많이 활용되는 경로임은 분명하다. 따라서 이메일에 대한 분석방법에 대해서도 한 번쯤 생각해 보는 것이 중요할 것이다.

 

메일과 관련된 내용은 Internet Message Format(RFC 2822)를 통해 자세히 알 수 있으며,

여기서는 메일 헤더의 각 필드에 대한 내용이 여기서 다루지 않을 생각이다. 각 헤더에 대해 자세히 확인하고자 한다면 위 문서를 통해 확인하길 바란다.

 

Bcc(숨은참조 기능)

여기서는, "도착주소 필드(Desitination address fields)"에 대한 내용에 대해 기록할 예정이다.( 이 부분을 잘못 기억하고 있어 피본 기억이 있음 ㅜ,ㅡ)

위 RFC2822 -> 3.6.3 섹션에 보면, 메일이 도착할 수 있는 주소필드는 총 3가지로 구분된다.

1. To - 받는 사람을 정의

1. CC(Carbon Copy) - 받는 사람외에 해당 메일을 참조하는 사람을 정의

2. Bcc(Blind Carbon Copy) - CC와 동일하나, 받는사람의 정의가 노출되지 않음 ( 숨은참조 ) -> 정말 이런건 왜만든 걸까. ㅜㅜ

 

위 3가지 중, 문제가 되는 것은 [Bcc]이다. 왜냐하면, 숨은참조를 하게되면 아무리 받은쪽에서 메일의 헤더를 본다고 한들 숨은참조된 대상을 확인할 수 없기 때문이다. ( 숨은참조한 대상은 메일을 발송한쪽에서만 확인이 가능하다. )

경우에 따라서는 Bcc는 대량의 메일 발송에 쓰이는 경우도 있기도 하다. (물론, 대부분은 이런 식으로 발송하지 않을 것이지만...)

 

이 Bcc는 스팸을 발송하는 공격자에게 꽤나 유용한 기능으로 생각되며, To에는 전혀 다른 사람의 메일 주소를 입력하고 Bcc에 메일 사용자의 주소를 입력해서 마치 사용자로 하여금 다른 사람한테 갈 메일이 자신에게 잘 못 수신된 것처럼 보여질 수 있게한다. 또한, 잘못 전달된 메일이라도 열어보려고 하는 것이 마치 습성인 사람도 있는 것이 문제이며, 이와 같은 기능은 스팸메일이 피해범위를 가늠하기도 어렵게 한다.

이러한 Bcc는 위와 같이 악용될 소지가 다분하기 때문에 일부 웹메일 서비스에서는 메일 작성 시, Bcc에 들어갈 수 있는 메일 주소의 수를 제한시켜두기도 하고, 스팸메일의 수신가능성 때문에 도착한 메일의 Bcc 필드가 설정된 수준 이상을 초과할 경우 스팸처리해 버리기도 한다.

( 정상적인 대량메일 발송의 경우, 숨은참조를 하는 것은 충분히 올바른 행동은 아니라고 생각됨 )

 

return-path

return-path는 보내진 메일의 반송처를 정의할 때 사용된다.

하지만, SMTP에 의해 옴겨지는 메일의 경우에는 보통 return-path 필드가 생략된다. (이는 SMTP 방식으로 인해)

 

Received

Received 필드는 아래와 같은 토큰열로 구성되며,

  1. 생략 가능, "from", atom, 의 후에 기호화 도메인명 ;
  2. 생략 가능, "by", atom 의 후에 기호화 도메인명;
  3. 생략 가능, "via", atom 의 후에 다른 atom;
  4. 다음의 것의 열(하늘도 가능): "with", atom의 후에 다른 atom;
  5. 생략 가능, "id", atom 의 후에 (1) atom 또는 (2) < 토큰, 기호화 주소, > 토큰;
  6. 생략 가능, a "for", atom, 의 후에 기호화 주소
  7. 세미콜론
  8. 타임 스탬프

각각의 SMTP서버는 받은 메일에 대한 Received 필드를 첨가하여 발신한다.

Received는 아래에서 위쪽으로 분석하여 경로를 확인할 수 있다.

 

아래에는 이메일 헤더정보를 입수했을 때 추적할 수 있는 방법을 추가로 기술한다.

이메일 추적을 지원하는 웹사이트: http://www.ip-adress.com/trace_email/

 

1. 이메일의 속성보기를 통해 메일헤더값을 확인/복사하여 이 사이트에 붙여넣기 한다. (아래 그림참조)

 

 

2. 하단의 [Trace Email Sender]버튼을 클릭한다.

3. 결과가 아래와 같이 출력된다.

( 여기서 추적한 결과는 이라크...로 나오네..;; )

 

And

[Pack/UnPack]엔트로피 실행 압축 확인&해제 기법

|

 

최근의 봇이나 웜 등의 악성코드들은, 안티 바이러스 프로그램을 회피하기 위해서 실행 압축 등의 코드 혼란 기법을 사용하고 있다. 이러한 기술들은 악성코드를 분석하고자 하는 인원들에게는 매우 환영받기 어려운 것들로 ㅜㅜ  이러한 기술들을 통해 악성코드의 탐지 및 방어는 점점 더 어려워 지고 있다.

여기서는 이러한 실행압축 기술의 분석에 응용 가능한 엔트로피 분석을 이용한 범용적인 압축해제 기법에 대해 다룬다.

 

실행압축이란, 실행 파일을 압축하여 파일의 크기를 줄이고, 파일의 분석을 어렵게 하는 기술로 실행압축 파일은 크게 실행 압축 해제 부분과 실제로 실행되는 부분으로 나눌 수 있다.

여기서 나오는 알고 넘어가야할 개념이 OEP(Original Entry Point)인데, OEP란 실행 압축 파일이 스스로 실행 압축을 해제한 뒤 처음으로 실행하는 명령어의 주소를 일컫는 용어로, 원래의 EP(Entry Point)를 말한다. OEP가 중요한 이유는 실행압축된 파일의 분석을 위해서는 실제로 실행되는 부분을 찾아야 분석이 가능하기 때문이다.

 

현재까지 주로 사용되는 실행압축 해제 기법은,

디버거 및 분석도구들을 이용하여 수동으로 분석하는 방법( 매우 비효과적이다. 하지만 알려지지 않은 패커의 등장에는 이방법밖에 없음을 잊지 말자 )

특정 실행 압축 알고리즘의 특징을 기반으로 한 압축해제 방법 ( 언패킹도구 활용. 알려지지 않은 패커일 경우에는 활용할 수 없음 )

실행 압축 기법에 의존하지 않는 실행압축 해제 방법

PolyUnpack 방식: 실행 압축 파일의 실행 흐름은 원래의 실행 파일의 명령어에 도달할 수밖에 없다는 가정을 바탕으로하며, 실행 압축한 코드를 연속적으로 일부분 실행하며 부분분석을 수행하고, 이를 통해 악성코드 여부를 판단할 수 있다.

OmniUnpack 방식: 모든 실행코드를 분석하지 않고 메모리를 관찰하여 프로세스가 데이터를 쓴 메모리 영역으로 실행 흐름이 바뀌는 순간 그 영역을 분석하는 방법 ( PolyUnpack 방식에 비해 필요 없는 분석 시간을 줄일 수 있음 )

Renovo 방식: 가상머신을 사용하여 실행 압축된 파일을 해제하는 기법으로, 분석하는 동안 악성코드 분석도구가 원래의 시스템으로 부터 격리되어 감염의 위험성이 현저히 낮아지니다는 점과 기존의 기법들과 달리 프로세스의 관점이 아닌 전체 시스템 관점에서 악성코드 분석이 가능하다는 장점이 있다. 하지만, OEP를 찾는데는 어려움이 있다.

 

● 엔트로피를 이용한 실행압축 해제 기법

여기서 말하는 방법은, Shannon의 정보 엔트로피 개념을 통하여 정보의 양을 수치화하는 압축확률확인 방법으로 압축 알고리즘의 압축률을 평가할 때 유용하게 이용되는 방법을 역이용하는 것이다.

엔트로피가 높은 데이터일수록 나타날 수 있는 모든 비트들이 고루 나열되어 엔트로피가 높을수록 압축률이 높다고 추측할 수 있게된다.

이러한 엔트로피의 특성을 이용하면 실행 압축된 파일이 실제 실행파일보다 압축률이 높기 때문에 비교적 더 높은 엔트로피 값을 갖게된다는 가설이 성립되며 이를 통해 실행압축된 파일임을 확인할 수 있는 것이다.

또한, 실제 실행압축 프로그램을 이용해 압축된 실행파일을 실행하게되면, 실행압축되기 전의 코드 위치와 같은 메모리 주소에 압축해제가 되는 것을 확인할 수 있다.

 

아래에는 이와 같은 기법의 연구내용 보고서를 참조한다.

 

Entropy Unpacking.zip

 

또한, 이 아래에는 엔트로피 값을 이용해 파일을 분석할 때 사용 가능한 도구를 추가 첨부한다. 이 도구는 원래 IDA Plugin으로 사용되지만, 윈도우에서 독립실행도 가능하다.

 

ida-ent.zip

 

(이 두 첨부파일은 암호로 보호됩니다.)

And
prev | 1 | 2 | 3 | 4 | 5 | ··· | 9 | next