toolsmith: OWASP Xenotix XSS Exploit Framework

Prerequisites

Current Windows operating system

Introduction

Hard to believe this month’s toolsmith marks seven full years of delivering dynamic content and covering timely topics on the perpetually changing threat-scape information security practitioners face every day. I’ve endeavored to aid in that process 94 straight months in a row, still enjoy writing toolsmith as much as I did day one, and look forward to many more to come. How better to roll into our eighth year than by zooming back to one of my favorite topics, cross-site scripting (XSS), with the OWASP Xenotix XSS Exploit Framework. I’d asked readers and Twitter followers to vote for November’s topic and Xenotix won by quite a majority. This was timely as I’ve also seen renewed interest in my Anatomy of an XSS Attack published in the ISSA Journal more than five years ago in June 2008. Hard to believe XSS vulnerabilities still prevail but according to WhiteHat Security’s May 2013 Statistics report:

1)      While no longer the most prevalent vulnerability, XSS is still #2 behind only Content Spoofing

2)      While 50% of XSS vulnerabilities were resolved, up from 48% in 2011, it still took an average of 227 for sites to deploy repairs

Per the 2013 OWASP Top 10, XSS is still #3 on the list. As such, good tools for assessing web applications for XSS vulnerabilities remain essential, and OWASP Xenotix XSS Exploit Framework fits the bill quite nicely.

Ajin Abraham (@ajinabraham) is Xenotix’s developer and project lead; his feedback on this project supports the ongoing need for XSS awareness and enhanced testing capabilities.

According to Ajin, most of the current pool of web application security tools still don't give XSS the full attention it deserves, an assertion he supports with their less than optimal detection rates and a high number of false positive. He has found that most of these tools use a payload database of about 70-150 payloads to scan for XSS. Most web application scanners, with the exception of few top notch proxies such as OWASP ZAP and Portswigger’s Burp Suite, don't provide much flexibility especially when dealing with headers and cookies. They typically have a predefined set of protocols or rules to follow and from a penetration tester’s perspective can be rather primitive. Overcoming some of these shortcomings is what led to the OWASP Xenotix XSS Exploit Framework.

Xenotix is a penetration testing tool developed exclusively to detect and exploit XSS vulnerabilities. Ajin claims that Xenotix is unique in that it is currently the only XSS vulnerability scanner with zero false positives. He attributes this to the fact that it uses live payload reflection-based XSS detection via its powerful triple browser rendering engines, including Trident, WebKit and Gecko. Xenotix apparently has the world's second largest XSS payload database, allowing effective XSS detection and WAF bypass. Xenotix is also more than a vulnerability scanner as it also includes offensive XSS exploitation and information gathering modules useful in generating proofs of concept.

For feature releases Ajin intends to implement additional elements such as an automated spider and an intelligent scanner that can choose payloads based on responses to increase efficiency and reduce overall scan time. He’s also working on an XSS payload inclusive of OSINT gathering which targets certain WAF's and web applications with specific payloads, as well as a better DOM scanner that works within the browser. Ajin welcomes support from the community. If you’re interested in the project and would like to contribute or develop, feel free to contact him via @ajinabraham, the OWASP Xenotix site, or the OpenSecurity site.

Xenotix Configuration

Xenotix installs really easily. Download the latest package (4.5 as this is written), unpack the RAR file, and execute Xenotix XSS Exploit Framework.exe. Keep in mind that antimalware/antivirus on Windows systems will detect xdrive.jar as a Trojan Downloader. Because that’s what it is. ;-) This is an enumeration and exploitation tool after all. Before you begin, watch Ajin’s YouTube video regarding Xenotix 4.5 usage. There is no written documentation for this tool so the video is very helpful. There are additional videos for older editions that you may find useful as well. After installation, before you do anything else, click Settings, then Configure Server, check the Semi Persistent Hook box, then click Start. This will allow you to conduct information gathering and exploitation against victims once you’ve hooked them.

Xenotix utilizes the Trident engine (Internet Explorer 7), the Webkit engine (Chrome 25), and the Gecko engine (Firefox 18), and includes three primary module sets: Scanner, Information Gathering, and XSS Exploitation as seen in Figure 1.

FIGURE 1: The Xenotix user interface

We’ll walk through examples of each below while taking advantage of intentional XSS vulnerabilities in the latest release of OWASPMutillidae II: Web Pwn in Mass Production. We covered Jeremy Druin’s (@webpwnized) Mutillidae in August 2012’s toolsmith and it’s only gotten better since.

Xenotix Usage

