Building Secure Applications, Security Models, and Web Security

1
Building Secure Applications, Security Models,
and Web Security

• Lesson 26

2
Building Secure Systems

• Vulnerabilities frequently found in operating
  systems and application programs.
• Problem is not new, weve always had problems
  with the security of our systems and flaws in the
  operating system.
• Is it really that hard to build a secure system?

3
Why systems are not secure

• Security is fundamentally difficult.
• What is adequate for most functions isnt for
  security
• good enough doesnt apply for security
• Security is often (usually) an afterthought.
• Security is viewed as an impediment.
• False solutions impede progress
• industry subject to fads -- quick fixes cause
  us to become complacent.
• Technology is oversold -- the problem is often
  with the people not the computers.
• Errors are made and not found (inadequate
  testing, poor programming techniques).

4
Example of poor programming/errors

• Buffer Overflows
• result of poor programming practice
• use of functions such as gets and strcpy
• these dont check input for boundaries
• may allow individual to gain root or admin access

5
Sample Buffer Overflow Example
include ltstdio.hgt include ltstring.hgt void
func(char p) char stack_temp20
strcpy(stack_temp, p) printf(stack_temp)
int main(int argc, char argv) func(I AM
MORE THAN TWENTY CHARACTERS LONG!) return
0
6
Exploits

• Buffer Overflows
• fingerd, statd, talkd,
• result of poor programming practice
• Shell Escapes
• special character in input string causes escape
  to shell

7
Cover your tracks

• Adjust log files
• RootKit
• contains sniffer, login program that disables
  logging, hacker versions of several system
  utilities (e.g. ps)
• Looping
• launch attack from another system youve
  compromised thus hiding trail
• greatly increases complexity of tracking

8
Security Kernel

• The HW and SW that implements the reference
  monitor
• All accesses that subjects make to objects are
  authorized on information in an access control
  database.
• The specific checks that are made and all
  modifications to the access control database are
  controlled by the reference monitor in accordance
  with the established security policy.

Audit File
Reference Monitor
Subjects
Objects
Access Control Database
9
Three Principles for Security Kernels

• Completeness it must be impossible to bypass.
• All access to information must be mediated by the
  reference monitor.
• Isolation it must be tamperproof
• The OS and the reference monitor should protect
  themselves from modification.
• Verifiability it must be shown to be properly
  implemented.
• Good software engineering practices.
• Simplicity of function in the kernel.
• Minimize the size of the kernel.

10
Security Models -- principles

• Identity can each user, program, object, and
  resource be uniquely identified?
• Accountability can users be held accountable
  for their actions?
• Monitoring is a record maintained of users
  actions?
• Authorization do rules exist to govern which
  entities may access which objects?
• Least privilege are users restricted to the
  minimal set of resources needed to perform their
  job?
• Separation are the actions of entities
  prevented from interfering or colluding with the
  actions of other entities?
• Redundancy are copies of hardware, software,
  and data components maintained to ensure
  consistency, accuracy, and timeliness of results?

11
Security Models Bell La Padula

• Model used in the Orange Book, Traditional
  approach/concern for the military.
• Particular emphasis is on preventing unauthorized
  disclosure of information.
• Simple Security Condition
• allows a subject read access to an object only if
  the security level of the subject dominates the
  security level of the object.
• -Property
• allows a subject write access to an object only
  if the security level of the subject is dominated
  by the security level of the object. Also known
  as the Confinement Property.
• No Read Up/No Write Down

12
Security Models Biba

• Supports 5 different integrity principles
• Low-Water Mark Policy the integrity level of a
  subject immediately following an observed access
  to an object is set to be the lower of the
  integrity levels for the subject and the object.
• Low-Water Mark Policy for Objects similar to
  previous except works on objects.
• Low-Water Mark Integrity Audit Policy
  introduces concept of corruption level to measure
  possible corruption of data, corruption level set
  to lowest integrity level of subjects and
  objects.
• Ring Policy enforces a strict, unmodifiable
  integrity level for the life of subjects and
  objects (you cant modify files of higher
  classification and you cant execute programs of
  a higher classification level).
• Strict Integrity Policy Includes the previous
  principle (ring policy) and adds another
  stipulation, a subject cant observe an object
  with a higher classification level.

13
Security Models Clark-Wilson

• Military security model is focused on
  unauthorized disclosure but in some environments
  disclosure is not as important as modification
  (confidentiality vs integrity).
• For Clark-Wilson, integrity is the focus.
• Goal is to insure that no user can modify data in
  a manner that would result in the loss or
  corruption of assets.
• 2 mechanisms used to achieve goal
• Well-formed transactions data can only be
  modified in very constrained ways.
• Separation of Duty Separates operations into
  parts and requires each part be performed by a
  different subject.

14
Application Security The Goal

• define, design, deliver, and operate application
  systems possessing adequate and appropriate
  security and internal controls
