Web Admin Blog Real Web Admins. Real World Experience.

26Apr/111

Demanding Secure Developers

Much like many other companies these days, National Instruments hires many of our developers straight out of school. Many times when engaging with these new hire developers, I will ask them what kind of security they learned at their university. In almost all cases I've found that the answer hasn't changed since I graduated back in 2002. Occassionally I'll get a developer who mentions one particular professor or class where they discussed secure coding practices, but most of the time the answer is "I didn't learn security in school". This absolutely kills me. It's like asking an architect to design a building without them knowing anything about support structures and load distribution. The end result may look awesome on the outside, but the slightest breeze will knock it over. With computers being embedded into literally every aspect of our society, do you really want code that crumbles the moment a user does something other than what was explicitly intended?

This leads me to the conclusion that security should be considered a fundamental part of code development and not an afterthought. We should be teaching security to students at a University level so that when they graduate, corporations don't spend valuable time re-training them on proper development techniques. I've heard rumors of large companies like Oracle actually being able to impact college curriculum by telling universities they simply won't hire developers without security training. Unfortunately, most companies aren't in a position to make demands like that, but it certainly wouldn't hurt to develop relationships with faculty at your local university and tell them what you'd like to see out of their students. I did some poking around on the internet and it seems like some professors are already starting to get the memo. For example, I found a great paper written by three professors at the USAF Academy Dept. of Computer Science called Incorporating Security Issues Throughout The Computer Science Curriculum where they say:

While the general public is becoming more aware of security issues, what are our universities doing to produce graduates ready to address our security needs?  Computer science as a discipline has matured to the point that students are regularly in tructed in software engineering principles--they learn the importance of life cycle issues in the development and maintenance of software.  Where are they receiving similar instruction on security concerns in the software life cycle?  The authors propose that security should be taught throughout every computer science curriculum--that security should always be a concern and should be considered in the development of all software just as structured programming and documentation are.

Gentlemen, I couldn't agree more.  Security needs to be a foundational piece of every Computer Science program in the country.  Not one class.  Not one professor.  Secure programming techniques need to be a consideration in every CS class in every university.  Universities teach students how to write functions, create object-oriented code, and do proper documentation, but when graduates don't know the basic tenets of input validation, then we have a real problem.  If you agree with me, then I challenge you to write to the Dean of your local CS program and ask them what they are doing to ensure graduates are familiar with secure coding practices.  I'd be very interested in hearing back from you as to what their response was.

22Jul/103

Static Application Vulnerability Testing: Binary Scanning vs Source Code Scanning

I had a meeting yesterday with a vendor who sells a SaaS solution for binary application vulnerability testing. They tell a very interesting story of a world where dynamic testing ("black box") takes place alongside static testing ("white box") to give you a full picture of your application security posture. They even combine the results with some e-Learning aspects so that developers can research the vulnerabilities in the same place they go to find them. In concept, this sounds fantastic, but I quickly turned into a skeptic and as I dug deeper into the details I'm not sure I like what I found.

I wanted to make sure I fully understood what was going on under the hood here so I started asking questions about the static testing and how it works. They've got a nice looking portal where you name your application, give it a version, assign it to a group of developers, and point it to your compiled code (WAR, EAR, JAR, etc). Once you upload your binaries, their system basically runs a disassembler on it to get it into assembly code. It's then at this level that they start looking for vulnerabilities. They said that this process takes about 3 days initially and then maybe 2 days after the first time because they are able to re-use some data about your application. Once complete, they say they are able to provide you a report detailing your vulnerabilities and how to fix them.

The thing that immediately struck me as worth noting here was the 2-3 day turnaround. This means that our developers would need to wait a fairly substantial amount of time before getting any feedback on the vulnerability status of their code. In a world full of Agile development, 2-3 days is a lifetime. Compare that to static source code testing where you get actionable results at compile time. The edge here definitely goes to source code testing as I believe most people would prefer the near-instant gratification.

