Thursday, November 19, 2009

Another 0day on HP Power Manager

I have been working on this CVE-2009-2685/ZDI ( 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(

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. 

Tuesday, October 20, 2009

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.

Wednesday, July 22, 2009

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="">here</a>.

MyCERT released the <a href="">advisory</a> and workaround (yes, with pictures) on how to do the 'kill-bit' thing for this particular CLSID.

Wednesday, July 15, 2009

Conficker.C and DNS

I have been working to track conficker's dns queries in order to  identify infected machines/network with conficker.c. Tracking a 50K DNS names and 500++ queries from each conficker is a bit troublesome when u have to record all the DNS queries (200M records/day) and compare it with 50K/day conficker.c domain names.:).

The main idea of why we're working on this so that the infected machine can be identify based on queries made by conficker.c to contact to the conficker.c's c&amp;c.  Below is one of the result from our tracking on conficker.c dns query to .MY domains in the hitlist :

Another result for the tracker.

Looking at the trends from both pictures, its coming from the same source (see over geomap). Why?..:)

The tracker is basically is a ruby code build over dnsruby's and ruby-pcap library for collecting packets and processing the dns packets only. So far, the  tracker is working fine except if it receive malformed dns traffic which normally will be discarded by the tracker

Monday, March 30, 2009

Conficker: The other not so famous Variant A

There are lot more discussions are going on for Conficker variant C (ConfickerC) due to 1st April. Why 1st april?. The 1st april is the day ConfickerC should call home for updates. The domain name generator  algorithm  used by ConfickerC is making blocking or detecting live ConfickerC update servers is becoming harder when it will search for about 50K domains name.  . Please refer to SRI excellent  write-up for more information about ConfickerC here.  MyCERT advisory about ConfickerC is here.

I can’t say much about the current situation but based on my observation on dns traffic we have, we only observed low volume of traffics contacting ConfickerC domains name hosted in .my domain. Maybe because it wasn’t the time yet.(my timeframe of observation was on 27-29 March 09).

Compare to ConfickerA (variant A), I observed more traffics are looking for the domain name: is the server that will be contacted by ConfickerA. Take a look at ConfickerA file sample and we’ll see the domain name. It’s very disturbing to notice that variant A is still out there screaming for their C&C server while alot more discussion have been switching to ConfickerC.

....................SNIP ...............SNIP....................
....................SNIP ...............SNIP....................
Sat Mar 28 17:29:00 +0800 2009 - 202.XXX.YY.132 is looking for
Sat Mar 28 16:32:07 +0800 2009 - XXX.60.YY.229 is looking for
Sat Mar 28 15:29:41 +0800 2009 - 203.XXX.YY.85 is looking for
Sat Mar 28 15:46:26 +0800 2009 - 202.YY.56.XXX is looking for
Sat Mar 28 15:15:55 +0800 2009 - 202.XX.XX.229 is looking for
....................SNIP ...............SNIP....................
....................SNIP ...............SNIP....................

During the timframe ( 27-29 March 09), it is about 1167+ queries to DNS looking for the it’s still considered a big infection based on DNS traffics query only. Luckily the is no longer running. But, the infected machines is still need to be clean-up.

MyCERT already released advisory for ConfickerA and also mentioned about tools that can be used to remove the ConfickerA. The advisory is here. If you haven’t patch your MS08-67, please do so.