Spi Workshop Preso Worm Hack2

The Hacking Evolution:
New Trends in Web Application Exploits and

Vulnerabilities
Brian Christian, Senior Security Engineer and Co-Founder, S.P.I
Dynamics
Agenda
Part 1: Introduction – How on earth did we get to this point?
Part 2: Identifying the Problem – How does this stuff happen?
Part 3: Key Application Vulnerabilities – Past, present and

future
Part 4: What Application Security Means to Compliance

Efforts and how to fix the problem.
Part 5: More information and online resources
Part 6: Q&A
SPI Dynamics Confidential

Part One
Introduction
 Who We Are - SPI Dynamics in a nutshell

 Application Security -How did we get to
this point?

SPI Dynamics
The Leader In Web Application

Security Assessment
We manufacture and license WebInspect, our industry
leading web application security assessment product,
to enterprises, consultants, and other institutions,
both directly and via global partners.
We own the world’s leading database of web
application security vulnerabilities, SecureBase™.
SecureBase is updated frequently by SPI Labs, our
U.S.-based research & development organization.

Web Sites
Simple, single server solutions
Browser Web Server

HTML
CGI

Web Applications
Very complex architectures, multiple

platforms, multiple protocols
Web Services
Application Database
Wireless Web Servers Server Server
Presentation Business Customer
Layer Logic Identification
Media Store Content Access
Browser services Controls
Transaction
Information
Core Business
Data

Common Web Applications

The Absolute Truth
 All code has bugs – regardless of platform,

language or application.
 From a Microsoft to a Mom and Pop’s home-
brewed application, all code has bugs.
 Some bugs are functionality bugs, which are
discovered by QA.
 Other bugs are security bugs, which largely go
unidentified.
 As long as functionality is the main objective and
not security, there will always be vulnerabilities in
computer applications.

Why These Thing Happen
This is your developed application.

This is all the stuff that
your application was
supposed to do, but
doesn’t do. These are
Functionality bugs
This is all the stuff that

your application is
supposed to do.
This is all the stuff

that your
application CAN
also do, but you’re
not aware of.
These are Security
his is your application design. vulnerabilities

Why Web Application Attacks Occur
The Web Application

Security Professionals Don’t
Know The Applications Security Gap Application
Developers and
QA Professionals
Don’t Know
“As a Network Security Security
Professional, I don’t “As an Application
know how my Developer, I can
company’s web build great features
applications are and functions while
supposed to work so I meeting deadlines,
deploy a protective but I don’t know
solution…but don’t how to develop my
know if it’s protecting web application
what it’s supposed to.” with security in
mind.”

Web Applications Breach the Perimeter
INTERNET
HTTP
FTP TELNET IMAP SSH POP3

DMZ
Firewall only allows PORT 80 (or 443

SSL) traffic from the internet to the
web server.
Any – Web Server: 80

TRUSTED
INSIDE
Firewall only allows applications

on the web server to talk to
application server.
Web Server Application Server

CORPORATE
Firewall only
INSIDE
allows application
server to talk to
database server.
Application Server Database

Web Applications Invite Public Access
“Today over 70% of

attacks against a
company’s website or
web application come
at the ‘Application
Layer’ not the network
or system layer.”
- Gartner Group

Web Application Risk
“Web application incidents cost companies

more than $320,000,000 in 2001.”
Forty-four percent (223 respondents) to the

2002 Computer Crime and Security Survey were
willing and/or able to quantify their financial
losses. These 223 respondents reported
$455,848,000 in financial losses.
“2002 Computer Crime and Security Survey”
Computer Security Institute & San Francisco

FBI Computer Intrusion Squad

Part Two
Identifying the Problem
 What are the primary vulnerabilities?

 How and why they occur

Web Application Vulnerabilities
Web application vulnerabilities

occur in multiple areas.
Application
Parameter
Manipulation
Administration
Cross-Site Scripting
Extension Checking
SQL Injection
Common File Checks
Buffer Overflow
Data Extension
Checking Reverse Directory
Platform Transversal
Backup Checking
Known JAVA Decompilation
Vulnerabilities Directory
Enumeration Path Truncation
Hidden Web Paths
Path Truncation
Cookie Manipulation
Hidden Web Paths
Application Mapping
Forceful Browsing
Backup Checking
Directory Enumeration

Cross Site Scripting
(or XSS)
Cross Site Scripting (XSS)
 Cross-site scripting (also know as XSS or CSS)

occurs when dynamically generated web pages
display input that is not property validated.
 A user passes input in the form of a parameter to

the web server.
 The web server returns the user provided input

back to the user without proper encoding.
 Again, a demonstration!

