การเก็บ physical memory image ด้วย dd และ netcat (#2)

เมื่อคราวก่อนนู้น ผมได้กล่าวถึงการทำ image ของ physical memory โดยใช้ Helix Live CD ไปแล้ว ซึ่งในตอนนั้นใช้วิธีการย้าย image ไปไว้ที่ share ของเครื่องอื่น วิธีการนี้นั้นจะทำให้เครื่่องคอมพิวเตอร์ที่ทำการตรวจสอบมี connection เพิ่มขึ้นมาอีกอันหนึ่ง ดังนั้นผู้ที่ทำการตรวจสอบจะต้องทำการบันทึกผลกระทบนี้ลงไปในรายงานด้วย

การใช้ Helix มีข้อดีคือสะดวก ไม่ต้องพิมพ์คำสั่งที่ซับซ้อน แต่ข้อเสียคือการใช้งาน Helix นั้นจะทำให้ helix.exe ถูกโหลดเข้าไปในหน่วยความจำด้วย (นอกเหนือจากโปรเซสที่จำเป็นเช่น dd) ซึ่งอาจจะไปทับข้อมูลของโปรเซสที่จบการทำงานไปแล้ว แต่มีความสำคัญก็เป็นได้ (helix.exe เป็น GUI ดังนั้นพื้นที่ในการใช้งานในหน่วยความจำย่อมมีขนาดใหญ่กว่าโปรแกรมแบบ command line ธรรมดา)

ดังนั้นวันนี้ก็เลยจะนำเสนออีกวิธีการหนึ่งในการทำ physical memory image และย้ายไปไว้ในเครื่องอื่นโดยอัตโนมัติโดยใช้ dd และ netcat เพียงแค่สองโปรแกรมเท่านั้น วิธีการนี้ทำให้เราไม่ต้องโหลด helix.exe เข้าสู้หน่วยความจำ และไม่ต้องสร้าง connection สำหรับนำไฟล์ไปไว้ใน share เครื่องอื่น แต่จะสร้าง connection ระหว่าง netcat ของเครื่องที่เราต้องการเก็บ image กับเครื่องปลายทาง

ในขั้นตอนแรก ให้เรารันคำสั่งต่อไปนี้บนเครื่องที่จะย้ายไฟล์ image มาเก็บไว้
nc.exe -l -p 8000 | dd.exe of=image-xpsp2.dd

คำสั่งดังกล่าวเป็นการบอกให้เครื่องคอมพิวเตอร์ที่เราต้องการย้ายไฟล์มาเปิด port หมายเลข 8000 เพื่อรอรับ connection เมื่อมี connection เข้ามาจะทำการส่งต่อข้อมูลไปยังโปรแกรม dd เพื่อทำการเขียนไฟล์ image-xpsp2.dd ซึ่งเป็นไฟล์ image ที่เราต้องการ

ในขั้นต่อมา ให้เรารันคำสั่้งต่อไปนี้บนเครื่องที่เราต้องการทำ physical memory image

dd.exe if=\\.\PhysicalMemory bs=4096 conv=noerror | nc.exe remote-address 8000

คำสั่งดังกล่าวเป็นการรัน dd เพื่อเก็บ image จากเครื่องที่เราต้องการตรวจสอบ จากนั้น netcat จะทำการส่งต่อข้อมูลไปยังเครื่อง remote-address ที่ port หมายเลข 8000 อีกทีหนึ่ง

หลังจากที่ได้ image มาแล้วก็ลองมาทำการทดสอบว่า lsproc-xpsp2 ที่เขียนขึ้นมาสามารถ parsing เพื่อเรียกดูข้อมูลได้หรือไม่



lsproc-xpsp2 ก็ยังสามารถอ่าน image ที่เก็บด้วยวิธีการนี้เช่นกัน :)

lsproc สำหรับระบบปฏิบัติการ Windows XP SP2

หลังจากที่วันก่อนได้ใช้ lsproc ทำการอ่านข้อมูลของ physical memory image ของระบบปฏิบัติการ Windows 2000 Server SP4 ไปแล้ว ในวันนี้เราจะมาดู physical memory image ของระบบปฏิบัติการ Windows XP SP2 กัน

