Presentation is loading. Please wait.

Presentation is loading. Please wait.

CSCE 548 Secure Software Development Weak Password-Based Systems Store and Protect Data Securely Information Leakage Failure to Handle Errors Correctly.

Similar presentations


Presentation on theme: "CSCE 548 Secure Software Development Weak Password-Based Systems Store and Protect Data Securely Information Leakage Failure to Handle Errors Correctly."— Presentation transcript:

1 CSCE 548 Secure Software Development Weak Password-Based Systems Store and Protect Data Securely Information Leakage Failure to Handle Errors Correctly CSCE 548 Secure Software Development Weak Password-Based Systems Store and Protect Data Securely Information Leakage Failure to Handle Errors Correctly

2 CSCE 548 - Farkas2 Reading This lecture: – Howard et al., 19 deadly sins: Chapters 6, 13, 12, 11 (Howard et al., 24 deadly sins: Chapters 11, 12, 17, 19)

3 Identification Establishes the identity of an individual/system/ap- plication/etc. Proof of identity: password, driver’s license, Id card, etc. CSCE 522 - Farkas3

4 4 Authentication Allows an entity (a user or a system) to prove its identity within a context, e.g., computer system Typically, the entity whose identity is verified reveals knowledge of some secret S to the verifier Strong authentication: the entity reveals knowledge of S to the verifier without revealing S to the verifier

5 CSCE 522 - Farkas5 Authentication Information Must be securely maintained by the system.

6 CSCE 522 - Farkas6 Elements of Authentication Person/group/code/system: to be authenticated Distinguishing characteristics: differentiates the entities to be authenticated Proprietor/system owner/administrator: responsible for the system Authentication mechanism: verify the distinguishing characteristics Access control mechanism: grant privileges upon successful authentication

7 CSCE 522 - Farkas7 Authentication Requirements Network must ensure – Data exchange is established with addressed peer entity not with an entity that masquerades or replays previous messages Network must ensure data source is the one claimed Authentication generally follows identification – Establish validity of claimed identity – Provide protection against fraudulent transactions

8 CSCE 522 - Farkas8 User Authentication What the user knows – Password, personal information What the user possesses – Physical key, ticket, passport, token, smart card What the user is (biometrics) – Fingerprints, voiceprint, signature dynamics

9 CSCE 522 - Farkas9 Passwords Commonly used method For each user, system stores (user name, F(password)), where F is some transformation (e.g., one-way hash) in a password file – F(password) is easy to compute – From F(password), password is difficult to compute – Password is not stored in the system When user enters the password, system computes F(password); match provides proof of identity

10 CSCE 522 - Farkas10 Vulnerabilities of Passwords Inherent vulnerabilities – Easy to guess or snoop – No control on sharing Practical vulnerabilities – Visible if unencrypted in distributed and network environment – Susceptible for replay attacks if encrypted naively Password advantage – Easy to modify compromised password.

11 CSCE 522 - Farkas11 Attacks on Password Guessing attack/dictionary attack Social Engineering Sniffing Trojan login Van Eck sniffing

12 CSCE 522 - Farkas12 Password Management Policy Educate users to make better choices Define rules for good password selection and ask users to follow them Ask or force users to change their password periodically Actively attempt to break user’s passwords and force users to change broken ones Screen password choices

13 Digital Certificates Most common digital certificate: X.509 Initially issued in 1988 Rely on PKI and hierarchy of certificate authorities Certificate Authority: issue and revoke digital certificates, accepts user notifications, publishes revocation list CSCE 522 - Farkas13

14 Digital Certificates Basic Content – … – Issuer – Validity Not Before Not After – Subject – Subject Public Key Info Public Key Algorithm Subject Public Key – … – Certificate Signature Algorithm – Certificate Signature CSCE 522 - Farkas14

15 Problem with X.509 Large file Long duration  needs validation of certificate for revocation Why are digital certificates revoked? – Exposure of private key – Incorrect/unauthorized issuance – Termination of assignment CSCE 522 - Farkas15

16 Return to Multiple Authentication CSCE 522 - Farkas16 I am Ann. Here is my X.509 System 1 System 3 System 2 I am Ann. Here is my X.509 I am Ann. Here is my X.509 CA Verify Certificate

17 Single Sign On CSCE 522 - Farkas17 I am Ann. Here is my X.509. Give me a locally verifiable token. System 1 System 3 System 2 I am Ann. Here is my SAML token I am Ann. Here is my SAML token SAML token CA Verify Certificate

18 CSCE 548 - Farkas18 Information Protection During transit During use During storage