SQL Injection
SQL Injection – Defined
 SQL injection is a technique for exploiting web

applications that use client-supplied data in SQL
queries without stripping potentially harmful
characters first.
 Allow me to demonstrate!

Part Three
Key Application Vulnerabilities
 Past, Present and Future

 Google Hacking

Google Hacking
More then searching for great pr0n.
Google Hacking
 Find vulnerable sites using Google (Old method –

new life)
 Example Search Queries
 “filetype:mdb inurl:admin” – 180 results
 “Filetype:xls inurl:admin” – 14,100 results
 “ORA-00921: unexpected end of SQL
command” – 3,470 results
 “allintitle:Netscape Enterprise Server Home
Page” – 431 results

Google Hacking
 Take this method a step further and use it to

narrow your attack victims.
 “inurl:id= filetype:asp site:gov” – 572,000 results
 “inurl:id= filetype:asp site:com” – 7,150,000
results
 “inurl:id= filetype:asp site:org” – 3,240,000
results
 Use this list as a baseline for identifying SQL

injection vulnerabilities

Google Hacking
 Take this method a step further and use it to

narrow your attack victims.
 “inurl:id= filetype:asp site:gov” – 572,000 results
 “inurl:id= filetype:asp site:com” – 7,150,000
results
 “inurl:id= filetype:asp site:org” – 3,240,000
results
 Use this list as a baseline for identifying SQL

injection vulnerabilities

Google Hacking
 Took 1 hour of coding

 500 vulnerable sites were found in 1 minute and
26 seconds

Google Hacking
Find next victim
Exploit victim Exploit victim
 Application Worm

Enter the Santy Worm
 Perl.Santy is a worm written in Perl script that attempts to

spread to Web servers running versions of the phpBB 2.x
bulletin board software Viewtopic.PHP PHP Script Injection
Vulnerability
 Other systems are not affected. If successful, the worm copies

itself to the server and overwrites the files with the following
extensions:
.asp, .htm, .jsp, .php, .phtm, .shtm
 The worm uses the Google search engine to find potential new
infection targets. Google has now implemented blocking
Perl.Santy search requests, which is expected to greatly reduce
the worm's ability to propagate and lower the risk of further
infections.

Enter the Santy Worm
 Perl.Santy.A [Computer Associates], Santy [F-

Secure], Net-Worm.Perl.Santy.a [Kaspersky],
Perl/Santy.worm [McAfee], PHP/Santy.A.worm
[Panda], Perl/Santy-A [Sophos], WORM_SANTY.A
[Trend Micro]
 UNIX, LINUX, Windows 2000, Windows 95,

Windows 98, Windows Me, Windows NT, Windows
Server 2003, Windows XP

http://www.google.com/search?num=100&hl=en&lr=&as_qdr=all&q=allinurl%3A+
%22viewtopic.php%22+%22

The Past, the Present, and the Future of Hacking
How prolific could this whole scenario be?
Where We’ve Been – The Past
 Since most sites were

static HTML, not much to
do but try to obtain root /
admin privileges on the
machine or deface the
website.
 This proved for some

great comedy.

Where We’re At– The Present
 Since more dynamic

and unique content has
been added to
websites, and users
demand even MORE
functionality so that
they can do everything
electronically, insecure
content was added at
an expedited pace!
 And users and

management demand
even more!

Where We’re Going– The Future
 Application hacking is
becoming more complex
as applications are
becoming more complex.
The possibilities are
endless when it comes
down to what can you
exploit in web
applications.
 Take for Instance

Application Worms, Web
Application Worms.

What Application Security Means to Compliance Efforts
How prolific could this whole scenario be?
Types of Compliance Regulations
 Privacy
 HIPPA (Health Insurance Portability and
Accountability Act)
 SOX (The Sarbanes-Oxley Act )
 GLBA (Gramm-Leach-Bliley Act)
 Disclosure
 CA1386
 Federal Trade Commission
 Privacy Policy
 Practice
 PCI
Privacy
 Privacy
 HIPAA (Health Insurance Portability and
Accountability Act)
 SOX (The Sarbanes-Oxley Act )
 GLBA (Gramm-Leach-Bliley Act)

HIPAA
 The Health Insurance Portability and Accountability Act

(HIPAA) mandates the privacy and security of personal
health
 The Security Rule of the Act recommends information
security best practices to protect personal information.
 HIPAA requires organizations to perform a HIPAA security
risk assessment to determine what applications and data are
vulnerable, to ensure proper authentication, access
control, and logging systems, and to conduct ongoing
auditing of information systems to test for newly discovered
vulnerabilities.
 Web Challenge:
 Establishing a security policy
 Establishing standards that support the policy
 Effectively auditing to ensure policy compliance

