Joe Yeager, Security Engineer - PowerPoint PPT Presentation

1 / 88
About This Presentation
Title:

Joe Yeager, Security Engineer

Description:

MySpace Sues Spammer. Lawsuit claims Richter spoofed login pages to steal usernames and passwords in a ' ... No login errors, no changes, user works normally ... – PowerPoint PPT presentation

Number of Views:130
Avg rating:3.0/5.0
Slides: 89
Provided by: SPIDyna5
Category:

less

Transcript and Presenter's Notes

Title: Joe Yeager, Security Engineer


1
Joe Yeager, Security Engineer SPI Dynamics, Inc.
London, England
2
Overview
  • Background
  • Secure Software Forum (SSF)
  • SPI Dynamics
  • Web applications and their vulnerabilities
  • Offense
  • Case studies
  • Examples
  • Cross Site Scripting (XSS)
  • Cross Site Request Forgery (CSRF)
  • SQL Injection
  • Blind SQL Injection
  • Defense
  • Trustworthy Computing Security Development
    Lifecycle
  • Application Security Assurance Program (ASAP)

3
Secure Software Forum (SSF)
  • Started February 2005
  • Annual education series dedicated to secure
    software
  • Leading security experts collaborate on education
    initiatives
  • Yearly programs include
  • February kick-off event at RSA
  • Free workshop series
  • Executive dinner series
  • http//www.securesoftwareforum.com/

4
SPI Dynamics Overview
  • Founded January 2000 by Web application and
    security experts
  • The leader in Web application security assessment
    throughout the lifecycle
  • Eight patents pending or issued
  • 1000 customers all over the World
  • Strong in F500, all industries and government
  • 2006 Inc. 500 list of fastest-growing private
    companies
  • 2005 Deloitte Technology Fast 500
  • 2005 Deloitte Georgia Technology Fast 50

Annual Revenue
5
History of Application Security
6
The Evolution of Web Applications
Static web Page
  • A typical web application in 2000
  • Basic static HTML pages
  • Informational applications
  • Not mission critical functions

Static web Page
Static web Page
Static web Page
Static web Page
7
The Evolution of Web Applications
Simple, single server solutions
Browser Web Server
8
Web Application Architecture of Today
Web Services
Database Server Customer Identification Access
Controls Transaction Information Core Business
Data
Application Server Business Logic Content Services
Web Servers Presentation Layer Media Store
Wireless
Browser
9
Web Applications Breach the Perimeter
Trusted Inside
Internet
DMZ
IIS SunOne Apache
ASP .NET WebSphere Java
SQL Oracle DB2
Corporate Inside
HTTP(S)
Firewall only allows PORT 80 (or 443 SSL) traffic
from the Internet to the web server. Any Web
Server 80
Firewall only allows applications on the web
server to talk to application server.
Firewall only allows application server to talk
to database server.
IMAP FTP SSH TELNET POP3
10
Layered Model of Security
Web Application Code - Content - Implementation
Web Server Known Vulnerabilities -
Misconfigurations
Operating System Known Vulnerabilities -
Misconfigurations
Network Layer Exposed Hosts/Protocols
11
Vulnerability Characteristics
  • Extremely easy to exploit
  • Sometimes requires nothing more than a Web
    browser
  • Orders of magnitude easier than buffer overflows
  • Difficult to deal with at the perimeter
  • SSL Encrypted Traffic, huge volume
  • Rules granular to each input on each page, change
    as app changes

12
Vulnerability Remediation
Global Notification
Uniform Vulnerabilities
No Notification
Custom Vulnerabilities
Single Source Fix
Custom Testing
Standardized Testing
Custom Fix
13
Current State of the Industry
14
Compelling Evidence
Over 70 percent of security vulnerabilities
exist at the application layer, not the network
layer Gartner
The battle between hackers and security
professionals has moved from the network layer to
the Web applications themselves Network World
64 percent of developers are not confident in
their ability to write secure applications Micros
oft Developer Research
Hacking has moved from a hobbyist pursuit with a
goal of notoriety to a criminal pursuit with a
goal of money Counterpane Internet Security
15
Prevalence of Web App Vulns
16
Mitre CVE Statistics
17
The State of Application Security
POSTED 956 a.m. EST, January 23, 2007
18
Web ApplicationVulnerability Overview
19
Web Application Vulnerabilities
Web application vulnerabilities occur in three
major areas
20
Web Application Vulnerabilities
  • Platform
  • Known vulnerabilities can be exploited
    immediately with a minimum amount of skill or
    experience script kiddies
  • Easiest to defend against among web application
    vulnerabilities
  • Must have streamlined patching procedures
  • Must have inventory process
  • Examples
  • IIS UNICODE
  • Apache chunked encoding