ดังที่ทราบกันดีว่า lsproc ซึ่งพัฒนาขึ้นโดย Harlan Carvey นั้นสามารถอ่าน image ของระบบปฏิบัติการ Windows 2000 SP4 เท่านั้น (เนื่องจากมันเป็น PoC ซึ่งคาดว่าขี้เกียจเขียนให้มัน support image ที่ได้จากระบบปฏิบัติการรุ่นอื่นๆ ให้รู้ว่ามันทำได้เป็นพอ) ดังนั้นด้วยความที่ช่วงนี้ว่างงาน จึงได้หยิบเอาเจ้า lsproc มาทำการตัดแปลงใหม่ให้สามารถอ่าน physical memory image ของ Windows XP SP2 ได้โดยตั้งชื่อเป็น lsproc-xpsp2

ผลที่ได้จากการอ่าน physical memory image ของระบบปฏิิบัติการ Windows XP SP2 ด้วย lsproc-xpsp2 เป็นดังภาพข้างล่าง



:) ดูดีทีเดียวแหละ จากการทดสอบหลายๆครั้งพบว่ายังไม่มีข้อผิดพลาดขึ้นในการทำงาน ซึ่งเด๋วจะให้ชาวบ้านช่วยทดสอบอีกทีหนึ่ง

วกกลับมาดูที่ผลลัพธ์กันนิดนึง สังเกตว่าจะเห็นโปรเซสของ dd.exe ซึ่งมีเครื่องหมาย (x) อยู่ประมาณ 3 - 4 โปรเซส (เป็นโปรเซสที่จบการทำงานไปแล้ว) ซึ่งสาเหตุเนื่องมาจากผมพิมพ์ syntax ผิดตอนเก็บ image ครับ - -" เลยทำให้ content ของ physical memory image นี่มีโปรเซสของ dd.exe ปนอยู่กระจายเต็มไปหมด

หลังจากที่ดูประสิทธิภาพการทำงานของ lsproc-xpsp2 ไปแล้ว เรามาดูกันสักหน่อยดีกว่าว่า lsproc-xpsp2 มีอะไรแตกต่างกับ lsproc จึงสามารถอ่าน physical memory image ของ Windows XP SP2 ได้ (ลืมบอกไปว่า lsproc-xpsp2 อ่าน image ของ Windows 2000 SP4 ไม่ได้นะครับ แหะๆ แต่ในอนาคตจะ merge รวมกับ lsproc แต่คงต้องขออนุญาตเจ้าของก่อน)

lsproc-xpsp2 แตกต่างจาก lsproc ดังนี้

• offset ของข้อมูลต่างๆในโครงสร้างข้อมูล EPROCESS และ ETHREAD ซึ่งสามารถดูข้อมูลสรุปได้จาก blog ของ Andreas Schuster ซึ่งเป็นหนึ่งในบุคคลแรกๆที่ทำเกี่ยวกับเรื่อง memory analysis และเป็นคนเขียนโปรแกรม PTFinder ครับซึ่งเป็นโปรแกรมทำงานใกล้เคียงกับ lsproc ครับ
  
