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, 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?

3. 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).

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

5. 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; }

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 you’ve 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 Subjects Reference Monitor 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 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.

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

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 Management • 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 -Integrity -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 – 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.

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 repairman’s 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

37. Number of defacements by TLD

38. E-commerce

39. Threats at key points to E-commerce

40. A type of Social Engineering <script> password = prompt(“Please enter your dial-up password”,””); <script>

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)

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. from:http://www.moneymuseum.com/standard_english/raeume/geld_machen/bank/praxis/ecommerce/einfuehrung/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.