21
Web Application Vulnerabilities
  • Administration
  • More difficult to correct than known issues
  • Require increased awareness
  • Remnant files can reveal applications and
    versions in use
  • Backup files can reveal source code and database
    connection strings
  • Examples
  • Extension Checking
  • Common File Checks
  • Data Extension Checking
  • Backup Checking
  • Directory Enumeration
  • Path Truncation
  • Hidden Web Paths
  • Forceful Browsing

22
Web Application Vulnerabilities
  • Application
  • Coding techniques do not include security
  • Input is assumed to be valid, but not tested
  • Inappropriate file calls reveal source code
    system files
  • Unexamined input from a browser can inject
    scripts into page for replay against later
    visitors
  • Unhandled error messages reveal application and
    database structures
  • Unchecked database calls can be piggybacked
    with a hackers own database call, giving direct
    access to business data through a web browser
  • SQL Injection
  • Hidden Web Paths
  • Forceful Browsing
  • Custom Application Scripting
  • Parameter Manipulation
  • Examples
  • Application Mapping
  • Cookie Manipulation

23
Cross Site Scripting (XSS)
24
Case Study - Google
Impact
Fix
References
Cause
Case Study
Demo
25
Case Study - Google
Impact
Fix
References
Cause
Case Study
Demo
26
Case Study - Google
Impact
Fix
References
Cause
Case Study
Demo
27
Case Study - PayPal
Impact
Fix
References
Cause
Case Study
Demo
Phishing Scam Uses PayPal Secure Servers
Scripting flaw makes fake page with valid
security certificate possible.
Peter Sayer, IDG News Service Friday, June 16,
2006 0300 PM PDT
A cross-site scripting flaw in the PayPal Web
site allows a new phishing attack to masquerade
as a genuine PayPal log-in page with a valid
security certificate, according to security
researchers. Fraudsters are exploiting the flaw
to harvest personal details, including PayPal
log-ins, Social Security numbers, and credit card
details, according to staff at Netcraft, an
Internet services company in Bath, England. The
PayPal site, owned by eBay, allows users to make
online payments to one another, charged to their
credit cards, and log-in credentials for the
service are a prized target of fraudsters.
28
Case Study - PayPal
Impact
Fix
References
Cause
Case Study
Demo
29
XSS Demo Overview
Impact
Fix
References
Cause
Case Study
Demo
  • Definition
  • Client side scripting languages injected into web
    page
  • HTML
  • JavaScript
  • VBScript
  • Facilitators
  • URL spoofing
  • URL obfuscation
  • Mitigating factors
  • Social engineering

