Building Secure Applications, Security Models, and Web Security

Lesson 26

Building Secure Systems

• Vulnerabilities frequently found in operating systems and application programs.

• Problem is not new, we’ve 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?

Why systems are not secure

• Security is fundamentally difficult.• What is adequate for most functions isn’t for security• “good enough” doesn’t 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).

Example of poor programming/errors

• Buffer Overflows• result of poor programming practice

• use of functions such as gets and strcpy– these don’t check input for boundaries

• may allow individual to gain root or admin access

Sample Buffer Overflow Example

#include <stdio.h>#include <string.h>

void func(char *p){ char stack_temp[20]; strcpy(stack_temp, p); printf(stack_temp);}

int main(int argc, char* argv[]){ func(“I AM MORE THAN TWENTY CHARACTERS LONG!”); return 0;}

Exploits

• Buffer Overflows• fingerd, statd, talkd, …

• result of poor programming practice

• Shell Escapes• special character in input string causes escape to

shell

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 you’ve

compromised thus hiding trail

• greatly increases complexity of tracking

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

ReferenceMonitor

AccessControl

Database

ObjectsSubjects

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.

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?

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”

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 can’t modify files of “higher” classification and you can’t execute programs of a higher classification level).

• Strict Integrity Policy – Includes the previous principle (ring policy) and adds another stipulation, a subject can’t observe an object with a higher classification level.

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.

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 organization’s 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”

Controls required for trust in an application system

Network/Communications

DatabaseManagement

Host/Distributed

Processors

ApplicationSystem

PersonnelSecurity

PhysicalSecurity

ProceduralSecurity

LegalProtections

Security Controls

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

Quality Attributes

-Correctness-Reliability-Integrity-Usability-Confidentiality

The application system is viewed as nested within other technicalSystems since it will depend on their utilities and will rely on theirIntegrity features to create a reliable and trusted environment.

Controls also include interaction with external elements.

FromComputer Security Handbook3ed

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.

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.

• 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.

• 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.

• 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.

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.”

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.”

Model Framework for Management Control over Automated Information Systems

• 6 phases• Initiation – what’s the problem to be solved?• Definition – Develop functional statement of user’s 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.

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

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

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 repairman’s visiting the site for adjustments and inspections. Distance and remoteness are two major factors for implementing SCADA systems

SCADA ElementsThere are four major elements to a SCADA system: the operator, master terminal unit (MTU), communications, and remote terminal unit (RTU).

RTU 1 RTU 2

Modem Modem

Modem

Modem

OPERATOR HQ

MTU

Modem Modem

RTU 3 RTU 4

Radio

Radio

Radio

Web Security

Web Defacement

Web Defacement -- Hactivism

Web Defacement Trends

Web Defacements – some info

Web Defacement – OS Stats for 10/2001

Number of defacements by TLD.com 8727 29.52.br 2225 7.53.net 1322 4.47.org 1226 4.15.tw 1218 4.12.cn 1138 3.85.us 871 2.95.edu 847 2.86.mx 744 2.52.jp 714 2.42.kr 675 2.28.de 636 2.15.uk 530 1.79.it 454 1.54.il 397 1.34.au 369 1.25.gov 318 1.08.ar 317 1.07.za 269 0.91.in 261 0.88.ca 218 0.74

.ch 212 0.72

.cl 212 0.72

.be 210 0.71

.se 199 0.67

.th 197 0.67

.mv 194 0.66

.pe 189 0.64

.hk 186 0.63

.ru 177 0.6

.nl 162 0.55

.pl 157 0.53

.pt 150 0.51

.cz 130 0.44

.mil 128 0.43

.tr 117 0.4

.ma 105 0.36

.hu 104 0.35

.gr 102 0.3526407 89.36

E-commerce

Threats at key points to E-commerce

A type of Social Engineering

<script>password = prompt(“Please enter your dial-up password”,””);<script>

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 system

also a buffer overflow problem

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)

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.

from:http://www.moneymuseum.com/standard_english/raeume/geld_machen/bank/praxis/ecommerce/einfuehrung/set/set.html

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

What does SET support

• Currently only supports credit card transactions.• Does not support debit card payments

• Does not support stored-value payment systems.

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.