Implementing a Comprehensive Application Security Program

www.niiconsulting.com
Implementing a Comprehensive
Application Security Program
Taufiq Ali
Manager – Security Assessment

Agenda
 The Biggest Hack in History
 How the Cookie Crumbles
 Answers!
 Technology Solutions
 Strategies
 Q&A

Information Security
View from the Trenches

Recent News

Paradigm Shift – Part I
APT & The Season of Hacks
6

What is APT
APT = Advanced Persistent Threat
APT is defined as a group of sophisticated,
determined and coordinated attackers
that have been systematically
compromising U.S. Government and
Commercial networks for years. The vast
majority of APT activity observed has
been linked to China.
APT is a term coined by the U.S. Air Force
in 2006
7

APT Objectives
 Political
 Includes suppression of their own
population for stability
 Economic
 Theft of IP, to gain competitive advantage
 Technical
 Obtain source code for further exploit
development
 Military
 Identifying weaknesses that allow inferior
military forces to defeat superior military
forces
8

Targeting and Exploitation Cycle

How RSA was hacked
 RSA is one of the biggest security
companies in the world
 Rivest Shamir Adelman – iconic founders
 Created a multi-billion $ enterprise
10

Initial Intrusion into the Network
 Specific email IDs were discovered from
public sources and social engineering
 Spoofed email was sent
 The email subject line read “2011
Recruitment Plan.”
 The attachment was a backdoor Excel file,
titled “2011 Recruitment plan.xls.
 It exploited a 0-day vulnerability - Adobe
Flash vulnerability (CVE-2011-0609)

Establish a Backdoor into the Network
 Attempt to obtain domain administrative credentials . .
. Transfer the credentials out of the network
 The attackers then established a stronger foothold in
the environment by moving laterally through the
network and installing multiple backdoors with
different configurations.
 The malware is installed with system level privileges
through the use of process injection, registry
modification or scheduled services.
 Poison Ivy variant set in a reverse-connect mode that
makes it more difficult to detect

Obtain User Credentials
 The attackers often target domain controllers
to obtain user accounts and corresponding
password hashes en masse.
 The attackers also obtain local credentials
from compromised systems
 The APT intruders access approximately 40
systems on a victim network using
compromised credentials
 Analysts have seen as few as 10
compromised systems to in excess of 150
compromised systems

Conclusion
 The APT is everyone’s
problem. No target is too
small, or too obscure, or
too well-known, or too
vulnerable. Its’ not spy-
vs.-spy, but spy-vs.-
everyone.
 This is a war of attrition
against an enemy with
extensive resources. It is
a long fight, one that
never ends.
 They steal information to
achieve economic,
political and strategic
advantage.
 They establish and
maintain an occupying
force in their target’s
environment.
 They steal between $40
billion to $50 billion in
intellectual property from
U.S. organizations each
year.

Conclusion
 These are real and they are on a spree
 Your applications and end points are key
entry points for such attacks

THE BIGGEST HACK IN
HISTORY

Gonzalez, TJX and Heart-break-land
 >200 million credit card number stolen
 Heartland Payment Systems, TJX, and 2 US
national retailers hacked
 Modus operandi
 Visit retail stores to understand workings
 Analyze websites for vulnerabilities
 Hack in using SQL injection
 Inject malware
 Sniff for card numbers and details
 Hide tracks

The hacker underground
 Albert Gonzalez
 a/k/a “segvec,”
 a/k/a “soupnazi,”
 a/k/a “j4guar17”
 Malware, scripts and hacked data hosted on servers in:
 Latvia
 Netherlands
 IRC chats
 March 2007: Gonzalez “planning my second phase against
Hannaford”
 December 2007: Hacker P.T. “that’s how [HACKER 2]
hacked Hannaford.”
Ukraine
New Jersey
California

Where does all this end up?
 Commands used on IRC
 !cardable
 !cc, !cclimit, !chk, !cvv2, !exploit, !order.log,
!proxychk
IRC Channels
#cc
#ccards
#ccinfo
#ccpower
#ccs
#masterccs
#thacc
#thecc
#virgincc