• Application systems are seen as the sum of
  hardware, software, data, communications, and
  other technologies working together to produce
  some product or service in direct fulfillment of
  the organizations business goals.
• The challenge for the security official is to
  use these principles to promote the creation of a
  developmental environment where future
  application systems can be built possessing
  adequate and appropriate controls.
• From Computer Security Handbook, 3ed

15
Controls required for trust in an application
system
The application system is viewed as nested within
other technical Systems since it will depend on
their utilities and will rely on their Integrity
features to create a reliable and trusted
environment.
Physical Security
Legal Protections
Network/ Communications Database Manag
ement

• Security Controls
• Edits
• -Correction Routines
• -Data Validation
• -Data Views
• -Permissions
• -Passwords/access
• -File Integrity
• Audit trail
• -Backup/retention
• -Reconciliation
• -Audit/Security
• -Line control
• -Encryption

Quality Attributes -Correctness -Reliability -Int
egrity -Usability -Confidentiality
Host/ Distributed Processors
Application System
From Computer Security Handbook 3ed
Procedural Security
Personnel Security
Controls also include interaction with external
elements.
16
Desired Quality Attributes

• Correctness The degree to which system outputs
  satisfy the accuracy requirements of the business
  activity being supported.
• Reliability The degree to which the system
  meets the business requirements for operational
  up time.
• Integrity A measure of completeness and
  soundness of design and construction. A system
  that has integrity can be trusted by the user.
• Usability A measure of being fit for use by
  the representative employee in the actual
  workplace.
• Confidentiality A measure of privacy or secrecy
  that is required by nature of the information
  involved or the sensitivity of the business
  process.

17
Security and Internal Controls

• Edits Edits are defined checks and controls
  that ensure accuracy of input data. The
  sufficiency of edits and their use during the
  business process is based on the stringency of
  the quality attribute metrics. The more severe
  the metric, the more important the edits.
• Correction Routines Software and/or manual
  routines invoked to correct errors and omissions
  discovered by an edit.
• Data validation Software and/or manual routines
  to check the accuracy and appropriateness of data
  before entry to a system or database.

18

• Data Views Subset access to a total data
  collection based on predetermined need of an
  employee or class of employees for the data in
  performance of their duties.
• Permissions Actions that a user is permitted to
  take once access has been granted to a store of
  data. These permissions may be to READ, WRITE,
  APPEND, DELETE, EXECUTE, or any combination based
  on job requirements.
• Passwords for Access Access to systems, data,
  and the granting of permitted actions is based on
  recognition by the security software of a unique
  identification code. Passwords must be kept
  secure.
• File Integrity Routines Software housekeeping
  routines for maintaining the trustworthiness of
  data in a database. The more severe the accuracy
  requirements, the more stringent these routines
  and the more often they should be run.

19

• Audit Trails Recordings of three types of
  processing activities (1) logs to aid in the
  reconstruction of transactions (2) logs to meet
  the requirements of the audit staff and (3)
  logs recording security accesses, activities, and
  suspected violations.
• Backup and Retention Policies and procedures
  for ensuring the ability to reconstruct files,
  software, and business transactions in the event
  of a processing interruption or to meet a legal
  requirement.
• Reconciliation Routines Procedures to bring
  about a settlement or adjustment between
  differing information sources, databases, or
  reports.

20

• Audit/Security Reports Suspected violation or
  incident reports generated for the purpose of
  adjusting controls and managing system resources.
• Line Control Physical location and/or placement
  of controls on communication lines to prevent
  unauthorized access to the line.
• Encryption Encryption is a means of maintaining
  secure data in an insecure environment.

21
Past Development Problems

• General Accounting Office reports from 60s,
  70s, and 80s described a general lack of
  security in application systems. Reports
  repeatedly found
• Lack of internal controls in application
  systems, making them subject to unauthorized
  manipulation.
• Lack of software quality and insufficient
  testing.
• Systems not properly documented, making it
  extremely difficult to reconstruct processing or
  to make necessary changes over the life of the
  application.
• Lack of access control on computer processes and
  data files.

22
WHY? Well, at the time

• Limiting access through physical means and
  simple password schemes was seen as the principle
  control mechanism required in the mainframe and
  nonintelligent terminal environment.
• Computers were physically limited in the amount
  of available computing resources that could be
  dedicated to security and internal control
  functions.
• Since compelling business arguments for controls
  were difficult to make, top management was
  generally ambivalent. Controls sounded good, but
  they could not inconvenience anyone, or slow
  anything down, or require significant funding.

23
Model Framework for Management Control over
Automated Information Systems

• 6 phases
• Initiation whats the problem to be solved?
• Definition Develop functional statement of
  users need
• System Design Detailed specifications
• Programming and Training Code developed and
  tested, training starts
• Evaluation and Acceptance Field testing, user
  accepts
• Installation and Operation Full implementation
  in field
• Note how this is really describing software
  engineering.
• Development of secure systems really relies on
  sound SE practices.

24
Application Testing

