Software vulnerability analysis skills

During routine analysis of software vulnerabilities, it often takes a long period of analysis time, namely, hours, days, or even longer. Therefore, it is necessary to summarize some analysis skills. Different analysis ideas and skills are adopted for different vulnerability types, which can effectively improve the analysis speed. For some popular 0-day vulnerabilities, there are usually analysis articles on the Internet, but they are generally "conclusive analysis", that is, directly post vulnerability code to identify errors, instead of "thinking analysis ". If you often analyze vulnerabilities, you will find that the time used for your analysis is often not to analyze the vulnerability code, but to locate the vulnerability code. Therefore, debugging and analysis of vulnerabilities sometimes mean that the breakpoint is not accurate. In addition, you can guess with some guesses, and finally analyze the vulnerability code. If you are familiar with assembly instructions, this is not a problem.

 

Below are some tips I have summarized on several instance vulnerabilities I have analyzed in the past. However, there are a lot of skills and limited space. Here we only list some common methods. You are also welcome to share some of your analysis skills.
 

Tip 1: Quickly locate the IE class member functions called by JS Code
 

CVE-2011-0027 Microsoft Data Access Component integer overflow vulnerability is Pwn2Own 2010 hacker competition was used to break the IE8 browser vulnerability, the key vulnerability trigger code is as follows:
 

Localxmlid1 = document. getElementById ('xml1 '). recordset; // obtain the xml Element xmlid1 recordset, that is, the database table record set localxm1_1.cachesize = 0x40000358; // set the number of records that can be saved. This value eventually causes Integer Overflow

Now we will introduce a method for quickly locating the IE member functions called by the above two lines of code. First, we will use IDA to load the vulnerability file msado15.dll and allow loading the Microsoft symbol table, select the "Function name" column, press the "Alt + T" shortcut key to pop up the search box, and enter the keyword "cachesize ":



 

Press Ctrl + T to continue searching for the next one and find two related functions:



 

Based on the function name, the following function may be used to set and obtain the attribute value of cachesize:
 

CRecordset::put_CacheSize(long *) CRocordset::get_CacheSize(long) 

The CacheSize value 0x40000358 set in CRecordset: Secret indicates that CRecordset: put_CacheSize is indeed a function for setting the CacheSize value:
 

0:005> gBreakpoint 1 hiteax=40000358 ebx=04bdcfd8 ecx=6e61d340 edx=00000000 esi=01fbf144 edi=00000000eip=6e6ac957 esp=01fbeb58 ebp=01fbf040 iopl=0         nv up ei pl zr na pe nccs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000246msado15!CRecordset::put_CacheSize:6e6ac957 8bff            mov     edi,edi0:005> dd esp01fbeb58  6e62f3ec 04bdcfd8 40000358 0000000001fbeb68  01fbf074 04bdcfd8 11000011 0000000001fbeb78  03570ae8 004ad070 00538a30 0000008801fbeb88  00470000 00000002 03570760 01fbec8401fbeb98  76fc3193 00470138 76fc316f 764736b801fbeba8  00000000 00470000 03570768 00518a7801fbebb8  004767b8 004768e4 00559258 00476db801fbebc8  76f8d74d 0051d968 00472a98 01fbedc0

Localxm1_1.cachesize = 0x40000358 the JS Code that sets CacheSize in this line calls the CRecordset: put_CacheSize function. Using similar methods, it is easy to confirm that document. getElementById ('xmlid1 '). recordset calls the CGenericElement: get_recordset function. You can try it yourself.
 

Tip 2: Quickly locate heap vulnerability code through page heap
 

Page Heap is a debugging support function introduced by windows 2000, or DPH (Debug Page Heap). When this mechanism is enabled, the Heap manager adds a fence Page dedicated to detecting overflow after the Heap block, an exception is immediately triggered when a data overflow occurs on a fence page. This is often the most timely trigger of a vulnerability. It is not only applicable to heap overflow, but also to other types of heap vulnerabilities.
 

Take the CVE-2013-0077 Microsoft DirectShow heap overflow vulnerability as an example, use the following command to enable the page heap (gflags ):

Gflags.exe-I player.exe + hpa
 

