toolsmith: Social-Engineer Toolkit (SET) - Pwning the Person

Prerequisites/dependencies

Python interpreter

Metasploit

BackTrack 5 R3 also includes SET

Introduction

My first discussion of  Dave Kennedy’s (@dave_rel1k) Social-Engineer Toolkit (SET) came during exploration of the Pwnie Express PwnPlug Elite for March 2012’s toolsmith.  It was there I talked about the Site Cloner feature found under Website Attack Vectors and Credential Harvesting Attack Methods. Unless you’ve been hiding your head in the sand (“if I can’t see the security problem, then it doesn’t exist”) you’re likely aware that targeted attacks such as spear phishing, whaling, and social engineering in general are prevalent. Additionally, penetration testing teams will inevitably fall back on this tactic if it’s left in scope for one reason: it always works. SET serves to increase awareness for all the possible social engineering vectors; trust me, it is useful for striking much fear in the hearts of executives and senior leaders at client, enterprise, and military briefings. It’s also useful for really understanding the attacker mindset. With distributions such at BackTrack including SET, fully configured and ready to go, it’s an absolute no brainer to add to your awareness briefing and/or pen-testing regimen.   

Dave is the affable and dynamic CEO of TrustedSec (@trustedsec) and, as SET’s creator, describes it in his own words:

The Social-Engineer Toolkit has been an amazing ride and the support for the community has been great. When I first started the toolkit, the main purpose was to help out on social engineering gigs but it's completely changed to an entire framework for social-engineering and the community. SET has progressed from a simple set of python commands and web servers to a full suite of attacks that can be used for a number of occasions. With the new version of SET that I'm working on, I want to continue to add customizations to the toolkit where it allows you to utilize the multi attack vector and utilize it in a staged approach that’s all customized. When I'm doing social-engineering gigs, I change my pretext (attack) on a regular basis. Currently, I custom code some of my options such as credential harvester first then followed by the Java Applet. I want to bring these functionalities to SET and continue forward with the ability to change the way the attack works based on the situation you need. I use my real life social-engineering experiences with SET to improve it, if you have any ideas always email me to add features!

Be sure to catch Dave’s presentation videos from DEFCON and DerbyCom, amongst others, on the TrustedSec SET page.

Quick installation notes

It’s easiest to run SET from BackTrack. Boot to it via USB or optical media, or run it as a virtual machine. Navigate to Applications | BackTrack | Exploitation Tools | Social Engineering Tools | Social Engineering Toolkit | set and you’re off to the races.

Alternatively, on any system where you have a Python interpreter and a Git (version control/source code management) client, you can have SET up and running in minutes. Ideally, the system you choose to run SET from should have Metasploit configured too as SET calls certain Metasploit payloads, but it’s not a hard, fast dependency. If no Metasploit, many SET features won’t work, simple. But if you plan to go full goose bozo…you catch my drift.

I installed set on Ubuntu 12.10 as well as Windows 7 64-bit as simply as running git clone https://github.com/trustedsec/social-engineer-toolkit/ set/ from a Bash shell (Ubuntu) or Git Shell (Windows). Note: if you’re running anti-malware on a Windows system where SET is to be installed, be sure to build an exclusion for the SET path or AV will eat some key exploits (six to be exact). A total bonus for you and I occurred as I wrote this. On 24 JAN, Dave released version 4.4.1 of SET, codename “The Goat.” If you read the CHANGES file in SET’s readme directory you’ll learn that this release includes some significant Java Applet updates, encoding and encryption functionality enhancements, and improvements for multi_pyinjector. I updated my BackTrack 5 R3 instance to SET 4.4.1 by changing directory to /pentest/exploits, issuing mv set set_back, then the above mentioned git command. Almost instantly, a shiny new SET ready for a few laps around the track.  Your SET instance needs to be available via the Internet for remote targets to phone home to, or exposed to your local network for enterprise customers. You’ll be presenting a variety of offerings to your intended victims via the SET server IP or domain name.

SET unleashed

Now to rapid fire some wonderful social engineering opportunities at you. How often do you or someone you know wander up to a sign or stop at a web page with a QR code and just automatically scan it with your smart phone? What if I want to send you to any site of my choosing? I’ll simply generate a QR code with the URL destination I want to direct you to. If I’m a really bad human being that site might be offering up the Blackhole exploit kit or something similar. Alternatively, as SET recommends when you choose this module, “when you have the QRCode generated, select an additional attack vector within SET and deploy the QRCode to your victim. For example, generate a QRCode of the SET Java Applet and send the QRCode via a mailer.”

