Showing posts with label Exploits. Show all posts
Showing posts with label Exploits. Show all posts

Tuesday, June 5, 2007

Responsibility is Everyone's Job

The software developers constantly talk about responsible disclosure.

Responsible disclosure is basically defined as informing the software developer of a vulnerability so that the vulnerability can be researched and fixed. This is compared to full disclosure where the vulnerability is announced to everyone without giving the software developer a chance to fix the vulnerability. Contrast this with the economic pressure for a software developer to reveal a vulnerability, which is none.

The spectrum consists of Full Disclosure (tell everyone), Responsible Disclosure (tell the developer), and Non-Disclosure (tell no one). Without going into details suffice it to say the responsible disclosure is currently mainstream.

The question is how the developers handle fixing the vulnerability. The general thought is that a responsible company would put resources into fixing these as soon as possible, but these comercial developers are, for the most part are in business to make a profit. I am not including open source developers in this post.

Now for two examples of how Microsoft has handeled responsible disclosures.

The ANI exploit, which I wrote about in Vista Smista& ANI Exploit. The vulnerability was disclosed in December of 2006 and not fixed until exploits where released in March. An quote from my previous blog is below and more details are in my other post mentioned above:
In short this was disclosed to Microsoft in December of 2006. Apparently the first report of this vulnerability was used as an exploit was March 28th. Due to the wide spread use of the exploit several third parties released interim patches... Microsoft
reacted, as it tends to do when third party patches are released, and the news
media starts to publish... Microsoft released the official patch out-of-cycle on
Tuesday the 3rd of April (instead of today the 10th of April).

Just recently, the end of May 2007, a vulnerability in Microsoft Web Server IIS 5.X where authentication can be bypassed, was announced. However this vulnerability was discovered December 15th 2005 (no this is not a typo) and was subsiquently responsibly disclosed to Microsoft. Apparently Microsoft finally decide to publically disclose the vulnerability, but without a fix. Unless you consider paying for an upgrade to Windows Server 2003 and IIS 6.0 a patch.

Keeping in mind thath these are just two examples where:
  1. Microsoft failed to fix a known vulnerability for several months until an exploit was released.
  2. Kept a vulnerability secret for over a year and then releases the information and requires a paid upgrade to the latest code for a fix.

I think Microsoft should re-evaluate their responsibilities as a good citizen or netizen.

Thursday, May 31, 2007

When Google isn't Google: Google-analytics Compromised

It has been reported the the popular Google Analytics has been compromised. The details are in the ISC Diary Entry titled Google Counter ... isn't.

What this means to the average user is that any web site that uses Google Analytics, and there are more than a few that use this free service, will attempt to infect your computer.

Wat is the average user to do? Disable javascript and break most web sites? Which is almost like putting bars on your windows and refusing to leave the house.

Well it isn't a secret what I do I use Firefox and the noscript extension as my main defense against this. I normally leave anything not required for accessing a site, including Google Analytics, disabled. I was initially surprised by the number of javascripts attempting to run from sites I had not directly connected to. I would describe this as checking who a visitor is bringing with them when they want to visit my house.

sites that where used to See "Drive by What?" for my latest blog entry on the subject, or check here for all my references to noscript.

Monday, March 26, 2007

The Band-aid Approach