After the page heap hpa is enabled and the operation is re-appended, the data is broken when it is copied to the heap boundary:
 

(4b8.358): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=000000c3 ebx=003fac98 ecx=00000003 edx=000000f7 esi=001bbdd4 edi=003fb000 eip=7d0706d0 esp=02a5f650 ebp=02a5f658 iopl=0 nv up ei pl nz na po nc cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00010202 quartz!ParseSequenceHeader+0x114: 7d0706d0 f3a5 rep movs dword ptr es:[edi],dword ptr [esi] 

The above is the command that causes overflow due to data interruption. By analyzing the function, it is easy to locate the vulnerability code. If page heap is not enabled and debugging is performed by default, the following commands are disconnected:
 

(4c8.6bc): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=41414141 ebx=003f0000 ecx=41414141 edx=03128e40 esi=03128e38 edi=00000012 eip=7c930efe esp=0465f998 ebp=0465fbb8 iopl=0 nv up ei pl zr na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010246 ntdll!RtlAllocateHeap+0x653: 7c930efe 8b39 mov edi,dword ptr [ecx] ds:0023:41414141=???????? 

This is the memory read exception caused by heap overflow. It is no longer the original scenario when the vulnerability is triggered. Therefore, after page heap is enabled, it is easier for you to locate the vulnerability code.

 

Tip 3: locate the Integer Overflow Vulnerability code based on heap allocation records

 

Take CVE-2011-0027 Microsoft Data Access Component integer overflow vulnerability as an example, this vulnerability is in Pwn2Own 2010 hacker competition, Dutch hacker Peter Vreugdenhil using it to break windows 7 IE8 browser.

The following is an exception after logging on to poc.html:

(7b8.278): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=0000036b ebx=0000035b ecx=00000000 edx=00000001 esi=088c8000 edi=00000000 eip=6887746f esp=044dee84 ebp=044dee88 iopl=0 nv up ei pl nz na po nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010202 mshtml!CImpIRowset::HRowNumber2HROWQuiet+0x23: 6887746f 8906 mov dword ptr [esi],eax ds:0023:088c8000=???????? 0:005> !heap -p -a 088c8000 address 088c8000 found in _DPH_HEAP_ROOT @ 8821000 in busy allocation ( DPH_HEAP_BLOCK: UserAddr UserSize - VirtAddr VirtSize) 88227ec: 88c7298 d64 - 88c7000 2000 72eb8e89 verifier!AVrfDebugPageHeapAllocate+0x00000229 77034ea6 ntdll!RtlDebugAllocateHeap+0x00000030 76ff7d96 ntdll!RtlpAllocateHeap+0x000000c4 76fc34ca ntdll!RtlAllocateHeap+0x0000023a 730d975d MSDART!MpHeapAlloc+0x00000029 6e5406e7 msado15!CRecordGroup::AllocateHRowRange+0x00000085 6e540650 msado15!CRecordset::PrepareForFetch+0x000000e2 6e5d44ae msado15!CRecordset::MoveAbsolute+0x000003e3 6e5680a5 msado15!CRecordset::_MoveFirst+0x0000007d 6e5d7957 msado15!CRecordset::MoveFirst+0x00000221 6e54fde6 msado15!CRecordset::Invoke+0x00001560 71dcdb38 jscript!IDispatchInvoke2+0x000000f0 71dcda8c jscript!IDispatchInvoke+0x0000006a 71dcd9ff jscript!InvokeDispatch+0x000000a9 71dcdb8a jscript!VAR::InvokeByName+0x00000093 71dcd8c8 jscript!VAR::InvokeDispName+0x0000007d 71dcd96f jscript!VAR::InvokeByDispID+0x000000ce 71dce3e7 jscript!CScriptRuntime::Run+0x00002b80 71dc5c9d jscript!ScrFncObj::CallWithFrameOnStack+0x000000ce 71dc5bfb jscript!ScrFncObj::Call+0x0000008d 71dc5e11 jscript!CSession::Execute+0x0000015f 71dbf3ee jscript!NameTbl::InvokeDef+0x000001b5 71dbea2e jscript!NameTbl::InvokeEx+0x0000012c 71db96de jscript!NameTbl::Invoke+0x00000070 685aaa7b mshtml!CWindow::ExecuteTimeoutScript+0x00000087 685aab66 mshtml!CWindow::FireTimeOut+0x000000b6 685d6af7 mshtml!CStackPtrAry<unsigned long,12>::GetStackSize+0x000000b6 685d1e57 mshtml!GlobalWndProc+0x00000183 770e86ef USER32!InternalCallWinProc+0x00000023 770e8876 USER32!UserCallWinProcCheckWow+0x0000014b 770e89b5 USER32!DispatchMessageWorker+0x0000035e 770e8e9c USER32!DispatchMessageW+0x0000000f 