From the SET menu, choose 1) Social-Engineering Attacks, then 9) QRCode Generator Attack Vector, and enter your desired destination URL. SET will generate the QR code and write it to /pentest/exploits/set/reports-qr_attack.png as seen in Figure 1.

Figure 1: QR Code attack generated by SET

From SET’s main menu, 3)Third Party Modules will offer you the RATTE Java Applet Attack (Remote Administration Tool Tommy Edition), and 2) Website Attack Vectors | 1) Java Applet Attack Method will provide templates or site cloning with which you can delivery one heck of a punch via the QR code vector.

Our good friend Java is rife for social engineer targeting opportunities and SET offers mayhem aplenty to capitalize on this fact.  Here’s a sequence to follow from the SET menu:

1) Social-Engineering Attacks | 2) Website Attack Vectors | 1) Java Applet Attack Method | 1) Web Templates

Answer yes or no to NAT/Port Forwarding, enter your SET server IP or hostname, and select 1 for the Java Required template as seen in Figure 2.

Figure 2: Java applet prepped for deployment

You’ll then need to choose what payload you wish to generate. Methinks ye olde Windows Reverse_TCP Meterpreter Shell (#2 on the list) is always a safe bet. Select it accordingly. From the list of encodings, #16 on the list (Backdoored Executable) is described as the best bet. Make it so. Accept 443 as the default listener port and wait while SET generates injection code as seen in Figure 3.

Figure 3: SET-generated injection code

The Metasploit framework will then launch (wake up, Neo...the matrix has you…follow the white rabbit) and the handlers will standby for your victim to come their way.

Now, as the crafty social engineer that you are, you devise an email campaign to remind users of the “required Java update.” By the way, this campaign can be undertake directly from SET as well via 1) Social-Engineering Attacks | 5) Mass Mailer Attack. When one or more of your victims receives the email and clicks the embedded link they’ll be sent to your SET server where much joy awaits them as seen in Figure 4.

Figure 4: Victim presented with Java required and “trusted” applet

When the victim selects Run, and trust me they will, the SET terminal on the SET server will advise you that a Meterpreter session has been opened with the victim as seen in Figure 5.

Figure 5: Anyone want a shell?

For our last little bit of fun, let’s investigate 3) Infectious Media Generator under 1) Social-Engineering Attacks. If you select File-Format Exploits, after setting up your listener, you’ll be presented with a smorgasbord of payload. I selected 16) Foxit PDF Reader v4.1.1 Title Stack Buffer Overflow as I had on old VM with an old Foxit version on it. Sweet! When I opened the fileformat exploit PDF created by SET with the Foxit 4.1.1, well…you know what happened next.

As discussed in the PwnPlug article, don’t forget the Credential Harvester Attack Methods under Website Attack Vectors. This is quite literally my favorite delivery vehicle as it is utterly bomb proof. Nothing like using the templates for your favorite social media sites (you know who you are) and watching as credentials roll in.

In Conclusion

Evil-me really loves SET; it’s more fun than a clown on fire. Remember, as always with tools of this ilk, you’re the good guy in this screenplay. Use SET to increase awareness, put the fear of God in your management, motivate your clients, and school the occasional developer. Anything else is flat out illegal. J As Dave mentioned, if you have ideas for new features or enhancements for SET, he really appreciates feedback from the community.

Ping me via email if you have questions or suggestions for topic via russ at holisticinfosec dot org or hit me on Twitter via @holisticinfosec.

Cheers…until next month.

Acknowledgements

Dave Kennedy, Founder, TrustedSec, SET project lead

2012 Toolsmith Tool of the Year: ModSecurity for IIS

Congratulations to Ryan Barnett of Trustwave and Greg Wroblewski of Microsoft.
ModSecurity for IIS is the 2012 Toolsmith Tool of the Year.
ModSecurity for IIS finished with 35.4% of the vote, while the Pwnie Express Pwn Plug came in second with 22.8%, and the Arachni Web Application Security Scanner came in third with 18.1% of the votes.

