[framework] Any hints for this port (Zenworks sploit) ?

[nowwhat at free.fr]

Merci q:

Egghunting will probably be a good idea in the future, the problem for now is I
can't execute s**t since I just randomly pop something I can't predict into EIP.
The server justs close the connexion when I spam it with my return address. It's
probably ASCII related, although I'm not too sure how I could both write the
return adress and be ASCII compliant...


PS : merci pour les liens c'est plein d'infos passionantes (:

Selon Jerome Athias <jerome.athias at free.fr>:

> Salut Gabriel ;-)
>
> I don't really know more about this vulnerability... sorry
> Btw, I think that you want/need an egghunter.
> http://www.hick.org/code/skape/papers/egghunt-shellcode.pdf
>
http://www.metasploit.com/confs/recon2005/recent_shellcode_developments-recon05.pdf
>
> PS: note that searching for "hunter" and "egg" in the exploit modules
> directory of the Metasploit framework should reveal some nice examples
> This was discussed in some messages in the Metasploit Framework's
> mailing-lists.
>
> I hope that it can help you.
>
> Voilà
> /JA
>
> nowwhat at free.fr a écrit :
> > Hi,
> >
> > I am trying to port "Novell ZENworks 6.5 Desktop/Server Management
> Overflow"  to
> > my version of ZenWorks agent (4.0.X) which is vulnerable according to the
> > references.
> >
> > I have a couple problemes though.
> >
> > I would appreciate if someone could correct me on the following :
> >
> > The exploit is triggered by sending two inputs to the server (possible user
> then
> > password, although I would doubt it knowing Novell's architecture - but its
> out
> > of scope)
> > First input is a fairly large amount of bytes - ~32k which will include
> payload.
> > Second input is much smaller and included in original exploit the return
> adress.
> >
> > When both 'packet' made it to the server, it starts moving the first chunk
> of
> > data to another place in memory, until it tries to write into another
> modules'
> > code segment which trigger an access violation. The bytes that were
> successfully
> > copied overwrote part of another module's (ntdll) stacks (is that possible?
> > can't quite understand there).
> >
> > The access violation make the process jumps into ntdll's code and run until
> it
> > pop something off of the corrupted stack (which is not completely corrupted
> > btw).
> >
> > I tried to figure out where to put my return adress using the offset tools
> of
> > the framework; The chunk of data that gets poped is not consistant accross
> > execution (ranges somewhere between offset 16000 and 20000 in my load).
> >
> > I had the rather stupid idea to fill this area with my return address so
> that it
> > gets poped whatever happens. But the server just resets the connexion -
> possibly
> > because the return address contains 0x00 that justs make the proc stops the
> > buffer copy?
> >
> > Do you feel this is exploitable?
> >
> > PS : I would also apreciate if someone had the original white paper of this
> > vulnerability - I have been unable to find it.
> >
> > Regards,
> >
> > Gabriel
>