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

CSCE 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)

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

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

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

CSCE 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

CSCE 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

CSCE 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

CSCE 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

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

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

CSCE 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

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 Farkas13

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 Farkas14

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 Farkas15

Return to Multiple Authentication CSCE 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

Single Sign On CSCE 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

CSCE Farkas18 Information Protection During transit During use During storage

CSCE 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

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

CSCE 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

CSCE 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

CSCE 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

CSCE 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

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

CSCE 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)

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

CSCE 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

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

CSCE 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

CSCE 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

CSCE 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

CSCE 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

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

CSCE Farkas35 Information Leakage By accident By intention

CSCE 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

CSCE 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

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

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

CSCE 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

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

CSCE 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

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

CSCE Farkas44 Inference Channels Statistical Database Inferences General Purpose Database Inferences

CSCE 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)

CSCE 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)

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

CSCE 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

CSCE Farkas49 Database Constraints Integrity constraints Database dependencies Key integrity

CSCE 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

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

CSCE 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

CSCE 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

CSCE 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

CSCE 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

CSCE 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

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

Next Class Failing to Handle Errors Correctly Design Patterns CSCE Farkas58