As ModSecurity is best utilized with the OWASP ModSecurity Core Rule Set (CRS), I will make a $50 donation to the CRS Project. I strongly advocate for your supporting this project as well; any amount will help.

Congratulations and thank you to all of this year's participants; we'll have another great round in 2013.

toolsmith: Violent Python - A Book Review Applied to Security Analytics

Prerequisites/dependencies

Python interpreter

BackTrack 5 R3 is ideally suited to make immediate use of Violent Python scripts

Introduction

Happy New Year and congratulations on surviving the end of the world as we know it (nyah, nyah Mayan calendar). Hard to imagine we’re starting yet another year already; 2012 simply screamed by. Be sure to visit the HolisticInfoSec blog post for the 2012 Toolsmith Tool of the Year and vote for your favorite tool of 2012.

I thought I’d start off 2013 with a bit of a departure from the norm. Herein is the first treatment of a book as a tool where the content and associated code can be utilized to perform duties specific to the information security practitioner. I can think of no better book with which to initiate this approach than TJ O’Connor’s Violent Python, A Cookbook for Hackers, Forensic Analysts, Penetration Testers, and Security Engineers. Yes, this implies that you should buy the book; trust me, it’s worth every dime of the $34. Better still, TJ has donated all his proceeds to the Wounded Warrior Project. That said, I’ll post TJ’s three scripts we’ll discuss here so as to whet your appetite. I’ve had the distinct pleasure of working with TJ as part of the SANS Technical Institute’s graduate program where we, along with Beth Binde, wrote AssessingOutbound Traffic to Uncover Advanced Persistent Threat. I’ve known some extremely bright capable information security experts in my day and I can comfortably say TJ is hands down amongst the very best of that small group. As part of his service as an officer in the U.S. Army (hooah) TJ has served as the course director for both computer exploitation and digital forensics at the US Military Academy and as an communications officer supporting tactical communications. His book maps nicely to a philosophy I embrace and incorporate in the workplace. Security monitoring, incident response (and forensics), and attack and penetration testing are the three pillars of security analytics, each feeding and contributing the others in close cooperation. As an example, capable security monitoring inevitably leads to a need for incident response, and after mitigation and remediation have ensued, penetration testing is key to validating that corrective measures were successful, which in turn helps the monitoring team assess and tune detection and alerting logic. Security analytics: the information security circle of life J.

How does a book such as TJ’s Violent Python reverberate with this philosophy? How about entire chapters dedicated to each of the above mentioned pillars, including Python scripts for network traffic analysis (monitoring), forensic investigations (IR), as well as web recon and penetration testing. We’ll explore one script from each discipline shortly, but not before hearing directly from the author:

“In a lot of ways writing a book is a cathartic experience where you capture a lot of things you have done. All too often I'm writing scripts to achieve an immediate effect and then I throw away the script. For me the book was an opportunity to capture a lot of those small projects I've done and simplify the learning curve for others. My favorite example was the UAV takeover in the book. We show how to take over any really Ad-Hoc WiFi toys in under 70 lines of code. A few friends joked that I couldn't write a script in under 100 lines to crash a UAV. This was my chance to provide them a working concept and it worked! Unfortunately it left my daughter with a toy UAV cracked into several pieces as I refined the code. From a defensive standpoint, understanding a scripting language is absolutely essential in my opinion. The ability to parse data such as DNS traffic or geo-locate IP traffic (both shown in the book) can give a great deal of visibility. Forensics tools are great but the ability to build your own are even better. We show how to write tools to parse out iPhone backups for data and scrape for specific objects. The initial feedback from the book has been overwhelming and I've really enjoyed hearing positive feedback. No future plans right now but a good friend of mine has mentioned writing "Violent Powershell" so we'll see where that goes.”    

Violent Python provides readers the basis for scripts to attack network services, analyze digital artifacts, investigate network traffic for malicious activity, and data-mine social media, not to mention numerous other activities. This is a must-read book that includes a companion site with all the code discussed. Let’s take a closer look at three of these efficient and useful Python scripts.

Making Use of Violent Python

As noted above, I’ve posted the three scripts discussed in this section, along with the PCAP and PDF (malicious) discussed on my website. Email or Tweet for the zip passwords.