These steps assume you’ve installed Mutillidae II somewhere, ideally on a virtual machine, and are prepared to experiment as we walk through Xenotix here.

Let’s begin with the Scanner modules. Using Mutillidae’s DNS Lookup under OWASP Top 10 à A2 Cross Site Scripting (XSS) à Reflected (First Order) à DNS Lookup. The vulnerable GET parameter is page and on POST is target_host. Keep in mind that as Xenotix will confirm vulnerabilities across all three engines, you’ll be hard pressed to manage output, particularly if you run in Auto Mode; there is no real reporting function with this tool at this time. I therefore suggest testing in Manual Mode. This allows you to step through each payload and as seen Figure 2, we get our first hit with payload 7 (of 1530).

FIGURE 2: Xenotix manual XSS scanning

You can also try the XSS Fuzzer where you replace parameter values with a marker, [X], and fuzz in Auto Mode. The XSS Fuzzer allows you to skip ahead to a specific payload if you know the payload position index. Circling back to the above mentioned POST parameter, I used the POST Request Scanner to build a request, establishing http://192.168.40.139/mutillidae/index.php?page=dns-lookup.php as the URL and setting target_host in Parameters. Clicking POST then populated the form as noted in Figure 3 and as with Manual mode, our first hits came with payload 7.

FIGURE 3: Xenotix POST Request Scanner

You can also make use of Auto Mode, as well as DOM, Multiple Parameter, and Header Scanners, as well as a Hidden Parameter Detector.

The Information Gathering modules are where we can really start to have fun with Xenotix. You first have to hook a victim browser to make use of this tool set. I set the Xenotix server to the host IP where Xenotix was running (rather than the default localhost setting) and checked the Semi Persistent Hook checkbox. The resulting payload of

was then used with Mutillidae’s Pen Test Tool Lookup to hook a victim browser on a different system running Firefox on Windows 8.1. With the browser at my beck and call, I clicked Information Gathering where the Victim Fingerprinting module produced:

Again, entirely accurate. The Information Gathering modules also include WAF Fingerprinting, as well as Ping, Port, and Internal Network Scans. Remember that, as is inherent to its very nature, these scans occur in the context of the victimized browser’s system as a function of cross-site scripting.

Saving the most fun for last, let’s pwn this this thang! A quick click of XSS Exploitation offers us a plethora of module options. Remember, the victim browser is still hooked (xooked) via:

I sent my victim browser a message as depicted in Figure 4 where I snapped the Send Message configuration and the result in the hooked browser.

FIGURE 4: A celebratory XSS message

Message boxes are cute, Tabnabbing is pretty darned cool, but what does real exploitation look like? I first fired up the Phisher module with Renren (the Chinese Facebook) as my target site, resulting in a Page Fetched and Injected message and Renren ready for login in the victim browser as evident in Figure 5. Note that my Xenotix server IP address is the destination IP in the URL window.

FIGURE 5: XSS phishing Renren

But wait, there’s more. When the victim user logs in, assuming I’m also running the Keylogger module, yep, you guessed it. Figure 6 includes keys logged.

FIGURE 6: Ima Owned is keylogged

Your Renren is my Renren. What? Credential theft is not enough for you? You want to deliver an executable binary? Xenotix includes a safe, handy sample.exe to prove your point during demos for clients and/or decision makers. Still not convinced? Need shell? You can choose from JavaScript, Reverse HTTP, and System Shell Access. My favorite, as shared in Figure 7, is reverse shell via a Firefox bootstrapped add-on as delivered by XSS Exploitation --> System Shell Access --> Firefox Add-on Reverse Shell. Just Start Listener, then Inject (assumes a hooked browser).

FIGURE 7: Got shell?

Assuming the victim happily accepts the add-on installation request (nothing a little social engineering can’t solve), you’ll have system level access. This makes pentesters very happy. There are even persistence options via Firefox add-ons, more fun than a frog in a glass of milk.

In Conclusion

While this tool won’t replace proxy scanning platforms such as Burp or ZAP, it will enhance them most righteously. Xenotix is GREAT for enumeration, information gathering, and most of all, exploitation. Without question add the OWASP Xenotix XSS Exploit Framework to your arsenal and as always, have fun but be safe. Great work, Ajin, looking forward to more, and thanks to the voters who selected Xenotix for this month’s topic. If you have comments, follow me on Twitter via @holisticinfosec or email if you have questions via russ at holisticinfosec dot org.

Cheers…until next month.

Acknowledgements

Ajin Abraham, Information Security Enthusiast and Xenotix project lead

