Exploit docs

[masgad at gmail.com (M. GAD)]

On Wed, Oct 29, 2008 at 3:59 PM, Jerome Athias <jerome.athias at free.fr> wrote:
> I agree.
>
> I've put exploits modules (of the MSF v2) in a database to use them with
> theXploiter.
>
> https://www.securinfos.info/metasploit/MSF-XB-MCD.png

Jerome, you have already done a greate work but why you stopped at MSF v2 :(

> So, I know which exploits target, for example, port 21. theXploiter uses
> nmap to scan the target and if it find the port 21 open; it shows you
> directly the possible MSF exploits modules.
> The launching an exploit, theXploiter will automatically fill the fields
> like target IP, target Port, and via fingerprinting will try to identify
> the target system loale and SP, then theXploiter search the most
> reliable return address to use for this target and launches the attack.

I have looked at ur code at a glance, u have advanced well. However, I
think it may be simpler to program new functionalities (i.e., databse
backend, automatic Exploiter) in Ruby.
This has several advantages because it will allow the reuse of MSF
libraries and classes and will encourage other metasploiters to be
involved.

> I thought also to put exploits modules in XML files, what do you think
> about it? (even if it would be time consumming at start)

Why do it manually? there exist some tools to export Databases into
XML and vice versa. For example:
 "mysqldump --xml --databases your database name -u username -p
password >test.xml"

 IMHO, what we need is an extension of MSF that is compatible with the
current implementation and that maximize the reuse of MSF code. This
may be achieved through the following steps:
(1) determine the useful information that one can need to characterize
the module (exploit, payload, etc),
(2) Code these information directly into the module when creating it
(as already done with the platform and privilege attributes),
(3) Design database schema and tables,
(4) write a program to extract information coded within the module and
export it to the database,
(5) Design the exploiter as a plugin of MSF (this is another story but
I have some clues for doing that)

Now, as the thread is becoming more close to framework-hackers, HDM or
list moderators can switch it there.

Regards,
MG


> M. GAD a ?crit :
> > In fact consulting references one by one to find out more information
> > about the exploit is sufficiently tedious. MSF-XB quite facilitate it
> > but we still need to visit several sites.
> > There is a closely related issue: selecting appropriate exploits. As
> > the number of exploits and auxiliary tools increases it will be more
> > difficult to select an appropriate exploit. Although the current GUI
> > or the web interface are supporting module selection either by
> > platform or arch, we need sometimes to make selection based on other
> > criteria a combination of them. For example, selecting an exploit
> > based on the privilege that it provides, according to its launching
> > source, according to the directly involved program (the vulnerable
> > program) , etc.
> >
> > The current implementation of modules has useful information about
> > modules that represent a good basis for this.
> > However, we need to:
> > (1) add more information such as the corresponding CPE entry (Common
> > Platform Enumeration of MITRE) or the attributes of reasonable attack
> > classification (I suggest the one attached with this email)
> > (2) think about importing such information into a backend DB. This
> > will facilitate the selection process as well as allows establishing a
> > link with CVE, OSVDB or CPE detailed data easily.
> >
> > Best regards,
> > M GAD