19 CSCE 548 - Farkas19 Access Control Protection objects: system resources for which protection is desirable – Memory, file, directory, hardware resource, software resources, external devices, etc. Subjects: active entities requesting accesses to resources – User, owner, program, etc. Access mode: type of access – Read, write, execute

20 CSCE 548 - Farkas20 Access Control Requirement Cannot be bypassed Enforce least-privilege and need-to-know restrictions Enforce organizational policy

21 CSCE 548 - Farkas21 Access Control Access control: ensures that all direct accesses to object are authorized Protects against accidental and malicious threats by regulating the reading, writing and execution of data and programs Need: – Proper user identification and authentication – Information specifying the access rights is protected form modification

22 CSCE 548 - Farkas22 Access Control Access control components: – Access control policy: specifies the authorized accesses of a system – Access control mechanism: implements and enforces the policy Separation of components allows to: – Define access requirements independently from implementation – Compare different policies – Implement mechanisms that can enforce a wide range of policies

23 CSCE 548 - Farkas23 Authorization Management Who can grant and revoke access rights? Centralized administration: security officer Decentralized administration: locally autonomous systems Hierarchical decentralization: security officer > departmental system administrator > Windows NT administrator Ownership based: owner of data may grant access to other to his/her data (possibly with grant option) Cooperative authorization: predefined groups of users or predefined number of users may access data

24 CSCE 548 - Farkas24 Discretionary Access Control Access control is based on – User’s identity and – Access control rules Most common administration: owner based – Users can protect what they own – Owner may grant access to others – Owner may define the type of access given to others

25 CSCE 548 - Farkas25 Access Matrix Model Read Write Own Read Write Own OBJECTS AND SUBJECTS SUBJECTSSUBJECTS Joe Sam File 1File 2

26 CSCE 548 - Farkas26 Implementation Access Control List (column) File 1File 2Joe:Read Joe:WriteSam:Read Joe:OwnSam:Write Sam:Own Capability List (row) Joe: File 1/Read, File 1/Write, File 1/Own, File 2/Read Sam: File 2/Read, File 2/Write, File 2/Own Access Control Triples SubjectAccessObject JoeReadFile 1 JoeWriteFile 1 JoeOwnFile 1 JoeReadFile 2 SamReadFile 2 SamWrite File 2 SamOwnFile 2 (ACL)

27 CSCE 548 - Farkas27 ACL vs. Capabilities ACL: – Per object based – Good for file systems Capabilities: – Per subject based – Good for environment with dynamic, short- lived subjects

28 CSCE 548 - Farkas28 Access Control Conditions Data-dependent conditions: access constraints based on the value of the accessed data Time-dependent: access constraints based on the time of the data access Context-dependent: access constraints based on combinations on data which can be accessed History-dependent: access constraints based on previously accessed data

29 CSCE 548 - Farkas29 Software and ACL Vulnerable languages: any – C, C++, Java,.Net, etc. Vulnerable platforms: any – Windows, UNIX, Linux, etc.

30 CSCE 548 - Farkas30 Problem Areas Too much access – Not following least privilege Security violations – Deny access – unavailability – World readable – information disclosure – Write for everyone – incorrect execution, denial of service, taking over the system

31 CSCE 548 - Farkas31 Recommendation Use the operating system’s security technologies Keep secrets out of harm’s way Use security technology (access control support, encryption, etc.) properly Scrub the memory securely once finished with secret data

32 CSCE 548 - Farkas32 Weak Access Control Set access control and grants write access to low privileged user Creates an object without setting access control and creates object in a place writable by low- privileged user Writes configuration information into a shared area Writes sensitive information into a shared area

33 CSCE 548 - Farkas33 Testing for Weak Access Control Design-level problem  use threat modeling – Use your brain – Install application and check for access control on the created objects – Monitor for security of the functions that create objects – For binary code: reverse engineer and look for password-like code – Use special tool designed for specific languages and platforms – Consider context

34 CSCE 548 - Farkas34 Problem Areas Embedding secret in code – Application code contains authentication, encryption keys, etc.

35 CSCE 548 - Farkas35 Information Leakage By accident By intention

36 CSCE 548 - Farkas36 Communication Channels Overt Channel: designed into a system and documented in the user's manual – Information leakage: designers and developers DO NOT understand security needs of the application Covert Channel: not documented. Covert channels may be deliberately inserted into a system, but most such channels are accidents of the system design. – Information leakage: slow information flow to unauthorized recipient