toolsmith: OWASP ZAP - Zed Attack Proxy

Prerequisites

Java Runtime Environment

ZAP runs on Linux, Mac OS X, and Windows

Happy Thanksgiving: "As we express our gratitude, we must never forget that the highest appreciation is not to utter words, but to live by them." -JFK

Introduction

November 2011’s toolsmith is the 61^st in the series for the ISSA Journal, thus marking five years of extensive tools analysis for information security practitioners. Thank you for coming along for the ride.

Fresh on the heels of a successful presentation on OWASP Top 10 Tools and Tactics at an even more successful ISSA International in Baltimore I was motivated to give full coverage this month to the OWASP Zed Attack Proxy, better known as ZAP. I had presented ZAP as a tool of choice when assessing OWASP Top Ten A1 – Injection but, as so many of the tools discussed, ZAP delivers plenty of additional functionality worthy of in-depth discussion.

OWASP ZAP is a fork of the once favored Paros Proxy, which has not been updated since August 2006. As such, it should be noted with no small irony that we covered Paros in December 2006; this is an excellent opportunity to show you how far ZAP has come from the original project.

ZAP is the result of Simon Bennetts’ (Psiinon) hard work, though he’s got help from co-lead Axel Neumann (@a_c_neumann) and many contributors.

As an official OWASP project, ZAP enjoys extensive use and development support as an “easy to use integrated penetration testing tool for finding vulnerabilities in web applications.”

Simon offered a veritable plethora of feedback for this article, as provided throughout the rest of the introduction. He indicated that he originally released ZAP specifically for developers and functional testers; a group which he believes is poorly represented in the security tools market.

Ease of use was a prime concern, as was documentation and to his surprise it turned out that it was the security folk who took up ZAP the quickest, providing great feedback, reporting issues and asking for lots of enhancements. Simon still wants ZAP to be ideal for people new to web application security but it’s also going to be enhanced with more and more advanced features aimed at profession penetration testers.

Simon also wanted ZAP to be a community project; there are many open source security tools that are tightly controlled by one individual or company. While he doesn’t have a problem with that fact he does believe that the real strength of open source comes when anyone can contribute to a project and take it in directions its initial developers never envisaged.

Anyone and everyone is welcome to contribute to ZAP, and not necessarily coding only; they welcome help with testing, documentation, localization, issues identification and enhancement requests. Help spread the word as well via articles, reviews, videos, blogs, Twitter, etc.

ZAP is also one of the few open source security tools to be fully internationalized. It has been translated into 10 languages and download statistics indicate that approximately half of the ZAP users worldwide are likely to be non-native English speakers.

ZAP is intended to provide everything that you need to perform a penetration test on a web application.

If you are new to web application security then it might be the only security tool you need. However, if you're an experienced penetration tester be sure to include it as one of the many tools in your toolbox.

As a result, the development team is trying to make it as easy as possible to integrate ZAP with other tools. They provide a way to invoke other applications from within ZAP passing across the current context. In version 1.3 they introduced an API which allows the core ZAP functionality to be invoked by a REST API, and will be extended to cover even more of ZAP's features in future releases.

This is an ideal way for other applications to directly drive ZAP, and can be used when ZAP is running in 'headless' mode (i.e. without the UI).

They've also put together a POC showing how ZAP can be used by developers to include basic security tests in their continuous integration framework and be alerted to potential security vulnerabilities within hours of checking code.

Simon and team don’t believe in reinventing the wheel, which is why they always seek high quality open source components to reuse before implementing a new feature from scratch.

As such, the brute force/forced browsing support is provided via DirBuster and fuzzing makes use of the JBroFuzz libraries (both OWASP projects).

Amongst the more advanced features that users might not be aware of is that ZAP keeps track of all of the anti-CSRF tokens it finds. If fuzzing a form with an anti CSRF-token in it, ZAP can regenerate the token for each of the payloads you fuzz with. There’s also an experimental option that allows this to be turned on when using the active scanner as well. I can say that quality CSRF testing is not commonplace among ZAP’s web application testing contemporaries.

For ZAP version 1.4 the development team has decided to focus on:

·         Improving the active and passive scanners

·         Improving stability (especially for large sites)

·         Session token analysis

In July 2011 ZAP was evaluated and designated as a 'stable' OWASP project, the highest level currently available. Further, OWASP projects are now being restructured; ZAP has been designated as one of the small number of 'flagship' projects.

Rightfully so; thank you Simon.

Let’s run ZAP through its paces.

ZAP Installation and Configuration