SOX - The Sarbanes-Oxley Act
 Sarbanes-Oxley focuses on regulating corporate behavior for the

protection of financial records instead of enhancing the privacy and
security of confidential customer information.
 Difficult because it was not written specifically with information
technology or information security in mind
 Addresses
 How information is accessed
 What leaves the corporate network
 Other financial controls
 Web Challenges
 Financial information resides on the same networks as web
applications or there associated systems (Databases, etc)
 Web front ends for financial systems are a common interface to
financial systems.
 These can be susceptible to web application attacks
 Requires the development of a policy

GLBA - The Gramm-Leach-Bliley Act
 The Gramm-Leach-Bliley Act (GLBA), formally known as the Financial

Modernization Act of 1999,
 Established requirements for financial institutions in the United States
to protect consumers’ personal financial information.
 The GLBA contains three principle requirements
 The Financial Privacy Rule requires financial institutions to publish
a privacy notice to their customers
 Consumers also must be given the right to limit the sharing of
their personal information.
 The Safeguards Rules require all financial institutions to design,
implement and maintain safeguards and a security plan to protect
customer information that they handle.
 Web Challenges
 Customer information resides on the same networks as web
applications or there associated systems (Databases, etc)
 Web front ends for financial systems are a common interface to
customer financial systems.
 These can be susceptible to web application attacks
 Requires the development of a policy

Disclosure
 Disclosure
 CA1386
 MANY others are coming VERY SOON

CA 1386
 Enacted in order to force anyone holding private personal

information, to inform consumers immediately if their
personal information has been compromised.
 The law also gives consumers the right to sue
 Any business, organization or individual that holds private
personal information for a person residing in the state of
California is bound by the provisions of the law, so
California SB 1386 has a much greater impact nationally
than is typical for state legislation.
 Web Challenges:
 Is a performance based law, not policy based
 If you get hacked you have to disclose the incident

Federal Trade Commission
 Federal Trade Commission

 Privacy Policy
www.owasp.org
www.webappsec.org
www.securityfocus.com
www.spidynamics.com

Federal Trade Commission
 From: http://www.ftc.gov/privacy/
 “Under the FTC Act, the Commission guards against
unfairness and deception by enforcing companies'
privacy promises about how they collect , use and
secure consumers' personal information.”
 Web security challenge:
 Companies are being investigated for FTC violations
because they are not living up to there stated policy
 http://www.webappsec.org/documents/real_world_web_hack
 PETCO
 Guess
 Many others

Visa PCI
 The Payment Card Industry (PCI) Data Security Standard is a

collaborative effort by Visa, MasterCard, American Express and
Discover to ensure the protection of customers' personal
information.
 The standard establishes 12 security requirements that all
members, merchants and service providers must adhere to.
 Sections 6, 11 and 12 have specific web related issues.
 Web security challenges
 PCI is the most comprehensive and specific standard in the
industry.
 Following the standard will greatly improve a companies
web application security overall
 Not following PCI can cost a company it’s ability to process
credit cards

VISA PCI
 http://usa.visa.com/business/accepting_visa/ops_risk_management/cisp.html
 Go to VISA.COM and search for PCI
 Build and Maintain a Secure Network

 1. Install and maintain a firewall configuration to protect data
 2. Do not use vendor-supplied defaults for system passwords and other security
parameters
 Protect Cardholder Data
 3. Protect stored data
 4. Encrypt transmission of cardholder data and sensitive information across public
networks
 Maintain a Vulnerability Management Program
 5. Use and regularly update anti-virus software
 6. Develop and maintain secure systems and applications
 Implement Strong Access Control Measures
 7. Restrict access to data by business need-to-know
 8. Assign a unique ID to each person with computer access
 9. Restrict physical access to cardholder data
 Regularly Monitor and Test Networks
 10. Track and monitor all access to network resources and cardholder data
 11. Regularly test security systems and processes
 Maintain an Information Security Policy
 12. Maintain a policy that addresses information security

General compliance needs
 Establish a security policy

 Identify what will be done to address web application
security needs and who will be responsible for it
 Follow the policy
 Ensure that security policies are being followed
throughout the software lifecycle
 Document that the policy was followed
 Have a record of testing that was done to ensure that
the policy was followed
 SDLC
 The Software Development Lifecycle Cycle needs to
respect and support compliance efforts
 Unlike other compliance efforts, web application security
needs to be integrated into the SDLC

ASAP Process
Support &
Requirements Design Development Test (QA) Release
Services
Security Training Source code review Security services
Security Threat Development QA Automated assessment

