Metasploit mailing list archives

Any hints for this port (Zenworks sploit) ?


From: nowwhat at free.fr (nowwhat at free.fr)
Date: Thu, 23 Aug 2007 17:40:29 +0200

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






Current thread: