Friday, August 23, 2013

JackCR ISSA 2013 Netwars Challange - Memory Issues

ISSA 2013 Netwars Challange - Getting the memory image to work.


Introduction


Unlike @JackCR's previous challenges, this one is 1. from a Linux server, and 2. does not have a memory component. Well, that is not entirely accurate, there is a memory dump but it is not usable because of the way that vmss2core produces a file that is not useful for linux memory forensics. Long story short, Volatility can now read vmem (VMWare memory) and vmss (VMWare Snapshot) natively - don't use vmss2core anymore!

That said, there is a way to extract the memory image so that you can process it in volatility... once you have also created a profile!


A Word of Warning


Please note in this post I will use /path/to/image/ to represent the full path to where I hve mounted my evidence VMDK. You will need to change this to match your system if you want to replicate what I have done.


Converting the Memory Dump


After a quick bit of google-fu I was able to find a page [http://wiki.yobi.be/wiki/RAM_analysis] that described a process for extracting the memory image in RAW from the ELF64 format used by VirtualBox, and acting on the hunch that the ELF32 format would be functionally similar decided to try it out.

$ readelf --program-headers vmss.core

Elf file type is CORE (Core file)
Entry point 0x0
There are 2 program headers, starting at offset 52

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  NOTE           0x000074 0x00000000 0x00000000 0x00144 0x00000     0
  LOAD           0x001000 0x00000000 0x00000000 0x20000000 0x20000000 RWE


The line that we care about is LOAD. Based on this output we now know out RAW data is 0x20000000 long and begins at offset 0x001000. After a little bit of hex-dec conversion we can then use dd to export this section

$ dd if=vmss.core bs=4096 skip=1 count=131072 of=memdump.bin
131072+0 records in
131072+0 records out
536870912 bytes (537 MB) copied, 9.01116 s, 59.6 MB/s



Now we have our memory dump, we now need to determine what profile we need and to generate it as need. Luckily we have a partition image that should hopefully have the /boot and /usr/src/linux-headers-* directories on it, which we need to create the specific profile for this system

# mkdir /media/temp
# mount -t ext3 -o ro /path/to/image/issa-2013-challenge.sda1.dd /media/temp
# cd /media/temp
# ls
bin  boot  cdrom  dev  etc  home  initrd.img  lib  lost+found  media  mnt  opt  proc  root  sbin  selinux  srv  sys  tmp  usr  var  vmlinuz



Looking good :)

# cat etc/*-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=9.10
DISTRIB_CODENAME=karmic
DISTRIB_DESCRIPTION="Ubuntu 9.10"


Not so good, this is an OLD version of Ubuntu :(

# ls boot usr/src
boot:
abi-2.6.31-14-generic-pae     grub                              memtest86+.bin                    vmcoreinfo-2.6.31-14-generic-pae
config-2.6.31-14-generic-pae  initrd.img-2.6.31-14-generic-pae  System.map-2.6.31-14-generic-pae  vmlinuz-2.6.31-14-generic-pae

usr/src:
linux-headers-2.6.31-14  linux-headers-2.6.31-14-generic-pae


Excellent, we have what we need to compile a custom profile anyway. Step 1 - get the System.map and kernel headers from the target system. You can also get them from the distribution repository, but it is better to get them from the target itself for maximum compatability.

# mkdir /path/to/image/temp
# cp -r usr/src/linux* /path/to/image/temp/
# mkdir /path/to/image/temp/boot
# cp boot/System.map-2.6.31-14-generic-pae /path/to/image/temp/boot/


Now we change the the location we have volatility sources downloaded and compile the profile based on our new paths
These directions are based on the current SVN version as of 2013-08-23 and assume you have pre-installed dwarfdump (see [http://code.google.com/p/volatility/wiki/LinuxMemoryForensics#Prerequisites])

# cd /path/to/image/volatility-read-only/tools/linux/
# make -C /path/to/image/temp/linux-headers-2.6.31-14-generic-pae CONFIG_DEBUG_INFO=y M=/path/to/image/volatility-read-only/tools/linux/ modules
# dwarfdump -di module.ko > module.dwarf
# make -C /path/to/image/temp/linux-headers-2.6.31-14-generic-pae CONFIG_DEBUG_INFO=y M=/path/to/image/volatility-read-only/tools/linux/ clean
# cp module.dwarf /path/to/image/temp/
# cd /path/to/image/temp/
# zip Ubuntu910.zip module.dwarf boot/System.map-2.6.31-14-generic-pae
# mkdir /path/to/image/temp/plugins
# cp Ubuntu910.zip /path/to/image/temp/plugins/


And now for the moment of truth, does this profile load?

# cd /path/to/image/volatility-read-only
# python vol.py --plugins=/path/to/image/temp/plugins --info | grep Ubu
Volatile Systems Volatility Framework 2.3_beta
LinuxUbuntu910x86 - A Profile for Linux Ubuntu910 x86


Looking good so far....

# python vol.py --plugins=/path/to/image/temp/plugins -f /path/to/image/memdump.bin --profile=LinuxUbuntu910x86 linux_ifconfig
Volatile Systems Volatility Framework 2.3_beta
Interface        IP Address           MAC Address        Promiscous Mode
---------------- -------------------- ------------------ ---------------
lo               127.0.0.1            00:00:00:00:00:00  False         
eth0             172.16.150.20        00:0c:29:7d:72:4b  False  
  

Success!

No comments:

Post a Comment