Another 0day on HP Power Manager

I have been working on this CVE-2009-2685/ZDI (http://www.zerodayinitiative.com/advisories/ZDI-09-081/) this afternoon and now managed to get the dummy shellcode (calc.exe) running.yey..:D

The bug was mentioned by ZDI at link provided, and as claimed by HP advisory, they already patch the bug(http://h20000.www2.hp.com/bizsupport/TechSupport/Document.jsp?objectID=c01905743).

Ironically, by using the same patch released by HP (4.9.2 - The latest one), i still managed to exploit the code. I guess, HP didn't really patch the bug. This is probably wild guess, but if we take a look at workaround, HP only recommending to limit the HP Power Manager Server access to trusted user/ip/network.

Exploiting this bug is trivial, though. Reading from any windows exploitation materials is enough. This standard/classic stack overflow for sprint bug. 

PPStream 0day

I just finished working on the PPStream exploit. The p0c to reproduce the bug was released at Milw0rm a few days go. By using the default exploit, we’ll notice that the bug is related to heap corruption instead just typical stack overflow on ActiveX. In stack overflow on ActiveX app, we can just simply heap spray the browser and overwrite SEH to get control of EIP and jump to heap to get to our shellcode. But, since this is heap overflow, overwriting SEH pointer is not possible due SEH pointer is located inside a stack frame instead of heap frame. On this particular exploitation, we need to rely on heap exploitation to get control of EIP.

After further analysis on the bug, i noticed that the param ofBackImage is the key to get heap overflow occur. So i made a little bit changes on p0c and start debugging on the p0c again. Since the key point of heap exploitation is to get control when heap is doing coalesce we need to get this assembly code (this is when heap is doing coalesce,we can have arbitrary overwrite if we can overflow the next/prev chunk) :

move dword ptr [eax],ecx ds:0023:41414141=?????

Since my target machine is running on XP SP1, i still can use arbitrary overwrite [WHERE] to VEH pointer. And to get reliable value on my shellcode location [WHAT], i’m using heap spray to place my shellcode. Below are the screenshot of the calc.exe got executed when vulnerable PPSTream (V2.6.86.8900) open the exploit page (via IE browser) (I promised i wont used Heap Spray technique ;)).

I apologize for very brief/basic information on this bug and also not releasing the exploit code. The reason is due to the current PPStream is not yet have a patch (during this blog post writing). I hope that one fine day i can publish this simple exploitation dev article.

Another IE 0-day

Another 0-day was released in-the-wild targeting Microsoft Internet Explorer. The bug is inside msvidctl.dll when working with media file (*.gif have been used in the wild exploitation). Below is the in-the-wild exploit analyzed by us (we modified the shellcode to %uxcccc).

Figure 1.0 showed the exception handler is executed and will pointing to our jump address (0c0c0c0c).

Figure 2.0 show the shellcode (xcc) been executed.

It's not really a common stack overflow bug. Please read excellent  vulnerability analysis done by websense <a href="http://securitylabs.websense.com/content/Blogs/3434.aspx">here</a>.

MyCERT released the <a href="http://www.mycert.org.my/en/services/advisories/mycert/2009/main/detail/677/index.html">advisory</a> and workaround (yes, with pictures) on how to do the 'kill-bit' thing for this particular CLSID.