CSCE 548 Secure Software Development Weak Password-Based Systems Store and Protect Data Securely...
-
Upload
allen-cameron -
Category
Documents
-
view
220 -
download
0
Transcript of CSCE 548 Secure Software Development Weak Password-Based Systems Store and Protect Data Securely...
CSCE 548 CSCE 548 Secure Software DevelopmentSecure Software Development
Weak Password-Based Systems Weak Password-Based Systems Store and Protect Data SecurelyStore and Protect Data Securely
Information LeakageInformation LeakageFailure to Handle Errors CorrectlyFailure to Handle Errors Correctly
CSCE 548 - Farkas 2
ReadingReadingThis lecture:
– Howard et al., 19 deadly sins: Chapters 6, 13, 12, 11 (Howard et al., 24 deadly sins: Chapters 11, 12, 17, 19)
Identification Identification
Establishes the identity of an individual/system/ap-plication/etc.
Proof of identity: password, driver’s license, Id card, etc.
CSCE 522 - Farkas 3
CSCE 522 - Farkas 4
AuthenticationAuthentication 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 522 - Farkas 5
Authentication InformationAuthentication Information
Must be securely maintained by the
system.
CSCE 522 - Farkas 6
Elements of AuthenticationElements 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 522 - Farkas 7
Authentication RequirementsAuthentication 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 522 - Farkas 8
User AuthenticationUser AuthenticationWhat 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 522 - Farkas 9
PasswordsPasswords 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 522 - Farkas 10
Vulnerabilities of PasswordsVulnerabilities 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 522 - Farkas 11
Attacks on PasswordAttacks on PasswordGuessing attack/dictionary attackSocial EngineeringSniffingTrojan loginVan Eck sniffing
CSCE 522 - Farkas 12
Password Management PolicyPassword Management PolicyEducate users to make better choicesDefine rules for good password selection
and ask users to follow themAsk or force users to change their password
periodicallyActively attempt to break user’s passwords
and force users to change broken onesScreen password choices
Digital CertificatesDigital Certificates
Most common digital certificate: X.509Initially issued in 1988Rely on PKI and hierarchy of certificate
authoritiesCertificate Authority: issue and revoke
digital certificates, accepts user notifications, publishes revocation list
CSCE 522 - Farkas 13
Digital Certificates Basic Digital Certificates Basic ContentContent
– …– Issuer– Validity
Not Before Not After
– Subject– Subject Public Key Info
Public Key Algorithm Subject Public Key
– …– Certificate Signature Algorithm– Certificate Signature
CSCE 522 - Farkas 14
Problem with X.509Problem with X.509
Large fileLong duration needs validation of
certificate for revocationWhy are digital certificates revoked?
– Exposure of private key– Incorrect/unauthorized issuance– Termination of assignment
CSCE 522 - Farkas 15
Return to Multiple Return to Multiple AuthenticationAuthentication
CSCE 522 - Farkas 16
I am Ann. Here is my X.509
System 1
System 3
System 2I am Ann. Here is my X.509
I am Ann. Here is my X.509
CA
Verify Certificate
Single Sign OnSingle Sign On
CSCE 522 - Farkas 17
I am Ann. Here is my X.509. Give me a locally verifiable token.
System 1
System 3
System 2I am Ann. Here is mySAML token
I am Ann. Here is my SAML token
SAML token
CA
Verify Certificate
CSCE 548 - Farkas 18
Information ProtectionInformation Protection During transit During use During storage
CSCE 548 - Farkas 19
Access ControlAccess 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 548 - Farkas 20
Access Control Requirement Access Control Requirement Cannot be bypassedEnforce least-privilege and need-to-know
restrictionsEnforce organizational policy
CSCE 548 - Farkas 21
Access ControlAccess 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 548 - Farkas 22
Access ControlAccess 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 548 - Farkas 23
Authorization ManagementAuthorization 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 548 - Farkas 24
Discretionary Access ControlDiscretionary Access ControlAccess 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 548 - Farkas 25
Access Matrix ModelAccess Matrix Model
Read
Write
Own
Read
Read
Write
Own
OBJECTS AND SUBJECTS
SUBJECTS
Joe
Sam
File 1 File 2
CSCE 548 - Farkas 26
ImplementationImplementationAccess Control List (column)
File 1 File 2Joe:Read Joe:ReadJoe:Write Sam:ReadJoe:Own Sam:Write
Sam:OwnCapability List (row)Joe: File 1/Read, File 1/Write, File 1/Own, File 2/ReadSam: File 2/Read, File 2/Write, File 2/Own
Access Control TriplesSubject Access ObjectJoe Read File 1Joe Write File 1Joe Own File 1Joe Read File 2Sam Read File 2Sam Write File 2Sam Own File 2
(ACL)
CSCE 548 - Farkas 27
ACL vs. CapabilitiesACL vs. CapabilitiesACL:
– Per object based– Good for file systems
Capabilities: – Per subject based– Good for environment with dynamic, short-
lived subjects
CSCE 548 - Farkas 28
Access Control ConditionsAccess 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 548 - Farkas 29
Software and ACLSoftware and ACL
Vulnerable languages: any– C, C++, Java, .Net, etc.
Vulnerable platforms: any– Windows, UNIX, Linux, etc.
CSCE 548 - Farkas 30
Problem AreasProblem 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 548 - Farkas 31
RecommendationRecommendation
Use the operating system’s security technologies
Keep secrets out of harm’s wayUse security technology (access control
support, encryption, etc.) properlyScrub the memory securely once finished
with secret data
CSCE 548 - Farkas 32
Weak Access ControlWeak 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 548 - Farkas 33
Testing for Weak Access ControlTesting 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 548 - Farkas 34
Problem AreasProblem Areas
Embedding secret in code– Application code contains authentication,
encryption keys, etc.
CSCE 548 - Farkas 35
Information LeakageInformation Leakage
By accidentBy intention
CSCE 548 - Farkas 36
Communication ChannelsCommunication 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 548 - Farkas 37
Information FlowInformation 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 548 - Farkas 38
Non-InterferenceNon-Interference
High-security data does not influence lower security data
How to guarantee it?
CSCE 548 - Farkas 39
Covert ChannelCovert ChannelTiming Channel: based on system timesStorage channel: not time related
communicationCan be turned into each other
CSCE 548 - Farkas 40
Covert ChannelCovert 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 transmittedSender:
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 548 - Farkas 41
Covert ChannelsCovert ChannelsProblems:
– Noise– Need sophisticated synchronization
Protection (user state, system state)– Removal– Slow down– Audit
CSCE 548 - Farkas 42
Cryptographic Timing AttackCryptographic 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 548 - Farkas 43
Inference ChannelsInference Channels
+ Meta-data Sensitive Information
Non-sensitiveinformation =
CSCE 548 - Farkas 44
Inference ChannelsInference ChannelsStatistical Database InferencesGeneral Purpose Database Inferences
CSCE 548 - Farkas 45
Statistical DatabasesStatistical 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 548 - Farkas 46
Statistical CompromiseStatistical CompromiseExact 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 548 - Farkas 47
Inferences in General-Purpose Inferences in General-Purpose DatabasesDatabases
Queries based on sensitive dataInference via database constraintsInferences via updates
CSCE 548 - Farkas 48
Queries based on sensitive dataQueries based on sensitive dataSensitive information is used in selection
condition but not returned to the user.Example: Salary: secret, Name: public
NameSalary=$25,000
Protection: apply query of database views at different security levels
CSCE 548 - Farkas 49
Database ConstraintsDatabase ConstraintsIntegrity constraintsDatabase dependenciesKey integrity
CSCE 548 - Farkas 50
Integrity ConstraintsIntegrity ConstraintsC=A+B A=public, C=public, and B=secretB can be calculated from A and C, i.e.,
secret information can be calculated from public data
CSCE 548 - Farkas 51
Database DependenciesDatabase DependenciesMetadata:Functional dependenciesMulti-valued dependenciesJoin dependenciesetc.
CSCE 548 - Farkas 52
Functional DependencyFunctional 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 548 - Farkas 53
Key integrityKey integrityEvery tuple in the relation have a unique
keyUsers at different levels, see different
versions of the databaseUsers might attempt to update data that is
not visible for them
CSCE 548 - Farkas 54
ExampleExample
Name (key) Salary Address
Black P 38,000 P Columbia S
Red S 42,000 S Irmo S
Secret View
Name (key) Salary Address
Black P 38,000 P Null P
Public View
CSCE 548 - Farkas 55
UpdatesUpdates
Public User:
Name (key) Salary Address
Black P 38,000 P Null P
1. Update Black’s address to Orlando2. Add new tuple: (Red, 22,000, Manassas)IfRefuse update: covert channelAllow update: • Overwrite high data – may be incorrect• Create new tuple – which data it correct
(polyinstantiation) – violate key constraints
CSCE 548 - Farkas 56
UpdatesUpdates
Name (key) Salary Address
Black P 38,000 P Columbia S
Red S 42,000 S Irmo S
Secret user:
1. Update Black’s salary to 45,000IfRefuse update: denial of serviceAllow update: • Overwrite low data – covert channel• Create new tuple – which data it correct
(polyinstantiation) – violate key constraints
CSCE 548 - Farkas 57
Inference ProblemInference ProblemNo general technique is available to solve
the problemNeed assurance of protectionHard to incorporate outside knowledge
Next ClassNext Class
Failing to Handle Errors CorrectlyDesign Patterns
CSCE 548 - Farkas 58