Comments on: You Don’t Need the Ultimate Pen-testing Framework!

By: Jerry

Jerry — Sun, 15 Aug 2010 22:36:55 +0000

I totally agree with Your article. Further more I would say that You can skip altogether frameworks and their pre-made exploits and payloads. Exploits have to be tuned each time to be effective and payloads are almost all catch by AV when touching the disk, even if You encode them. They can still have some chances if they run all in memory. But I had most success with unique non staged binary payloads. I also agree that with the CLI You can handle everything, even multiple sessions, better and faster then in msfconsole. For example using the cli command ‘socket’ You can create a listening server which forks on a unix socket on each new connection and then You can connect to each background process. This way You’re handling unlimited sessions fast and in 1 line.

By: WGet all the way

WGet all the way — Tue, 07 Jul 2009 17:04:50 +0000

[...] flowing in, the project has been started and then BAM, I’ve read an interesting article on GNUCITIZEN, which made me rethink my [...]

By: enigma

enigma — Sat, 20 Jun 2009 13:58:28 +0000

A lot of useful information and I totally agree with some of the issue’s raised, I’ve never installed nessus, its great for security testing but only if the server your scanning has nessus on the backend, which half of them dont!

By: pdp

pdp — Fri, 24 Apr 2009 11:37:28 +0000

My humble opinion is that we should have scraped nessus altogether and started something better from scratch but this is my humble opinion only.

By: JC

JC — Fri, 24 Apr 2009 09:30:01 +0000

Love this to bits – it just works.

Have you tried it with OpenVAS? I am not sure that OpenVAS-client is command line plug compatible with nessus

By: More Penetration Testing Goodness with Jeriko | GNUCITIZEN

More Penetration Testing Goodness with Jeriko | GNUCITIZEN — Tue, 07 Apr 2009 21:14:35 +0000

[...] weeks I’ve added more features to the Jeriko toolkit which I briefly covered in my post over here. For those of you who don’t know, Jeriko is a compilation of various bash scripts to ease [...]

By: No Frameworks but Environments | GNUCITIZEN

No Frameworks but Environments | GNUCITIZEN — Wed, 18 Mar 2009 10:51:57 +0000

[...] Network No Frameworks but Environments published: March 18th, 2009 We certainly don’t need the ultimate pentesting framework but we can make use of the ultimate pen-testing [...]

By: pagvac

pagvac — Sat, 14 Mar 2009 10:15:47 +0000

i agree that most of the stuff we need is on the shell already. pentesting frameworks is like the new security-testing hype. first we had hundreds of portscanners, then hundreds of webapp MiTM proxies, then hundreds of fuzzers, then hundreds of SQL injectors, now it’s about pentesting frameworks :)

Knowing a few scripting tricks is extremely powerful, as already-available tools are not customized enough for our tasks sometimes. furthermore, sometimes learning how to do something with a publicly-available tool can be MORE time-consuming than writing your own bash script to do so.

By: pdp

pdp — Mon, 09 Mar 2009 08:45:57 +0000

excellent, I will have a look :)

By: sid77

sid77 — Fri, 06 Mar 2009 14:55:26 +0000

Hi,

I’ve written a small patch against Jeriko-r31 to add some functionalities:
+ option to choose whether to run nessus or openvas
+ option to choose which metasploit db plugin to load
+ a bigger jerikorc
+ fixed a small typo in scan-vulnerabilities

The patch is hosted here: http://sid77.slackware.it/jeriko/

ciao

By: hartog

hartog — Fri, 06 Mar 2009 13:43:14 +0000

@pdp; great post, proofs the power of the shell once more :->. Some nice constructions in their as well :->

@postmodern; since when are sed, awk, grep, wget and many many others primitive? Most of them are/have (micro) expression/programming languages and they can be piped together. Throw in some Perl one-liners to become really powerful. *grrrrr* ;->

By: pdp

pdp — Wed, 25 Feb 2009 09:52:25 +0000

bash is pretty much a general purpose programming language. it has sockets, ways to interfere with C libs, etc. the reason I chose bash to implement most of the functionalities of this toolkit is because it comes by default and also it does a better job when it comes to managing processes and tasks then most general purposes languages. it is also quite fast compared to ruby for example. for sure python, ruby and perl can be used to do similar things but because they are too general purpose you will endup with much larger source code which will quickly turn into a framework, imho.

my argument is that the framework is already written for you. we do not need yet another abstraction layer on the top of the standard shell which already contains the majority of the functionalities that we need. the rest of the functionalities are provided by various standard utilities which are well integrated with the particular distribution you are running and the packet management system. some of the standard shell utills also provide features to interact with 3rd-party components in the most simplistic way (expect for example), while it will be a lot harder to do something similar with a general purpose language or the missing functionalities rely on a 3rd-party lib which is not easy to install or requires a fair bit of dependencies.

another example is metasploit’s session management feature. it is very useful, indeed, to start several sessions to the targets and switch between them on the go. though, this is a metasploit specific feature. however, screen and script provide similar functionalities which happen to be a lot better and work for all utilities including metasploit. therefore, I would rather rely on the toolkit that comes by default.

at the end of the day Jeriko is not a framework. it is a toolkit which is designed to run from the command line. all it does is it to save yourself some efforts typing long commands. it also ensures that no orphan processes are left when exiting different tasks. :)

By: postmodern

postmodern — Tue, 24 Feb 2009 23:58:25 +0000

Why still use shell scripting for this task, when it’s far easier in a Python, Jython, Ruby, JRuby or even a NetBeans shell? Instead of using primitive commands, you could use a general purpose programming language with a syntax that is conducive towards one-liners.

Taking it one step further, you could even load in various libraries or frameworks (there’s more than just Metasploit) into your interpretive language’s shell. You can get the same effect with cleaner syntax.

By: pdp

pdp — Mon, 23 Feb 2009 18:02:25 +0000

same with nmap. although nmap’s script scan option is quite powerful indeed, it just turns the tool into something which is not – a vulnerability scanner. coding in lua is no fun either.

By: pdp

pdp — Mon, 23 Feb 2009 17:59:03 +0000

imho, metasploit would have been a lot better if all it was just an exploitation framework, good for writing and running exploits only. The auxiliary modules are a bit redundant. perhaps the useful stuff like the BailiWicked auxiliary modules should have been put as exploit modules. and if only you could make the framework run faster :) that would have been great. other than that, it is one fine framework.

By: Pento

Pento — Mon, 23 Feb 2009 17:45:09 +0000

It’s like window managers and DE in Linux. You can live for example in minimal WM like fluxbox or ever dwm and find and use some small application for different purposes. But you can install gnome|kde and spend this time for work. As I think nmap+GNU Core Utilities+metasploit is the best choice.

By: pdp

pdp — Mon, 23 Feb 2009 15:45:01 +0000

actually I quite like wireshark :) but I was trying to encourage people to develop for the command line as it proves over time to be the simplest and fastest way to do things and given that you understand bash, you can do tones of good hacks.

By: rvdh

rvdh — Mon, 23 Feb 2009 14:26:25 +0000

Good post PDP.

True. most stuff even allready resides in the C libraries you already have. Same with nmap which uses those C libs. Like the sockets API et all. Same with sniffing a network, most stuff is provided in C libs as well and some parts are already accessable through the command line, takes a few commands to start capturing packets in your console in real time. Absolutely no need for a wireshark at all.