Injection Attacks Executing, Preventing, and Auditing

1
Injection AttacksExecuting, Preventing, and
Auditing

• Presentation by
• Michael Pinch
• Matthew Giordano
• January 26th, 2007

2
What is an Injection Attack?

• Exploits weak application level security around
  the system type ID
• Exploit allows the client, a.k.a. attacker, to
  piggyback code into a web page, and have the
  system ID execute it for them
• Can both execute commands and insert / update /
  delete data

3
What is the Danger?

• Typically system IDs have all access rights
  to the database
• When exploited, the attacker can do anything the
  system ID can
• Utilizes no special equipment or advanced
  knowledge

4
Industry

• Joint study by the US department of Commerce and
  Visa
• Ranked as one of the top 5 greatest data security
  vulnerabilities
• SQL injection is a technique used to exploit
  Web-based applications by using client-supplied
  data in SQL queries. SQL injection attacks are
  caused primarily by applications that lack input
  validation checks. Recently, commercial shopping
  cart products have been the focus of attack by
  hackers who seek account information. PCI DSS
  Requirement 6.5 requires that Web-facing
  applications be developed in accordance with
  secure coding guidelines to guard against such
  attacks.

5
Different Types of Code Injection

• SQL Injection (Most prevalent)
• LDAP Injection
• XML Injection
• Others
• Flaw is not code specific, rather in the web
  application it is embedded in

6
Structure of Web Based Systems

• Application logic Typically built with a
  scripting language (php, jsp, asp), a lightweight
  tool that interfaces with the data source and
  controls the behavior of the program
• Data Source Typically a database, but could
  also be a flat file, XML file, or another
  application
• The interface between the application and data
  source is typically done with an embedded
  language. Embedded systems integrate one type of
  code into another (such as a php script executing
  SQL commands)

7
How does it work?

• Review on Client-Server Architecture
• You (client) request a web page
• Server responds with the page, as displayed on
  the client computer
• Client enters data
• Server takes data, runs server side script,
  queries database, returns results

8
What really happens when you search?

• Server has a prewritten SQL query stored in a
  script
• select item, picture, from ItemDB where
  description client_input
• You input american psycho 1st
• Prewritten script is then executed by system as
  
• select item, picture, from ItemDB where
  description american
  psycho 1st
• Please Note You just used the system ID to
  execute a query that YOU wrote. In practice,
  most system IDs have DBA level access, and are
  only restricted by the logic built into the
  application itself.

9
This is the Danger!

• A direct link between the client and the all
  powerful system ID!

10
Code Example

• lt?PHP
• session_start()
• header("Cache-control private") // IE 6 Fix.
• error_reporting(E_ALL)
• ?gt
• lthtmlgt
• ltbody bgcolor whitegt
• lt?php
• email _SESSION'email' // Variable holding
  users email address
• value stripslashes(_POST'newdata') //
  Variable holding data entered
• fieldname _POST'type' // Variable holding
  fieldname to update
• if (_SESSION'access_rights' 1)
• db mysql_connect("localhost", "system_id",
  password") // Connects to local DB
• mysql_select_db("payroll",db) // selects
  database to query
• query "update data SET fieldname'value'
  WHERE email 'email'" // Prewritten Query
• result mysql_query(query,db) // executes
  query
• echo "ltMETA HTTP-EQUIV'Refresh' CONTENT'0
  URLreturn.php'gt"

11
How can we exploit this?

• SQL Query Stored in Application
• select item, picture, from ItemDB where
  description client_input
• To commit a SQL Injection Attack, enter into the
  web site form
• xdrop table ItemDB
• The query executed by the System ID will now
  be
• select item, picture, from ItemDB where
  description xdrop table ItemDB
• The server just executed the stored query, and we
  just effectively destroyed the entire ItemDB
  database!

12
Even More Fun

• Add A New User
• Canned Query SELECT email, passwd, login_id,
  full_name FROM members WHERE email
  user_input
• SQL Attack x' INSERT INTO members ('email',
  'passwd', 'login_id', 'full_name') VALUES
  (mike_at_pinch.com',mynewPW',pinch',Mike Pinch')