37 CSCE 548 - Farkas37 Information Flow Direct Flow: – Bell-LaPadula example Indirect flow: – Covert channel – Inference channel TS-subject S-object read info- flow TS-object S-subject write info- flow

38 CSCE 548 - Farkas38 Non-Interference High-security data does not influence lower security data How to guarantee it?

39 CSCE 548 - Farkas39 Covert Channel Timing Channel: based on system times Storage channel: not time related communication Can be turned into each other

40 CSCE 548 - Farkas40 Covert Channel Need: – Two active participants and encoding schema OR – Access to the system and knowledge about the system Example: sender modulates the CPU utilization level with the data stream to be transmitted Sender: repeat get a bit to send if the bit is 1 wait one second (don't use CPU time) else busy wait one second (use CPU time) endif until done

41 CSCE 548 - Farkas41 Covert Channels Problems: – Noise – Need sophisticated synchronization Protection (user state, system state) – Removal – Slow down – Audit

42 CSCE 548 - Farkas42 Cryptographic Timing Attack How long does it take to perform encryption – Table look ups – Non-constant time – Partial guesses  faster performance Measure the duration between messages, where message content depends on secret data

43 CSCE 548 - Farkas43 Inference Channels + Meta-data Sensitive Information Non-sensitive information =

44 CSCE 548 - Farkas44 Inference Channels Statistical Database Inferences General Purpose Database Inferences

45 CSCE 548 - Farkas45 Statistical Databases Goal: provide aggregate information about groups of individuals – E.g., average grade point of students Security risk: specific information about a particular individual – E.g., grade point of student John Smith Meta-data: – Working knowledge about the attributes – Supplementary knowledge (not stored in database)

46 CSCE 548 - Farkas46 Statistical Compromise Exact compromise: find exact value of an attribute of an individual (e.g., John Smith’s GPA is 3.8) Partial compromise: find an estimate of an attribute value corresponding to an individual (e.g., John Smith’s GPA is between 3.5 and 4.0)

47 CSCE 548 - Farkas47 Inferences in General-Purpose Databases Queries based on sensitive data Inference via database constraints Inferences via updates

48 CSCE 548 - Farkas48 Queries based on sensitive data Sensitive information is used in selection condition but not returned to the user. Example: Salary: secret, Name: public  Name  Salary=$25,000 Protection: apply query of database views at different security levels

49 CSCE 548 - Farkas49 Database Constraints Integrity constraints Database dependencies Key integrity

50 CSCE 548 - Farkas50 Integrity Constraints C=A+B A=public, C=public, and B=secret B can be calculated from A and C, i.e., secret information can be calculated from public data

51 CSCE 548 - Farkas51 Database Dependencies Metadata: Functional dependencies Multi-valued dependencies Join dependencies etc.

52 CSCE 548 - Farkas52 Functional Dependency FD: A  B, that is for any two tuples in the relation, if they have the same value for A, they must have the same value for B. Example: FD: Rank  Salary Secret information: Name and Salary together – Query1: Name and Rank – Query2: Rank and Salary – Combine answers for query1 and 2 to reveal Name and Salary together

53 CSCE 548 - Farkas53 Key integrity Every tuple in the relation have a unique key Users at different levels, see different versions of the database Users might attempt to update data that is not visible for them

54 CSCE 548 - Farkas54 Example Name (key)SalaryAddress Black P38,000 PColumbia S Red S42,000 SIrmo S Secret View Name (key)SalaryAddress Black P38,000 PNull P Public View

55 CSCE 548 - Farkas55 Updates Public User: Name (key)SalaryAddress Black P38,000 PNull P 1.Update Black’s address to Orlando 2.Add new tuple: (Red, 22,000, Manassas) If Refuse update: covert channel Allow update: Overwrite high data – may be incorrect Create new tuple – which data it correct (polyinstantiation) – violate key constraints

56 CSCE 548 - Farkas56 Updates Name (key)SalaryAddress Black P38,000 PColumbia S Red S42,000 SIrmo S Secret user: 1.Update Black’s salary to 45,000 If Refuse update: denial of service Allow update: Overwrite low data – covert channel Create new tuple – which data it correct (polyinstantiation) – violate key constraints

57 CSCE 548 - Farkas57 Inference Problem No general technique is available to solve the problem Need assurance of protection Hard to incorporate outside knowledge

58 Next Class Failing to Handle Errors Correctly Design Patterns CSCE 548 - Farkas58


Download ppt "CSCE 548 Secure Software Development Weak Password-Based Systems Store and Protect Data Securely Information Leakage Failure to Handle Errors Correctly."

Similar presentations


Ads by Google