Finding vulnerabilities
Secure Programming
Lecture 3
In the news
“In DEF CON, a man in jeans was passing out cards. There was no company logo or name on the card, just this message” (via @mikko)
In the news
Another fake google.com certificate (but allegedly it was just a bizarre mistake):
TURKTRUST Inc. incorrectly created two subsidiary CAs […] The *.EGO.GOV.TR subsidiary CA was then used to issue a fraudulent digital certificate to *.google.com.
Interesting projects for monitoring or fixing current CA system: Convergence, SSL observatory, Sovereign Keys, Certificate Transparency, Perspectives
Admin
Demonstration:
- Maxim Strygin
- Lab sessions: Wednesdays, 10am-12pm, from week 3
- Place TBD
RSS feed with latest news
Where are we?
Set of principles that can guide us when designing secure systems, but…
- not all systems designed with these principles in mind
- principles are not a silver bullet
How do we go about finding vulnerabilities?
Threat modeling
Several steps:
- information collection (assets, entry points, external entities, trust levels, main components)
- architecture modeling
- threat identification (e.g., attack trees)
- documentation of findings
- prioritization of implementation review (e.g., DREAD)
Attack trees
You can annotate nodes with additional values (equipment requirements, cost, etc.)
DREAD problems
Original rating obtains overall risk value by averaging the score in each category. Reasonable?
Risk A: damage 1, rest 10 → 8.2
Risk B: discoverability 1, rest 10 → 8.2
Which one would you prefer?
Application review
Review of the actual software artifact, incorporating:
- results from the design review
- results from the operational review
Several techniques:
- code audit
- testing techniques (e.g., fuzzing)
Preliminaries
- What are the review's goals
- What is the timeline?
- Ensure proper legal documents are in place!
Tips
Avoid drowning
Iterative process
Coordinate with other assessors
In the end, creative process that requires to acquire and build specialized skills
Code auditing
Code comprehension strategies:
- Trace malicious input
- Analyze sub-components (module, algorithm, class)
Candidate point strategies:
- trace back from potential vulnerabilities (from source code analysis or black box testing tools)
Design generalization strategies:
- model the system: infer high-level abstractions and identify vulnerabilities
- hypothesis testing: model subsystem starting from an hypothesis of its working
Fuzzing
Throw random/unexpected/corner case input to an application and see if manifests a bug (e.g., crashes)
- fast: checks for lots of cases
- (relatively) simple: enables testing of cases that are not manageable via manual code audit
- effective
Well-known technique (B. Miller's original 1990 report)
Fuzzing
More recent efforts:
Case study
Finding vulnerabilities in electronic voting systems
An Experience in Testing the Security of Real-World Electronic Voting Systems,
IEEE Transactions on Software Engineering, 36(4), 2010
Top-To-Bottom Review (TTBR)
Review of electronic voting systems ordered by California Secretary of State D. Bowen in summer 2007
Similar study in Ohio the following year
“Are our voting systems secure, accurate, reliable and accessible?”
For each analyzed system, established:
- document review team
- source code review team
- “red” team
Analysis environment
All teams required to sign strict NDAs
→ I cannot show you any piece of code
Voting system: DREs and VVPAT
Voting system: Optical scanners
Voting system: DTDs
Functional overview
- Prior to election, ballot information is prepared at election central
- On election day, voting machines are initialized using Data Transport Devices (DTDs)
- DREs and optical scanners are tested with sample votes (logic and accuracy testing)
- Actual voting takes place
- After election is closed, results are collected on DTDs and returned to election central
- Tally is computed
Security evaluation
Scope of work: try and compromise the accuracy, security, and integrity of the voting systems
- cause incorrect recording, tabulation, tallying or reporting of votes
- alter critical election data such as election definition or system audit data
We were provided with:
- documentation
- source code
- working machines
Methodology
High-level view of the system:
- information gathering
- identify high-level components and information flows
- develop misuse cases
Low-level, concrete implementation:
- low-level information flow
- identify threats and attack exposures
- attack a component
- compromise the entire system
0. Information gathering
Collect all available information on the system and set up the testing and analysis environment
- copy of each components
- copy of source code and binaries
- copy of all documentation
- vendor support (e.g., training)
1. High-level components and flows
Identify abstract components (as opposed to actual, physical machines): e.g., DRE, DTD
Identify high-level information that is generated, transported, or used by each component: e.g., ballot, recorded vote
Security assumptions (confidentiality, integrity, availability) about this information:
- data loaded on DTD is the same as that generated at election central
- data on DTD cannot be altered
2. Misuse cases
Devise scenarios where some security assumptions is violated and determine the resulting failure
What-if scenarios
Data on DTD can be altered without being detected:
→ invalid ballot information
→ invalid election results
3. Low-level information flow
Model input/output interface of each software and hardware component
Identify data, protocol, data format, and physical carrier
Determine how data is authenticated and validated by each component and how it is protected from eavesdropping, MITM attacks, tampering and replay attacks
Understand how encryption is used and how key material is managed
Components and information flow
4. Threats and exposures
Threat modeling
- who are the attackers?
- what are their motivations, capabilities, and goals?
Identify actual attack scenarios, combining
- threat modeling,
- misuse cases (step 2), and
- low-level information (step 3)
5. Attacking a component
Vulnerability analysis of a component
Exploit development
- Ad hoc tools (debuggers, exploitation frameworks, etc.
- long days (and nights) in the lab :-)
6. Compromising the system
Leverage the vulnerabilities identified earlier to compromise the entire system
Evaluate how a compromised component can take advantage of legitimate information flow to take control of other devices
Findings
- Autorun vulnerability on election management system at election central
→ arbitrary code execution - Integer overflow vulnerability in DRE
→ arbitrary code execution - Voter cards are encrypted but key is stored on the card itself
→ multiple voting - DRE store in a global variable whether it's in testing mode
→ detection evasion - many, many more!
An election stealing virus
- By leveraging the autorun vulnerability, install a Trojan on the election management system
- The Trojan modifies the DTD data to exploit the integer overflow vulnerability and install a malicious firmware on the DRE
- The malicious firmware modifies the vote, causes denial of service attacks, and disrupts the elections