Thanks,
Ok I get your point. And now back to the stuff.. ->
I had some time to play with it again. And with some help from eeye's pages
I got it right on a win2k sp2 iis5.0. Exploit code attached. Search for the
text ->
<-- snip -->
ÌÌÌÌYOURBADASSCODECOMESHEREREMOVETHEBREAKPOINTFIRST
<-- snip -->
that IS the point where we will be executing eventually. I know there
request isn't the nicest possible.. I'm not an AD however :) I'm not goona
spend more time on
this. But if someone does a nice "reverse shell" for example. You could let
me
know :) I think it should be a matter of just pasting it into the the right
place and do
some cleaning and make sure inetinfo exits nicely (somehow :)). It works
exactly as eEye's
probably does. I just found the heap allocation address.. and flooded it
abit. to get my
code slide down to 00AC0061 .. which is approx 100bytes above the text I
entered above.. It
would be nice to know if it hit's the same spot on win2k servers and others
as well.. so
please info about it. And the final note goes -> NO I didn't get it to work
just by pasting it
into a telnet localhost 80 session. for some reason.
thanks and laters,
JODE
ps. the codes does nothing else than launches a breakpoint call at THE
(ÌÌÌÌ) location
And for some reason it get's to the breakpoint usually the second time you
run it against the IIS.. after that
it blows home every time.
----- Original Message -----
From: "Ryan Permeh" <ryanat_private>
To: "Joakim Sandström" <jodeat_private>; "Vuln-Dev"
<VULN-DEVat_private>
Sent: Tuesday, June 26, 2001 6:20 PM
Subject: Re: .ida vulnerability..
> well, i suppose i will post a response here, since i was the one that
wrote
> the exploit handed to microsoft.
>
> firsrt, the heap grows with suffiencintly large requests. we are talking
> about 20k+ requests.
> you probably will get cutoff if you try to put 20k chars in the url, and
> besides, they will probably be converted to garbage anyways(the whole wide
> char conversion).
>
> in the exploit that we gave microsoft, we used a specific header(eeye:
> data\r\n) to pad our requests onto the heap. It have since heard of some
> more ways to do this that are more reliable, but have no working code
> implementing them.
>
> right now, we have gotten code to run on 2k, xp, and nt, all service
packs.
> the code we provided microsoft was tuned out of the box to consistantly
hit
> a 2k server/advanced server sp1 install, but it could have been tweaked(we
> made padding and eip based on command line ops) to work on any of them.
>
> The core reason we have not publicly released(and it seems that the media,
> along with numerous other sources think we already have), is due to the
high
> skew factor in this. an exploit that runs 90% of the time on sp1 will
crash
> nt 100% of the time. and nt's heap is very sensitive to this, so you
> basically have to be right no, and it tended to taske us about 3-4 times
> with a debugger to get "right on".
>
> This problem is real, and whether we do or donot decide to finally release
> code, i know of multiple exploits that are in the wild(not public, but not
> ours, nor based on any code we have produced), some with higher degree of
> accuracy in differing situations.
>
>
> In this vein, i beleive that it may be a wise thing for this group to
> examine the following information:
> http://www.msnbc.com/news/592066.asp?0dm=C1BQT
>
> since it deffinately affects everyone who deals with vulnerability as
> research. eEye is a commercial organization, and we publish research as
> part of our commitment to the security community, groups like this
threaten
> to make people and groups that publish vulnerabilty research into the bad
> guys, rather than the companies who create vulnerabilities in their
systems.
> just something for everyone to think about.
>
>
> Signed,
> Ryan Permeh
> eEye Digital Security Team
> http://www.eEye.com/Retina -Network Security Scanner
> http://www.eEye.com/Iris -Network Traffic Analyzer
>
> ----- Original Message -----
> From: "Joakim Sandström" <jodeat_private>
> To: "Vuln-Dev" <VULN-DEVat_private>
> Sent: Monday, June 25, 2001 7:11 AM
> Subject: .ida vulnerability..
>
>
> > Hi Folks,
> >
> > I had some time off work last weekend so I took a look at the new .ida
> > vulnerability. I was debugging
> > a win2k adv server with sp2 installed. First of all I tried to get eip
> over
> > run and successfully did
> > that after trying out different params. The first thing I noticed was
that
> > (as stated on eeye's pages) that
> > the buffer get's converted to wide character (which makes this really
> > tricky) .. But according to
> > eeye's description about the vuln I should be able to push in more stuff
> and
> > make the heap (or whatever)grow larger so I could produce some of my own
> > input data to appear in mem locations as 00430043.
> > First of all I must admit I didn't succeed. Seems to me that the
> exceptions
> > from the overflow occur before the "payload" get's parsed into the
memory.
> I
> > can't locate the payload anywhere.. (and in some occasions the actual
> > buffer).
> > >From what I know.. I see this as a deadlock situation.. Maybe it's
> doable..
> > Though I don't have time
> > to further investigate the vuln. Has anyone else tried it out? Results?
> Any
> > certain combinations of payloads and overflow size which produces a good
> > result? I bet this all varies allot form win2k version and sp versions?
> > Another thing that wonders me.. Why haven't eeye released the proof of
> > concept they are promising on their website? I'd really like to see
> (follow
> > the flow) how you can get all this together. The exploit eeye had sent
to
> > microsoft was based on win2k prof.and sp1. Is this because it was
> un-doable
> > on win2k servers?
> >
> >
> >
> > thanks,
> > JODE
> >
> >
>
This archive was generated by hypermail 2b30 : Wed Jun 27 2001 - 09:11:51 PDT