Metasploit mailing list archives
Exploit docs
From: masgad at gmail.com (M. GAD)
Date: Thu, 30 Oct 2008 10:30:28 +0100
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
Current thread:
- Exploit docs metamaillist (Oct 28)
- Exploit docs H D Moore (Oct 28)
- Exploit docs Jerome Athias (Oct 28)
- Exploit docs M. GAD (Oct 29)
- Exploit docs Jerome Athias (Oct 29)
- Exploit docs M. GAD (Oct 30)
- Exploit docs Jerome Athias (Oct 30)
- Exploit docs H D Moore (Oct 30)
- Exploit docs Jerome Athias (Oct 30)
- Exploit docs Jerome Athias (Oct 28)
- Exploit docs H D Moore (Oct 28)