[framework] Metasploit 3.0 for Windows Test Installer

[H D Moore]

On Saturday 24 March 2007 16:22, Alexander Sotirov wrote:
> ./script/../config/boot.rb:28:Warning: require_gem is obsolete.  Use
> gem instead

Fix available via Online Update.

> The msfweb UI opens before the installer is done. You should put a
> checkbox "Launch Metasploit" on the last screen of the installer, and
> open the UI only after the user click the Finish button.

Will do.

> The About button in the top right corner does not highlight when I move
> the mouse over it. All other buttons do.

I couldn't reproduce this, what browser?

> Most windows always has a horizontal scrollbar (on IE6 SP0). It seems
> like the content is always about 10 pixels wider than the window.

Yeah, getting the fonts and window sizes to match across 
Linux/Windows/MacOSX seems almost impossible. Its ugly, but doesn't seem 
to be hurting anything right now.

> A taskbar (or window list) for switching between windows would be nice.
> It's very easy to open a lot of windows and get lost.

I added a unique ID to the title of each Window, adding a taskbar or 
cascader is going to be a bit of a challenge. The windowing code is based 
on the Prototype JS Windowing library and messing with the internals to 
add a task bar may be too much work right now.

> To raise a window you have to click on its border. It would be better
> if you could raise it by clicking anywhere inside it.

This is also tricky to do using the Prototype library. You can raise a 
window by click the bottom edge as well, but I agree that clicking 
anywhere in the content should raise the Windows as well. Something that 
may be relatively simple to add is to auto-raise when the mouse goes 
across the window (seems easier to hack in the the onmousedown for all 
elements within the content).

> When you select an exploit, it's not clear how to actually run it. You
> have to read all the text in the window to figure out that there is a
> "Please select a target" list under the exploit description. Visually
> it looks too similar to the "External references" list above it. It
> would be better if you had a big "Run" button.

Point taken, I will try to make the next step more clear. 

> After you select the target, the window shows a list of payloads. There
> is no way to go back and change the target, you have to close the
> window and start from scratch. There's also no visual indication of
> what target you have selected.
>
> The interface for running exploits should either be a wizard style
> interface (with Next and Prev buttons), or even better a window that
> shows you all currently selected options (including the target and
> payload) and you can set them in any order you want. There is no reason
> to force the user to select a target and a payload before everything
> else.

There is a dependency that requires the target to be set before the 
payload, and the payload before the options. The target can define the 
architecture and OS, so the list of compatible payloads isn't know until 
a target is selected. The same applies to the options -- you don't know 
all of the available options until the payload has been selected. 

We are using a wizard-based approach for the GTK GUI right now, and I 
can't say I like one method better than the other (but thats why I use 
the console). I will see what I can do about next/prev buttons.

> In the options window there is no need to show "Optional" next to the
> optional options. Just mark the required ones with "Required" - use red
> color to highlight it. This will be more consistent with how forms are
> done on most websites.

Got it.

> Why is there a "Launch Exploit" button under each section with options?
> It's not clear if the buttons do the same thing or if they are
> different. Which one should I press?

This button is triplicated so that the user doesn't have to scroll all the 
way to the top to launch the exploit after setting an option. They all do 
the same thing, but its a pain to scroll up 4 pages of options after 
filling in the Evasion or Advanced options. Any suggestions for redoing 
this?

> In the options window there is a "Change" link that should allow you to
> change the exploit, payload and target. At least that's what it looks
> like from the interface. However, it allows you to change only the
> payload.

Thats correct, it only lets you change the payload, you would have to go 
one step further back to change the target (due to the dependencies).

> When you click on the "Change" link and select a new payload, all
> options that you previously entered are gone and you have to enter them
> again.

There is no stored state or session at this time, but I can look into 
adding one. Support for this may not arrive until after 3.0 is released 
unless someone else wants to send me a patch.

> When I launch an IE exploit, it runs it in the background and drops me
> in a console. What am I supposed to do in this console? Instead, it
> should show me a status page that gives me the URL I need to give to
> the victim. The console should open only after I get a shell.

This is an implementation artifact -- the only way to really see the 
output of the exploit in real-time is via the console interface right 
now, so this was recycled for exploits and sessions. Eventually, the 
console should only be used by the actual Console link. Doing 
this "right" (adding a new polling mechanism and creating a new wrapper 
around the exploit attempt) will have to wait until the next release 
(unless someone sends me a patch...).

> It would be nice if I could close my browser, then open another one and
> get back all the windows I had open in the previous session.

Sure would :-) We need to have sessions or user profiles or some form of 
storage before that becomes possible. The windowing system is kind of 
dumb now (all windows appear in the center and overlap, etc), but I still 
think what we have now is a good start. 

Besides, nobody wants to wait another 2 years for 3.0 to become stable :-)

Thanks for all the feedback!

-HD