TJ suggests utilizing a BackTrack distribution given that many of the dependencies and libraries required to use the scripts in this book are inherent to BackTrack. We’ll follow suit on a BackTrack 5 R3 virtual machine. Before beginning, we’ll need to set up a few prerequisites. Execute easy_install pyPDF python-nmap pygeoip mechanize BeautifulSoup4 at the BT5R3 root prompt. This will install pygeoip as needed for our first exercise. I’m going to conduct these exercises a bit out of chapter sequence in order to follow the security analytics lifecycle starting with monitoring. This drops us first into Chapter 4 where we’ll utilize MaxMind’s GeoLiteCity to map IP addresses to cities. In order to do so, you’ll need to set up GeoLiteCity on BackTrack or your preferred system with the following steps:

1.  mkdir /opt/GeoIP

2.  cd /opt/GeoIP/

3.  wget http://geolite.maxmind.com/download/geoip/database/GeoLiteCity.dat.gz

4.  gunzip GeoLiteCity.dat.gz

You’ll then need to edit line 7 of geoPrint.py to read gi = pygeoip.GeoIP('/opt/GeoIP/GeoLiteCity.dat') or download the updated copy of the script I’ve posted for you.

I’ve created a partially arbitrary scenario for you with which to walk through the security analytics lifecycle using Violent Python. To do so I’ll refer to what was, in 2009 an actual malicious domain, used to host shellcode for PDF-based malware attacks. I grabbed a malicious PDF sample from Contagio, an excellent sample resource. The IP address I associate with this domain is where I am taking creative liberties as the domain we’ll discuss, ax19.cn, no longer exists, and there is no record of what its IP address was when it was in use. The PCAP we’ll use here is one I edited with bittwiste to arbitrarily introduce a suspect Chinese IP address to what was originally a packet capture from a machine compromised by Win32.Banload.MC. I’ve shared this PCAP and the PDF as mentioned above so you can try the Python scripts with them for yourself.  

In this scenario, your analysis machine is Linux only. Just you, a Python interpreter, and a shell; no fuss, no muss.

As we’re starting in the monitoring phase, imagine you have a network for which the traffic baseline is well understood. You can assert, from one particular high value VLAN, that at no time should you ever see traffic bound for China.  Your netflow monitoring for that VLAN is showing far more egress traffic bound for IP space that is not on your approved list established from learned baselines. You initiate a real-time packet capture to confirm. Capture (suspect.pcap) in hand, you’d like to validate that the host is indeed conversing with an IP address in China. Violent Python’s geoPrint.py script is a great place to start as it leverages the above-mentioned GeoLiteCity data from MaxMind along with the PyGeoIP library from Jennifer Ennis and dpkt. Execute python geoPrint.py -p suspect.pcap and you’ll see results as noted in Figure 1.

Figure 1: geoPrint.py confirms Chinese takeout

Your internal host (RFC 1918, and thus unregistered) with IP address 192.168.248.114 is clearly conversing with 116.254.188.24 in Beijing. Uh-oh.

Your team now moves into incident response mode and seizes the host in question. You interview the system’s user who indicates they received an email what the user thought was a legitimate help desk notification to read a new policy. The email had an attached PDF file which the user downloaded and opened. Your suspicions are heightened, as such you grab a copy of the PDF and head back to your analysis workstation. You’re interested to see if there is any interesting metadata in the PDF that might help further your investigation. You refer to Chapter 3 of Violent Python which discusses Forensic Investigations with Python. The pdfRead.py script incorporates the PyPDF library which allows you to extract PDF document information (metadata) in addition to other capabilities. Execute python pdfRead.py -F suspect.pdf and dump the metadata as seen in Figure 2.

Figure 2: pdfRead.py dumps suspect PDF metadata

The author reference is a standout for you; from a workstation with a browser you search “Zeon Technical Publications” and find reference to it on VirusTotal and JSunpack; these results along with a quick MD5sum hash match indicate that this PDF is clearly malicious. The JSunpack reference indicates that shellcode phones home to www.ax19.cn (see Figure 3), a domain for which you’d now like to learn more.

Figure 3: JSunpack confirms an evil PDF

You could have sought anonymity to conduct the above mentioned search, which lead us to the third pillar of our security analytics lifecycle. This third phase here includes web recon as discussed in Chapter 6 of Violent Python, a common step in the attack and penetration testing discipline, to see what more we can learn about this malicious domain. As we often seek anonymity during the recon phase, Violent Python allows you maintain a bit of stealth by leveraging the deprecated Google API against which a few queries a day can still be executed. The newer API requires a developer’s key which one can easily argue is not anonymous. Executing python anonGoogle.py -k 'www.ax19.cn' will return yet another validating result as seen in Figure 4.

