[12647] in bugtraq

home help back first fref pref prev next nref lref last post

Re: hard-coded windows exploits

daemon@ATHENA.MIT.EDU (dark spyrit)
Thu Nov 18 13:02:30 1999

Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-Id:  <Pine.LNX.3.96.991118185552.678A-100000@attica.gen.nz>
Date:         Thu, 18 Nov 1999 18:56:18 +1300
Reply-To: dark spyrit <dspyrit@BEAVUH.ORG>
From: dark spyrit <dspyrit@BEAVUH.ORG>
X-To:         bugtraq@securityfocus.com
To: BUGTRAQ@SECURITYFOCUS.COM

On Tue, 16 Nov 1999, Jeremy Kothe wrote:

> Just a general note concerning Windows overflows - most (if not all) of the
> publicly available exploits I have seen floating around are still using
> hard-coded addresses for system calls.
>
> I thought people might want to know that it is possible (and, indeed quite
> easy) to get the addresses of system functions in a system independant way.
>
> The technique is simple - all windows processes are launched (called) from
> Kernel32.dll originally, so at the TOP of the stack (give or take a DWORD,
> depending on launch environment) there is a pointer to code inside
> kernel32.dll.
>
> Given that the top of the stack is stored at fs:4, it is easy to scan from
> the top of the stack, looking for kernel32.dll's pe header.
>
> Using an SEH block to skip over incorrect addresses on the stack, we
> can locate and lookup whatever functions we want from Kernel32 (and from
> there to any other .dll)

Most of the time, as you will be targetting a specific version of a
program - it simply isn't worth the effort. Using static links
to GetProcAddress and LoadLibrary of the targets executable saves you the
trouble and the extra bytes.

I have used a similar technique once while doing a penetration test.
The system was using a vulnerable cgi, unfortunately the cgi had multiple
versions - and no hint was given to what version the remote system was
running.
In this case, the technique is a good one.. because you can afford to 'hit
and miss' - only having to supply different RET addresses and some slight
buffer manipulation definitely saves time and hassle.

I may release that particular exploit to demonstrate the technique used..
I think the reason there haven't been any made publicly available is a
good 3/4 of the time there just isn't a lot of point making use of the
method.

Cheers,

dark spyrit
http://www.beavuh.org - bend over and pray.

home help back first fref pref prev next nref lref last post