• Traditional application testing focuses on issues
  such as
• data validation, boundary testing
• load and stress testing, and
• functionality testing.
• For security testing we also want to check that
• a user cannot gain unintended access to data
  belonging to other users
• a user must not be able to break the application
  and cause a temporary or permanent disruption to
  the service
• security features work as designed/intended
• Web applications prime candidates for testing

25
Other tests to consider

• protocol sniffing and replaying attacks
• buffer overflow
• Hidden Manipulation - Changing hidden field
  values
• Cookie Poisoning - Altering the content of a
  cookie
• Backdoor and Debug Options - Trying debug syntax
  on URLs
• Third Party Mis-Configuration - Attempting Web
  server default configuration vulnerabilities
• Known Vulnerabilities - Trying all publicly know
  vulnerabilities
• Cross Site Scripting - Entering executable
  commands into Web site buffers
• Forceful Browsing - Accessing orphan scripts

26
SCADA systems
Supervisory control and data acquisition (SCADA)
is a system that allows an operator to monitor
and control processes that are distributed among
various remote sites. There are many processes
that use SCADA systems hydroelectric, water
distribution and treatment utilities, natural
gas, etc. SCADA systems allow remote sites to
communicate with a control facility and provide
the necessary data to control processes. For many
of its uses, SCADA provides an economic
advantage. As distance to remote sites increase
and difficulty to access increases, SCADA becomes
a better alternative to an operator or
repairmans visiting the site for adjustments and
inspections. Distance and remoteness are two
major factors for implementing SCADA systems
27
SCADA Elements
There are four major elements to a SCADA system
the operator, master terminal unit (MTU),
communications, and remote terminal unit (RTU).
Modem
Modem
RTU 1
RTU 2
Modem
OPERATOR HQ
Radio
Modem
MTU
Radio
Radio
Modem
Modem
RTU 3
RTU 4
28
Web Security
29
Web Defacement
30
Web Defacement -- Hactivism
31
Web Defacement Trends
32
Web Defacements some info
33
Web Defacement OS Stats for 10/2001
34
(No Transcript)
35
(No Transcript)
36
(No Transcript)
37
Number of defacements by TLD
38
E-commerce
39
Threats at key points to E-commerce
40
A type of Social Engineering
ltscriptgt password prompt(Please enter your
dial-up password,) ltscriptgt
41
Finding well-known vulnerabilities

• Automated Scripts
• Phfscan.c
• an example script that implemented an interface
  to a white-pages like service used to look up
  name and address information. User could,
  however, trick it to execute commands locally by
  escaping the script by using a newline
  character in the input.
• Cgiscan.c
• scans for a number of the older scripts such as
• PHF - (see above)
• count.cgi - buffer overflow, allow remote
  execution
• test-cgi - list all files and directories in
  scripts directory (thus may be able to find
  other, more serious, vulnerabilities)
• PHP - one vulnerability allowed you to view any
  file on systemalso a buffer overflow problem

42
Taking down a web site using only a
browser -from Hacking Exposed

• Sample ColdFusion problem (problem is in how they
  handle their input validation for passwords)
• Point your browser to the Administrator logon
  page of a typical ColdFusion server
• Edit the HTML by using File Edit Page
• Change the ACTION tag by prepending the server
  name/address to the URL
• Change the HTML tag holding the password so the
  size and maxlength properties are in the
  1,000,000 range
• Preview and save the HTML file
• Generate close to 1,000,000 characters and input
  to password field.
• Watch CPU utilization go to 100 (or if you make
  it 1,000,000,000 watch it die instantly)

43
(No Transcript)
44
(No Transcript)
45
SET
SET uses a system of locks and keys along with
certified account IDs for both consumers and
merchants. Then, through a unique process of
"encrypting" or scrambling the information
exchanged between the shopper and the online
store, SET ensures a payment process that is
convenient, private and most of all
secure. fromhttp//www.moneymuseum.com/standard_
english/raeume/geld_machen/bank/praxis/ecommerce/e
infuehrung/set/set.html
46
Secure Electronic Transaction (SET)

• Emerging standard for secure credit card payments
  over the Internet.
• Industry backed standard (created by MasterCard
  and VISA)
• Transaction can either be web or email
• Specifies the mechanisms but not the specific
  implementation
• Specifies the following security assurances be
  provided
• Confidentiality
• Data Integrity
• Client authentication
• Merchant authentication

47
What does SET support

• Currently only supports credit card transactions.
• Does not support debit card payments
• Does not support stored-value payment systems.

48
Stored-account payment system

• Stored-account payment system
• Modeled after existing electronic payment
  systems such as credit and debit cards in which a
  corresponding account of credit (or deposit) is
  maintained.
• The money always resides in a bank account.
• Stored-value payment system
• Use bearer certificates much like hard cash.
• The bearer certificate resides within the
  personal computers or smart cards and is
  transferred between the parties, as when cash
  changes hands.
• Value placed directly on hardware token.