Based on the exception information above, we can know that the program will cause a heap overflow when writing data to the heap block with the address 0x88c7298 and the size of 0xd64. Repeat! Stack tracing information returned by the heap command can be seen that the overflow heap block is allocated by calling the MpHeapAlloc function in the CRecordset: MoveFirst function. The upper-layer function that calls the allocation function is CRecordGroup :: allocateHRowRange, Which is disconnected from this function. After following up:
 

Breakpoint 0 hit eax = 00000001 ebx = 40000358 ecx = 76fc0000f edx = 096f2d34 esi = 09759d70 edi = 40000358 eip = 69da06be esp = 0446 eeec ebp = 0446eef8 iopl = 0 nv up pl zr na pe nc cs = 001b ss = 0023 ds = 0023 es = 0023 fs = 003b gs = 0000 efl = 00000246 msado15! CRecordGroup: AllocateHRowRange + 0x5e: 69da06be 85ff test edi, edi 0: 005> p eax = 00000001 ebx = 40000358 ecx = 76fc0000f edx = 096f2d34 esi = 09759d70 edi = 40000358 eip = 69da06c0 esp = 0446 eeec ebp = 0446eef8 iopl = 0 nv up pl ei nz na po nc cs = 001b ss = 0023 ds = 0023 es = 0023 fs = 003b gs = 0000 efl = 00000202 msado15! CRecordGroup: AllocateHRowRange + 0x60: 69da06c0 0f8e34213200 jle msado15! CRecordGroup: AllocateHRowRange + 0x62 (69dc3efa) [br = 0] 0: 005> p eax = 00000001 ebx = 40000358 ecx = 76fc0000f edx = 096f2d34 esi = 09759d70 edi = 40000358 eip = 69da06c6 esp = 0446 eeec ebp = 0446eef8 iopl = 0 nv up ei pl nz na po nc cs = 001b ss = 0023 ds = 0023 es = 0023 fs = 003b gs = 0000 efl = 00000202 msado15! CRecordGroup: AllocateHRowRange + 0x64: 69da06c6 8bc7 mov eax, edi // eax = edi = 0x40000358, that is, CacheSize 0: 005> p eax = 40000358 ebx = 40000358 ecx = 76fc0000f edx = 096f2d34 esi = 09759d70 edi = 40000358 eip = 69da06c8 esp = 0446 eeec ebp = 0446eef8 iopl = 0 nv up nz na po nc cs = 001b ss = 0023 ds = 0023 es = 0023 fs = 003b gs = 0000 efl = 00000202 msado15! CRecordGroup: AllocateHRowRange + 0x66: 69da06c8 8b3dfc10d969 mov edi, dword ptr [msado15! _ Imp _ MpHeapAlloc (69d910fc)] ds: 0023: 69d910fc = {MSDART! MpHeapAlloc (72de9730 )} 0: 005> p eax = 40000358 ebx = 40000358 ecx = 76fc0000f edx = 096f2d34 esi = 109edi = 72de9730 eip = 69da06ce esp = 0446 eeec ebp = 0446eef8 iopl = 0 nv up ei pl nz na po nc cs = 001b ss = 0023 ds = 0023 es = 0023 fs = 003b gs = 0000 efl = 00000202 msado15! CRecordGroup: AllocateHRowRange + 0x6c: 69da06ce 89460c mov dword ptr [esi + 0Ch], eax ds: 0023: latency = 00000000> p eax = 40000358 ebx = 40000358 ecx = 76fc0000f edx = 096f2d34 esi = 09759d70 edi = 72de9730 eip = 69da06d1 esp = 0446 eeec ebp = 0446eef8 iopl = 0 nv up pl nz na po nc cs = 001b ss = 0023 ds = 0023 es = 0023 fs = 003b gs = 0000 efl = 00000202 msado15! CRecordGroup: AllocateHRowRange + 0x6f: 69da06d1 8b0d10f0e569 mov ecx, dword ptr [msado15! G_hHeapHandle (69e5f010)] ds: 0023: latency = 0: 005> p eax = 40000358 ebx = 40000358 ecx = 096f0000 edx = 096f2d34 esi = 09759d70 edi = 72de9730 eip = 69da06d7 esp = 0446 eeec ebp = 0446eef8 iopl = 0 nv up ei pl nz na po nc cs = 001b ss = 0023 ds = 0023 es = 0023 fs = 003b gs = 0000 efl = 00000202 msado15! CRecordGroup: AllocateHRowRange + 0x75: 69da06d7 8d048504000000 lea eax, [eax * 4 + 4] // allocated heap block size = 0x40000358*4 + 4 = 0xd64, here, the maximum value of eax is 0 xffffff. After eax * 4 + 4 is changed to 0x100000D64> 0xFFFFFFFF, the integer overflow is caused, and the result overflow is equal to 0xD64. If we set the CacheSize to 0x3FFFFFFF, the heap block allocated later is 0. 0: 005> p eax = 00000d64 ebx = 40000358 ecx = 096f0000 edx = esi = 09759d70 edi = 72de9730 eip = 69da06de esp = 0446 eeec ebp = 0446eef8 iopl = 0 nv up ei pl nz na po nc cs = 001b ss = 0023 ds = 0023 es = 0023 fs = 003b gs = 0000 efl = 00000202 msado15! CRecordGroup: AllocateHRowRange + 0x7c: 69da06de 50 push eax // heap block size = 0xd64 0005> p eax = 00000d64 ebx = 40000358 ecx = 109edx = 096f2d34 esi = 09759d70 edi = 72de9730 eip = 69da06df esp = 0446eee8 ebp = 0446eef8 iopl = 0 nv up ei pl nz na po nc cs = 001b ss = 0023 ds = 0023 es = 0023 fs = 003b gs = 0000 efl = 00000202 msado15! CRecordGroup: AllocateHRowRange + 0x7d: 69da06df 68347a000 push limit 0: 005> p eax = 00000d64 ebx = 40000358 ecx = 108edx = esi = 09759d70 edi = 72de9730 eip = 69da06e4 esp = 0446eee4 ee4 BP = 0446eef8 iopl = 0 nv up ei pl nz na po nc cs = 001b ss = 0023 ds = 0023 es = 0023 fs = 003b gs = 0000 efl = 00000202 msado15! CRecordGroup: AllocateHRowRange + 0x82: 69da06e4 51 push ecx 0: 005> p eax = 00000d64 ebx = 40000358 ecx = 096f0000 edx = esi = 72edi = 72de9730 eip = 69da06e5 esp = %ebp = 0446eef8 iopl = 0 nv pl nz na po nc cs = 001b ss = 0023 ds = 0023 es = 0023 fs = 003b gs = 0000 efl = 00000202 msado15! CRecordGroup: AllocateHRowRange + 0x83: 69da06e5 ffd7 call edi {MSDART! MpHeapAlloc (72de9730 )}

 