• โครงสร้างข้อมูลของ EPROCESS และ ETHREAD ของ Windows 2000 SP4 และ Windows XP SP2 มีการเปลี่ยนแปลงในบางส่วนครับ (เอ๊ะ สองข้อนี้มันเขียนรวมกันได้นี่หว่า - -" แหะๆ)
  

จบแหล้ว ห้วนๆนี่แหละ

การอ่านข้อมูล image ของ physical memory (RAM) เพื่อทำการค้นหาว่า ณ เวลาที่เก็บข้อมูลมีโปรเซสใดรันอยู่บ้าง

หลังจากที่ได้กล่าวถึงการ dump ข้อมูลจาก Physical Memory มาในคราวที่แล้ว วันนี้จะกล่าวถึงเรื่องการนำข้อมูลของ RAM ที่ได้มาไปทำการวิเคราะห์ โดยจะดูว่า ณ เวลาที่ทำการเก็บข้อมูลนั้นมีโปรเซสใดรันอยู่บ้าง

หมายเหตุ: ซอฟต์แวร์และวิธีการที่ใช้วิเคราะห์ที่จะกล่าวต่อไปนี้นั้น สามารถวิเคราะห์ RAM ที่ได้จากระบบปฎิบัติการ Windows เท่านั้น ไม่สามารถวิเคราะห์ข้อมูล RAM ของระบบปฏิบัติการ Linux ได้ เนื่องจากโครงสร้างในการเก็บข้อมูลนั้นต่างกัน

แล้วเราจะวิเคราะห์ยังไง ?? ก่อนที่จะไปดูวิธีการ เราจะไปดูกันก่อนว่ามีโปรแกรมใดบ้างที่ช่วยในการวิเคราะห์...

โปรแกรมที่ช่วยในการวิเคราะห์นี้มีชื่อว่า lsproc ซึ่งเขียนโดย Harlan Carvey โดย lsproc นั้นจะทำการอ่าน image ที่เราได้จาก RAM แล้วทำการค้นหาโครงสร้างข้อมูลต่างๆ (data structure) และทำการแสดงข้อมูลออกมาเป็นดังภาพข้างล่าง

หมายเหตุ: ข้อมูลจาก RAM ที่นำมาวิเคราะห์นี้ได้จากระบบปฏิบัติการ Windows 2000 Server SP4



จากภาพ lsproc จะทำการแสดง หมายเลขโปรเซส (PID), หมายเลขโปรเซสที่ทำให้เกิดโปรเซสนั้น (PPID) ชื่อของโปรเซส, ตำแหน่งที่อยู่ใน Physical memory (offset) และเวลาที่โปรเซสถูกสร้างขึ้น สังเกตว่าผลลัพธ์ที่ได้มานั้นมีโปรเซสของ dd (PID หมายเลข 216) และโปรเซสของ helix (PID หมายเลข 404) ที่เราใช้ในการเก็บข้อมูลของ physical memory รวมอยู่ด้วย นอกจากนี้ lsproc ยังสามารถดึงรายชื่อของโปรเซสที่จบการทำงานไปแล้วขึ้นมาแสดงได้ หากข้อมูลของโปรเซสดังกล่าวที่อยู่ใน RAM ยังไม่ถูกเขียนทับโดยโปรเซสอื่นๆ โปรเซสที่จบการทำงานไปแล้วนั้นข้างหลังชื่อของโปรเซสจะมีเครื่องหมาย (x) อยู่ ซึ่งในที่นี้ก็คือ userinit.exe (PID หมายเลข 1048) และ winmgmt.exe (PID หมายเลข 1052)

หลังจากที่รู้จักโปรแกรมช่วยกันไปแล้ว คราวนี้เราจะมาดูกันว่า lsproc ทำงานกันอย่างไร

lsproc ทำงานโดยทำการอ่าน image ที่ได้จาก RAM แล้วทำการค้นหาโครงสร้างข้อมูลที่เรียกว่า EPROCESS ซึ่งเป็นโครงสร้างข้อมูลที่ระบบปฏิบัติการ Windows ไว้ใช้สำหรับทำการเก็บข้อมูลของโปรเซสต่างๆที่เกิดขึ้นบนระบบ โดยโครงสร้างข้อมูล EPROCESS ของระบบปฏิบัติการ Windows 2000 Server SP4 นั้นสามารถดูได้จาก Forensik Blog (เค้าเขียนว่า Forensik จริงๆ ไม่มีเขียนผิดนะ แหะๆ)

ในโครงสร้างข้อมูล EPROCESS นั้น ได้เก็บโครงสร้างข้อมูลที่น่าในใจอย่างหนึ่งคือ DISPATCHER_HEADER ซึ่งโครงสร้างข้อมูลดังกล่าวมีลักษณะดังต่อไปนี

      +0x000 Header           : struct _DISPATCHER_HEADER, 6 elements, 0x10 bytes
         +0x000 Type             : UChar
         +0x001 Absolute         : UChar
         +0x002 Size             : UChar
         +0x003 Inserted         : UChar
         +0x004 SignalState      : Int4B
         +0x008 WaitListHead     : struct _LIST_ENTRY, 2 elements, 0x8 bytes
            +0x000 Flink            : Ptr32 to 
            +0x004 Blink            : Ptr32 to 

ชนิดของข้อมูลที่ทำตัวหนานั้นคือ Type และ Size ซึ่งจากข้อมูลของ Forensik Blog ได้บอกไว้ว่าค่า Type จะเป็น 0x03 และ Size จะเป็น 0x1b เสมอ ซึ่งค่านี้จะคงที่ตั้งแต่ Windows 2000 Server SP4 ไปจนถึง Windows 2003 Server ดังนั้นเราสามารถใช้ค่านี้ทำการระบุตำแหน่งของข้อมูลที่เกี่ยวข้องกับโปรเซสใน physical memory ได้

เมื่อทำการระบุตำแหน่งของข้อมูลที่เกี่ยวข้องกับโปรเซสได้แล้ว จากนั้นเราทำการอ่านข้อมูลทั้งหมดที่เกี่ยวข้องกับโปรเซสนั้นๆ โดยจำนวนข้อมูลที่อ่านจะขึ้นอยู่กับขนาดของ EPROCESS ของแต่ละระบบปฏิบัติการ โดยระบบปฏิบัติการ Windows 2000 Server SP4 นั้นจะมีขนาด 0x290 bytes

เมื่ออ่านข้อมูลจำนวน 0x290 bytes ของ EPROCESS แล้ว เราจะทำการตรวจสอบอีกขั้นหนึ่งว่าข้อมูลที่เราอ่านมานั้นเป็น EPROCESS จริงๆหรือไม่ ซึ่งขั้นตอนที่ lsproc ทำการตรวจสอบนั้นคือทำการตรวจสอบค่าของ Synchronization Event #2 และ #3 ของ EPROCESS ซึ่งทั้ง 2 ค่านี้จะอยู่ที่ตำแหน่ง 0x13c และ 0x164 จากตำแหน่งเริ่มต้นของ EPROCESS ซึ่งหากค่าของ Synchronization ทั้งสองเป็น 0x040001 แล้ว แสดงว่าข้อมูลจำนวน 0x290 bytes ที่อ่านมานั้นเป็น EPROCESS

หลังจากที่มั่นใจว่าข้อมูลที่อ่านมาจำนวน 0x290 bytes นั้นเป็น EPROCESS แล้ว lsproc จึงทำการอ่านข้อมูล ณ ตำแหน่งต่างๆ เช่น ชื่อของโปรเซส (0x1fc), เวลาที่โปรเซสถูกสร้างขึ้น (0x088), PID (0x09c), PPID (0x1c8) แล้วจึงนำมาแสดงผลต่อไป

ปิดท้ายกันด้วยขั้นตอนการทำงานแบบหยาบๆของ lsproc ครับ :)

