Developing an auxiliary – the FTP scanner module
Let's try and build a simple module. We will write a simple FTP fingerprinting module and see how things work. Let's examine the code for the FTP module:
class MetasploitModule < Msf::Auxiliary
include Msf::Exploit::Remote::Ftp
include Msf::Auxiliary::Scanner
include Msf::Auxiliary::Report
def initialize super(
'Name' => 'FTP Version Scanner Customized Module',
'Description' => 'Detect FTP Version from the Target',
'Author' => 'Nipun Jaswal',
'License' => MSF_LICENSE
)
register_options( [
Opt::RPORT(21),
])
end
We start our code by defining the type of Metasploit module we are going to build. In this case, we are writing an auxiliary module that is very similar to the one we previously worked on. Next, we define the library files we need to include from the core library set, as follows:
We define the information of the module with attributes such as name, description, author name, and license in the initialize method. We also define what options are required for the module to work. For example, here, we assign RPORT to port 21, which is the default port for FTP. Let's continue with the remaining part of the module:
def run_host(target_host) connect(true, false)
if(banner)
print_status("#{rhost} is running #{banner}")
report_service(:host => rhost, :port => rport, :name => "ftp", :info => banner)
end disconnect
end
end
Libraries and functions
Let's see some important functions from the libraries that are used in this module, as follows:
We define the run_host method, which serves as the primary method. The connect function will be responsible for initializing a connection to the host. However, we supply two parameters to the connect function, which are true and false. The true parameter defines the use of global parameters, whereas false turns off the verbose capabilities of the module. The beauty of the connect function lies in its operation of connecting to the target and recording the banner of the FTP service in the parameter named banner automatically, as shown in the following screenshot:
Now, we know that the result is stored in the banner attribute. Therefore, we print out the banner at the end. Next, we use the report_service function so that the scan data gets saved to the database for later use or advanced reporting. The method is located in the report.rb file in the auxiliary library section. The code for report_service looks similar to the following screenshot:
We can see that the provided parameters to the report_service method are passed to the database using another method called framework.db.report_service from /lib/msf/core/db_manager/service.rb. After performing all the necessary operations, we just disconnect the connection with the target.
This was an easy module, and I recommend that you try building simple scanners and other modules like these.
Using msftidy
Nevertheless, before we run this module, let's check whether the module we just built is correct with regards to its syntax. We can do this by passing the module from an inbuilt Metasploit tool named msftidy, as shown in the following screenshot:
We will get an info message indicating No CVE references found, which is frankly a go-ahead since this is our custom module and doesn't require any CVE references. Now, let's run this module and see what we gather:
We can see that the module ran successfully, and it has the banner of the service running on port 21, which is 220-FileZilla Server 0.9.60 beta. The report_service function in the previous module stores data to the services section, which can be seen by running the services command, as shown in the preceding screenshot.
Tip
For further reading on the acceptance of modules in the Metasploit project, refer to https://github.com/rapid7/metasploit-framework/wiki/Guidelines-for-Accepting-Modules-and-Enhancements.
Msftidy won't run unless you install Ruby in Ubuntu. You can simply type apt install ruby to use the msftidy tool.