The next thing worth noting was that they are taking binary files and disassembling them in order to find vulnerabilities. This lends itself to one major issue which is how can you determine with any accuracy the line number of a particular vulnerability written in let's say Java from assembly code generated by disassembling the binaries. By default, it's simply not possible. This vendor claimed that they can by adding in some debug strings at compile time, but even then I'd contend that you're not going to get much. I'm guessing they have some heuristics that are able to tell what function generated a set of assembly code, but I'm extremely skeptical that they can do anything with variable names, custom code functions, etc. I've seen some source code scanners, on the other hand, that not only tell you what line of code is affected, but are able to give you an entire list of parameters that have been consequently affected by that vulnerability. The edge here definitely goes to source code testing.

The main benefit that I can see with binary testing vs source code testing is that we can test code that we didn't write. Things like APIs, third-party applications, open source, etc are all things that we now have visibility into. The only problem here is that while we now can see the vulnerabilities in this software, they are unfortunately all things that we can't directly influence change in, unless we want to send our developers off to work on somebody else's software. I'd argue that scanning for vulnerabilities in that type of code is their responsibility, not ours. Granted, it'd be nice to have validation that there aren't vulnerabilities there that we're exposing ourselves to by uptaking it, but in all honesty are we really going to take the time to scan somebody else's work? Probably not. The edge here goes to binary testing with the caveat being that it's in something that I frankly don't care as much about.

This isn't the complete list of pros and cons by any means. It's just me voicing in writing some concerns that I had about the technology while talking to this particular vendor. In my opinion, the benefits of doing source code testing far outweigh any benefits that we could get from testing compiled binary files. What do you think about the benefits of one versus the other? I'd certainly love for someone to try to change my mind here and show me where the real value lies in binary testing.

23Feb/1028

A XSS Vulnerability in Almost Every PHP Form I’ve Ever Written

I've spent a lot of time over the past few months writing an enterprise application in PHP.  Despite what some people may say, I believe that PHP is as secure or insecure as the developer who is writing the code.  Anyway, I'm at the point in my development lifecycle where I decided that it was ready to run an application vulnerability scanner against it.  What I found was interesting and I think it's worth sharing with you all.

Let me preface this by saying that I'm the guy who gives the training to our developers on the OWASP Top 10, writing secure code, etc.  I'd like to think that I have a pretty good handle on programming best practices, input validation, and HTML encoding.  I built all kinds of validation into this application and thought that the vulnerability scan would come up empty.  For the most part I was right, but there was one vulnerability, one flaw in particular, that found it's way into every form in my application.  In fact, I realized that I've made this exact same mistake in almost every PHP form that I've ever written.  Talk about a humbling experience.

So here's what happened.  I created a simple page with a form where the results of that form are submitted back to the page itself for processing.  Let's assume it looks something like this:

<html>
 <body>
  <?php
  if (isset($_REQUEST['submitted']) && $_REQUEST['submitted'] == '1') {
    echo "Form submitted!";
  }
  ?>
  <form action="<?php echo $_SERVER['PHP_SELF']; ?>">
   <input type="hidden" name="submitted" value="1" />
   <input type="submit" value="Submit!" />
  </form>
 </body>
</html>

It looks fairly straightforward, right? The problem has to do with that $_SERVER['PHP_SELF'] variable. The intent here is that PHP will display the path and name of the current page so that the form knows to submit back to the same page.  The problem is that $_SERVER['PHP_SELF'] can actually be manipulated by the user.  Let's say as the user I change the URL from http://www.webadminblog.com/example.php to http://www.webadminblog.com/example.php"><script>alert('xss');</script>.  This will end the form action part of the code and inject a javascript alert into the page.  This is the very definition of cross site scripting.  I can't believe that with as long as I've been writing in PHP and as long as I've been studying application security, I've never realized this.  Fortunately, there are a couple of different ways to fix this.  First, you could use the HTML entities or HTML special character functions to sanitize the user input like this:

htmlentities($_SERVER['PHP_SELF]);

htmlspecialchars($_SERVER['PHP_SELF]);

This fix would still allow the user to manipulate the URL, and thus, what is displayed on the page, but it would render the javascript invalid.  The second way to fix this is to use the script name variable instead like this:

$_SERVER['SCRIPT_NAME'];

This fix would just echo the full path and filename of the current file.    Yes, there are other ways to fix this.  Yes, my code example above for the XSS exploit doesn't do anything other than display a javascript alert.  I just wanted to draw attention to this issue because if it's found it's way into my code, then perhaps it's found it's way into yours as well.  Happy coding!

13Nov/096

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

  1. Introduction to XML/Web Services Threats
  2. Techniques for Defending XML Threats
  3. XML Attack Examples and Classification
  4. 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
13Nov/090

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)
  1. 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)
  2. 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)
  3. A3 - Broken Authentication and Session Management: Means credentials have to go with every request.  Should use SSL for everything requiring authentication.
  4. A4 - Insecure Direct Object Reference: This is part of enforcing proper "Authorization", along with A7 - Failure to Restrict URL Access.
  5. 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)
  6. 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.
  7. A7 - Failure to Restrict URL Access: This is part of enforcing proper "authorization", along with A4 - Insecure Direct Object References.
  8. 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.
  9. 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.
  10. 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.

13Nov/090

Securing the Core JEE Patterns

This presentation was by Rohit Sethi, the Project Leader for the Secure Pattern Analysis Project at OWASP and he works at Security Compass, a security analysis and training company.  My notes from the session are below:

  • Before anyone starts building complex systems, they need to design.
  • We create threat models on completed designs.
  • What about during design?
  • Book: "Core J2EE Patterns Best Practices and Design Strategies"
  • If you use J2EE development, chances are you're using patterns documented here
  • Core J2EE patterns are used extensively
  • Patterns are used in JSF, Velocity, Struts, Tapestry, Spring, and Proprietary Frameworks

Example: Project: Analyze Patterns

Use to Implement:

  • Synchronization Tokens as Anti-CSRF Mechanism
  • Page-level authorizations

Avoid:

  • XSLT and Xpath vulnerabilities
  • XML Denial of Service
  • Disclosure of information in SOAP faults
  • Publishing WSDL files
  • Unhandled commands
  • Unauthorized commands

Project Goals

  • Analyze patterns for security pitfalls to avoid
  • Determine how patterns can implement security controls
  • Provide advice portable to most frameworks

A security pattern is not the same as a security analysis of a pattern.

Uses

  • Designing new web application frameworks (make the next generation of frameworks secure by default)
  • Designing new apps that use the patterns
  • Source code review of existing apps
  • Runtime assessment of existing apps
  • Integrate with threat modeling of new or existing apps

You can help:

  • Tell developers
  • Improve the analysis

Next Steps?

  • Add code review and examples to the existing pattern book
  • Look at other pattern books to see if there are other patterns that we should analyze

Our Dream

  • New web application framework idea + Design-time security analysis = Secure-by-default web application framework
12Nov/090

Threat Modeling

This presentation was by John Steven, the NoVA Chapter Lead and Senior Director of Advanced Technology Consulting at Cigital, Inc.   He notes that this is not that MS thing, it is not going to help you find XSS, and is not going to help you with Risk Management.  My notes are below:

Don't use threat modeling to help you with the things you already have checklists for.

Do this because you want to understand the intersection of your stakeholder's goals and the architecture.

What is a Threat?

  • An agent who attacks you?
  • An attack?
  • An attack's consequence?
  • A risk?

What is a Threat Model

  • Depiction of
    • The system's attack surface
    • Threats who can attack the system
    • Assets threats may compromise
  • Some leverage risk management practices
    • Estimate probability of attack
    • Weight impact of successful attack

Threat

  • Capability
    • Access ot the system
    • Able to reverse engineer binaries
    • Able to sniff the network
  • Skill Level
    • Experienced hacker
    • Script kiddie
    • Insiders
  • Resources and Tools
    • Simple manual execution
    • Distributed bot army
    • Well-funded organization
    • Access to private information
  • Threats help
    • Encourage thorough throught about how intentions for misuse
    • Determine "out of bounds" scenarios