ZAP is installation is very simple. Once unpacked on your preferred platform, invoke ZAP from the application icon or at the command prompt via the appropriate executable. A current Java Runtime Environment is a requirement as all the executables (EXE, BAT, SH) invoke java –jar zap.jar org.zaproxy.xap.ZAP.

Most importantly ZAP, runs as a proxy. Configure your preferred browser to proxy via localhost and the default port of 8080. I change the port to 8088 to avoid conflict with other proxies and services. You can change the port under Tools à Options à Local proxy if you run multiple proxies that you bounce between during assessments. I do and as such I use the Firefox add-on FoxyProxy to quickly dial in my proxy of choice.

You must also generate an SSL certificate in order to use and test SSL enabled sites. You will be prompted to do when running ZAP for the first time.

ZAP Use

In addition to the aforementioned Security Regression Tests for developers, the OWASP ZAP project offers ZAP Web Application Vulnerability Examples, or ZAP WAVE. Download it and drop zap-wave.war in the webapps directory of your favorite servlet engine. On Debian/Ubuntu systems sudo apt-get install tomcat6 will get you in business with said servlet engine quickly. In addition to a LAMP stack on an Ubuntu 11.10 VM I run Tomcat for just such occasions. OWASP WebGoat also runs as a standalone test bed or via a servlet engine.

Enable ZAP, with your browser configured to proxy through it, then navigate to the system (VM or real steel) hosting ZAP WAVE, usually on port 8080. As an example: http://192.168.140.137:8080/zapwave/.

ZAP WAVE includes “active” vulnerabilities such as cross-site scripting and SQL injection as well as “passive” vulnerabilities including three types of information leakage and two session vulnerabilities.

There are also pending false positives that are not yet ready for primetime.

The developers recommend that you explore the target app with ZAP enabled as a proxy, and touch as much of it as possible before spidering. Doing so helps ZAP find more vulns as you may cross paths with error messages, etc.

I typically visit the root of the application hierarchy for a web application I wish to assess, right-click on it, select Attack, then Spider site. This crawls the entire site hierarchy and populates the tree view under the Sites tab in ZAP’s left pane as seen in Figure 1.

Figure 1: ZAP spidering

Crawling/spidering can have unintended side-effects on an application, even adding or deleting records in a database, so be advised.

A good crawl ensures a better active scan, but before beginning a scan, set your Scan Policy via Analyze à Scan Policy as seen in Figure 2. You may wish to more narrowly scope your scan activity to just the likes of information gathering or SQL injection as seen in Figure 2.

Figure 2: ZAP scan policy

Spidering and scan policy configuration complete, right click the root, or a specific node you wish to assess as you can choose Attack à Active scan site or Attack à Active scan node.

You can also exclude a site from the scope in a similar fashion.

A full scan of the ZAP WAVE instance completed in very short order; results were immediate as seen in Figure 3.

Figure 3: ZAP scan results

ZAP includes the expected Encode/Decode/Hash functionality via Edit à Encode/Decode/Hash or Tools à Encode/Decode/Hash along with a manual editor for generating manual requests. I’ll often run ZAP for nothing more than encoding, decoding, and hashing; it’s a great utility.

The Port Scan feature is also useful. It will select the in-scope host by default; just click the Port Scan tab then the start button.

The Brute Force tab is a function of the above-mentioned DirBuster component and includes seven dictionary lists to choose from. I ran this against my full host VM rather just the servlet element and included the dictionary-list-1.0 dictionary for a simple, quick test.

Figure 4: ZAP DirBuster at work

One of my favorite ZAP features (there are many) is the Fuzzer. Per the Fuzzer component guidance:

·         Select a request in the Sites or History tab

·         Highlight the string you wish to fuzz in the Request tab

·         Right click in the Request tab and select 'Fuzz...'

·         Select the Fuzz Category and one or more Fuzzers

·         Press the Fuzz button

·         The results listed in the Fuzzer tab - select them to see the full requests and responses.

The fuzzer, like the scanner, includes functionality which causes ZAP to automatically regenerate the tokens when required

I ran Fuzzer against http://192.168.140.137:8080/zapwave/active/xss/xss-form-anti-csrf.jsp and fuzzed the anticsrf and name variables as it is a recent addition per the ZAP WAVE download site.

As seen in Figure 5, the fuzzer offers a wider array fuzzers within a given category.

FIGURE 5: ZAP fuzzer config

In the understanding that fuzzing is the art of submitting a great deal of invalid or unexpected data to a target, you can look for variations in results such as response code (200 OK) and response times. Where normal response times per request average between 2ms and 4ms for ZAP WAVE hosted on a local VM, one request in particular stood out at a 402ms response time. I checked for the string passed and cracked up.

