Do tools here ever make it into Backtrack?

[Sys7emR00t]

How can you just submit a program to the repository...? It doesn't look like anyone pays much attention to actually adding these tools. Just saying.

I have a nice Vulnerability Identification script I'd like to have added.

[purehate]

We check this all the time. You cannot just add something to our repos, that would be seriously irresponsible. In fact, of all the forums threads I check this one the most. So add your script if you want it to be considered.

Thats why this is called Tool Requests, because we consider them.

[Sys7emR00t]

I have written a script that queries Exploit-DB, downloads and compiles the exploit, tries it and then checks for local privilege escalation to root before trying another one. I'm still working out some side-effects, but it can try nearly 120 exploits per minute. It's written in bash, do I have to have it turned into some kind of executable before submitting it for consideration or do you just wanna see the code?

[Sys7emR00t]

Did you get my message?

[Middle]

I am very interested in this!

Keen to see this in action, and it is great that it is coded in Bash XD

And no it can be left as a script, there are a few tools in backtrack all ready that are Bash scripts...

[wh1t3fang]

I have seen many tools that get submitted in this forum and then later get added to the backtrack repos. You script sounds like a good idea. You should post it and see if it will get added.

[purehate]

The best way to get a tool included is to send me or Balding_Parrot the following things via email:

The script
What the script does
If there is already a script which does the same thing, why is yours better.

Then I will test it out and see what we as a team think. Normally I will mail back with some corrections & features I think should be added, we may go back and forth a few times and after its all fixed we can add it. I will tell you this, the MAIN thing I look for in any tools (Besides if it works or not) is proper error handling. I cant stand it when tools do not handle errors properly.

[lupin]

Just curious - what use cases did you have in mind for this tool? I can forsee some problems using something like this in a pentest, for example the noise created by an internal server making multiple HTTP requests to exploit-db and the potential for an inappropriately targeted (or even appropriately targeted) privilege escalation exploit to crash or otherwise damage the target system. Do you have proper logging in place so any potential damage can be tracked to identify the cause if any damage may occur?

And as purehate mentioned - error handling. Can the program deal with no compiler being present or with failed HTTP requests? What about exploits that do not need to be compiled and instead need to be run through an interpreter?

[Sys7emR00t]

Lupin, yes, the tool is "noisy", which is why it's more aimed at defense-hardening or white-box tests. Though, most exploits on Exploit-DB (since they're just source-code) aren't detected by conventional IDSs. When you're thinking entirely as an ethical hacker "use cases" isn't even a real question...admins or just security enthusiasts could run it to find out if they're systems are vulnerable to any of the Exploit-DB exploits.

Bash returns errors upon exit that should be very understandable to most backtrack users (especially if the only problem is something as trivial as no compiler). I'm working on more advanced error handling for compile-time or run-time errors, thoguh at this point it will just skip these exploits since chances are the system is then missing a dependent program or library. HTTP requests errors will also be skipped. The biggest problem I'm having is in adding a timeout feature for exploits that try to connect to an app or program that isn't installed; in this case the script never moves on to try the next exploit. We're still beta

purehate, emailing you right now

[lupin]

When you're thinking entirely as an ethical hacker "use cases" isn't even a real question...

So what is it then, a "fake" question? Use cases are a valid thing to define for any type of software. It's appropriate for both a softwares author and its users to know what a piece of software is meant to be used for, its purpose in other words, and to claim otherwise is nonsensical.