Figure 4: anonGoogle matches ax19.cn to malicious activity

With seven rich chapters of Python goodness, TJ’s Violent Python represents a golden opportunity to expanding your security analytics horizons. There is so much to learn from here while accentuating your use of Python in your information security practice.

In Conclusion

I’m hopeful this slightly different approach to toolsmith was useful for you this month. I’m looking to shake things up a bit here in 2013 and am certainly open to suggestions you may have regarding ideas and approaches to doing so. Violent Python was a great read for me and a pleasure to put to use for both this article as well as in my personal tool box. I’m certain you’ll find this book equally useful.

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

Cheers…until next month.

Acknowledgements

TJ O’Connor, Violent Python author

Mila Parkour, Contagio

Choose the 2012 Toolsmith Tool of the Year

Merry Christmas and Happy New Year! It's that time again.
Please vote below to choose the best of 2012, the 2012 Toolsmith Tool of the Year.
We covered some outstanding information security-related tools in ISSA Journal's toolsmith during 2012; which one do you believe is the best?
I appreciate you taking the time to make your choice.
Review all 2012 articles here for a refresher on any of the tools listed in the survey.
You can vote through January 31, 2013. Results will be announced February 1, 2013

Create your free online surveys with SurveyMonkey, the world's leading questionnaire tool.

toolsmith: ModSecurity for IIS

Part 2 of 2 - Web Application Security Flaw Discovery and Prevention

Prerequisites/dependencies

Windows OS with IIS (Win2k8 used for this article)

SQL Server Express 2004 SP4 and Management Studio Express for vulnerable web app

.NET Framework 4.0 for ModSecurity IIS

Introduction

December’s issue continues where we left off in November with part two in our series on web application security flaw discovery and prevention. In November we discussed Arachni, the high-performance, modular, open source web application security scanning framework. This month we’ll follow the logical work flow from Arachni’s distributed, high-performance scan results to how to use the findings as part of mitigation practices. One of Arachni’s related features is WAF Realtime Virtual Patching.

Trustwave Spider Lab’s Ryan Barnett has discussed the concept of dynamic application scanning testing (DAST) data that can be imported into a web application firewall (WAF) for targeted remediation. This discussion included integrating export data from Arachni into ModSecurity, the cross–platform, open source WAF for which he is the OWASP ModSecurity Core Rule Set (CRS) project leader. I reached out to Ryan for his feedback with particular attention to ModSecurity for IIS, Microsoft’s web server.

He indicated that WAF technology has gained traction as a critical component of protecting live web applications for a number of key reasons, including:

1)      Gaining insight into HTTP transactional data that is not provided by default web server logging

2)      Utilizing Virtual Patching to quickly remediate identified vulnerabilities

3)      Addressing PCI DSS Requirement 6.6

The ModSecurity project is just now a decade old (first released in November 2002), has matured significantly over the years, and is the most widely deployed WAF in existence protecting millions of websites. “Until recently, ModSecurity was only available as an Apache web server module. That changed, however, this past summer when Trustwave collaborated with the Microsoft Security Response Center (MSRC) to bring the ModSecurity WAF to the both the Internet Information Services (IIS) and nginx web server platforms.  With support for these platforms, ModSecurity now runs on approximately 85% of internet web servers.” 

Among the features that make ModSecurity so popular, there are a few key capabilities that make it extremely useful:

It has an extensive audit engine which allows the user to capture the full inbound and outbound HTTP data.  This is not only useful when reviewing attack data but is also extremely valuable for web server administrators who need to trouble-shoot errors.

·         It includes a powerful, event-driven rules language which allows the user to create very specific and accurate filters to detect web-based attacks and vulnerabilities.

·         It includes an advanced Lua API which provides the user with a full-blown scripting language to define complex logic for attack and vulnerability mitigation.

·         It also includes the capability to manipulate live transactional data.  This can be used for a variety of security purposes including setting hacker traps, implementing anti-CSRF tokens, or Cryptographic HASH tokens to prevent data manipulation.

In short, Ryan states that ModSecurity is extremely powerful and provides a very flexible web application defensive framework that allows organizations to protect their web applications and quickly respond to new threats.