การเก็บข้อมูลที่อยู่ใน RAM สำหรับการทำ Computer Forensics

ขึ้นชื่อว่า Live Response (การวิเคราะห์ข้อมูลเกี่ยวกับการบุกรุกโดยอาศัยข้อมูลและสถานะปัจจุบันของเครื่องที่ถูกบุกรุกเป็นหลัก) ก็คงจะปฏิเสธไม่ได้ว่าข้อมูลที่อยู่ใน RAM นั้นมีความสำคัญอย่างยิ่งยวดสำหรับการวิเคราะห์ เนืองจากข้อมูลดังกล่าวเป็นจะเป็นสิ่งที่ช่วยให้เห็นภาพมากขึ้น ณ ขณะที่เครื่องที่ถูกบุกรุกมีโปรเซสใดรันอยู่บ้าง ดังนั้นในวันนี้ผมจะมากล่าวถึงวิธีการเก็บข้อมูลที่อยู่ใน RAM ว่าสามารถทำได้อย่างไร

วิธีการที่ง่ายที่สุดคือใช้ Helix Live CD ซึ่งมี GUI ให้ใช้แบบง่ายๆเลย หน้าตาของ Helix ก็เป็นดังภาพข้างล่าง



โดยปกติแล้วเราจะใช้ dd เพื่อทำการสร้าง image ของฮาร์ดดิสก์แต่อย่างไรก็ตาม dd สามารถทำการ "dump" ข้อมูลจาก Physical memory หรือ RAM ได้อีกด้วย จากภาพข้างบนเป็นการดึงข้อมูลจาก RAM บนระบบปฏิบัติการ Windows ซึ่งหากต้องการรันแบบ command line นั้นสามารถรันได้โดยใช้คำสั่ง