• System then Executes SELECT email, passwd,
  login_id, full_name FROM members WHERE email
  x' INSERT INTO members ('email', 'passwd',
  'login_id', 'full_name') VALUES
  (mike_at_pinch.com',mynewPW',pinch',Mike
  Pinch')
• I now have my very own account!

13
One More for Good Measure

• Forgot my Password
• Canned Query SELECT email, passwd, login_id,
  full_name FROM members WHERE email
  UserInput
• SQL Attack x' UPDATE members SET email
  pinch_at_CLIENTX.com' WHERE email
  sysadmin_at_CLIENTX.com
• System then Executes SELECT email, passwd,
  login_id, full_name FROM members WHERE email
  x' UPDATE members SET email pinch_at_CLIENTX.com'
  WHERE email sysadmin_at_CLIENTX.com
• Now just go to forgot my password, type
  pinch_at_CLIENTX.com, and the system will
  conveniently email me the system
  admins password!

14
Halftime Discussion

• Does anyone have any questions about HOW this
  attack works, why it is possible, or anything
  else?

15
Is this as easy as it looks?

• Requires knowledge of the DB schema
• Work Around
• Standard DB error messages return information
  about DB schema
• Enter bad data -gt get error messages!
• Programmers use descriptive table names

16
Error Message Masking

• Bad

• Good

17
Error Masking

• Blocks real error messages from being displayed
  to the client
• Best Practice
• All specific errors messages are suppressed,
  either through using a generic error message, or
  blocking them altogether.

18
How are Attacks Prevented?

• Sanitize all input including
• Data collected in Forms through browsers
• Data collected in URLs
• Data collected through cookies
• White/Black List
• Mask Error Messages
• Continuous Monitoring
• New Technique SQL Firewalls

19
Prevalence of Attacks

• Injection attacks are extremely powerful, almost
  always malicious, and nearly undetectable (until
  its too late)
• Danger comes from simplicity no special
  hardware or software is necessary. Just syntax
  knowledge and a browser!
• In 2006, 14 of newly released commercial
  application and open source tools were vulnerable
  to SQL injection attacks.
• A recent study of web sites not masking error
  messages returned a total of 10.3

20
Integrating into the Audit

• Weak controls related to preventing injection
  attacks may require nature, timing and extent of
  financial statement substantive audit procedures.
• Assistance may be needed from systems or data
  management professionals to help identify if
  there were instances in which the control
  weaknesses were exploited.
• Cobit Framework (See excerpt)
• DS 5.3, Identity Management

• Cobit Framework
• DS 5.3, Identity Management
• All users (internal, external and temporary) and
  their activity on IT systems (business
  application, system operation, development and
  maintenance) should be uniquely identifiable.
  User access rights to systems and data should be
  in line with defined and documented business
  needs and job requirements. User access rights
  are requested by user management, approved by
  system owner and implemented by the
  security-responsible person. User identities and
  access rights are maintained in a central
  repository. Cost-effective technical and
  procedural measures are deployed and kept current
  to establish user identification, implement
  authentication and enforce access rights.

21
What Systems are Vulnerable?

• Predominantly internally developed applications
• Web based client-server architecture
• Any system where access is available via the web

22
How do you determine if a system is vulnerable?

• Inquire
• Do you have database and server error messages
  masked?
• Do you have a strategy to sanitize all user input
  to detect SQL injection attacks?
• Walk me through how your system prevents SQL
  injection attempts, IE filtering input, limiting
  rights.
• Observe
• Ask client to generate an error message
• Should either be generic or non-existent
• Inspect
• Request code sample showing filtering module
  logic
• Should filter out suspicious characters such as
  ,/ etc
• View White/Black List
• Attack and Penetration Testing

23
Demonstration
24
Questions / Comments

• Open Discussion
• References
• http//www.sarbanes-oxley.com/section.php?level1
  pub_idSarbanes-Oxley
• http//usa.visa.com/download/business/accepting_vi
  sa/ops_risk_management/Top_5_Vulnerabilities_Bulle
  tin_August2006.pdf - 2006 Visa USA
• "Applying an improved economic model to software
  buy-versus-build decisions", Higaki,Wesley.
  Hewlett-Packard Journal, August 1995.
• "Cobit 4.0", IT Governance Institute, 2005
• Mitre Corporation, 2006