I also sought details from Greg Wroblewski, Microsoft’s lead developer for ModSecurity IIS.

“As ModSecurity was originally developed as an Apache web server module, it was technically challenging to bring together two very different architectures. The team managed to accomplish that by creating a thin layer abstracting ModSecurity for Apache from the actual server API. During the development process it turned out that the new layer is flexible enough to create another ModSecurity port for the nginx web server. In the end, the security community received a new cross-platform firewall, available for the three most widely used web servers.

The current ModSecurity development process (still open, recently migrated to GitHub) preserves compatibility of features between three ported versions. For the IIS version, only features that rely on specific web server behavior show functional differences from the Apache version, while the nginx version currently lacks some of the core features (like response scanning and content injection) due to limited extensibility of the server. Most ModSecurity configuration files can be used without any modifications between Apache and IIS servers. The upcoming release of the RTM version for IIS will include a sample of ModSecurity OWASP Core Rule Set in the installer.

Installing ModSecurity for IIS

In order to test the full functionality of ModSecurity for IIS I needed to create an intentionally vulnerable web application and did so following guidelines provided by Metasploit Unleashed. The author wrote these guidelines for Windows XP SP2, I chose Windows Server 2008 just to be contrarian. I first established a Win2k8 virtual machine, enabled the IIS role, downloaded and installed SQL Server 2005 Express SP4, .NET Framework 4.0, as well as SQL Server 2005 Management Studio Express, then downloaded and the ModSecurity IIS 2.7.1 installer. We’ll configure ModSecurity IIS after building our vulnerable application. When configuring SQL Server 2005 Express ensure you enable SQL Server Authentication, and set the password to something you’ll use in the connection string established in Web.config. I used p@ssw0rd1 to meet required complexity. J Note: It’s “easier” to build a vulnerable application using SQL Server 2005 Express rather than 2008 or later; for time’s sake and reduced troubleshooting just work with 2005. We’re in test mode here, not production. That said, remember, you’re building this application to be vulnerable by design. Conduct this activity only in a virtual environment and do not expose it to the Internet. Follow the Metasploit guidelines carefully but remember to establish a proper connection string in the Web.config (line 4) and build it from this sample I’m hosting for you rather than the one included with the guidelines. As an example, I needed to establish my actual server name rather than localhost, I defined my database name as crapapp instead of WebApp per the guidelines, and used p@ssw0rd1 instead of password1 as described:

I also utilized configurations recommended for the pending ModSecurity IIS install so go with my version.

Once you’re finished with your vulnerable application build you should browse to http://localhost and first pass credentials that you know will fail to ensure database connectivity. Then test one of the credential pairs established in the users table, admin/s3cr3t as an example. If all has gone according to plan you should be treated to a successful login message as seen in Figure 1.

FIGURE 1: A successful login to CrapApp

ModSecurity IIS installation details are available via TechNet but I’ll walk you through a bit of it to help overcome some of the tuning issues I ran into. Make sure you have the full version of .NET 4.0 installed and patch it in full before you execute the ModSecurity IIS installer you downloaded earlier.

Download the ModSecurity OWASP Core Rule Set (CRS) and as a starting point copy the files from the base_rules to the crs directory you create in C:\inetpub\wwwroot. Also put the test.conf file I’m also hosting for you in C:\inetpub\wwwroot. This will call the just-mentioned ModSecurity OWASP Core Rule Set (CRS) that Ryan maintains and also allow you to drop any custom rules you may wish to create right in test.conf.

There are a few elements to be comfortable with here. Watch the Windows Application logs via Event Viewer to both debug any errors you receive as well as ModSecurity alerts once properly configured. I’m hopeful that the debugging time I spent will help save you a few hours, but watch those logs regardless. Also make regular use of the Internet Information Services (IIS) Manger to refresh the DefaultAppPool under Application Pools as well as restart the IIS instance after you make config changes. Finally, this experimental installation intended to help get you started is running in active mode versus passive. It will both detect and block what the CRS notes as malicious. As such, you’ll want to initially comment out all the HTTP Policy rules in order to play with the CrapApp we built above. To do so, open modsecurity_crs_30_http_policy.conf in the crs directory and comment out all lines that start with SecRule. Again, we’re in experiment mode here. Don’t deploy ModSecurity in production with the SecDefaultAction directive set to "block" without a great deal of testing in passive mode first or you’ll likely blackhole known good traffic.