dd if=\\.\PhysicalMemory of=ram.img bs=4096 conv=noerror

if ย่อมาจาก input file ซึ่งหมายถึงว่าให้ dd ทำการอ่านข้อมูลจากอะไร หากเป็น RAM บนระบบปฏิบัติการ Windows เราจะใช้ \\.\PhysicalMemory ในขณะที่บนระบบปฏิบัติการ Linux นั้นจะเป็น /dev/mem

หมายเหตุ: \\.\PhysicalMemory สามารถใช้ได้ตั้งแต่ Windows 2000 จนถึง Windows 2003 Server SP0 แต่ Windows 2003 Server SP1 จนถึง Vista จะไม่สามารถใช้ dd อ่านได้เนื่องจากระบบปฏิบัติการรุ่นใหม่ไม่ยอมให้ dd ซึ่งเป็นโปรแกรมในระดับ user-mode สามารถเข้าถึง \\.\PhysicalMemory ได้ จะยอมให้เฉพาะระดับ kernel-mode เท่านั้นเช่น device-driver ที่สามารถเข้าถึงได้ แต่อย่างไรก็ตามผมได้พบว่าเค้าให้ไปอ่านที่ \\.\DebugMemory ซึ่งไว้จะตรวจสอบความถูกต้องอีกทีครับ

of ย่อมาจาก output file ซึ่งหมายถึงว่าให้ dd ทำการเขียนข้อมูลไปที่ใด ในที่นี้คือเขียนผลลัพธ์ไปที่ไฟล์ ram.img แต่อย่างไรก็ตามไม่แนะนำให้เขียนข้อมูลลงในในเครื่องที่ทำการตรวจสอบ เพราะอาจจะไปเขียนทับข้อมูลสำคัญที่ถูกลบไปแล้วในฮาร์ดดิสก์ได้ ซึ่งทางเลือกก็คือ

• เขียนข้อมูลลงไปใน external storage เช่น USB thumb drive หรือไม่ก็ external harddisk
• เขียนข้อมูลลงไปใน share ของคอมพิวเตอร์อีกเครื่องหนึ่ง
  

วิธีการแรกเป็นที่นิยมมากกว่าเนื่องจากระบบที่ทำการเก็บข้อมูลนั้นไม่ต้องเชื่อมต่อออกไปยังภายนอก ซึ่งส่งผลกระทบต่อสภาพแวดล้อมของระบบน้อยกว่าวิธีการที่สอง

bs ย่อมาจาก byte sector (ถ้าจำไม่ผิด) เป็นการบอกให้ dd ทำการอ่านและเขียนข้อมูลทีล่ะ 4096 byte

conv=noerror อันนี้ไม่รู้จะอธิบายยังไงดี สรุปใจความสั้นๆคือในกรณีที่ dd ทำการอ่านข้อมูลแล้วเกิดข้อผิดพลาดขึ้น ให้ dd ทำการอ่านข้อมูลต่อไปโดยที่ไม่ต้องหยุดการทำงาน

หลังจากทำการดึงข้อมูลจาก RAM ออกมาแ้ล้ว ควรทำการ hash ไฟล์ข้อมูลจาก RAM ทุกครั้งด้วย md5 หรือ SHA-1 ตามแต่สะดวก ในกรณีถ้าใช้ Helix มันจะทำการ hash ให้โดยอัตโนมัติครับ

SANS GIAC Certified Incident Handler (GCIH)

กลับมาอีกครั้งหลับจากห่างนานไปนานร่วม 2 -3 เดือน แหะๆ ที่หายไปไม่ใช่แอบไปจีบสาวที่ไหน แต่อ่านหนังสือสอบ certification ตัวนึงคือ GIAC GCIH นั่นเอง ซึ่งก็สามารถสอบผ่านได้ด้วยคะแนน 99 กับ 88 ตามลำดับ วันนี้ก็เลยจะมาโม้เรื่องเจ้า certification ตัวนี้สักหน่อยว่าคืออะไร