30
XSS Demo
Impact
Fix
References
Cause
Case Study
Demo
31
URL Obfuscation
Impact
Fix
References
Cause
Case Study
Demo
  • Dotted Decimal IP addresses
  • URL http//www.google.com
  • IP http//216.239.51.99
  • Decimal - http//3639554915
  • 216 2563 239 2562 51 2561 99
  • Octal - http//0330.0357.0063.0143
  • Hexadecimal - http//0xd8ef3363
  • Hexadecimal encoded
  • http//7777772E676F6F676C652E636F6D
  • URLomatic (http//www.samspade.org/t/url)
  • TinyURL (eg. http//tinyurl.com/y8pgom)

32
Phishing Attack
Impact
Fix
References
Cause
Case Study
Demo
  • Cross-Site-Scripting attack via emailed vector.
  • Innocent-looking link has embedded client side
    script

33
Phishing Attack
No Alarms and No Surprises
  • Original legitimate website
  • No login errors, no changes, user works normally
  • UserID and Password quietly handed off to remote
    website
  • No injected

34
Reflected vs. Persistent XSS
Impact
Fix
References
Cause
Case Study
Demo
  • Reflected
  • Embedded script forwarded to victim, generally
    via email with script contained in obfuscated
    URL
  • Persistent
  • Permanently embed script into web applications
  • Blogs
  • Shared Calendars
  • Message Boards
  • Web Forums
  • System logs
  • Convince victim to visit vulnerable web page

35
XSS Cause
Impact
Fix
References
Cause
Case Study
Demo
  • Cause
  • Unfiltered user input is embedded in web page
  • Example
  • Request
  • http//www.example.com?namejoepasswordsecret
  • Response
  • ASP
  • Welcome back ("name"))
  • PHP
  • Welcome back

36
XSS Fix
Impact
Fix
References
Cause
Case Study
Demo
  • Filter user input
  • Whitelist
  • Blacklist
  • HTML encode user supplied data prior to inclusion
    in a web page
  • ASP/ASP.Net
  • Server.HTMLEncode (strHTML String)
  • PHP
  • string htmlspecialchars (string string , int
    quote_style)

37
XSS References
Impact
Fix
References
Cause
Case Study
Demo
  • Whitepapers
  • http//www.spidynamics.com/spilabs/education/white
    papers/ CrossSiteScripting.html
  • FAQs
  • http//www.cgisecurity.com/articles/xss-faq.shtml
  • http//www.owasp.org/index.php/XSS
  • Cheat Sheet
  • http//ha.ckers.org/xss.html

38
Cross Site Request Forgery (CSRF)
39
Case Study - Google
Impact
Fix
References
Cause
Case Study
Demo
40
CSRF Demo Overview
Impact
Fix
References
Cause
Case Study
Demo
  • Definition
  • An attack that tricks a victim into loading a
    page that contains a malicious request
  • Exploits the trust established between a web
    browser and web app
  • Performs actions on behalf of the victim
  • Targets functions that cause a state change on
    the server
  • Synonyms
  • XSRF, Session Riding, Cross-Site Reference
    Forgery, Hostile Linking, One-Click attack
    (Microsoft)
  • Facilitators
  • Persistent session credentials
  • Mitigating factors
  • Social engineering

41
CSRF Demo
Impact
Fix
References
Cause
Case Study
Demo
42
CSRF Impact
Impact
Fix
References
Cause
Case Study
Demo
  • Actions are performed on behalf of the victim
    which were not intended
  • Posting to message board
  • Transferring funds
  • Changing password
  • Etc.
  • Non-repudiation victim cannot prove that the
    actions were not performed intentionally

43
CSRF Cause
Impact
Fix
References
Cause
Case Study
Demo
  • Cause
  • Actions are performed without forcing human
    intervention
  • or
  • Source of request not confirmed
  • Example
  • GET http//site.com/trade?stockgoogno500action
    sell
  • or
  • POST /trade HTTP/1.1
  • Host site.com
  • ...
  • Cookie SessionIDw5l3xp55viao1455aqkqsaji
  • stockgoogno500actionsell

44
CSRF Fix
Impact
Fix
References
Cause
Case Study
Demo
  • Countermeasures that do NOT work
  • Secret cookies
  • All cookies are transmitted when requests are
    made
  • Using POST instead of GET request
  • Numerous options for crafting POST requests
  • Countermeasures that do work
  • Server side
  • Per-request nonce for URLs/forms
  • ASP.Net -
  • J2EE CSRF Guard (http//www.owasp.org/index.php/
    CSRF_Guard)
  • PHP CSRF Guard (http//www.owasp.org/index.php/PHP
    _CSRF_Guard)
  • Force human intervention
  • Secondary login
  • Confirmation email or SMS message
  • CAPTCHA
  • Client side
  • Always log out of applications when finished

45
CSRF References
Impact
Fix
References
Cause
Case Study
Demo
  • Whitepapers
  • http//www.isecpartners.com/files/XSRF_Paper_0.pdf
  • FAQs
  • http//www.cgisecurity.com/articles/csrf-faq.shtml
  • http//www.owasp.org/index.php/CSRF
  • http//www.owasp.org/index.php/Testing_for_CSRF

46
SQL Injection
47
Case Study - RI.gov
Impact
Fix
References
Cause
Case Study
Demo
48
Case Study - RI.gov
Impact
Fix
References
Cause
Case Study
Demo
49
Case Study - CardSystems
Impact
Fix
References
Cause
Case Study
Demo
50
Case Study - CardSystems
51
Case Study - CardSystems
52
Case Study - CardSystems
53
SQL Injection Demo Overview
Impact
Fix
References
Cause
Case Study
Demo
  • Definition
  • User input is concatenated into SQL queries
  • Verbose Server provides detailed error messages
  • Blind Error messages are suppressed
  • Facilitators
  • Majority of websites are database driven
  • Mitigating factors
  • Database ACLs can limit access to data

54
SQL Injection Demo
Impact
Fix
References
Cause
Case Study
Demo
55
Sample SQL - Authentication
Impact
Fix
References
Cause
Case Study
Demo
?
56
SQL Injection Impact
Impact
Fix
References
Cause
Case Study
Demo
  • Confidentiality
  • SELECT
  • Data integrity
  • INSERT, DROP, DELETE
  • Authentication bypass
  • OR 11 --
  • System compromise
  • Stored procedures
  • Extended stored procedures

57
Database Driven Page
  • Page reads ErrorCode from request
  • Uses ErrorCode in a SQL Query
  • Writes the results of the query

58
Common Database Query
Query written as text string
sSql "select ErrorMessage from ErrorMessages
where ErrorCode " Request("ErrorCode")
Query parameter appended to query
select ErrorMessage from ErrorMessages where
ErrorCode 2
59
Problem Unvalidated Input
select ErrorMessage from ErrorMessages where
ErrorCode 2
  • Invalid character entered is used in query
  • Resulting back-end query results in an ODBC error
    message

60
Piggybacking queries with UNION
Values entered into the parameter ErrorCode now
have the ability to modify the query itself (
instead of just being a parameter to the query)
select ErrorMessage from ErrorMessages where
ErrorCode 9 union select name from sysobjects
where xtypeu
UNION keyword tells SQL to combine two statements
into one
61
Enumerate all tablesin the database
Sysobjects stores names of tables in
database Name name of table Xtype type of
table (system, user) Xtypeu all user
tables, no system tables.
62
A SubQuery Enumerates Columns in the Table
  • Columns are stored in syscolumns
  • Keyed on ID
  • Subquery against ID in sysobjects for the table
    you want

Select name from syscolumns where id(select id
from sysobjects where nametable)
63
Select the data from the column
  • 4 HTTP packets to your data
  • Find the injection
  • Select tables from sysobjects
  • Select columns from syscolumns
  • Select data from column

64
Stored ProceduresExtended Stored Procedures
  • xp_cmdshell
  • exec master..xp_cmdshell dir
  • xp_regread
  • Read registry keys
  • xp_makecab
  • Build compressed archives
  • xp_terminate_process
  • sp_addextendedproc
  • Custom extended stored procedures
  • sp_makewebtask
  • Export results to web page

65
Blind SQL Injection
66
Blind SQL Injection Demo
Impact
Fix
References
Cause
Case Study
Demo
67
SQL Injection Fix
Impact
Fix
References
Cause
Case Study
Demo
  • Harden SQL server
  • Filter user input
  • Whitelist
  • Blacklist
  • Parameterized SQL queries
  • SqlConnection objConnection new
    SqlConnection(_ConnectionString)
    objConnection.Open() SqlCommand objCommand new
    SqlCommand( "SELECT FROM User WHERE Name
    _at_Name AND Password _at_Password", objConnection)
    objCommand.Parameters.Add("_at_Name",
    NameTextBox.Text) objCommand.Parameters.Add("_at_Pas
    sword", PasswordTextBox.Text) SqlDataReader
    objReader objCommand.ExecuteReader()

68
SQL Injection References
Impact
Fix
References
Cause
Case Study
Demo
  • Whitepapers
  • http//www.spidynamics.com/spilabs/education/white
    papers/SQLinjection.html
  • http//www.spidynamics.com/assets/documents/Blind_
    SQLInjection.pdf
  • http//www.nextgenss.com/papers/advanced_sql_injec
    tion.pdf
  • FAQs
  • http//www.cgisecurity.com/development/sql.shtml
  • http//www.owasp.org/index.php/SQL_injection
  • Cheat Sheets
  • http//ferruh.mavituna.com/makale/sql-injection-ch
    eatsheet/
  • http//www.jungsonnstudios.com/blog/?i14bin1110

69
Managing Software Assurance
70
Web Application Security Programs
Certain industries make automated application
assessments standard practice
Networks Secured, Applications Vulnerable
Early Adopters Begin Manual Application Testing
These early adopter industries establish
application security programs
2000
2006
  • Web application security programs
  • Enabled across the software development lifecycle
    (SDLC)
  • Leverage automated assessment software
  • Involve cross functional teaming
  • Require executive sponsorship

71
Policies are a good start
  • Policies can
  • Give guidance and articulate what is expected
    during the software lifecycle
  • Can mandate verification
  • VISA PCI
  • HIPAA, SOX, GLBA, Privacy policies
  • Polices do not
  • Take the place of a mature SDLC
  • Ensure that application are secure

72
NSA using Persistent Cookies
73
White House using Persistent Cookies
74
Security and the SDLC
  • Problems are a part of the way we build software
  • Solutions need to be part of the process

75
Elements that Drive Change
People Providing guidance on secure application
development
Process Security cannot be an afterthought
Tools Providing the most innovative tools
76
People Education As a Driver
Patterns Practices Dedicated team focused on
security guidance
MSDN and TechNet Sharing whitepapers and how tos
Education Train every Developer and IT
Professional on security
77
Process Security Development Lifecycle (SDL)
  • Reduce the number of security errors
  • Reduce the severity of any security errors not
    found
  • Reduce the attack surface

78
Tools Innovation and Automation
Tools facilitate creating secure applications
Secure by Default
Static Analysis
Create non-admin apps
Scan your code for security vulnerabilities
Use features like the /GS switch and SafeCRT
libraries to create secure apps
Seamless create applications for a custom zone
Nurturing the Partner Ecosystem
79
Engineering ExcellenceFocus Yielding Results
80
Application Security Assurance ProgramMaturity
Model Best Practices
81
Application Security Assurance Program (ASAP)
  • ASAP Maturity Model is about defining a roadmap
    and execution of the SDL
  • Organizations should implement their own
    Trustworthy Computing Initiative tailored to
    their own needs
  • Describes the programs needed to integrate
    security throughout the software development
    lifecycle and throughout the production lifespan
    of the application
  • A holistic program providing end to end lifecycle
    coverage while spanning People, Process and
    Technology

TECHNOLOGY
PROCESS
PEOPLE
Executive Buy-in, Integrated Organization
Proactive Strategic
Technical Management Curriculum
Policy-driven Secure SDL
Management
Cross-Functional Teams
Integrated Development QA Tools
Developer Awareness
Reactive Tactical
Security Department Testing Tools
Organizational Silos
82
ASAP Maturity Model
Level 1 Reactive Tactical
  • Characterized By
  • Security team finds application vulnerabilities
    from initial scanning efforts
  • Most vulnerabilities require development fixes
  • Vulnerability reports sent to development
  • Development pushes back due to short timelines
    business impact of security rework
  • Due to a lack of application security training,
    issue acceptance and resolution is difficult

TECHNOLOGY
PROCESS
PEOPLE
Proactive Strategic
Reactive Tactical
Security Department Testing Tools
Organizational Silos
83
ASAP Maturity Model
  • Characterized By
  • Security team conducts assessment
  • Developers trained on security
  • Vulnerabilities still require development
    fixes
  • Vulnerability reports sent to development

Level 2 Planned Purposeful
TECHNOLOGY
PROCESS
PEOPLE
Proactive Strategic
Cross-Functional Teams
Integrated Development QA Tools
Developer Awareness
  • Now, developers understand the issues
  • The development process still doesnt include
    proactive secure development.

Reactive Tactical
Security Department Testing Tools
Organizational Silos
84
ASAP Maturity Model
  • Characterized By
  • Vulnerability management software used across
    SDLC
  • Security processes in place across SDLC
  • Security integrated into entire development
    lifecycle
  • All levels of the organization committed to
    security
  • Complete security curriculum standard practice

Level 3 Proactive Strategic
TECHNOLOGY
PROCESS
PEOPLE
Executive Buy-in, Integrated Organization
Technical Management Curriculum
Policy-driven Secure SDL
Management
Cross-Functional Teams
Integrated Development QA Tools
Developer Awareness
Security Department Testing Tools
Organizational Silos
85
ASAP Best Practices

Regulatory Compliance


86
Cost of Fixing Vulnerabilities
Source IDC and IBM Systems Sciences Institute
87
  • Questions?

88
Resources Contact Information
  • Workshop Overview (slides and URLs)
  • http//www.securesoftwareforum.com/sutton
  • Secure Software Forum
  • http//www.securesoftwareforum.com
  • Blog
  • http//portal.spidynamics.com/blogs/msutton
  • Whitepapers
  • http//www.spidynamics.com/spilabs/education/white
    papers.html
  • SQL Injection
  • Blind SQL Injection
  • Cross-Site-Scripting
  • LDAP Injection
  • SOAP Attacks

Joe Yeager Me (SE) jyeager_at_spidynamics.com Dan
Buckley Sales dbuckley_at_spidynamics.com
Write a Comment
User Comments (0)
About PowerShow.com