There was a comment posted asking why I was against the approach of shuffling buffers around in my post entitled Exploit Longevity (http://sec-soapbox.blogspot.com/2007/03/exploit-longevity.html).

Before I can answer I need to make sure that we have a common understanding of buffers and buffer overflows.

What is a Buffer?

A buffer is a portion of memory where a program stores information that changes. Every time a web site address is typed into a web browser the address is stored in a buffer.

What is a Buffer Overflow?

Buffers do not have an unlimited size, and that fact can be exploited. By providing too much information to the program and overflowing the buffer. When a buffer is overflowed one of two things happen the program crashes or runs what the perpetrator wants it to.

When the program crashes that is a Denial of Service (DoS) attack.

When the program executes what the attacker intended that is an exploit. For a little more meat, e.g. technical explanation. The attacker will usually uses a series of NoOp* instructions to create a "NoOp slide"before the exploit code. Once the program tries to execute the code that was after the buffer it will "slide down" the NoOps to the exploit.

Is Moving the Buffer a Cure?

Consider finding out that someone with the right tool, a "slim jim," can open your car door and steal the car. The manufacture sends has all the cars modified to move the "weak link" over 5 inches, but not protect it. Since everyone knows the fix it simply takes car thieves a short time to adjust and continue stealing cars.

Of course its different with software patches... Not.

For the exploiter the patch is simply the instruction manual for finding the new location of the buffer.

In essence this type of patch is a band-aid not a cure.

* A single byte machine code that performs no operations. Originally used to remove code from machine code with out having to rewrite major portions of the program.

What is a buffer overflow

What prevents a buffer overflow

Why moving a buffer isn't a fix

With securely written programs buffer overflows can't happen.

Tuesday, March 20, 2007

Exploit Longevity

Ever notice how some exploits just seem to stay around forever?

There is actually a simple, but in my opinion ugly, explanation for this. As usual an example can be worth a thousand words, and I’m going to use rpc18.c as an example:

//////////////////////////////////////////////////////
//
// Windows RPC DCOM Remote Exploit with 18 Targets
// by pHrail and smurfy + some offsets by teos
//
// Targets:
// 0 Win2k Polish nosp ver 5.00.2195
// 1 Win2k Polish +sp3 ver 5.00.2195
// 2 Win2k Spanish +sp4
// 3 Win2k English nosp 1
// 4 Win2k English nosp 2
// 5 Win2k English +sp1
// 6 Win2k English +sp2 1
// 7 Win2k English +sp2 2
// 8 Win2k English +sp3 1
// 9 Win2k English +sp3 2
// 10 Win2k English +sp4

// 11 Win2k China +sp3
// 12 Win2k China +sp4
// 13 Win2k German +sp3
// 14 Win2k Japanese +sp2
// 15 WinXP English nosp ver 5.1.2600
// 16 WinXP English +sp1 1
// 17 WinXP English +sp1 2
// 18 WinXP English +sp2

//
/////////////////////////////////////////////////////////

Notice targets 3-10 are all English versions of Windows 2000 and 16-18 are all Windows XP. Now each target has a different patch level so it must be exploiting the exact same issue, but wait there is more. The next section below shows the offset where the exploit is located.

The text on each line in quotes is the location where the exploit is located in the program. The troubling issue is that for each patch level the location has changed. In other words instead of fixing the problem with the patch the location of the vulnerability is moved, and obviously, as rpc18.c shows, this is not an effective method.

/* Myam add OFFSETS*/
char win2knosppl[] = "\x4d\x3f\xe3\x77"; /* polish win2k nosp ver 5.00.2195*/
char win2ksp3pl[] = "\x29\x2c\xe4\x77"; /* polish win2k sp3 - ver 5.00.2195 tested */
char win2ksp4sp[] = "\x13\x3b\xa5\x77"; /* spanish win2k sp4 */
char win2knospeng1[] = "\x74\x16\xe8\x77"; /* english win2k nosp 1 */
char win2knospeng2[] = "\x6d\x3f\xe3\x77"; /* english win2k nosp 2 */
char win2ksp1eng[] = "\xec\x29\xe8\x77"; /* english win2k sp1 */
char win2ksp2eng1[] = "\x2b\x49\xe2\x77"; /* english win2k sp2 1 */
char win2ksp2eng2[] = "\xb5\x24\xe8\x77"; /* english win2k sp2 2 */
char win2ksp3eng1[] = "\x7a\x36\xe8\x77"; /* english win2k sp3 1 */
char win2ksp3eng2[] = "\x5c\xfa\x2e\x77"; /* english win2k sp3 2 */
char win2ksp4eng[] = "\x9b\x2a\xf9\x77"; /* english win2k sp4 */
char win2ksp3chi[] = "\x44\x43\x42\x41"; /* china win2k sp3 */
char win2ksp4chi[] = "\x29\x4c\xdf\x77"; /* china win2k sp4 */
char win2ksp3ger[] = "\x7a\x88\x2e\x77"; /* german win2k sp3 */
char win2ksp2jap[] = "\x2b\x49\xdf\x77"; /* japanese win2k sp2 */
char winxpnospeng[] = "\xe3\xaf\xe9\x77"; /* english xp nosp ver 5.1.2600 */
char winxpsp1eng1[] = "\xba\x26\xe6\x77"; /* english xp sp1 1 */
char winxpsp1eng2[] = "\xdb\x37\xd7\x77"; /* english xp sp1 2 */
char winxpsp2eng[] = "\xbd\x73\x7d\x77"; /* english xp sp2 */