GIAC GCIH หรือ GIAC Certified Incident Handler เป็น certification ที่ออกมาเพื่อรับรองผู้ที่มีความสามารถในการทำ incident response (การรับมือกับเหตุการณ์บุกรุกระบบเครือข่ายคอมพิวเตอร์) ซึ่งในปัจจุบันนั้นเท่าที่รู้ GCIH ที่มีอยู่ประเทศไทยนั้นมีอยู่คนเดียว คือ ผมเอง :) (แก้ไขครับ พอดีไปค้นเจอมา ไม่ใช่คนแรกแล้วครับ อดเลย แหะๆ มีคนสอบได้ก่อนผมครับชื่อ Sekpon Juntapremjitt ครับ) แต่ถ้าหากนับ GIAC สาขาอื่นเข้าไปด้วยนั้น ในประเทศไทยจะมีอยู่ 5 คนคือ

• ปริญญา หอมเอกนก (GCFW - เกี่ยวกับไฟร์วอลล์)
• เรืองไกร รังสิพล (GCIA - เกี่ยวกับการวิเคราะห์การบุกรุก)
• วิริยะ อุปัติศฤงค์ (GCIA - เกี่ยวกับการวิเคราะห์หารบุกรุก)
• Sekpon Juntapremjitt (GCIH)
• ผมเอง (GCIH)

Certification ของ GIAC นั้นจะมีอายุอยู่ได้ 4 ปี หลังจากนั้นจะต้องสอบใหม่ หากคนที่เคยได้ certification ของ GIAC ไม่ยอมทำการต่ออายุ status ของคนที่ถือใบ certification ตัวนี้จะขึ้นว่า Expired ครับ ดังนั้นถ้าเจอใครที่อ้างว่าเป็น GIAC หรือเห็นหน้าเก่าๆที่บอกว่าเป็น GIAC แล้วไม่แน่ใจว่ายังหมดอายุแล้วหรือยังสามารถตรวจสอบได้ที่ http://www2.giac.org/certified_professionals/ ครับ เข้าไปตามสาขาแล้วทำการ search ด้วยชื่อได้เลยครับ "อย่าให้ใครมาหลอกคุณ"

อ๊ะ.... ลืมบอกไป ชื่อของผมยังไม่ขึ้นครับเพราะเพิ่งสอบเสร็จไปเมื่อวาน (29 ตุลาคม 2550) แหะ

สำหรับเนื้อหาที่สอบสำหรับ GCIH ก็ตามนี้เลยครับ http://www2.giac.org/certbulletin/gcih.php
อ่านมันเข้าไป ถ้าแน่ใจว่าความรู้แน่นพอก็อ่านเองเลยครับ เพราะผมก็อ่านเองแล้วไปสอบเหมือนกัน เพราะว่าค่าติวของที่นี่แพงมากครับ 2000$ กว่าเหรียญ ตกแล้วก็แสนกว่าบาทครับ ยังไม่รวมค่าสอบอีก 399$ ส่วนผมเลือกวิธีการสอบแบบ challenge ครับ จะเสียค่าสอบ 899$ เหรียญโดยจะแถมตัวอย่างข้อสอบมาให้สองชุดครับ ก็ทำกันเข้าไป แต่ว่าไม่ว่าจะสอบแบบธรรมดาหรือสอบแบบ challenge จะมีกฏหนึ่งที่เหมือนกันคือต้องสอบให้เสร็จภายใน 4 เดือนนับตั้งแต่สมัครครับ สนามสอบก็สบายๆ เป็นการสอบแบบ online ครับ ที่ไหนก็ได้ขอเพียงมี internet ที่ไม่หลุดบ่อยๆก็พอ แต่ว่าตั้งแต่วันที่ 1 ธันวาคม 2550 เป็นต้นไปจะมีการเปลี่ยนแปลงกฏครับ คือจะต้องไปสอบตามสนามสอบที่ระบุไว้ ซึ่งในปัจจุบันยังไม่มีสนามสอบในเมืองไทย... แต่จากการสอบถามคาดว่าน่าจะมีในอนาคตอันใกล้ครับ

การสอบนั้นจะแบ่งออกเป็นสอบ 2 ครั้ง แต่ละครั้งมี 75 ข้อ/เวลา 2 ชั่วโมง เนื้อหาคนละส่วนกัน ต้องทำคะแนนให้ได้มากกว่า 70% ขึ้นไปทั้ง 2 ครั้งถึงจะผ่าน ตอนผมสอบนี่ part 1 นี่ค่อยข้างง่ายครับ แต่เจอ part 2 นี่ค่อนข้างเขี้ยวพอตัวเลย โชคไม่ดีเจอ random ข้อยากๆมาก แต้มเลย drop อย่างที่เห็น