Kickoff Modeling Assessment Automated tools
Tools Assessment
Create Development tools Infrastructure Assessment
Standards Secure coding
libraries QA Manual
Infrastructure Assessment
Design tools
Pen Testing
Regulatory Compliance

Enterprise-Wide Web Application Security
Web Application Security testing

must be applied in all phases of the
Application Lifecycle and by all
constituencies throughout the
enterprise – Auditors, Application
A D
Developers, QA and Security
Operations. Web
Application
Security
S Q

Application Developers
• Must have clear cut security
D
requirement to follow during
Development and QA phases
• Need to run automated tests on code
during Development phase
• Must utilize secure code for re-use
• Require automated testing products
A
that integrate into current Web
Web
environment
Web
Application
Application
Application
Security
S Q

Quality Assurance Professionals
Must test applications not only for functionality but also for security
•
Must test environments for potential flaws and insecurities
D
•
•
•
Must provide detailed security flaw reports to development
Require automated testing products that integrate into current
environment
A
Web
Web
Web
Application
Application
Application
Security

Security Operations
• Must continually test application in a real
D
world environment to asses impact of ongoing
code changes A
• Must look for all levels of web vulnerabilities
WebWeb
• Platform Web
Application
Application
Application
• Informational
Security
• Application
Q
S
Security

Security Auditors and Risk

and Compliance Officers
• Help define regulatory requirements during
the Definition phase of the Application
Lifecycle
A
• Assess applications once they are in the
Production phase to validate compliance
• Must act as resource for what is and is not
acceptable D
Web
Web
Web
Application
Application
Security
S Q

Part Five
Other Online Resources
 Websites and mailing lists on the net

Websites
 - www.spidynamics.com
 Web Application Security Consortium -

www.webappsec.org
 CGISecurity.net – http://www.cgisecurity.net/
 Open Web Application security Project -

www.owasp.org
 WebAppSec Mailing list – Security Focus

Questions?
Contact
Brian Christian: bchristian@spidynamics.com
SPI Dynamics, Inc.

115 Perimeter Center Place
Suite 1100
Atlanta, GA 30346
For a free
WebInspectTM 15-day
trial download visit:
www.spidynamics.co
m

Spi Workshop Preso Worm Hack2

Transféré par

Informations du document

Description originale:

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Spi Workshop Preso Worm Hack2

Transféré par

Droits d'auteur :

Formats disponibles

The Hacking Evolution:

New Trends in Web Application Exploits and

Part 1: Introduction – How on earth did we get to this point?

Part 2: Identifying the Problem – How does this stuff happen?

Part 3: Key Application Vulnerabilities – Past, present and

Part 4: What Application Security Means to Compliance

Part 5: More information and online resources

SPI Dynamics Confidential

 Who We Are - SPI Dynamics in a nutshell

SPI Dynamics Confidential

The Leader In Web Application

SPI Dynamics Confidential

Simple, single server solutions

Browser Web Server

SPI Dynamics Confidential

Very complex architectures, multiple

SPI Dynamics Confidential

SPI Dynamics Confidential

 All code has bugs – regardless of platform,

SPI Dynamics Confidential

This is your developed application.

This is all the stuff that

This is all the stuff

SPI Dynamics Confidential

The Web Application

SPI Dynamics Confidential

FTP TELNET IMAP SSH POP3

Firewall only allows PORT 80 (or 443

Any – Web Server: 80

Firewall only allows applications

Web Server Application Server

Application Server Database

SPI Dynamics Confidential

“Today over 70% of

SPI Dynamics Confidential

“Web application incidents cost companies

Forty-four percent (223 respondents) to the

“2002 Computer Crime and Security Survey”

Computer Security Institute & San Francisco

SPI Dynamics Confidential

Identifying the Problem

 What are the primary vulnerabilities?

SPI Dynamics Confidential

Web application vulnerabilities

SPI Dynamics Confidential

 Cross-site scripting (also know as XSS or CSS)

 A user passes input in the form of a parameter to

 The web server returns the user provided input

SPI Dynamics Confidential

 SQL injection is a technique for exploiting web

SPI Dynamics Confidential

Key Application Vulnerabilities

 Past, Present and Future

SPI Dynamics Confidential

 Find vulnerable sites using Google (Old method –

SPI Dynamics Confidential

 Take this method a step further and use it to

 Use this list as a baseline for identifying SQL

SPI Dynamics Confidential

 Take this method a step further and use it to

 Use this list as a baseline for identifying SQL

SPI Dynamics Confidential

 Took 1 hour of coding