Building an In-House Application Security Assessment Team
This presentation was by Keith Turpin from The Boeing Company. About three years ago, all of Boeing's assessments were coming from outsourced service providers. They realized that they were unable to have control over the people and process and had difficulties integrating the controls into the SDLC and decided to bring these functions in house. The goal of this presentation is to show some of the issues they ran into and how they addressed those problems. My notes from the presentation are below:
Contraced Services Considerations
- Some Advantages:
- Highly skilled
- Established tools, processes, and standards
- Unbiased
- Available as needed
- Some Disadvantages:
- Expensive, especially for an extended engagement
- Less control and flexibility
- Not familiar with company processes and culture
- Rotating staff
Planning
- Considerations for establishing an internal team:
- Time to staff and train the team
- Overlap of external and internal teams
- Development of processes and standards
- Acquiring necessary tools
Service Model
- Define the services your team will provide. This will be greatly influenced by:
- The team's size and skills
- The number of applications you have to support
- The tools available
- The level of executive support
- The funding model
- Who pays for your services
- The team's role
- Development support, pre-deployment testing or post deployment auditing and pen testing
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.
Application Security Metrics from the Organization on Down to the Vulnerabilities
This presentation was by Chris Wysopal, the CTO of Veracode. My notes are below:
"To measure is to know." - James Clerk Maxwell
"Measurement motivates." - John Kenneth Galbraith
Metrics do Matter
- Metrics quantify the otherwise unquantifiable
- Metrics can show trends and trends matter more than measurements do
- Metrics can show if we are doing a good job or bad job
- Metrics can show if you have no idea where you are
- Metrics establish where "You are here" really is
- Metrics build bridges to managers
- Metrics allow cross sectional comparisons
- Metrics set targets
- Metrics benchmark yourself against the opposition
- Metrics create curiosity
Metrics Don't Matter (Mike Rothman)
- It is too easy to count things for no purpose other than to count them
- You cannot measure security so stop
- This following is all that matters and you can't map security metrics to them:
- Maintenance of availability
- Preservation of wealth
- Limitation on corporate liability
- Compliance
- Shepherding the corporate brand
- Cost of measurement not worth the benefit
Bad metrics are worse than no metrics
Security Metrics Can Drive Executive Decision Making
- How secure am I?
- Am I better off than this time last year?
- Am I spending the right about of money?
- How do I compare to my peers?
- What risk transfer options to I have?
Goals of Application Security Metrics
- Provide quantifiable information to support enterprise risk management and risk-based decision making
- Articulate progress towards goals and objectives
- Provides a repeatable, quantifiable way to assess, compare, and track improvements in assurance
- Focus activities on risk mitigation in order of priority and exploitability
- Facilitate adoption and improvement of secure software design and development processes
- Provide and objective means of comparing and benchmarking projects, divisions, organizations, and vendor products
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.
Enterprise Application Security – GE’s Approach to Solving Root Cause
The first presentation of the day that I went to was by GE's Darren Challey and was about GE's application security program and how he took a holistic approach to securing the enterprise. My notes on this presentation are below:
Why is AppSec so hard?
- AppSec changes rapidly (look at difference between 2004, 2007, and 2010 Top 10)
- Changing landscape
- Increase skill and talen t pool of technically proficient individuals willing to break the law
- Growing volume of financially valuable data online
- Development of criminal markets (black markets) to facilitate conversion to money
- "Attackers now have effective skills, something to steal, and a place to sell it"
- Application Security is a complete one-sided game
- Need to become an enabler (not a barrier)
- Must inject application security earlier through Guidance, Education, and Tools
- Must understand the development and deployment process and integrate rather than mandate
- NIST study on cost to repair defects when found at different stages of software development (http://www.nist.gov/director/prog-ofc/report02-3.pdf)
- Solving the problem of the enterprise (Culture Change)
- Success factors
- Form a mission and strategy
- Develop policy (but not corporate "mandate")
- Gain executive buy-in (cost / benefit / risk)
- Understand the magnitude of problem (metrics)
- Asset inventory and vulnerability management
- Develop standards (what should I do and when?)
- Establish a formal program (strong leadership)
- Focus on education and training materials
- Develop in-house expertise, services and "COE"
- Continuous improvement, measurement, KPI
- Communicate!
- Drive a culture change (shared need, WIIFM)
- Communicate expectations with vendors
- Implement incentives (and penalties)
- Digitize after the process is solid (tools)
- AppSec program mission & structure
- AppSec program strategy
- Policy (guidance) -> Standards (Guidance) -> Training (Education) -> Metrics (tools) -> Security tools (tools) -> Inventory & tracking (tools) -> Monitor & Improve
Guidance
- "GE Application Security Working Group" (Talking to the businesses is critical! Meet every 2 weeks.)
- Secure Coding Guidelines
- Vulnerability Remediation Guide
- Secure Deployment
- Quick Reference Card
- Contractual Language
- Desk Calendars
- Metrics: AppSec calendars helped increase visitors to key Guidance materials (track hits to website docs when certain activities take place)
Education
- CBT1: Intro to AppSec at GE (60 min for any IT person) - why AppSec is important and what happens when you don't do it
- CBT2: GE Best Practices for Secure Coding (90 min)
- CBT3: Attack Profiles & Countermeasures (120 min for security people)
- Developer Awareness Assessment:
- 100's of internally-developed questions
- Randomized questions, timed completion
- Vendors track their own resutls
- Allows tailoring of training/awareness programs
Tools
- - COE AppSec assessment services
- Vendor framework & Metrics
- Compliance handbook
- Common objects repository
- GE Enterprise Application Security
- Scanning and Monitoring tools
- Automation is the way to go (but the tools are not quite there yet)
Metrics
- Measure Vendor AppSec Performance (Avg % Critical/High Vulnerabilities per Assessment vs % Assessments with Zero Critical/High Vulnerabilities)
- Is it making a difference (map avg of critical/high vulnerabilities per assessment)
Forming a Center of Excellence
- Combines the best available people, processes and tools
- Formal training & defined roles (Comprehensive training program for all auditors to ensure skills are kept current and that auditors can provide more than one type of service)
- COE Team structure (tools, research, operations, stakeholder management, queue management, application security auditors
- Application Assessment Types (black/grey box vs white box)
- Application assessment process (map of the workflow with "swim lanes" of who does each step)
- Measure number of vulnerabilities and severities
- Measure customer satisfaction (overall, ease of engagement, responsiveness)
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:
Cryptography for Penetration Testers – OWASP AppSec NYC 2008
This presentation was on "Cryptography for Penetration Testers" and was by Chris Eng, the Senior Director of Security Research at VeraCode.
The Premise
How much do you really have to know about cryptography in order to detect and exploit crypto weaknesses in web apps.
Goals
- Learn basic techniques for identifying and analyzing cryptographic data
- Learn black-box heauristics for recorgnizing weak crypto implementation
- Apply techniques
The Crypto that Matters in 6 Short Slides
Types of Ciphers
- Block Ciphers: Operates on fixed-length groups of bits, called blocks. Block sizes vary depending on the algorithm. Several different modes of operation for encrypting messages longer than the basic block size. Example ciphers include DES, 3DES, Blowfish, AES
- Stream Ciphers: Operates on plaintext one bit at a time
Block Ciphers: Electronic Code Book (ECB) Mode
- Fixed-size blocks of plaintext are encrypted independently
- Each plaintext block is substituted with ciphertext block, like a codebook
- Weaknesses: Structure in plaintext is reflected in ciphertext. Ciphertext blocks can be modified without detection.
Bliock Ciphers: Cipher Block Chaining (CBC) Mode
- Each block of plaintext is XORed with the previous ciphertext block before being encrypted
- Change of message affects all following ciphertext blocks
- Initialization Vector (IV) is used to encrypt first block
Stream Ciphers
- Plaintext message is processed byte by byte (as a stream)
- Key scheduler algorithm generates a keystream using a key and an Initialization Vector (IV combined (XOR) with plaintext bit by bit
- Encrypt by XORing plaintext with the generated keystream
Common Crypto Mistakes
- Insecure cipher mode (usually ECB)
- Inappropriate key reuse
- Poor key selection
- Insufficient key length
- Insecure random number generation
- Proprietary or home-grown encryption algorithms (Don't do this ever!)
Analysis Techniques
Dealing with Gibberish Data
What do you do when you are pen testing a web application and you encounter data that is not easy to interpret?
- Cookies
- Hidden fields
- Query string parameters
- POST parameters
How random is it?
- Output of cryptographic algorithms should be evenly distributed, given a sufficiently large sample size.
- Tools such as ENT (http://www.fourmilab.ch/random) will calculate entropy per byte, chi-square distribution, arithmetic mean, serial correlation, etc
Observe Characteristics
Is the length a multiple of a common block size?
- Indicates that the application may be using a block cipher
Is the length the same as a known hash algorithm?
- For example, MD5 is usually represented as 32 hex characters
- May also indicate the presence of an HMAC
- Still may be worthwhile to hash various permutations of known data in case a simple unkeyed hash is being used
Stimulus, Response
Does the length of the token change based on the length of some value that you can supply?
For a block cipher, you can determine the block size by incrementing input one byte at a time and observing when the encrypted output length jumps by multiple bytes (ie, the block size)
How does the token change in response to user-supplied data?
- Figure out how changing different parts of the input affects the output
- Is more than one block affected by a single character change in the input?
Deeper Block Cipher Inspection
Are there any blocks of data that seem to repeat in the same token or over multiple tokens?
- Possibly ECB mode, this doesn't just happen by coincidence
EXAMPLE
Context: A public-facing web portal for a large ISP. Used an encrypted cookie to authenticate identity. A new cookie is issued on each request. Base64 decoded EE cookies. Divided by 8 and found 8 byte blocks. Noticed some repetition in the same position. The only variable blocks are the last two (possibly a "last accessed" timestamp or similar timeout mechanism). Register a new account with a username of 'c' x 32, the maximum length permitted, and observe the value of the EE cookie.
'c' x 32 is Perl notation for "cccccccccccccccccccccccccccccccc"
The token is longer, meaning the username is probably stored in the cookie. Still noticed repition in same position. Register another account with a username of 'c' x 16 and compare to the EE cookie generated in the previous step. Didn't see two identical blocks for 'c' x 16 and four identical blocks for 'c' x 32. Reason is padding. The username doesn't align perfectly with the block offset. Want to figure out what position in the cookie the usernaem is located. Additional user accounts were created with specific usernames in order to determine if there is any initial padding in the first block. Now you know where the username is in the ciphertext.
Able to successfully subvert the authentication mechanism without any knowledge of the algorithm or the key, based solely on observed patterns in the ciphertext. The root cause was the insecure cipher mode and the lack of a verification mechanism. ECB mode shoul dnot be used (use CBC instead).
EXAMPLE
Token values observed in URLs. Changed every time we logged on to the application. Never the same for any two sessions or any two users. Base64 decoded values for several different "stmt" tokens. Statement numbers were displayed in the browser. Looked for correlations between statement number and cipher-text. Conclusion: It looks like a stream cipher. Use XOR to calculate 10 bytes of the keystream based on the known plain-text (ie. the statement number). Now try the same things against one of the other collected tokens, such as the one called "Ctxt". Get ASCII text that allows you to infer what it would say. Expand it out more and more to get the keystream. Repeat over and over until you have enough of the key to figure out anything in the application.
Through this iterative process, we can obtain the entire keystream (or rather, a sufficient amount of the keystream to encrypt and decrypt all of the cipher-text we encounter). Can replace the statement number with another valid statement number and view the contents.
Able to subvert the encryption mechanism without any knowledge of the algorithm or the key based solely on observed patterns in the ciphertext. They were using RC4 with a unique key generated for each user session. Root cause of the vulnerability is the re-use of the keystream.
Practical Advanced Threat Modeling – OWASP AppSec NYC 2008
This presentation was by John Steven who is the Senior Director of Advanced Technology Consulting at Cigital, Inc.
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, and assets threats may compromise.
- Some leverage risk management practices. Estimate probability of attack. Weigh impact of successful attack.
Elements of a threat model
- Structural view
- Threat actors
- Assets
- Attack vectors
- Privilege/"trust"
Threat
- Capability: Access to 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 and determine "out of bounds" scenarios.
A Few Words on STRIDE
- A conceptual checklist backed by data flow diagrams
Attack Trees
- Aggregate attack possibilites
- Use OR, AND
- Allow for decoration (probability, cost, skills required, etc)
Threat Modeling as a Process
- Use threat modeling to identify where potential threats exist relative to the architecture, how threats escalate privilege, specify vectors of attack, identifies components and assets worth protecting.
Leading Up to Threat Modeling
- Identify threats
- Enumerate doomsday scenarios
- Document misuse/abuse
- Diagram structure, assets
- Annotate diagram with threats
- Enumerate attack vectors
- Iterate
Input: Goals, Doomsday Scenarios
Misuse/Abuse Cases (use case view and component view)
Inputs: Security Requirements (specified security features - "128 bit encryption", "software security != security software")
Anchor in Software Architecture
Consider where attacks occur:
- Top-down: enumerate business objects (sensitive data, privileged functionality)
- Bottom-Up: enumerate application
Output: Security Assessment & Test Design. Threat models drive assessments, Test design. Establish rules of engagement. Prioritize areas of interest. Manage a team in risk-based fashion. Establish a single tie between vulnerability and control.
Application Structure: No "One Size Fits All"
Application Structure: Topology - Coloration shows authorization by role. Arrows indicate resolution of principal/assertion propagation. Use structure to separate privilege.
Application Structure: Components - Component diagrams show critical choke points for security controls (input validation, authentication, output encoding).
Application Structure: Frameworks - Showing frameworks indicates where important service contracts exist "up" and "down".
Assets: Flow - Assets exist not only in rest, but also flow through the system. Use different types of flags to represent data flow of assets.
Use different colored arrows to represent each different attack vector.
Target Using Layered Attacks: Bootstrap later attacks with those that "deliver". Use one layer to exploit another (net, app). Combine attacks to reach desired target.
Take Homes
- Base threat model in software architecture
- When specific use (cases) and high-level architecture are defined: inventory roles, entitlements, if one doesn't exist and inventory assets, sensitive data, privileged components
- Enumerate initial attack vectors. Use common low hanging fruit.
- Elaborate more attacks. Find opportunities for privilege escalation. Layer attacks to target or "hop" to assets. Fill in gaps by "inventing" attacks.
- Use threat modeling to drive security testing
Lotus Notes/Domino Web Application Security – OWASP AppSec NYC 2008
This presentation was by Jian Hui Wang (girl) who is a security professional, but "a nobody in NYC". Talking about Lotus Notes/Domino web application architecture and security features, web application common development mistakes and fixes, and test methodology.
Lotus Notes/Domino History
Lotus Notes is client and Domino is the server. Supports multiple protocols with one interface (HTTP, LDAP, SMTP/POP/IMAP, file sharing). Strong on workflow application and collaborative application. Used by .gov, .edu, .com. Google search shows 66 million notes databases facing the internet. People use it because it's easy to develop and deploy a simple application, granular access control, good logging method, and it integrates well with e-mails.
Notes Databases
Notes databse is building block of Domino application (.nsf or .ntf). Notes Database is a container for data (document, message, web page), design elements (form, page, view, folder, navigator, agent, frameset, outline).
Two components in Domino server architecture. There is an HTTP Server and a Domino Engine (URL Parser, Command Handler, and Database).
Web Access Syntax
- http://host/data/base/NotesObject?Action&Arguments
- Database = Notes Database
- NotesObject = the web accessible design element
- Action = the action on NotesObject
- Arguments = the qualifiers for the action (optional)
Notes Database Access Control List (ACL)
- Define users and groups access privileges on the database
- Seven access levels (manager, designer, editor, author, reader, depositor, and no access)
- Eight access options for each level (create/delete documents, create/delete folders/views, create/delete agents, create/delete public documents)
- Anonymous and -Default-
- Maximum internet and password access: only works for name-password authentication but not for certificate authentication. A web user cannot get the access greater than the "Maximum" access even if the access explicitly given is higher
- Further restriction can be done by conjunction with reader field, author field, and access list of documents for granular read and write access control
Notes Web Authentication
- Anonymous user - who does not have Person documents in DOmino Directory (names.nsf)
- Authentication occurs if anonymous access is disabled on server configuration document and Notes objects
- Name-password authentication: user/pass are authenticated to Person document and internet password in Domino directory (names.nsf). Basic authentication and session-based authentication. Internet password lockout function (Notes 8 only)
- SSL client certificate authentication
Common Security Mistakes in Development
- Unauthorized Access: Anonymous access. Anonymous privilege is assigned to Default access level if there is no anonymous group explicitly set. Default access level is Designer and Maximum Internet and Password Access is Editor of most built-in templates. Forceful browsing. Solutions are to setup anonymous group and assign it "no access". Review the ACLs of all databases and confidential documents.
- Using Default Objects (Databases): Default databases are statrep.nsf, schema.nsf, reports.nsf, names.nsf, log.nsf, events.nsf, doladmin.nsf, dbdirman.nsf certsrv.nsf, certlog.nsf, admin4.nsf, ... Anonymous users should not be allowed to access these databases.
- Default Objects (view): $DefautlView?OpenView, $DefaultNav?OpenNav, $DefaultForm?OpenForm, help?OpenHelp, $about?OpenAbout, $searchform?searchdomain, $searchform?searchsite, $searchform?searchview, $Icon?OpenIcon, $first, $file. Solutions are to use the URL redirection and mapping on server document, customize the default pages, and apply the appropriate access control.
- SQL Injection: Places to process User Input (@Commands, WebQueryOpen, WebQuerySave, WebQueryClose, @URLQueryString, OpenAgent, RunAgent). Solutions is input validation in fields by formula or lotus scripts
- Cross Site Scripting: Most cross site scripting vulnerabilities are persistent. Solutions are to use input validaton or to HTMLencode.
- Session Management: By default uses basic authentication. Username and password are sent in clear-text in teh packet of every request. Solution is to configure the server document to use session-based authentication. Do not append sensitive data to Querystring.
- Information Leakage: Hard coding username and password. Solutions are to remove the sensitive information from the source code and log and customize the error message.
- Operating System Interaction: LotusScript has system commands such as Shell, OSLoadProgram, OSLoadLibrary, FileCopy, Open, Kill, Get, Input, Close. Solution is to hardcode the path and validate the filename input.
Testing security is challenging but it can be done:
- Lotus Notes Designer (Design Synopsis)
- Grep
- A good text editor
- Paros
References
- Secure Domino Application
- Lotus Security Handbook
Buildng and Stopping Next Generation XSS Worms – OWASP AppSec NYC 2008
I was originally planning on going upstairs for the SaaS Security presentation, but I had to come downstairs again to get my lunch and this topic seemed interesting, especially given the prevalence of cross site scripting in websites (see OWASP Top 10). The presentation was by Arshan Dabirsiaghi, the director of research at Aspect Security. He actually began by talking about Clickjacking and said that Jeremiah Grossman and RSnake gave up enough clues for him to figure out the exploit as far as Adobe flash goes and says that he'd rate the vulnerability a 7/10 in flash and an overall 10/10. Example non-weaponized exploit at http://i8jesus.com/stuff/clickjacking/test1.html using iframes and CSS. Suggested fix is to apply framebreakers to your page.
Is an XSS worm really a worm?
5 components of a worm:
- Reconnaissance - "[the worm] has to hunt out other network nodes to infect"
- Attack - "[components] used to launch an attack against an identified target system"
- Communication - "nodes in the network can talk to each other"
- Command - "nodes in the worm network can be issued operation commands"
- Intelligence - "the worm network needs to know the location of the nodes as well as characteristics about them"
Short answer: 3/5 - probably
How are XSS worms different from traditional?
- Infection model - Current model requires user interaction, worm strictly contained within web application, passive and localized, no Warhol worms (15 mins of fame).
- Payload capability - Perform any application function (money transfer, close account). XSSProxy/Attack API. Malware (yikes)
- Target shift - Internet worms can own everything both in front of and behind a firewall (island hopping).
- Penetration - Need to trick the user into spreading between sites using a 3rd party proxy.
Traits of Current XSS Worms
- Static payloads
- Passive infection strategy
- Staty on the same domain (don't say nduja)
- Uncontrolled growth
- No command and control
Current Incident Response Options
- Fix the vulnerability
- Manual purging - can only be done by experts and doesn't scale
- Database snapshot restore - effectively removes all worm data from tained columns, but forces loss of other application data
- Search & Destory - works now. Tricky in the future, but possible.
Next Gen XSS Worm Reconnaissance: A reconnaissance component will be added to the client side to find more web applications to infect. Nodes can use HTML5 Workers/Google Gears WorkerPool/<insert tomorrow's new RIA technology>. What about SOP? Old and busted: utilize 3rd party proxy (a la jikto ~2007). What attackers should be doing now: malware - no SOP! Next gen hotness: cross-site XHR, XDR, postMessage. Allows cross-site bidirectional communication. Servers must opt in, like Flash, so absolutely no security issues there (kidding)
Cross-site communication in HTML5
- postMessage(): Cross-domain communication based on strings. What do developers do with strings? JSON/eval() SiteA + JSON + SiteB = Shared Security
Staniford, Paxson & Weaver's Reconnaisance Techniques
- "hit list scanning"
- Permutation Scanning
- Topological Scanning (not without malware, cross-site XHR)
Next Gen XSS Worm Attack: An attack component will be added to the client side. New client side piece delivered with reconnaissance piece to attack other off-domain web apps. 85% of websites have XSS (how much is reflected vs stored?) How likely is it to fnd a stored XSS in another web app
Polymorphic Javascript: javascript can be highly mutated
Next Gen XSS Worm Communication: A communication component will never occur in a XSS worm. Can't communicate directly from victim browser to another victim browser. "centralization" in worms is just another word for weakness.
Next Gen XSS Worm Command: A command component will be added to the worm payload. Communicationw ith operator necessary for command-and-control structure, data delivery (new target info, soruce updates, etc)
- Attacker quietly posts signed payloads
- Victim creates token
- Victim queries Google form token using JSON
- Victim finds a signed result
- Executes the signed payload
Next Gen XSS Worm Intelligence: An intelligence component will be used after initial worm stages, it can't be trusted (adversaries can poison). XSS worms probably don't need this, they typically follow a pattern where the first 24 hours it reaches massive infections through epic growth rate. After that, gone and never seen again.
Ways to Prevent Next Gen XSS Worms
- search+destroying polymorphed javascript
- on demand exploit egress filters: popular sites need agile response techniques
- OWASP AntiSamy - safe rich input validation. Uses a positive security model for rich input validation. High assurance mechanism for stopping XSS (and phishing) attacks
- utilizing cross-domain workflows: letting the browser SOP protection prevent cookie disclosure + sensitive application information
- browser content restrictions: Doesn't make sense in a DOM. Requires parsers to honor end tag attributes.