full-disclosure - Pentesting an IDP-System

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <200405291447.33328@M3T4>
From: fdlist at digitaloffense.net (H D Moore)
Subject: Pentesting an IDP-System

On Saturday 29 May 2004 06:03, ph03n1x wrote:
> Do you guys have an idea how i could test it more efficiently, is there
> some software that automatically tries to attack with a bunch of the
> most common and new exploits so i dont have to do it manually?
> Preferably some GPL or other "free" stuff since i dont have a budget
> for this.

Check out the Metasploit Framework, it was designed with IDS testing in 
mind.  There is an environment option that you can set from the console 
that forces all "nop" instructions to be randomized; you may want to try 
setting this and see if the attack is detected at all :) [1]

The Framework is available from: 
   http://metasploit.com/projects/Framework/

Version 2.0 is the latest public release. If you read through the Crash 
Course PDF on the documentation page, it will describe how to configure 
random nop sleds, as well how the system works in general. The 2.0 
release includes about twenty exploits; updated and new modules are sent 
out to the Framework mailing list. If you have any questions about using 
the Framework, or the general development status, drop us a message
at msfdef[at]metasploit.com.

-HD

1. Something you may want to keep in mind is that intrusion detection 
systems which follow a first-exit methodolgy (Snort, etc) will normally 
report only one event for a given attack. If the "nops" rule matches 
before the exploit rule, that would be the only event reported. The Snort 
team has added something called "event queueing" in the 2.1.3/2.2 version 
(currently in CVS), that allows much better control over which types of 
events override each other. Some day we may post our paper on bypassing 
every single signature with event masking...