Threat Modeling as a Process

  • Know thy enemy and how they attack you (who, what, how, why, impact, mitigation)

Threat Modeling - High-level Process

  1. Diagram Structure
  2. Identify Assets
  3. Identify Threats
  4. Stitch Threats onto Structure
  5. Enumerate Doomsday Scenarios
  6. Document Misuse/Abuse
  7. Enumerate Attack Vectors
  8. Iterate

1. Diagram the Software

  • Different methods of diagraming (likes the whiteboard the best)

1.1  - Anchor in Software Architecture

Consider where attacks occur

Top-down

  • Enumerate business objects
    • Sensitive data
    • Privileged functionality

Bottom-up

  • Enumerate application entities
    • Sensitive data
    • Privileged functionality

Look for

  • Middleware
  • Open source
  • Frameworks

1.2 - Identify Application Attack Surface

  • Are there different privilege levels?
  • Connectivity between services and processes

1.3 - Annotate with Design Patterns

  • Are there pieces that whitebox testings is unable to analyze?
  • What types of frameworks is the application using?
  • Where are there command patterns?
  • Where is there an inversion of control?

1.4 - Consider Patterns' Responsibilities

  • Document specific standards for implementing each responsibility
  • List out each pattern, piece of app, and associated standards

1.5 - Enumerate Potential Failures in Design Elements

1.6 - Find Key Structural Componenets

Component diagrams show critical choke points for security controls

1.7 - Identify Frameworks

Showing frameworks indicates where important service contracts exist 'up' and 'down'

1.8 - Explicitly Identify Controls

2 - Identify Assets

2.1 - Identify Critical Data Assets

  • Do I have PII?
  • Things that proxy for PII like sessions?

2.2 - Identify Interfaces as Proxies for Data

2.3 - Identify Assets flow through the System

  • Assets exist not only in rest, but also flow through the system
  • Think about where there are points you could stop the data from going

2.4 - Identify Critical Application Entities

2.5 - Identify 'Intermediate' Asset Objectives

Identify:

  • Sensitive data
  • Privileged function

Look out for:

  • Proxies, facades, etc
  • Services
  • UI vs implementation
  • Aggressive caching scheme

2.6 - Identify Equivalence-classes

  • In essence an escalation of privilege connector
  • Ex: Putting username and password and password reset questions on the same page puts them on the same equivalence-class without reauthentication and defeats the security control

3 - Identify Threat Agents

3.1 - Anchor Threats in Use Cases

  • What is the dumbest things that a user can do?
  • What is the most malicious thing a user can do?

4.1 - Identity Principal Resolution

  • Arrows indicate resolution of principal/assertion propagation

4.2 - Place Threats on Diagram

4.3 - Show Authorization in Structure

  • Coloration shows authorization by role
  • Color modules by who you would need to be to access them and look where the colors change
  • Has never NOT found a vulnerability for John

5 - Enumerate Doomsday Impacts

5.1 - Assign Threats Malicious Intent

  • What is each Threat's motivation?
  • What would drive escalation?
  • Why would each try beyond the first hurdle?

5.2 - Instanstiate Doomsday Attack

6.1 - Add in Misuse Cases

Convert Actors to Threats

  • Abuse - Make actors behave stupidly
  • Misuse - Make actors deviant/evil

6.2 - 'Cache' Misuse in a 'Cookbook'

7 - Enumerate Attack Vectors

7.1 - Pilfer technology-specific security standards

7.2 - Pilfer community resources

7.3 - Pass technology-specific resources as your own

  • When testing finds an attack:
    • First, decide if its impact warrants further exploration
    • Are additional impacts possible?
    • Consider what conceptual goals the attack supports
    • Then consider who could launch the attack against the application
  • After analysis converges, iterate secure design
12Nov/090

OWASP Live CD: An open environment for Web Application Security

General Goals Going Forward

  • Showcase great OWASP projects
  • Provide the best, freely distributable application security tools/documents
  • Ensure that the tools provided are easy to use as possible
  • Continue to document how to use the tools and how the modules were created
  • Align the tools with the OWASP Testing Guide v3 to provide maximum coverage
  • Awesome training environment