เมื่อสอบแบบ choice เสร็จแล้ว ถ้าผ่านได้ certification แบบ Silver ครับ ซึ่งถือเป็นระดับต่ำ (ผมก็อยู่ในระดับ Silver ครับ) ถ้าใครอยากอัพเกรดตัวเองก็สามารถทำได้โดย การสอบ paper ครับแล้วจะได้เลื่อนขั้นเป็นระดับ Gold (ผมวางแผนไว้ว่าจะสอบ Gold ในปีหน้าครับ)

โม้เสร็จแล้ว ไปก่อนล่ะ ครั้งหน้าคงเป็นอะไรที่มีสาระมากขึ้นครับ แหะๆ

หมดยุคของ vmware สำหรับการวิเคราะห์ malware

หากกล่าวถึง vmware หลายๆคนก็คงเคยเล่นกัน โดยเฉพาะพวกที่ชอบเล่นกับ malware หรือไม่ก็ exploit เพราะเนื่องจากเจ้า vmware นี่แหละ ที่ช่วยให้เราสามารถรันระบบปฏิบัติการหลายๆระบบ พร้อมกันไปในเครื่องคอมพิวเตอร์เพียงเครื่องเดียว ทำให้เราไม่ต้องหาเครื่องคอมพิวเตอร์อีกเครื่องเพื่อสร้างขึ้นมาเป็น test-based แต่ใช้เครื่องของเราเนี่ยแหละทำเป็น test-based ได้ไปในตัวได้เลย :)

ด้วยเหตุนี้ vmware จึงเหมาะสำหรับนำมาวิเคราะห์ malware เพราะการวิเคราะห์ malware นั้น นอกจากจะต้องวิเคราะห์แบบ static คือการวิเคราะห์โค้ดที่เขียนขึ้น (ผ่านทาง reverse engineering) ยังต้องวิเคราะห์แบบ dynamic คือการวิเคราะห์การทำงานจริง โดย vmware มักถูกนำมาใช้สำหรับการวิเคราะห์แบบ dynamic กล่าวคือทำการรันบน malware บนระบบปฏิบัติการที่สร้างขึ้นจาก vmware แล้วดูลักษณะการทำงานของ malware เนื่องด้วยระบบปฏิบัติการที่รัน malware เป็นระบบปฏิบัติการที่สร้างขึ้นบน vmware ดังนั้นนักวิเคราะห์มัลแวร์จึงไม่ต้องกังวลในกรณีที่ malware จะอันตรายกับระบบปฏิบัติการของตัวเอง

แต่ตอนนี้แนวทางการวิเคราะห์ใมัลแวร์ดังกล่าวทำท่าว่าจะมีปัญหาซะแล้ว เนื่องจากนาย Kato Ken นักวิจัยด้านความปลอยภัยคอมพิวเตอร์ชาวญี่ปุ่น ได้ค้นพบวิธีการตรวจสอบว่าระบบปฏิบัติการที่รันอยู่นั้นเป็นระบบที่อยู่บน vmware หรือไม่ โดยใช้ภาษา assembly ไม่เพียงกี่บรรทัดเท่านั้น ถ้าสนใจสามารถอ่านเพิ่มเติมได้ที่นี่ครับ

เนื่องจากผมไม่ค่อยมีเวลามาก (ทั้งๆที่แค่ใส่ inline assembly ลงไปในโค้ดไม่กี่บรรทัด แหะๆ) ดังนั้นก็เลยพยายามหาโค้ดสำเร็จรูปสำหรับการทดสอบที่มีชาวบ้านเขียนไว้แล้ว ซึ่งก็ได้พบกับ VmDetect ซึ่งพัฒนาโดย lallous ซึ่งโค้ดของหมอนี่นอกจากจะสามารถตรวจสอบ vmware ได้แล้ว ยังสามารถตรวจสอบ Microsoft Virtual PC ได้ด้วย

นี่เป็นภาพที่ทำการรัน VmDetect บนระบบปฏิบัติการธรรมดาครับ



