Transcript Chapter 03
Secure Code Development
What are the risks of delivering insecure
applications or software products?
How can a company ensure they produce
secure code?
What strategies can be used?
What tools exist?
What departments help with this
process?
Secure Programs
15-50 faults per 1000 lines of code.
Fixing faults:
◦ “penetrate and patch” search for bugs and
repair.
Is conformance to specifications sufficient?
Compare requirements with behavior.
◦ Find program security flaws.
◦ Either human error or malicious intent.
Tester’s perspective important.
Security Development Lifecycle
Align the below tasks with the SDLC.
Plan: product stakeholders & security meet.
Design: identify weaknesses early.
Develop: code securely.
Test: test products against security requirements.
Document: secure configurations of product
Assess: verify product security before release.
Respond: know how to deal with customers who
report security concerns with your product.
Threat Model (design phase)
Static Code Analysis Tools
Static analysis: static code analysis, data flow
static analysis, and metrics analysis
Peer code review: process automation
◦ preparation, notification, and tracking
Unit testing: JUnit and Cactus test creation,
execution, optimization, and maintenance
Runtime error detection: race conditions,
exceptions, resource & memory leaks, security
attack vulnerabilities.
Quality Assurance
Systematic evaluation of the various aspects of a
product to maximize the probability that
minimum standards of quality are being attained
by the production process.
Cannot guarantee production of quality products.
Two principles in QA:
◦ "Fit for purpose" - suitable for the intended purpose;
◦ "Right first time" - mistakes should be eliminated.
Quality is determined by the product users,
clients or customers, not by society in general.
Testing
Unit: test in controlled environment.
Integration: components work together.
Functional: does it meet requirements.
Performance: measure capability.
Acceptance: check meets customer
requirements.
Installation: final test during install.
Testing Continued
Regression: test product still meets
requirements after it has been modified.
Black Box: test without knowledge of how
the system was built.
White Box: test with full knowledge of the
system and its expected behavior.
Independent: Outsider view
Penetration: computer security testing.
Figure 3-19 Fault Discovery Rate
Reported at Hewlett-Packard.
Types of Flaws
Validation Error: permission checks.
Domain Error: controlled access to data.
Serialization and aliasing: program flow.
Inadequate identification and
authentication
◦ Authorization flaws
Boundary condition violation: exceed
them
Logic errors: errors in process design.
Secure Software Development Practices
Peer Reviews: review, walk-through, inspection.
Hazard Analysis: expose hazardous states.
Testing: quality assurance.
Good Design: fail-safe, earlier discussion items.
Prediction: risk analysis.
Static analysis: control and data flow, structure.
Configuration management: what changes when.
Analysis of mistakes: lessons learned.
Nessus Vulnerability Scanner (assess phase)
Non Malicious Program Errors
Buffer Overflows: coding error, buffer overruns.
◦ Attacker replaces code in the stack
Heap Overflow: dynamically allocated memory.
◦ Corrupt this data in specific ways to cause overwriting.
Incomplete Mediation: out of range input or value
injection
◦ http://www.comesite.com/purchasing/data&parm1=(303)5551234&price=10
◦ Tools: Hackbar, Tamper Data, OWASP Web Scarab, etc.
Figure 3-1 Places Where a Buffer Can Overflow.
Metasploit Pen Testing
Asset Management
Configuration Management
◦ Manage updates and deliveries.
Baselining
◦ capture a point in time.
Patch management
◦ Verification and delivery.
Vulnerability Management
◦ How will you respond to a customer?
Change Management
◦ If no change will become less secure.
TOCTTOU/Race Condition
Time of check time of use (TOCTOU)
◦
◦
◦
◦
◦
◦
“Alter a condition after it has been checked”.
A state attack leveraging an OS change of state
Hacker ask for permission to file “readme”.
OS Checks permission on file,
OS does something else…
Hacker makes file a symbolic link from readme to
/etc/shadow.
◦ OS allows access to file. Hacker changes passwords.
Discussion Questions
The common description of a salami
attack is penny shaving.
◦ Steal small amounts that no one will notice.
How could you prevent a salami attack
from being part of your software
product?
◦ Can you identify 3 controls to help?
Virus
Agent: virus author.
Malware that does not spread
automatically.
Requires a carrier (USB, CDROM, floppy).
Macro: MS (Word, Excel).
Polymorphic: changes its signature on install.
Boot sector: loads on system startup.
Stealth: hides from anti-virus software.
Figure 3-4 Virus Appended to a Program.
Figure 3-5 Virus Surrounding a Program.
Figure 3-6 Virus Integrated into a Program.
Figure 3-7 Virus Completely Replacing a Program.
Figure 3-8 Boot Sector Virus Relocating Code.
Figure 3-9 Recognizable Patterns in Viruses.
Anti-Virus is Reactionary
Polymorphic Virus
Virus coded to modify its signature.
Insert lines containing random comments.
Scanners: remove comments, white space.
Insert junk code intermittently.
◦ Changes the capitalization of the letters in the crucial strings.
◦ Traditional code normalization techniques are not applicable.
Use static encryption.
Change Variable names.
Protection Ring Model
Root kits
Malware that replaces portions of an operating system
at user level 3.
◦ Unix: replace ls, ps etc.
PATH:.:/usr/bin:/usr/sbin
Hide from /proc on linux
◦ Windows
Replace dir or task list
Kernel-mode rootkits operate in ring 0.
◦ Hide from /proc on linux
Root Kit Protection (OSSEC)
Targeted Malicious Code
Written for a specific application or
purpose
Trap doors: undocumented entry point.
Salami Attack: skimming small amounts.
Rootkits: Sony XPC example.
Privilege escalation: programs that run at
a high privilege level are targets.
Keystroke loggers.
Figure 3-10 Stubs and Drivers.
Covert Channels
Definition: any communication that
violates a security policy.
Storage Channel: use shared storage to
communicate, /tmp filesystem.
Covert timing channel: hacker notices the
difference in system response to an
incorrect password vs. incorrect
username.
Figure 3-11 Covert Channel Leaking Information.
Figure 3-12 Covert Channels.
Figure 3-13 File Lock Covert Channel.
Figure 3-14 File Existence Channel Used to Signal 100.
Figure 3-15 Covert Timing Channel.
Discussion Question
An electronic mail system could be used
to leak information.
How could email leakage occur?
What controls could detect or prevent
the leakage?
Modularity & Programming
Goals for a component
◦
◦
◦
◦
Have a Single purpose.
Be small: understand content and structure.
Be simple: KISS, low complexity.
Be independent: performs a task isolated from
other modules.
Benefits of Modularity
Maintenance: easier to maintain.
Understandability: easier to comprehend
smaller pieces of code.
Reuse: reuse code in other systems.
Correctness: quickly trace failures if it
only performs a single task.
Testing: simplifies testing.
Figure 3-16 Modularity.
Coupling & Cohesion
Concept used to describe objects in the
object oriented world.
Highly coupled = requires a lot of other
objects to complete a task.
High Cohesion = very independent object
Objects with high coupling have low
cohesion.
Figure 3-17 Coupling.
Object Oriented Programming
Java, PERL, Python, C++.
Programs are a series of connected
objects.
Communicate via message passing.
Objects are black boxes
◦ Have data encapsulated.
◦ Has methods that can be called.
Design by breaking problems into objects.
Object Oriented Class
Encapsulation
Concept used to describe how object
oriented design hides data.
An object is a black box.
Object provides methods to access data.
We do not know how the object
performs its function.
Hide what should be hidden.
Figure 3-18 Information Hiding.