« previous 1 2 3 4 next »

Now with GUI

MSF provides three interfaces to test the exploits: msfconsole, msfweb and msfcli. Once MFSweb has been launched, a simple Web server providing a graphical user interface to select exploits and other parameters such as target IP, port and payload, listens on the local system on TCP port 55555. The advantage of MSFweb is the possibility to allow several concurrent users to access the Web interface. However, the mini exploit server is completely unprotected, constituting a security risk in itself; the developers even advise against using it, saying that MSFweb is more meant to demonstrate the possibilities of the framework. By default, MSFweb only allows connections from the local computer. Team staff must adapt the configuration and should not forget to secure MSFweb appropriately.

With MSFcli, an adapted version of the Metasploit console msfconsole is available, which is especially suited for usage in scripts. It uses a slightly modified syntax, which packs the whole process of selecting targets, exploit and payload into one single command.

The MFSconsole is the primary front end for controlling Metasploit.

The MFSconsole is the main interface. Users of Linux-Bash will feel at home immediately even in the Windows version thanks to Cygwin. In any case, Linuxers should also install the Term::ReadLine::Gnu package from the "extras" directory to be able to use all the convenient Bash functionality, such as command completion.

In addition to standard console commands, there are special commands for the framework. For instance, the command show exploits displays all available exploits, and show payloads lists the shellcodes accordingly.

The "use" command, together with the name of an exploit module, switches to the specific environment of this exploit, providing more clarity and ease of use, since all other commands will only show options that are useful for this specific exploit. For instance, it is not possible to combine a Linux exploit with a Windows payload; some payloads also request a privileged shell on the attacked system, which is not provided by all exploits. In the Perl module, the developer predefines which payloads work with the exploit and equally important which targets are vulnerable. The framework pays attention to such dependencies.

If, for example, you use

use apache_chunked_win32

to switch to the module of the exploit for the security hole already known to compromise the system in some Apache versions, the framework only displays the relevant information. In this case, the command show payloads only lists the corresponding Win32 payloads, while show targets displays the vulnerable targets, i.e., Apache versions from 1.2.x to 1.3.24 running under Windows.

Additional information is communicated to the exploit via reserved local variables read out by the exploit module. The information required for the exploit is listed under show options. In the above example, this information includes the target IP address and perhaps the port number where Apache is listening, but also the program version of the attacked Web server:

set RHOST 192.168.1.10 
set RPORT 80 
set TARGET 2

This way, the framework is instructed to attack the system's Web server with the IP 192.68.1.10, where Apache version 1.3.22 is running. The variable "PAYLOAD" specifies which shellcode shall be infiltrated and executed. For some (few) attacks, the developers have also implemented a function that checks if the selected target is vulnerable. The command check performs the testing. Once a vulnerable system has been found, the command exploit executes the attack. The framework transfers the attack code, including payload, to the target system. A successful attack allows the attacker to access the system with a Telnet client to take over remote control, for example.

« previous 1 2 3 4 next »