The core of SAINTexploit is its many vulnerability exploits. Each exploit and all related information is stored in a separate plug-in file, making it easy to add or remove exploits. The plug-in files have a file name ending in .sx and are located in the exploits directory.
Each plug-in file contains general information about the exploit, tutorial information about the vulnerability, a definition of the input parameters, conditions under which to run the exploit, the type of shell spawned by the payload, and the exploit code itself. These are discussed in the following sections.
General Information ?
Each exploit plug-in begins by defining some general information about the vulnerability. For instance:name = "Microsoft IIS 5.0 printer ISAPI extension buffer overflow";
id = "iis_printer_isapi";
date = "20060208";
cve = "CVE-2001-0241";
bid = "2674";
osvdb = "3323";
saint_id = "web_server_iis_iis,web_server_iis_iisx"
The name is the name of the exploit, which is also the text which the user sees in the data analysis pages. The id corresponds to the file name of the plug-in, minus the .sx extension. The date is the date on which the exploit was added, in YYYYMMDD format.
cve is the CVE entry for the vulnerability. bid is the SecurityFocus Bugtraq ID of the vulnerability. osvdb is the Open Source Vulnerability Database entry for the vulnerability.
saint_id is the vulnerability check ID which is used to check for the same vulnerability in SAINT. All SAINT vulnerability check IDs can be found in the vulns.dat file.
Tutorial Information ?
The next section of the exploit plug-in is the tutorial information. This section contains the information which the user sees when clicking on the exploit name under the Exploits tab or on the data analysis screens.The tutorial information is divided into five sections: Background, Problem, Resolution, References, and Limitations. Each section is enclosed in braces. For instance:
problem {
The ISAPI extension which handles requests for file names
ending in <tt><b>.printer</b></tt> is affected by a buffer
overflow which could allow remote attackers to execute
arbitrary commands.
}
Notice that the tutorial information is written in HTML format. The only exception is the References section, which is simply a list of URLs. The URLs are shown as hyperlinks when viewed by the user.
Some client exploits have a sixth section, Instructions, which contains the body of the e-mail message which is sent out to prompt users to follow the exploit link. This section is plain text, except for the keyword %url% which stands for the link to the exploit. If the Instructions section is absent, then the e-mail message is a default string.
Type and Class ?
The next section of the exploit plug-in specifies the exploit type and class. For instance:type = "remote";
class = "web";
The type tells SAINTexploit how to run the exploit. The exploit type can be one of three strings. remote indicates that the exploit targets a service running on a remote host. local indicates that the exploit only runs after access to the target has been gained using a remote exploit or some other means. Local exploits usually result in privilege elevation if successful. client indicates that the exploit targets a vulnerability in an application which is initiated by a user. Client exploits use an exploit server to deliver the exploit to clients. tool indicates that the exploit does not attempt to penetrate the target, but instead performs some information gathering function.
The class groups exploits together based on similar application types or attack vectors. It can have one of eight different values: web, mail, ftp, rpc, passwords, browsers, windows_os, and other.
Parameters ?
The parameters setting is a variable list corresponding to the arguments which are passed to the exploit plug-in when executed. For example:parameters = ($port, $os, $shellport, $thisaddr, $target);
In this case, $port is the TCP port number of the remote service, $os is the platform type corresponding to one of the indices in the conditions, $shellport is the port used for remote access (see Shell Ports), $thisaddr is the address of the machine running SAINTexploit for the purpose of connecting back with a shell, and $target is the address of the target machine.
The parameter list corresponds to the fields which the user fills in when running the exploit individually. When running an automated penetration test, the values are automatically set by the SAINTexploit engine based on available information.
Conditions ?
Each exploit specifies a set of conditions which determine the circumstances under which the exploit should be attempted. The SAINTexploit engine automatically takes these conditions into accountwhen deciding which exploits to run. For example:
platform[0] = "Windows 2000";
platform[1] = "Windows XP";
default_port = "80/tcp";
condition = "Microsoft-IIS/5\.0";
In the above example, the exploit runs against Windows 2000 and Windows XP. The number in the brackets is the index which corresponds to the $os input parameter. (See parameters.) 80/TCP is the default port when running the exploit individually and the port which triggers the exploit during automatic penetration tests. The string Microsoft-IIS/5.0, if found in the received data during a port scan, also causes the exploit to run, enabling exploitation on non-standard HTTP ports. Note that the dot is escaped by a backslash because the string is a PERL-compatible regular expression, in which the dot character alone would have special meaning.
In some cases, it is useful for the condition to have an index as well. For example:
platform[0] = "Windows 2000";
platform[1] = "Windows XP";
default_port = "80/tcp";
condition[0] = "Microsoft-IIS/5\.0";
condition[1] = "Microsoft-IIS/5\.1";
In this case, rather than just triggering the exploit, the conditions also specify the $os setting when running the exploit. This exploit would be run with $os equal to 0 against Windows 2000 servers running IIS 5.0, and $os equal to 1 against Windows XP running IIS 5.1.
It is also possible to specify the exploit's order within the execution sequence of an automated penetration test. For example:
order = 4;
This line tells the exploit to run after any exploits with an order of 1, 2, or 3, but before any exploits with an order of 5. Controlling the order of execution is useful for ensuring that exploits with a higher potential to cause crashes run after those with a lower potential to cause crashes, to avoid false negatives. Exploits which are not known to cause crashes typically have an order of 1. Exploits which may cause a service to crash typically have an order of 3 or 4. Exploits which could cause the whole system to crash typically have an order of 5. The default order is 3.
Shell Type ?
The payloads of the exploits vary in the way they allow remote access after successful exploitation. The shell setting tells SAINTexploit which method the exploit uses, so that it can properly set up the connection. For example:shell = "reverse port";
There are several possible values for this setting:
- interactive: an interactive command shell runs in the same socket as the exploit
port: the exploit runs a command shell on the TCP port specified by the $shellport parameter
port n: the exploit runs a command shell on TCP port n
reverse port: a command shell connects back to SAINTexploit on the TCP port specified by the $shellport parameter
reverse port n: a command shell connects back to SAINTexploit on TCP port n
select port: same as reverse port if $shelltype para
direct: a command is sent as an argument to the exploit
meter is 0 or port if $shelltype parameter is 1
none: the exploit does not open a command shell
Exploit Code ?
The last section of the exploit plug-in is the exploit code. This is the exploit program itself. The start of the exploit code is marked by the word exploit followed by an open brace. The end is marked by a close brace. The code is written in SAINTexploit's own exploit programming language, which is syntactically similar to PERL but with some additional functions.To add exploits written in a different programming language, simply have the code within the plug-in call the code in a separate file. For example, if you want to have SAINTexploit call a Python program, create a SAINTexploit plug-in and put the following code into the plug-in:
exploit {
exec("exploits/myexploit.py", @ARGV);
}
Where "exploits/myexploit.py" is the location of the external program. Make sure that the external program handles the input parameters specified in the plug-in's parameter list.
No comments:
Post a Comment