OWTF 0.11 “Vienna” released!

The Offensive (Web, etc) Testing Framework (aka OWTF) is an OWASP+PTES-focused try to unite great tools and make pen testing more efficient @owtfp http://owtf.org
WARNING: This tool unites many great tools, websites, knowledge and their associated power, please hack responsibly and always have permission. That being said, happy pwnage 🙂

Dedicated with special love to BSides Vienna, its organisers and attendants, OWTF 0.11 “Vienna” is here!

NOTE: I ran into some issues with github which forced me to delete the repository and re-create it (in exactly the same location), apologies for the inconvenience!

Some links:
– Project page: http://owtf.org
– You will probably get the most out of this tool if you look at the Presentation Slides first.
– Download OWTF: https://github.com/7a/owtf/tree/master/releases
– Demo interactive reports (Firefox >= 8): https://github.com/7a/owtf/tree/master/demos

Change Log since OWTF 0.10 “Berlin” (Full change log is here):

19/01/2012 – 0.11 “Vienna” pre-alpha release: Dedicated with special love to BSides Vienna, its organisers and attendants
 + Significant report improvements
 + OWTF will now only execute external plugins once regardless of the number of targets (it was 1 x num_targets before, way slower)
 + Host names are now retrieved properly from python via import socket + socket.gethostbyname -> i.e. cannot use dns/host when /etc/hosts is required in a pen test (Bug report
 credit: Sandro Gauci)
 + Fixed licence to more accurately match 3-clause-BSD (the intended licence :))
 + Created initial FAQ based on actual feedback/questions
 + Added new grep + external plugins for HTML5 Cross Origin Resource Sharing (CORS) (OWTF-WGP-002) – Thanks to Krzyzstof Kotowicz for answering my questions + great PoCs 🙂
 + Added links to interesting resources for manual exploitation, etc on the external CORS plugin (Thanks to Krzysztof Kotowicz)
 + Added links to interesting resources for manual exploitation, etc on the external Cross Site Flashing plugin (Thanks to Krzysztof Kotowicz, Michele Orru, Mario Heiderich)
 + Tweaked cross site flashing passive plugin (google hacking searches) to also search for Silverlight’s stuff: clientaccesspolicy.xml, .xap and .scr files
 + Tweaked cross site flashing semi passive plugin to also try to get the clientaccesspolicy.xml file (Silverlight’s equivalent to crossdomain.xml)
 + Tweaked regexps for Application Configuration Management (OWASP-CM-004) to reduce false positives
 + Added regexps to Application Configuration Management (OWASP-CM-004) to search for PHP+ASP source code disclosure too
 + Added resources (Nicolas Gregoire’s XLT wiki) to XML Injection external plugin (to assist with manual exploitation)
 + Added Nicolas Gregoire’s HTTP-Traceroute.py reverse proxy check script to tools/discovery/web/rev_proxy (Thanks to Nicolas for allowing direct redistribution with OWTF!)
   Added a GET and TRACE reverse proxy checks using HTTP-Traceroute.py to: Infrastructure Configuration Management (OWASP-CM-003) – with WAF and Load Balancer checks –
   Link for background: http://www.agarri.fr/kom/archives/2011/11/12/traceroute-like_http_scanner/index.html
 + Bug fix: owtf.py -l net (also owtf.py -g net) would crash because there are no net plugins yet: An error message explaining this is now shown instead (Bug report credit: am
06, Michele Orru)
 + Bug fix: semi_passive/Testing_for_Cross_site_flashing@OWASP-DV-004.py does no longer show duplicates + minor plugin clean-up
 + Bug fix: Fixed some issues on Transaction DB comparisons that resulted in the Cache not working right
 + Modified web/passive/Spiders_Robots_and_Crawlers@OWASP-IG-001.py to directly submit the form on tool.motoricerca.info (because it does not work via link, uses POST only)
 + Added Start, End and Runtime fields to Plugin Register + Modified report to display the Start + End Date/Time for each plugin (potentially useful to correlate log events)
 + Added http://statsie.com passive analysis link (on Passive Search Engine Discovery)                                                                                        
 + Created a configuration health-check module by massive popular demand :). When OWTF starts it will now warn you when tools are missing and suggest how to fix it.          
 + Created initial rudimentary owtf_dir/tools/bt5_install.sh script (incomplete, but getting there) to download tools missing or unreliable in Backtrack 5                    
 + Updated install script (owtf_dir/install/bt5_install.sh) + /profiles/general/default.cfg to include the latest Arachni version (v0.4.0.2) and verified it works            
 + Experimental: Created a Command Register (owtf_review/db/command_register.txt) where information on all commands run is stored:                                            
   – Start+End Date/Time, Runtime, Status (Finished/Cancelled), Actual command run, Command without plugin output info (needed internally for the framework)                  
   – Purpose 1: Avoid running the same command several times, very useful when you have several domain.com targets. A message like “command already run for target X” appears
   – Purpose 2: Simple date and time correlation becomes possible: Useful for debugging and IDS testing (which exploit worked? what command brought the server down?, etc)    
   – Purpose 3: It is simply nice to have a log of every command that was run, and questions like “what tools did you run and how?” become easier to answer
 + Added link to Gareth Heyes’ awesome http://shazzer.co.uk project to assist with manual XSS exploitation
 + Added Command execution start date/time information on the screen so that the pen tester can make a better decision (wait/stop it)
 + Experimental: Created a redirect detection mechanism so that it is more intuitive to realise when all URLs are being redirected (i.e. blanket redirect from port 80 to 443)
   – Status will be marked as “302 Found”: Instead of the previous “200 OK”, which did not reflect the redirect (not ideal but better than 200)
   – URL will be set as the redirected URL: This way it is more obvious if the target is http:// but the transaction log is all https://, that there is a blanket redirect
   – Known issue: The scope can be wrong if the redirect is performed to outside of the target URL, need to work more on this

 + Experimental: If the user supplies only domain names, the scope expands to https + http for each domain
 + Experimental: If a passed URL cannot be reached it is removed from the report (assumed it does not exist) -> useful for huge scopes!