This vulnerability is caused by an integer overflow caused by CacheSize * 4 + 4 because the CacheSize integer value is not effectively determined, when CacheSize * 4 + 4 is used as the size of heap block allocation, a heap overflow occurs because the size of the heap block is too small.
 

Tip 4: Vulnerability Analysis Based on resumable recording

 

Taking the CVE-2012-0774 Adobe Reader TrueType font integer overflow vulnerability as an example, this vulnerability is mainly caused by overflow caused by parsing the virtual commands in the TTF font, in order to determine which virtual commands cause overflow, you can set the condition record breakpoint.

After the poc is enabled to trigger a crash, the vulnerability function is located through stack backtracking, marked as VulFunction, which is used to index virtual instruction processing functions.

 

Use the shortcut key Shift + F4 to record the breakpoint under VulFunction, and record the corresponding virtual instruction index number for each VulFunction call.

 

View the log window after the supervisor is running:

The index number of the virtual commands that cause the vulnerability is 0x26.

 

Tip 5: Vulnerability Analysis Based on JS logs

 

Sometimes, when debugging the IE vulnerability, We need to execute the JS Code in the sample, by adding some mathematical functions, such as math. atan2, math. asin and so on, you can also use other functions, and then through the jscript! Js: Math: Atan (or other functions) breakpoint to output log, so that analysts can observe the execution. For example, the poc contains the following js, where math. atan2 is added:

