Come To OpsCamp!
Next weekend, Jan 30 2009, there's a Web Ops get-together here in Austin called OpsCamp! It'll be a Web ops "unconference" with a cloud focus. Right up our alley! We hope to see you there.
Techniques in Attacking and Defending XML/Web Services
This presentation was by Jason Macy and Mamoon Yunus of Crosscheck Networks - Forum Systems. It wins the award (the one I just made up) for being the most vendor-oriented presentation at the conference. Not that it wasn't an interesting presentation, but their solution to defend against most of the attacks was "Use an XML Gateway" (guess what Forum Systems sells?) and the attacks were all presented using the CrossCheck SOAPSonar tool. I realize that being a vendor they probably have more knowledge than most in the field, but being an Open Source conference, you'd think they would have demonstrated using a free/open tool (SOAPUI?) and talked more about non-hardware solutions to fix the issues. My notes from the session are below:
Agenda
- Introduction to XML/Web Services Threats
- Techniques for Defending XML Threats
- XML Attack Examples and Classification
- Review sample attacks
Introduction to XML Threats
- Explicit Attacks
- Forced Disruption
- Information Theft
- Vendor Discovery
- Implicit Vulnerability
- Perimeter Breach (embeeded virus, malware)
- Infrastructure Malfunction (parser and data processing failures)
New Attack Vectors
- Protocol Firewalls are blind to XML
- Malware and virus delivered via SOAP attachments
- WSDL exposes schema and message structure
- Injection attacks exposed via XML parameters
- Data replay attacks
Security Testing - Base Requirements
- Security Framework
- Sign, ENcrypt, Decrypt, SSL
- Identity Framework
- Basic auth, SSL auth, WS-Security token auth
- Parameter Injection
- Database or file driven
- Permutations for security, identity, and SOAP/XML
- Concurrent Client Simultaneous Loading
- Denial of Service Testing
- SOAP with Attachments
- Malware and Virus testing
- Dynamic XSD Mutation
- Derive SOAP vulnerability profile from WSDL schema
OWASP Top 10 – 2010
This presentation was by Dave WIchers, COO of Aspect Security and an OWASP Board Member. My notes are below:
What's Changed?
- It's about Risks, not just vulnerabilities
- New title is: "The Top 10 Most Critical Web Application Security Risks"
- OWASP Top 10 Risk Rating Methodology
- Based on the OWASP Risk Rating Methodology, used to prioritize Top 10
- 2 Risks Added, 2 Dropped
- Added: A6 - Security Misconfiguration
- Was A10 in 2004 Top 10: Insecure Configuration Management
- Added: A8 - Unvalidated Redirects and Forwards
- Relatively common and VERY dangerous flaw that is not well know
- Removed: A3 - Malicious File Execution
- Primarily a PHP flaw that is dropping in prevalence
- Removed: A6 - Information Leakage and Improper Error Handling
- A very prevalent flaw, that does not introduce much risk (normally)
- Added: A6 - Security Misconfiguration
- A1- Injection: Tricking an application into including unintended commands in the data sent to an interpreter. (http://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet)
- A2 - Cross Site Scripting (XSS): Raw data from attacker is sent to an innocent user's browser. For large chunks of user supplied HTML, use OWASP's AntiSamy to sanitize this HTML to make it safe. (http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet)
- A3 - Broken Authentication and Session Management: Means credentials have to go with every request. Should use SSL for everything requiring authentication.
- A4 - Insecure Direct Object Reference: This is part of enforcing proper "Authorization", along with A7 - Failure to Restrict URL Access.
- A5 - Cross Site Request Forgery (CSRF): An attack where the victim's browser is tricked into issuing a command to a vulnerable web application. Vulnerability is caused by browsers automatically including user authentication data with each request. (Check out OWASP CSRFGuard, OWASP CSRFTester, http://www.owasp.org/index.php/CSRF_Prevention_Cheat_Sheet)
- A6 - Security Misconfiguration: All through the network and platform. Don't forget the development environment. Think of all the places your source code goes. All credentials should change in production.
- A7 - Failure to Restrict URL Access: This is part of enforcing proper "authorization", along with A4 - Insecure Direct Object References.
- A8 - Unvalidated Redirects and Forwards: Web application redirects are very common and frequently include user supplied parameters in the destination URL. If they aren't validated, attacker can send victim to a site of their choice.
- A9 - Insecure Cryptographic Storage: Storing sensitive data insecurely. Failure to identify all sensitive data. Failure to identify all the places that this sensitive data gets stored. Failure to properly protect this data in every location.
- A10 - Insufficient Transport Layer Protection
OWASP Top 10 Risk Rating Methodology
- Attack Vector (How hard for an attacker to use this flaw - 1 (Easy), 2 (Average), 3 (Difficult))
- Weakness Prevalence (How often is it found - 1 (Widespread), 2 (Common), 3 (Uncommon))
- Weakness Detectability (How hard is it for an attacker to find the flaw - 1 (Easy), 2 (Average), 3 (Difficult))
- Technical Impact (1 (Severe), 2 (Moderate), 3 (Minor))
This is generic across the internet, not specific to any organization.
Started a new "Prevention Cheatsheet Series" that the Top 10 references (XSS, SQL Injection, Transport Layer Security, CSRF, Direct Object Reference).
What is actually being released is RC1 of the Top 10 and they are encouraging people to provide comments through the end of the year and then use that feedback to post the final Top 10 in January 2010.
The ESAPI Web Application Firewall
This presentation was by Arshan Dabirsiaghi and was about the OWASP ESAPI Web Application Firewall (WAF) project. My notes are below:
WAF Fallacies (at least in regards to OWASP ESAPI WAF)
- WAFs add attack surface
- WAFs can create culture problems
- WAFs can't fix business logic vulnerabilities
- WAFs are way too expensive
- WAFs complicate networks
Why fix in ESAPI WAF vs Fix in code?
- Changing in ESAPI WAF is just a text file
- Shorter gap between time discovered and WAF fix vs code fix
Advantages of WAF
- Performance - Only your rules are checked, plus state is already managed by the app server
- Capability - being closer to the app lets us do more
- Process - Rules are closer to application owner, shortening discovery-to-patch time, also fix-to-patch-removal time
Principle: Make common tasks easy, uncommon tasks possible
General virtual patching functionality is easy to understand
Ability to write custom script rules as well "bean-shell-rules"
Fixing Injection Flaws is easy
Can fix business logic flaws with the WAF (missing authentication, missing functional access control, missing data layer access control)
Can add "outbound" security as well
- Add anti-clickjacking header
- Set uniform content-type
- Add HttpOnly flag
- Add secure flag
- Detect outbound information
- Replace outbound information
Takes advantage of early failing to make rules as optimized as possible
Now we see the tool demonstrated with several different vulnerabilities in a real-world application (JForum):
- Cross-Site Scripting Flaw (JForum XSS flaw is unable to be fixed with a WAF because of dynamic URLs)
- Unchecked Redirect
- Add HttpOnly
- Add anti-clickjacking header
- Privilege escalation
3 Different WAF Modes
- Log
- Block
- Redirect
Latency with all of the rules turned on is about 5%. With selected rules is closer to 0%. Basically an order of n magnitude where n is the number of rules enabled. Comes out to milliseconds.
Defending Yourself: Integrating Real Time Defenses into Online Applications
This presentation was by Michael Coates, the AppSensor Project Lead. Michael works as a Senior Application Security Engineer at Aspect Security. AppSensor is a real time defense system with the goal being to protect an application by detecting who is bad and getting rid of them before they do bad things. My notes from this session are below:
Agenda
- AppSensor Project
- Malicious Attackers
- Application Worms
Detecting Attacks the Right Way
- Integration
- Detect INSIDE the application
- Understand business logic
- Effectiveness
- Minimal false positives
- Immediate response
- Effort
- Automatic detection
- No manual work required
Detection Outside the Application (WAF)
- Application context not available
- No concept of access violations
- Custom application + Generic Solution != success
- Ex: Changing the account ID in /viewAccount?id=1002
Inside the Application is Best
- Understand application & business context
- Integration with authentication & user store
How Does AppSensor Protect the App?
- Take many requests for an attacker to find a vulnerability
- Takes fewer requests by AppSensor to determine that the user is malicious
AppSensor is Faster than Attacker
- User identified as malicious and blocked before a vulnerability is found
Categories of Detection
- Request
- Authentication
- Access Control
- Session
- Input
- Encoding
- Command Injection
- File IO
- User Trend
- System Trend
Attack Detection: Real vs Cyber World
- Why do bank robbers get caught?
- Why don't hackers get caught?
Let's Change Things - Applications Should...
- Detect attacks
- Understand normal use vs suspicious use
- Instantly identify attackers
- Shutdown attackers in real time
- Modify application accessibility for defense
Detecting Malicious Users
- Many malicious attacks are obvious and not "user error"
- POST when expecting GET
- Tampering with headers
- Submissions of XSS attack
Detecting Malicious Users
- Bypassing client side input validation
- Transaction using functionality not visible to user role
- Multiple access control violations
- Change of user agent midsession
- Double encoded data
The Code
- Leverages ESAPI!
- 3 lines to setup AppSensor
- 2 lines per AppSensor detection point
Setting up AppSensor
- Configure response action object (log logout, account lock)
- Create AppSensorIntrusionDetector with response action object
- Set ESAPI intrusion detector
Defining Response Policies
- ESAPI.properties file
- Define
- Threshold count
- Interval of events
- Response action
- Per exception type or aggregate
2 Lines to Use AppSensor
- Check for "maliciousness"
- Create new AppSensorException
Understanding the Intrusion Exception
new AppSensorIntrusion Exception(
- request.getServletPath(),
- "ACE1",
- "User Message",
- "Direct object tampering with ..."
);
AppSensor vs Scanners
- Tools attempt 10,000s of generic attacks
- AppSensor stops automated scans nearly instantly
AppSensor vs Human Attackers
- Very difficult for attacker
- Requires advanced obfuscation for each attack
- Multiple probes == detection
Application Worms on the Rise
- Twitter Worm
- MySpace Samy WOrm
- Huge damages for site
- Remediation
- Cleanup
- Bad PR
- Infected Users
- Leverage XSS and CSRF
Detecting/Preventing an Application Worm
- Can you find/fix all XSS?
- Pattern matching easily foiled
- Block the common factor!
- Worms use XSS and CSRF for propagation
- 1000% usage increase -> problem
- Our example: updateProfile, updateStatus, updateName
Case Study: Samy
- MySpace Application Worm
- XSS worm embedded in User Profile
- Exponential Growth of Samy's friends
Samy vs AppSensor
- AppSensor detects uptick in addFriend usage
- Compares against trended info
- Automatic response initiated
- Alert admin +200% add friend usage
- Alerts admin 2nd time +500% add friend usage
- Automatically shuts down add friend feature
- Result
- Worm contained
- Add friend temporarily disabled
- Site stays up
Benefits of Trend Monitoring
- Detection of
- Application worms
- Scripted attacks/probing
- CSRF attacks
- Alerting of excessive activity
- Selective feature shutdown for overall stability
AppSensor in Action
- Demo social networking app
- Defended with AppSensor trend monitoring
What's Under the Hood?
- REST communication between AppSensor & App
- Support Response Actions (warn user, logout user, disable user, etc)
AppSensor Brain
- Drools - Rule Based System
- Support for complex rule sets - much more than just counting feature usage
- Evaluates objects in Drools memory
The Exploit
- XSS infects victim's "Status" with worm
- CSRF adds victim as friend of Charlie
Defend with AppSensor
- AppSensor Policy
- Notify admin if events > 5
- Disable service if events > 10
- AppSensor notices anomaly - alerts admin
- After 10 events AppSensor disables just that feature of the site
- Users protected, worm contained, site stays up
Trend Monitoring Benefits
- Auto detection of attacks
- ...
Assessing Your Web App Manually Without Hacking It
After giving my presentation on "Using Proxies to Secure Applications and More" at the TRISC 2009 conference, I decided to attend the presentation by Robert "RSnake" Hansen and Rob MacDougal entitled "Assessing Your Web App Manually Without Hacking It". The gist of this presentation was that with a few simple tools (Web Developer Toolbar, NoScript, you web browser) you can spend about an hour looking at the characteristics of a web application in order to determine what types and how many vulnerabilities it may have. My notes on the presentation are below:
Using Proxies to Secure Applications and More
I've been really surprised that for as long as I've been active with OWASP, I've never seen a proxy presentation. After all, they are hugely beneficial in doing web application penetration testing and they're really not that difficult to use. Take TamperData for example. It's just a firefox plugin, but it does header, cookie, get, and post manipulation just as well as WebScarab. Or Google Ratproxy, which works in the background while you browse around QA'ing your web site and gives you a nice actionable report when you're done. I decided it was time to educate my peers on the awesomeness of proxies.
This past Tuesday I presented to a crowd of about 35 people at the Austin OWASP Meeting. The title of my presentation was "Using Proxies to Secure Applications and More". Since so many people came up to me afterward telling me what a great presentation it was and how they learned something they can take back to the office, I decided (with a little insistance from Ernest) that it was worth putting up on SlideShare and posting to the Web Admin Blog.
The presentation starts off with a brief description of what a proxy is. Then, I talked about the different types of proxies. Then, the bulk of the presentation was just me giving examples and demonstrating the various proxies. I included anonymizing proxies, reverse proxies, and intercepting proxies. While my slides can't substitue for the actual demo, I did try to include in them what tool I used for the demo. If you have any specific questions, please let me know. All that said, here's the presentation.
Best Practices Guide: Web Application Firewalls – OWASP AppSec NYC 2008
This presentation was by Alexander Meisel and is from a paper that was put together by the Germany OWASP chapter. He began by introducing the problem being online businesses having HTTP as their "weak spot". Then talked about the definition of the term "Web Application Firewall". It's not a network firewall and not only hardware. The targeted audience of the paper is technical decision makers, people responsible for operations and security, and application owners. Next he talked about some of the characteristics of web applicatons with regard to security. Prioritize web applications in regard to their importance (access to personal customer data, access to confidential company information, certifications). Some technical aspects include test and quality assurance, documentaiton, and vendor contracts.
Where do WAFs fit into the web application security field? WAFs are part of a solution. Create a table with wanted functionality (CSRF, session fixation, *-Injection). Do a rating/evaluation with "+" meaning it can be very well implemented using a WAF, "-" meaning it can not be implemented, "!" meaning depends on the WAF/application/requirement, and "=" meaning it can partly be implemented with a WAF.
Looks at the benefits and risks of WAFs. Good baseline security. Compliance. Just-in-time patching of problems. Additional benefits (depending on functionality) could be central reporting and error logging, SSL termination, URL encryption, etc.
Some risks involved in using WAFs are false positives, increased complexity, having yet another proxy, and potential side effects if the WAF terminates the application.
Protection against the OWASP Top 10. App vs WAF vs Policy. Three types of applications: web application in design phase, already productive app which can easily be changed, and productive app which cannot be modified or only with difficulty. Table of OWASP Top 10 in regards to work required with the 3 types of applications to fix the problem in the application itself, using a WAF, and using a policy.
Criteria for deciding whether or not to use WAFs. Company wide criteria includes the importance of the application for the success of the company, number of web applications, complexity, operational costs, and performance and scalability. Criteria with regard to the web application includes changeability of the application, documentation, maintenance contracts, and time required fixing bugs in third-party products. Consideration of financial aspects includes avoidance of financial damage via successful attacks and teh costs of using a WAF (license, update, project costs for eval and WAF introduction, volume of work required/personnel costs).
He started going pretty fast here since he was already running over on time. The gist was a bunch of best practices for introduction and operation of web application firewalls. He talked about technical requirements, job requirements, and an iterative procedure for implementation.
This presentation was mostly just an overview of what is in the paper and he didn't get into too much specifics. Go check out the paper at https://www.owasp.org/index.php/Best_Practices:_Web_Application_Firewalls to get the details!
w3af: A framework to own the Web – OWASP AppSec NYC 2008
This presentation on the w3af (Web Application Attack and Audit Framework) was by Andres Riancho (ariancho@cybsec.com) who is the project leader. w3af is an Open Source project (GPLv2). A script that evolved into a serious project. A vulnerability scanner. An exploitation tool. Found that the commercial tools were too pricey so developed a tool to make his job easier.
Finds almost all web application vulnerabilities. Cross platform (written in python). Uses tactical exploitation techniques to discover new URLs and vulnerabilities. GTK and Console user interface. Web service support. Exploits [blind] SQL injections, OS commanding, remote file inclusions, local file inclusions, XSS, unsafe file uploads and more. WML Support (WAP). Really easy to extend. Synergy among plugins. Ability to find vulerabilities in query string, post data, URL filename, headers, file content (when uploading with forms) and web services. 130 plugins and growing. Manual analysis web applications.
w3af is divided into two main parts, the core and the plugins. The core coordinates the process and provides features that plugins consume. Plugins share information with each other using a knowledge base. Design patterns and objects everywhere! 8 different types of plugins exist:
- Discovery Plugins: Find new URLs and create the corresponding fuzzable requests (webSpider, urlFuzzer, googleSpider, pykto)
- Discover plugins are run in a loop, the output of one discovery plugin is sent as input to the next plugin. This process continues until all plugins fail to find a new fuzzable request.
- Other discovery plugins try to fingerprint remote httpd, allowed HTTP methods, verify if the remote site has an HTTP load balancers.
- Audit Plugins: They take the output of discovery plugins and find vulnerabilities like [blind] SQL injection, XSS, buffer overflows
- Grep Plugins: These plugins grep every HTTP request and response to try to find information. Examples are findComments, passwordProfiling, privateIP, directoryIndexing, getMails, and lang.
- Attack Plugins: These plugins read the vuln objects from the KB and try to exploit.
- Output Plugins: They write messages to the console, html or text file.
- Mangle Plugins: They modify requests and responses based on regexs
- Evasion Plugins: They modify the requests to try to evade IDS detection
- Bruteforce Plugins: They try to bruteforce logins
The presenter then demonstrated the w3af utility. Very clean looking GUI similar to many of the linux GUI's available. Good use of tabs to separate various outputs. I haven't used it, but it looks fairly intuitive. It has the ability to create exploit shells (OS, SQL, etc) just like I've seen with uber-expensive products like CoreImpact. Ability to use python statements in HTTP requests to iterate through different pages. Some really useful graphing.
- archiveDotOrg plugin: Searches archive.org for older versions of the site, links that were linked somewhere in the past and now are kept in the dark. Old and unmaintained sections are prone to vulnerabilities
- Use of PHP easter eggs to fingerprint the remote PHP version. Old and almost forgotten technique. Accurate fingerprinting. Almost nobody disables the eggs (expose_php=off)
- Good samaritan module: A faster way to exploit blind SQL injections! A funny way to exploit blind SQL injections! "Guiding the blind man"
- Virtual Daemon: Ever dreamed about using metasploit payloads to exploit web applications? Now you can do it! Coded a metasploit plugin that connects to a virtual daemon and sends the payload. The virtual daemon is run by a w3af attack plugin and receives the payload and creates a tiny ELF/PE executable.
- w3afAgent: A reverse "VPN" that allows you to continue intruding into the target network. Send the w3afAgent client to the target host using a transfer handler (wget, tftp, echo). The cient connects back to w3af where the w3afAgent server runs a SOCKS daemon. (Just like CoreImpact!!! Freakin' sweet!) UDP traffic doesn't work, but could. Raw sockets, and sniffing won't work.
- Web 2.0 Support. w3af can analyze pages that make heavy use of JavaScript. THe manual solution available to achieve this task is the spiderMan plugin. Local proxy daemon. Analyzes requests and creates fuzzable requests. The user needs to navigate the JavaScript sections of the site. Supports JSON.
Future
- Some level of javascript support (mozrepl)
- More stable core
- Less false positives/negatives
- More attack plugins
- Better GTK user interface
- Better management report generation
- Long descriptions for vulnerabilities using OWASP attack information from the wiki.
Site: http://w3af.sf.net
OWASP Google Hacking Project – OWASP AppSec NYC 2008
This presentation is by Christian Heinrich, the project leader for the OWASP "Google Hacking" project. Presentation published on http://www.slideshare.net/cmlh Dual licensed under OWASP License and AU Creative Commons 2.5.
OWASP Testing Guide v3 - Spiders/Robots/Crawlers
1. Automatically traverses hyperlinks
2. Recursively retrieves content referenced
Behavior governed by the robots exclusion protocol. New method is <META NAME="Googlebot" CONTENT="nofollow"> Not supported by all Robots/Spiders/Crawlers. Traditional method is robots.txt located in web root directory. Regular expressions supported by minority only. "User-agent: *" applies to all spiders/robots/crawlers or you can specify a specific robot name. Can be intentionally ignored. Not for httpd access control or digital rights management.
Testing - Robots Exclusion Protocol
- Sign into Google Webmaster Tools
- On the dashboard, click the URL
- Click "Tools"
- Click "Analyze robots.txt"
Search Engine Discovery
Microsoft Remote Desktop Web Connection: intitle:Remote.Desktop.Web.Connection inurl: tsweb
VNC: "VNC Desktop" inurl:5800
Outlook Web Access: inurl:"exchange/logon.asp"
Outlook Web Access: intitle:"Microsoft Outlook Web Access - Logon"
Adobe Acrobat PDF: filetype:pdf
Google caught onto this and is now displaying a "We're sorry" message with certain searches. To get around, use different search queries that returns overlapping results.
Google Advanced Search Operators: "site:" and "cache:" Two ways of using "site:". EIther as "site:www.google.com" where you get that specific subdomain's results or "site:google.com" where you get all hostnames and subdomains. Use "cache:www.owasp.org" to display an indexed web page in the google cache. There is also a site operator labeled "Cached" which will do the same thing.
You can get updates of the latest relevant Google results (web, news, etc) using Google Alerts.
Download Indexed Cache
Google SOAP Search API. Query limited to either 10 words or 2048 bytes. One thousand search queries per day and limited to search results within 0-999. Up to 10K possible results from 10 different search queries.
$Google_SOA_Search_API -> doGoogleSearch( $key, $q, $start, $maxResults, $filter, $restricts, $safeSearch, $lr, $ie, $oe );
See presentation for response.
Proof of concept tool is "dic.pl" or "Download Indexed Cache" that downloads the search results. Licensed under the Apache License 2.0. Tool produces a URL and cachedSize response.
OWASP Google Hacking Project
Tools built using Perl using CPAN Modules SOAP::Lite, Net::Google, and Perl::Critic. Development environmetn is based on Eclipse with EPIC Plug-in. Subversion repository is at code.google.com.
Roadmap
Upcoming presentations at ToorCon X in San Diego, SecTor 2008 in Toronto, Canada, and RUXCON 2K8 in Sydney, Australia.
"TCP Input Text" Proof of Concept
"Speak English" Google Translate Workaround
Refactor and 3rd Project review of PoC Perl Code with public release at RUXCON 2K8 in November 2008.
Check in at code.google.com after RUXCON 2K8
4 hr "half day" training course Q1 2009