TJX direct costs
$24 million to
Mastercard
$41 million to
Visa
$200 million in
fines/penalties

How the Cookie Crumbles

OWASP TOP 10
A1: Injection
A2: Cross-Site Scripting (XSS)
A3: Broken Authentication and Session
Management
A4: Insecure Direct Object References
A5: Cross-Site Request Forgery (CSRF)
A6: Security Misconfiguration
A7: Insecure Cryptographic Storage
A8: Failure to Restrict URL Access
A9: Insufficient Transport Layer Protection
A10: Unvalidated Redirects and Forwards

Injection – 0wning the Enterprise
 Identifying SQL Injections
 Getting to all the data inside the database
 Reading Sensitive data inside the database
like system users, users, password etc.
 But how do you own the enterprise
 Cracking the password hashes
 Running OS level commands
 Escalating privileges
 Adding the user with administrators role
 Enterprise Owned!

Identifying SQL Injection
Identifying SQL Injections
[06:19:58] [INFO] TESTING FOR SQL INJECTION ON GET PARAMETER 'ID'
[06:20:10] [INFO] target url appears to have 2 columns in query
[06:20:10] [INFO] GET parameter 'id' is 'MySQL UNION query (NULL) - 1 to 20
columns' injectable
GET PARAMETER 'ID' IS VULNERABLE. DO YOU WANT TO KEEP TESTING THE
OTHERS (IF ANY)? [Y/N]

Database on the Web Server

What is Next?
 Running OS level commands
 Escalating privileges
 Adding the user with administrators role
 Taking remote access to the system

Net Result
Enterprise Owned!

XSS to 0wning the Enterprise
 XSS is a client side attack
 Attacking your client base
 Browser bugs are most popular targets for
compromising end point
 Java and Adobe Flash
 End points are entry into the network
 So what happens when you find Zero day
bug in most popular software’s like Java?

XSS to 0wning the Enterprise

Java Zeroday
 This exploit has been tested successfully
against multiple platforms,
 Internet Explorer
 Firefox
 Safari
 Chrome
 Fully Patched operating systems
 Windows
 Ubuntu
 OS X
 Solaris

It was raining shell’s

Chaining multiple issues
How other OWASP can be lethal when put
together

Death by thousand cuts (Rsnake Case Study)
 #1 - webmail is easily located
 #2 - easily discoverable and plentiful email addresses
 #3 - forgotten passwords are sent in plain text
 #4 - system will allow users to change email address to
any email address they want (with no verification)
 #5 - XSS vulnerabilities in the application
 #6 - usernames are email addresses
 #7 - recommendation engine sends custom emails
 #8 - login redirection issue
 #9 - function to detect valid users.
 #10 - change email function is vulnerable to CSRF