330,081 total downloads as of 10/5/2009

~5,094 GB of bandwidth since launch (7/2008)

Most downloads in 1 month = 81,607 (3/2009)

Available Tools: 26 "Significant"

  • Web Scarab
  • Web Goat
  • CAL9000
  • JBroFuzz
  • WSFuzzer
  • Wapiti
  • Burp Suite
  • Paro
  • Spike Proxy
  • Rat Proxy
  • w3af
  • Grendel Scan
  • Nikto
  • nmap
  • Zenmap
  • sqlmap
  • SQL Brute
  • Metasploit
  • ....

OWASP Documents

  • Testing Guide v2 & v3
  • CLASP
  • Top 10 for 2007
  • Top 10 for Java Enterprise Edition
  • AppSec FAQ
  • Books (CLASP, Top 10 2007, Top 10 + Testing + Legal, WebGoat and Web Scarab, Guide 2.0, Code Review)
  • WASC Threat Classification
  • OSTTMM

Where are we going?

  • Project Tindy (Live CD installed to a virtual hard drive, persistence, VMware, VirtualBox, and Paralles)
  • Project Aqua Dog (OWASP Live CD on a USB drive, VM install + VM engine + USB drive = mobile app sec platform, currently testing, Qemu is the current VM engine)
  • Much easier URL - AppSecLive.org
  • Community site around OWASP Live CD
  • Online Tool DB (331+ tools)
  • New release will be based on Ubuntu instead of SLAX
  • Create .deb packages for every tool
  • Create a repository for packages
  • Add dependency info to packages
  • Brings the 26,000+ existing packages to the Live CD
  • More fun cool stuff like Wubi (install Ubuntu onto an existing windows desktop to be able to dual-boot without repartitioning windows)

Design Goals

  • Easy for users to keep updated
  • Easy for project lead to keep updated
  • Easy to produce releases (every 6 months)
    • Crank out new .debs when new tool releases
    • Continually updating repository
  • Focused on just application security - not general pen testing
    • Both dynamic and static tools
    • Developer tools also

OWASP Education Project

  • Natural ties between these projects
    • Already being used for training classes
    • Need to coordinate efforts to make sure critical pieces aren't missing form the OWASP Live CD
    • Training environment could be customized for a particular class thanks to the individual modules
      • Student gets to take the environment home
    • As more modules come online, even more potential for cross pollination
    • Builder tools/docs only expand its reach
    • Kiosk mode?

Crazy Pie in the Sky Idea

  • .deb package + auto update + categories = CD profiles
  • Allows someone to customize the OWASP Live CD to their needs
  • Example Profiles:
    • Whitebox testing
    • Blackbox testing
    • Static analysis
    • Targe specific (Java, .Net)

What have you done for me lately?

  • For Testers/QA testers
    • Wide array of tools, preconfigured and ready to go
    • Nice "jump kit" to keep in your laptop bag
    • Great platform to test or learn the tools
  • For App Sec Professionals
    • Both dynamic and static tool coverage
    • Ability to customize the job your on
  • For Trainers
    • Ready to go environment for students
    • Ability to customize for the class

Get Involved

  • Join the mailing list
  • Post on hte AppSecLive.org forums
  • Download an ISO or VM
    • Complain or praise, suggest improvements
    • Submit a bug to the Google Code site
  • Create a deb package of a tool
    • How I create the debs will be documented, command by command and I'll answer questions gladly
  • Suggest missing tools, docs, or links
  • Do a screencast of one of the tools being used on the OWASP Live CD

Learn More

  • Google "OWASP Live CD"
  • Download & Community Site (http://AppSecLive.org)

Everything is stored in /opt/owasp

Tagged as: , , , No Comments
12Nov/090

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.

12Nov/090

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

  1. Configure response action object (log logout, account lock)
  2. Create AppSensorIntrusionDetector with response action object
  3. 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

  1. Check for "maliciousness"
  2. 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
  • ...