Using ModSecurity and virtual patching to protect applications

Now that we’re fully configured, I’ll show you the results of three basic detections then close with a bit of virtual patching for your automated web application protection pleasure. Figure 2 is a mashup of a login in attempt via our CrapApp with a path traversal attack and the resulting detection and block as noted in the Windows Application log.

FIGURE 2: Path traversal attack against CrapApp denied

Similarly, a simple SQL injection such as ‘1=1-- against the same form field results in the following Application log entry snippet:

[msg "SQL Injection Attack: Common Injection Testing Detected"] [data "Matched Data: ' found within ARGS:txtLogin: '1=1--"] [severity "CRITICAL"] [ver "OWASP_CRS/2.2.6"] [maturity "9"] [accuracy "8"] [tag "OWASP_CRS/WEB_ATTACK/SQL_INJECTION"] [tag "WASCTC/WASC-19"] [tag "OWASP_TOP_10/A1"] [tag "OWASP_AppSensor/CIE1"] [tag "PCI/6.5.2"]

Note the various tags including a match to the appropriate OWASP Top 10 entry as a well as the relevant section of the PCI DSS.

Ditto if we pop in a script tag via the txtLogin parameter:

[data "Matched Data: "] [ver "OWASP_CRS/2.2.6"] [maturity "8"] [accuracy "8"] [tag "OWASP_CRS/WEB_ATTACK/XSS"] [tag "WASCTC/WASC-8"] [tag "WASCTC/WASC-22"] [tag "OWASP_TOP_10/A2"] [tag "OWASP_AppSensor/IE1"] [tag "PCI/6.5.1"]

    

Finally, we’re ready to connect our Arachni activities in Part 1 of this campaign to our efforts with ModSecurity IIS. There are a couple of ways to look at virtual patching as amply described by Ryan. His latest focus has been more on dynamic application scanning testing as actually triggered via ModSecurity. There is now Lua scripting that integrates ModSecurity and Arachni over RPC where a specific signature hit from ModSecurity will contact the Arachni service and kick off a targeted scan. At last check this code was still experimental and likely to be challenging with the IIS version of ModSecurity. That said we can direct our focus in the opposite direction to utilize Ryan’s automated virtual patching script, arachni2modsec.pl, where we gather Arachi scan results and automatically convert the XML export into rules for ModSecurity. These custom rules will then protect the vulnerabilities discovered by Arachni while you haggle with the developers over how long it’s going to take them to actually fix the code.

To test this functionality I scanned the CrapApp from Arachni instance on the Ubuntu VM I built for last month’s article. I also set the SecDefaultAction directive set to "pass" in my test.conf file to ensure the scanner is not blocked while it discovers vulnerabilities. Currently the arachni2modsec.pl script writes rules specifically for SQL Injection, Cross-site Scripting, Remote File Inclusion, Local File Inclusion, and HTTP Response Splitting. The process is simple; assuming the results file is results.xml, arachni2modsec.pl –f results.xml will create modsecurity_crs_48_virtual_patches.conf. On my ModSecurity IIS VM I’d then copy modsecurity_crs_48_virtual_patches.conf into the C:\inetpub\wwwroot\crs directory and refresh the DefaultAppPool. Figure 3 gives you an idea of the resulting rule.  

FIGURE 3: arachni2modsec script creates rule for ModSecurity IIS

Note how the rule closely resembles the alert spawned when I passed the simple SQL injection attack to CrapApp earlier in the article. Great stuff, right?

In Conclusion

What a great way to wrap up 2012 with the conclusion of this two-part series on Web Application Security Flaw Discovery and Prevention. I’m thrilled with the performance of ModSecurity for IIS and really applaud Ryan and Greg for their efforts. There are a number of instances where I intend to utilize the ModSecurity port for IIS and will share feedback as I gather data. Please let me know how it’s working for you as well should you choose to experiment and/or deploy.

Good luck and Merry Christmas.

Stay tuned to vote for the 2012 Toolsmith Tool of the year starting December 15^th.

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

Cheers…until next month.

Acknowledgements

Ryan Barnett, Trustwave Spider Labs, Security Researcher Lead

Greg Wroblewski, Microsoft, Senior Security Developer