Death by thousand cuts - Attack
 Detect Valid user on the website (2#, 6#
and 9#)
 Now change my email address to one of the
email addresses of a corporate user (#4)
that's NOT a user on the system
 Finding valid users using the change email
function (#9)
 Send an email to one of the valid users on
the system (#2) using the recommendation
engine (#7).

Death by thousand cuts - Attack
 The link is a link to the login function (#8) that
redirects the user to an XSS hole (#5).
 Now the user has logged in and their browser
is under our control.
 Forward the user invisibly to the change email
function and force them to change their email
address through CSRF (#10) to another email
address that we've got control over.
 Then I have their browser submit the forgot
password function (#3) which delivers their
password to my inbox.

Take away..
 Often minor issues are overlooked but even
in some cases the smallest issues can
mount into huge compromises in security
 Even minor issues that are regularly
dismissed in security assessments can be
leveraged by a determined attacker to
compromise a corporation

Other aspects

Problem Background
Lack of Business Risk Perspective – US Department of Homeland Security:
“Most penetration testing processes and tools do little, if anything, to substantively address
the business risks...
This is largely due to the fact that the tools and the testers view the target systems with
“technology blinders” on...
Although many testing tools and services claim to rank vulnerabilities in terms of technical
severity, they do not typically take business risk into account in any significant sense.
At best, the test teams conduct interviews with the business owners of the applications and
the application architects in an attempt to ascertain some degree of business impact,
but that connection is tenuous.
…the business perspectives, however limited, that these processes can determine are all
post facto. That is, they make their business impact rankings after the test is
completed...This is a key shortcoming of penetration testing practices today.”
https://buildsecurityin.us-cert.gov/daisy/bsi/articles/best-practices/penetration/655-
BSI.html
Software Security – building security in, Chapter 6 on “Penetration Testing Today”
“The problem? No clue about security risk. No idea whether the most critical
security risks have been identified, how much more risk remains in the system,
and how many bugs are lurking in the zillions of lines of code”

The challenge
“Penetration testing is dead. The
concept as we know it is on its
death bed, waiting to die and
come back as something else.”
- Brian Chess, Co-Founder, Fortify Software

LET’S START AT THE
BEGINNING
Some theory

Approach
 Pre-sales Approach
 Client: “Please provide quote for black-box
penetration test”
 SP: “Hang on...”
 SP: “I’d first like to know…”
 Pre-sales approach evolved
 Client: “Please provide quote for black-box
penetration test”
 SP: “Hang on...”
 SP: “I’d first like to know…”

Traditional vs. Risk-based Security Testing
Traditional Testing Risk-based Testing
Focus is on technical
vulnerabilities
Focus is on business risks
Requires strong technical know-
how
Requires both technical and business
process know-how
Having the right set of tools is
critical
Understanding the workings of the
business and applications is critical
Is usually zero-knowledge Requires a person who understands
the business process to play a
significant role – usually an insider
Understanding the regulatory
environment is good
Understanding the regulatory
environment is mandatory

Traditional vs. Risk-based Pentesting
Traditional Pentesting Risk-based Pentesting
Severity levels are based on
technical parameters
Severity levels are based on risk to
the business
Risk levels in report are assigned
post facto
Risk levels in report reflect the levels
assigned prior to testing
Test cases are build based on
testing methodologies or generic
testing processes
Tests cases additionally build on risk
scenarios
Audience for the report is usually
the IT and Security teams
Audience for the report also includes
the business process owners and
heads of departments

Case study
 Corporate Banking Platform – allows 3 logins
 Maker who enters the transaction into the system
 Verifier who checks the transaction data
 Authorizer who authorizes the final payment
 Each screen in the web application is
different based on privilege level of logged in
user
 Security implemented by:
 Restricting access to URLs that allow certain
transactions
 Parameters that trigger certain transactions

Case study
 RA Phase
 Understand business process
 Understand business risks
 Define test cases
 Can maker do what verifier does
 Can verifier do what authorizer does
 Can client’s admin do what bank’s admin does
 So forth
 Pentesting discovers
 http://www.bankPay.co.in/BankPayApp/authorizePaymentAction.
action is available only to Authorizer
 But what if Maker puts it in his browser?
 Transaction still doesn’t get authorized
 Further investigation reveals a parameter:
 Filter=‘block’
 When this value is changed to:
 Filter=‘submitToPay’

Vertical Privilege Escalation

Authorization controls broken

Submission to pay – not allowed

Changing the parameter…

Understanding the business
 Who are the key actors – employees,
departments, customers, partners, vendors,
investors, brokers, franchisees, resellers?
 What applications do they use?
 What data do they access through these
applications?
 What are the risks if any of these actors
turns bad?
 What possibilities exist if an actor should
decide to misuse the data – building fraud
scenarios?

Regulations that drive webapp testing
 PCI DSS
 For all credit card processing merchants
 Quarterly, semi-annual, annual network scans and
penetration tests
 Focus on web application security
 Requires high-level of protection of credit card
data
 There are no fines for non-compliance but
breaches of security could put you out of business
 HIPAA
 For healthcare and pharma providers
 Requires high-level of protection for patient
records and medical history
 Fines for non-compliance are usually high
 Breaches could put you out of practice/business

Answers!

Technology Solutions
 Web Application Firewalls
 Privileged Identity Management Suites
 Application-Aware Firewalls
 Application-Aware SIEMS
 Database Access Management Solutions

Before we get to the technology…

Design
Develop/
Manage
Test
Train
Application Security – Holistic Solution

Secure Design
 Secure Designing Models
 Client Inputs
 Client Education
 Threat Modeling
 Vulnerability Classification – STRIDE
 Risk Classification – DREAD

Microsoft’s Threat Modeling Tool

Secure Coding Overview
Secure coding isn’t taught in school
 Homeland Security's Build Security In
Maturity Model (BSIMM)
 Microsoft's Security Development Lifecycle
(SDL)
 OpenSAMM (Software Assurance Maturity
Model)
 OWASP Secure Coding Guides

Vendor Management
 Big names != Good security
 Contractual weaknesses
 Lack of vendor oversight
 No penalties for blatantly buggy code!

Secure Hosting
 Web Security
 Secured web server
 Secured application server –
all components
 Web application firewalls
 Database Security
 Security Patches
 Users and Roles
 Access Control
 Logging
 Password Security
 Database Table Encryption
 Data Masking
 OS Security
 Security Patches
 Users and Groups
 Access Control
 Security Policies
 Secured Login
 Logging

Secure Testing
 Security testing options
 Blackbox
 Greybox
 Whitebox
 Source Code Review
 OWASP Top Ten
(www.owasp.org)
 OWASP Testing Guide

Training
 Back to basics
 Natural thought process
 Look at larger picture
 Make it fun
 Giving back to the community

Ground Realities!

Ground realities
 Business priorities
 Expand, grow, market share!!
 Developer illiteracy
 Unaware of security implications
 Shortcut fixes
 Vendor apathy
 Problem re-enforced by weak contracts
 Unclear budgets
 Lip service by management towards information
security
 CISO left fighting the battle alone without adequate
resources

Strategize!
Use Triage

Applications’ Triage / 1
 Application Risk Assessment
 Regulatory
 PCI DSS
 DOT
 HIPAA/SOX/etc.
 Legal
 Contractual
 Business Impact
 Reputation Impact

Applications’ Triage / 2
 Nature of the Application
 Internal
 External
 Mixed
 Number of registered users
 Revenue generating / Business process
supporting / Back-office / Reporting
 Data that it deals with
 Financial
 PII
 Corporate
 Other

Applications Triage / 3
 Developed In-house
 Currently being supported
 Developers have moved on
 Outsourced
 Within the country
 Externally
 Commercial Off the Shelf
 High Level of Customization
 No Customization
 Vendor Leverage
 Code/Libraries in Escrow
 Existing Vendor Relationship
 Dormant/Dead Vendor Relationship

Application Classification

Sample Strategies / A
FINPRO
Financial
Processing –
Accessible over
Internet
COTSE – Heavily
Customized
Isolate System in
the Data Center
Vendor
Relationship -
Dormant
Revive Vendor
Relationship
Implement PIM &
WAF
Determine
Alternatives

Sample Strategies / B
ATLAS
Claims Processing
– Agents Access
Over Internet
In-house
Developed
Implement &
Enforce Internal
SLAs
Active
Development
Team
Regular Secure
Coding Training
Emphasis on
Secure Coding
Libraries
Secure Hosting

Take-Aways
 Application security has a long way to
go for most large organizations
 The threat is ever-present and sustained
 Not all applications can be dealt with in
the same manner
 Strategizing helps direct limited
resources towards high-risk problems
 Vendors, business units, and information
security have to co-ordinate efforts, and
stop the blame-game

Ensure – this never happens!

Thank you!
Questions?
taufiq.ali@niiconsulting.com
Information Security
Consulting Services
Institute of Information
Security

Implementing a Comprehensive Application Security Program

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (8)

Similar a Implementing a Comprehensive Application Security Program

Similar a Implementing a Comprehensive Application Security Program (20)

Último

Último (20)

Implementing a Comprehensive Application Security Program