Math.atan2(0xbabe, "[*] Creating object button..."); var obj = document.createElement("button"); Math.atan2(0xbabe, "[*] Assigning data to title..."); obj.title = data.substring(0,0x40000-0x58); Math.atan2(0xbabe, "[*] Let's AppendChild"); div_container.appendChild(obj); 

Set the following breakpoint:

bu jscript!JsAtan2 ".printf \"%mu\", poi(poi(poi(esp+14)+8)+8);.echo;g"

 

The output window on windbg will be displayed after running:

[*] Creating object button... [*] Assigning data to title... [*] Let's AppendChild 

 

Tip 6: Use a VM snapshot to fix the heap address

 

This method was first mentioned by instruder In the QQ group. During vulnerability analysis, especially in the case of heap vulnerabilities, the heap address allocated for each reload operation is fixed, whether it is analysis or document writing, it is not applicable to our analysis and description. Therefore, we can first debug an address that has been allocated to the heap, and then save it as a virtual machine snapshot. When we need to start debugging again, you can recover the previously saved snapshots to perform debugging again. In this case, the heap address and the previously analyzed address are fixed.

 

Tip 7: monitor heap allocation and release to analyze UAF and double free Vulnerabilities

 

Taking the analysis of a previously assigned libpng double free vulnerability as an example, the release function free is monitored and output records for analysis. Stack backtracking during program crash is as follows:

 

Re-load with windbg. by monitoring the heap block release process, we can find that it has released a heap block in double mode, first off:

bu 3440D279 ".if(1){.echo EnterVulnFunc;gc}" bu 6e264b6c ".if(1){.echo Free heap block; dd esp l4;gc}" 

 

Output result:

EnterVulnFuncFree heap block0011bc5c  3441e2a2 138f0020 3b906313 10027b64Free heap block0011bc5c  3441dc6c 138f0020 3b906313 10027b64(1508.e84): Access violation - code c0000005 (first chance)First chance exceptions are reported before any exception handling.This exception may be expected and handled.eax=138f0018 ebx=138f0020 ecx=6e287a7e edx=10028a70 esi=008a0000 edi=00000000eip=77691f88 esp=0011bbe8 ebp=0011bbf8 iopl=0         nv up ei pl zr na pe nccs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010246ntdll!RtlFreeHeap+0x3a:77691f88 80780705        cmp     byte ptr [eax+7],5         ds:0023:138f001f=??

 

It can be seen that the same heap block is released multiple times. UAF is the most common vulnerability analysis in IE. If you want to quickly create a uaf ie Object, you need to release the distribution of the object. This can be achieved through the debugger script, or, similar to the EXE tool written by h4ckmp Based on the Windbg interface, you can quickly analyze the objects that cause the UAF vulnerability, as shown in.

 

Tip 8: Analysis Method Based on stain tracking

 

The taint tracing theory is good, but the finished product is often not optimistic. Stain tracking is like a "one-stop attack". It is not only time-consuming and labor-consuming but also time-consuming to develop a stain tracking tool, running large tools usually takes a long time, such as IE, Adobe, and other software, and sometimes even takes a whole day. This is generally used when debugging and analysis is inconvenient, this vulnerability mainly targets file format vulnerabilities. In addition, you can use dynamic plug-in frameworks such as pin to develop dynamic analysis tools for specific function hooks, such as heap allocation and release functions, or use them for fast analysis.