ส่วนนี่ก็เป็นภาพที่รัน VmDetect บนระบบปฏิบัติการที่อยู่บน vmware



แล้วมันสำคัญยังไง ? มันสำคัญตรงที่ว่านักพัฒนา malware สามารถใช้ความรู้ตรงจุดนี้เพิ่มความสามารถให้กับ malware เพื่อให้ทำการตรวจสอบว่าตัว malware เองรันอยู่บน vmware หรือไม่ หากรันอยู่บน vmware ตัว malware เองจะไม่ทำงาน หรืออาจะสั่งให้ทำลายระบบปฏิบัติการบน vmware เลยก็ได้... evil ครับ evil

pulsing zombie

zombie ในเชิงของ computer security หมายถึงเครื่องคอมพิวเตอร์ที่ถูกแฮกและถูกนำมาใช้เป็นเครื่องมือเพื่อกระทำสิ่งต่างๆตามที่ผู้บุกรุกต้องการ ไม่ว่าจะเป็นทำการสแกนเครื่องของชาวบ้านเค้า โจมตี DoS (Denial of Service) หรือ DDoS (Distributed Denial of Service) เพื่อทำให้ระบบเครื่อข่ายหรือเซิร์ฟเวอร์เป้าหมายไม่สามารถใช้งานได้อย่างปกติ ด้วยลักษณะของการที่เครื่องคอมพิวเตอร์ที่ถูกแฮค (ตายไปแล้ว) และได้ถูกใช้มาทำการโจมตีระบบอื่นๆอย่างบ้าคลั่ง (ถูกปลุกขึ้นมาและอะละวาด) ทำให้เป็นที่มาของคำว่า zombie นั่นเอง

แต่วันนี้ผมจะไม่กล่าวถึง zombie เพราะรู้สึกว่าก็น่าจะรู้จักกันมาพอสมควรแล้ว แต่ที่จะกล่าวในวันนี้จะเป็นรูปแบบหนึ่งที่พัฒนาขึ้นจาก zombie แบบธรรมดา โดยจุดประสงค์ของมันเพื่อหลีกเลี่ยงการตรวจสอบของผู้ดูแลระบบ และถึงแม้สามารถตรวจพบก็ไม่สามารถมั่นใจได้ว่าเป็น zombie หรือไม่ ชื่อของมันคือ pulsing zombie

pulsing zombie คือ zombie ประเภทหนึ่ง เป็นเครื่องคอมพิวเตอร์ที่ถูกแฮกและถูกนำมาใช้เพื่อทำการโจมตีระบบอื่นเช่นเดียวกับ zombie แบบธรรมดา แต่อย่างไรก็ตามข้อแตกต่างระหว่าง pulsing zombie และ zombie แบบธรรมดาก็คือ pulsing zombie จะไม่โจมตีเป้าหมายอย่าง "บ้าคลั่ง" (จำนวนมาก/เวลาน้อย) แต่จะโจมตีเหยื่ออย่าช้าๆ ค่อยเป็นค่อยไป (จำนวนปกติ/เวลานาน) ด้วยเหตุนี้เองทำให้มีความยากลำบากในการตรวจสอบ pulsing zombie มากกว่า zombie แบบธรรมดา เพราะลักษณะการโจมตีจะเหมือนการใช้งานธรรมดาของผู้ใช้นั่นเอง

โดยปกติแล้ว pulsing zombie มักถูกนำมาใช้เพื่อทำการ slow-down เป้าหมายมากกว่าการ shutdown เป้าหมาย หรือเรียกอีกอย่างหนึ่งว่า Degradation of Service ซึ่งเป็นรูปแบบหนึ่งของ DoS นั่นเอง (ตัวย่อ DoS เหมือนกันด้วย เฮ่อๆ)

แล้วทำไมถึงใช้คำว่า "pulsing" ? คำนี้ๆสามารถแปลได้ว่า ลักษณะของบางสิ่งบางอย่างที่มีการเต้นขึ้น-ลง เหมือนกับคลื่นหัวใจ ซึ่งก็ถูกนำมาใช้กับเจ้า zombie รูปแบบนี้ที่คล้ายๆกับคนที่ยังมีชีวิตอยู่นั่นเอง (แต่ที่จริงมันก็ตายไปแล้วนั่นแหละนะ) :)