DIRB is a Web Content Scanner. It looks for existing and/or hidden Web Objects. It basically works by launching a dictionary based attack against a web server and analizing the response.
DIRB comes with a set of preconfigured attack wordlists for easy usage but you can use your custom wordlists. Also DIRB sometimes can be used as a classic CGI scanner, but remember is a content scanner not a vulnerability scanner. We need to figure the vulnerability out and run the test manually.
How does DIRB work? URL Bruteforcer It looks for hidden Web Objects. It basically works by launching a dictionary based attack against a web server and analyzing the response. DIRB main purpose is to help in web application auditing.
DIRB main purpose is to help in professional web application auditing. Specially in security related testing. It covers some holes not covered by classic web vulnerability scanners. DIRB looks for specific web objects that other generic CGI scanners can’t look for. It doesn’t search vulnerabilities nor does it look for web contents that can be vulnerable.
This tool will only ease your work if you have conducted lots of audits on web applications or you have many experience do that . As looking at the result we need to conclude weather it is vulnerable or not.
Operating systems supported: Windows XP sp2 and above 32 bit *nix systems
The “cum security toolkit” (cst) contains a cgi vulnerability scanner and a port scanner, and can be used as a hacking tool, or as a security vulnerability assesment tool.
The cgi scanner is a web vulnerability scanner that scans using a database of scripts, files and directories (user editable). The sample databases included contain +2200 possibly vulnerable scripts/dirs. You can scan with or without using (multiple) proxy servers. The cgi scanner has +11 different anti-IDS tactics (hex-values, double slashes, self-reference directories, session splicing, parameter hiding, http misformatting, dos/win directory syntax, case sensitivity, null method processing, long urls, premature request ending and http 0.9 scans), and sends fake “X-Forwarded-For:”, “Referer:” and “User-Agent:” headers to hide your scans even more. You can also specify a waittime between 2 script fetches. The cgi scanner uses HEAD requests for faster scanning (you can scan using GET by providing an extra flag), and supports scanning virtual hosts. You can also specify another port to scan instead of the standard port 80, or another directory than the standard cgi-bin or scripts. The scanner outputs the scripts and/or directories that return a 200, 201, 202, 204, 403 or 401 HTTP code (you can specify other codes too using an extra flag) and outputs the target webserver software. You can scan single hosts, or supply a file with a list with targets for bulk scanning.
The port scanner is a simple TCP portscanner with banner grabbing. It outputs which ports are open, sends a string to the open ports (user specified), and shows their reply. It is more an enumeration / stress tool. You can scan separate ports and/or portranges, and you can scan a single host, or supply a list with servers for bulk scanning.
The cum security toolkit is not updated but very effective for some known vulnerabilities which help hackers / crackers to gain access.
How to scan: To scan a server, start cst_cgis.class like this: java cst_cgis -db:<scandb> -d:<dir> -h:<host>
So, you are at work and all you have are the default HTTP ports open. You still want to use other ports and do things other normal users would do. What do you do in such a case? Simple! Use Webtunnel!
Webtunnel is a network utility that encapsulates arbitrary data in HTTP and transmits it through a web server.
This rings a bell alright! HTTPTunnel! Well, not exactly. It is similar to httptunnel, however, it has several key important differences: its server component runs in the context of a web server as a CGI application (with optional FastCGI support) so it does not need its own port, and supports most things that the web server supports, such as authentication, HTTP 1.1, HTTPS, and client certificates; it uses simple requests and responses so it works seamlessly through forward and reverse proxies; it is multi-threaded (actually multi-process using sockets for inter-process communication) to allow multiple parallel connections to multiple destinations simultaneously. Also, HTTPTunnel refuses to work through a reverse proxy. To top it, it allowed only one connection at a time and required multiple instances to tunnel to different ports!
A good news is that a new version was released yesterday! So, in Webtunnel 0.0.3 you have, Added child wait in server to fix zombies under FastCGI Added user authentication based on HTTP user Added access control lists based on user Changed the default debug level to 1 Changed some command line behavior
Download and related information is available here: Download: Get the latest version of the software. Documentation: Browse the user documentation. Forums: Disucss with other webtunnel users. Bugs: Review and submit bug repots.
Related Blogs
Related Blogs on HTTP
Gone in 60 Days: Citi and Bank of America Won’t Live to See May …