%3CIMG+SRC%3D%60javascript%3Aalert%28%22RSnake+says%23%23%23+%27XSS%27%22%29%60%3E

Or, courtesy of the handy ZAP decoder:

Mr. Slowloris HTTP DoS himself causing grind even here. ;-)

In Conclusion

ZAP deserves its status as an OWASP flagship project. Whether you’re a seasoned veteran or new to the web application security game make the Zed Attack Proxy part of your arsenal. I’d go so far as to say, as 2011 is winding down, that ZAP feels like a likely front runner for 2011 Toolsmith Tool of the Year. But that is for you to decide, dear reader. Let me know if you agree.

Ping me via email if you have questions (russ at holisticinfosec dot org).

Cheers…until next month.

Acknowledgements

Simon Bennetts (Psiinon) for project feedback and details

Axel Neumann (@a_c_neumann) for draft review

OWASP Top 10 Tools and Tactics @ InfoSec Resources

I've been a busy lad of late and haven't been keeping up on posts, but I have been turning out some work elsewhere.
If you haven't already taken note, checkout my second installment for InfoSec Resources, specifically OWASP Top 10 Tools and Tactics.
It even made #4 on Reddit under NetSec and was March 24th's Post of the Day on PenTestIT. ;-)

{excerpt}

Lesson 1:

Software will always have bugs and by extension, security vulnerabilities. Therefore, a practical goal for a secure software development lifecycle (SDLC) should be to reduce, not necessarily eliminate, the number of vulnerabilities introduced and the severity of those that remain.

Lesson 2:

Exploitation of just one website vulnerability is enough to significantly disrupt online business, cause data loss, shake customer confidence, and more. Therefore, the earlier vulnerabilities are identified and the faster they are remediated the shorter the window of opportunity for an attacker to maliciously exploit them.

The conclusion is therefore simple: reduction and remediation of web application security flaws will shrink the number of attack vectors and improve security posture. Ground breaking, right? No, it’s old news, “security posture” is a worn out buzz phrase, and if everyone was diligent about the above mentioned reduction and remediation, we’d likely not need a Top 10 list or a 12th Website Security Statistic Report (count on one). But hey, then we’d have to find different work, right?

Gifford Pinchot once said “Never bet on a race unless you are running in it.”

As solutions are always better than complaints, let’s discuss how to get in the race with some tooling options as we explore each of the Top 10.

{/excerpt}

You know I'm an SDLC fan, and an ardent supporter of OWASP. This article blends those passions along with some insight as to how I conduct web application vulnerability research.

Note: Over the next few months, I'll be drilling into to each of the OWASP Top Ten, exploring the specific vulnerability and the aforementioned tooling and tactics to aid in better discovery and mitigation.
Look forward to those followup articles at InfoSec Resources.

Hope you enjoy.
Cheers.

Verizon Data Breach Report & OWASP Top 10's #6

The fact that Computerworld's Jeremy Kirk just reported that data breaches are often caused by configuration errors (as noted in Verizon's latest data breach report) should come as no surprise, yet I'm left shaking my head in continued disbelief at this issue's prevalence.

Per Jeremy, as summarized from the report:
"Verizon said it found that a surprising and "even shocking" trend is continuing: There are fewer attacks that focus on a software vulnerabilities than attacks that focus on configuration weaknesses or sloppy coding of an application."

Now we now why security misconfiguration is new to the OWASP Top 10 as of 2010, holding the #6 position.
Consider Figure 1 as ripped right from the OWASP Top 10 doc.


Figure 1

Can we agree that data breach qualifies as a "business impact"?

A recent example of classic security misconfiguration includes the design flaw in WordPress that, by default, allowed users to set up permissions that let anyone read their blog's wp-config.php configuration file; WordPress stores the bloggers' credentials in plain text (also OWASP Top 10 A9).
An attacker could create a scanner to locate all configuration files containing incorrect permissions, read database credentials, and compromise all found.


Figure 2

So easily avoided.

OWASP's recommendations include:
1. A repeatable hardening process that makes it fast and easy to deploy another environment that is properly locked down. Dev, QA, and production environments should all be configured the same. This process should be automated to minimize the effort required to setup a new secure environment.
2. A process for keeping abreast of and deploying all new software updates and patches in a timely manner to each deployed environment.
3. A strong network architecture that provides good separation and security between components. Consider running automated scans periodically to help you detect future misconfiguration or missing patches.

Make it so!

Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)