Domain 4. Secure Software Implementation (Programming)

Fundamental Concepts of Programming

  • The organisation is ultimately responsible for insecure software
  • Fundamental skill of a programmer: problem solving

Computer Architecture

  • CPU:
    • Arithmetic Logic Unit (ALU): mathematical and logical operations
    • Control Unit (CU): controls/directs the instructions processing
    • Registers: internal memory holding spaces, store the most immediate data
    • Machine Cycle:
      • Fetching: CU gets instruction from RAM (using memory address and pointer to keep track)
      • Decoding: CU deciphers instruction and move data to ALU
      • Execution: ALU processes the instruction
      • Storing: ALU stores result in Registers
  • Random Access Memory (RAM)
    • Layout:
      • Program text, use variables to access memory objects
      • Data, global data
      • Stack (allocated areas on RAM, LIFO), variables, local data, ESP
        • Most attacks happen here
        • PUSH/POP operations: used for allocating space on stack to run functions
          • PUSH, higher to lower address
          • POP, lower to higher address
          • ESP, higher to lower address
      • Heap (allocated areas on RAM), objects too large to be on stack
        • Can run more than one process at a time
    • Instantiation: the allocation of a memory object
  • Storage
  • I/O
  • Bus: communication channel between all components

Evolution of Programming Languages

  • Low-level programming: closely related to hardware
    • Assembler: converts assembly to machine code
  • High-level programming languages (HLL): isolate machine execution from the program’s function
  • Goal-orirented language: very high level
  • Natural languages: very very high level
  • Source code: converted into intruction codes (machine codes)
  • IDE and HLL allows people wihtout internal knowledge to develop code, this is bad from security standpoint
  • Language types
    • Compiled Languages
      • Compilation
      • Linking: Static and Dynamic
    • Interpreted Languages
    • Hybrid Languages
      • Source code is compiled into an intermediate stage that is then interpreted
      • Java (the intermediate stage is called byte code, JVM is the interpreter)
      • .Net, compiled into Common Intermediate Language (CIL), Common Language Runtime’s (CLR) converts to native code

Common Software Vulnerabilities and Controls

  • National Vulnerability Database (NVD)
    • US government repository, using Security Content Automation Protocol (SCAP)
    • Potential for automation
  • US Computer Emergency Response Team (CERT) Vulnerability Notes Database
    • Aims at reducing security risks due to software vulnerabilities
  • Open Source Vulnerability Database
    • Open source, independent
  • Common Vulnerabilities and Exposures (CVE)
    • A dictionary of publicly known vulnerabilities, free, international in scope
    • Structure
      • A number (CVE-1999-0067)
      • A brief description
      • Pertinent references
  • OWASP Top 10
    • Consider most common application security issues from a weakness and organisational perspective
  • Common Weakness Enumeration (CWE)
    • A list of software weaknesses created by a community initiative
    • Provides a common language for describing security weaknesses, free, international in scope
    • CWE/SANS top 25
      • Insecure interaction between components
      • Risky resource management
      • Porous defenses
      • Can be used as a checklist of reminders and as a source for a custom list that incorporates internal historical data

Busffer Overflow

  • When data that is being copied into the buffer is more than what the buffer can handle
  • To mitigate buffer overflow, better to understand Localiy of reference
  • Buffer overflow is historically the largest attack surface
  • Stack Overflow
    • when memory buffer overflows into the stack space
    • ESP tells which function to execute
    • EIP maintain the sequence order of functions, indicates the address (RET) of the next instruction
    • RET is placed on the stack when a function is called, if overwritten, EIP returns to another address
    • Unsafe functions: strcpy(), strcat(), no intrinsic length check before copying into memory
  • Heap Overflow
    • A heap overflow doesn’t necessarily overflow but corrupts the heap memory, overwriting variables and function pointers on the heap. Large objects that cannot be stored on stack are pushed to the heap.
    • Usually need special functions to allocate and deacllocate heap memory
      • malloc() (ANSI C), HeapAlloc() (Windows), new() (C++)
      • free(), HeapFree(), delete()
    • There is no intrinsic control on allocated memory boundaries, possible to overwrite other memory chunks
    • Common causes
      • Copying data into buffer without checking the size of input
      • Accessing buffer with incorrect length values
      • Improper validation of array index
      • Integer overflows or wraparounds
        • Language/processor dependent
        • Occurs during arithmetic operations
      • Incorrect calculation of buffer size
    • Implementation Controls
      • (most important) input (size) validation
      • Loop input check
      • Data type range check
    • Other controls:
      • Choose a type safe (closely related to memory safety) language
        • Type unsafe languages will not prevent an arbitrary integer to be used as a pointer
        • Type safe: Ada, Perl, Java, .Net
      • choose a proven library/framework
        • Safe C String (SafeStr) library
        • SafeInt (C++), IntegerLib (C/C++)
      • Replace deprecated, insecure and banned API
        • strncpy(), strncat(), if buffer size equals to the source, string may not be terminated
      • Use unsigned integers whenever possible, if use signed, check maximum and minimum values
      • Leverage compiler security
        • Microsoft Visual Studio /GS flag
        • Fedora/Red Hat FORTIFY_SOURCE GCC flag
        • StackGuard
      • Leverage OS features
        • Address Space Layout Randomization (ASLR)
        • Data Execution Protection (DEP)
        • Execution Space Protection (ESP)
      • Use memory checking tools
        • MemCheck, Memwatch, Memtest86, Valgrind, ElectricFence

Injection Flaws

  • SQL injection
    • Attack flow: Exploration, Experimenting, Exploiting
    • Blind SQL injection: construct boolean queries or check response time
  • OS Command injection
    • Software accepts arguments from the user to execute a single fixed program command
      • Injection is contained to the command
      • False assumption on the trustworthiness of the arguments
    • Software accepts arguments from the user which specifies what program command to execute
      • Injection is not contained
      • False assumption on the accessibility of the command
  • LDAP injection: similar concept, but with LDAP
  • XML injection
    • XPATH injection
      • Unvalidated XPath expression, exploit the structure
    • XQuery injection
      • Unvalidated XQuery expression, exploit retrieval of data
    • Characteristics
      • Input is interpreted as a command
      • Input is not sanitized or validated
      • Query is generated dynamically using user supplied input
    • Impacts
      • Disclosure, alteration or destruction of data
      • Compromise of OS
      • Discovery of the internal structure
      • Enumeration of user accounts from a directory store
      • Circumventing nested firewalls
      • Bypassing authentication
      • Execution of extended procedures and privileged commands
    • Mitigations
      • Validate all user input
        • Whitelisting
        • Validation on both server and client
        • Validate data type, range, length, format, values, canonical representations
      • Output encoding, escape special characters and quote input, disallowing meta-characters
      • Use structured mechanisms to separate data from code
      • Avoid dynamic query
      • Use a safe API to avoid the use of the interpreter, eg ESAPI by OWASP
      • Use parameterized queries (stored procedures etc)
      • Display generic error messages
      • Implement fail safe
      • Remove any unused functions or procedures
      • Implement least privilege by using views, and restricting tables, queries and procedures
      • Audit and log the queries, response time
      • Run the code in a sandbox to avoid OS command injection
        • eg Linux AppArmor, Unix chroot jail
      • Use runtime policy enforcement to create the list of allowable commands
      • Filter or quote LDAP syntax from user-controlled input
      • Application layer firewall, as a compensation

Broken Authentication and Session Management

  • Common issues
    • Allowing more than one set of authentication/session management
    • Transmitting credentials in cleartext
    • Storing credentials in cleartext
    • Hard coding credentials in code, config
    • Not using a random or pseudo-random mechanism to generate password/sessionID
    • Implementing weak account management functions
    • Exposing session IDs in the URL by rewriting the URL
    • Insufficient or improper session timeouts and account logout
    • Not implementing transport protection or data encryption
  • Countermeasures
    • Using proven authentication and session management
    • Use a single and centralized authentication mechanism
      • Multi-factor authentication and role based access control
    • Using a unique, non-guessable and random session ID
    • Storing authentication credentials in ciphertext
    • Do not hard code database connection strings, passwords or cryptographic keys in cleartext
    • Identify and verify users at both the source as well as at the end of the communication channel
    • Do not expose session ID in URLs or accept preset or timed out session ID
    • Ensure that XSS protection mechanism are in place
    • Require the user to re-authenticate upon account update
    • Do not implement custom cookies in code to manage state
      • Secure implementation of cookies by encrypting them to prevent tampering and cookie replay
    • Do not store, cache or maintain state information on the client without appropriate integrity check
      • Cache windowing: cache only available for a period of time
    • Ensure that all pages have a logout link
      • Don’t assume that the closing of the browser window will abandon all sessions and client cookies
    • Explicitly set a timeout and design the software to automatically log out
    • Implement the maximum number of authentication attempts allowed
    • Encrypt all client/server communications
    • Implement protection at transport layer (SSL/TLS) or at network layer (IPSec)

Cross-Site Scripting (XSS)

  • 1-2 punch: Injection and XSS, arguably the two most frequent
  • Non-persistent or Reflected XSS
    • Not stored on the app, just included in the resposne
    • Input script directly into the web app
    • Send a link with the script embedded and hidden in it
  • Persistent or Stored XSS
    • Permanently stored on the target servers
    • eg Samy Worm, Flash worm
  • DOM based XSS
    • Payload is placed in the response page due to weaknesses on the server side
    • Impacts:
      • Steal authentication information using the web application
      • Hijack and compromise users sessions and accounts
      • Tamper or poison state management and authentication cookies
      • Cause DoS by defacing the websites and redirecting users
      • Insert hostile content
      • Change user settings
      • Phish and steal sensitive information using embedded links
      • Impersonate a genuine user
      • Hijack the user’s browser using malware
    • Controls:
      • Handle the output to the client only after it is sanitized (escaped or encoded)
        • In conjunction with input validation, the best way to counter XSS
      • Input whitelisting
        • .net, validateRequest prevent any unencoded request to the server to be processed
      • Disallow the upload of .htm or .html
      • Use innerText instead of innerHtml when storing the input
      • Use secure libraries and encoding frameworks
        • Microsoft Anti-Cross Site Scripting
        • OWASP ESAPI Encoding module
        • Apache Wicket
        • SAP Output Encoding framework
      • Disabling the active scripting option in the browser
        • Install add-on plugins that will prevent the execution of scripts
        • NoScript is a popular add-on for the Mozilla Firefox browser
      • Use the HTTPOnly flag
      • Application layer firewall
  • Common uses:
    • Theft of authentication information from a web application
    • Session hijacking
    • Deploy hostile content
    • Change user settings, including future users
    • Impersonate a user
    • Phish or steal sensitive information

Insecure Direct Object References

  • Internal object redirecly manipulatable
  • Controls:
    • Avoid exposing internal functionality using a direct object reference
    • Use indirect object reference, such as a map
    • Do not expose internal objects directly via URLs or form parameters
    • Either mask or cryptographically protect (encrypt/hash) exposed parameters
    • Validate the input
    • Perform multi access control and authorization checks
    • RBAC, both context and content based
    • Code reviews
    • Parameter manipulation testing

Security Misconfiguration

  • Examples:
    • Missing software and OS patches
    • Lack of perimeter and host defensive controls
    • Installation of software with default accounts and settings
    • Installation of the administrative console with default configuration
    • Installation or configuration of unneeded resources
    • Not disabling directory listing on the server
    • Not explicitly setting up error and exception handling
    • Leaving behind any sample applications
    • Deploying tightly coupled applications and system-of-systems
  • Controls:
    • Changing default configuration
    • Removing unneeded resources
    • Establishing a (config) minimum security baseline (MSB)
    • Establishing an OS/applications hardening process
    • Establishing a controlled patching process
    • Establishing a scanning process
    • Handling errors explicitly (e.g redirects, error messages)
    • Removing any sample applications from production
    • Employing a loosely coupled and highly cohesive architecture

Sensitive Data Exposure

  • Insufficient data-in-motion protection
    • Passive sniffer
    • Surf Jacking attack: sniffing for session cookie on unencrypted network
    • Session hijacking
    • Replay attacks
    • TLS doesn’t necessarily prevent MITM, unless it’s end-to-end
  • Insufficient data-at-rest protection
    • Local storage
      • Web, mobile local storage are manipulatable
    • Browser settings
      • Cascading Style Sheet (CSS), browser caching, can steal browser history
    • Cache
    • Backups, logs and configuration files
    • Comments in code
    • Hardcoded secrets in code
    • Unhandled exceptions and error messages
    • Backend data stores
  • Electronic social engineering
    • Phishing, Spear phishing
    • Pharming (phishing without a lure):
      • Malicious code installed on a system and misdirects users to fraudulent web sites
      • Often works by modifying the local hosts or DNS poisoning
    • Vishing
      • VoIP phishing, attacker steals sensitive information using deceptive SET on VoIP networks
    • SMSishing(SMishing)
      • SMS phishing
    • Drivers:
      • Primary: human trust
      • Secondary:
        • No proper ACLs
        • Lack of spyware protection
    • Controls:
      • HTTPOnly flag, but cannot protect local storage
      • Private browsing, configure to not save history
      • Disable autocomplete
      • Disable caching of sensitive data, otherwise encrypt them
      • Don’t deploy backups
      • Server hardening, protect logs
      • Installation scripts, change logs should be removed
      • Comments shouldn’t reveal sensitive info
      • Static code analysis
      • Don’t store data that is not needed
      • Encryption, hashing, salting, eg bcrypt, PBKDF2 or scrypt
      • End-to-end channel security (SSL/TLS or IPSec)
        • Can encrypt data as well as a protection
      • Avoid using mixed SSL or pages missing ssl
      • Use secure flag for session cookie
        • Against Surf Jacking attack
      • Using proven cryptography, compliant with FIPS 140-2
      • Properly configure digital certificates
      • User education
      • Social engineering
        • Dilution (spoofback): sending bogus/faulty info to phisher to dilute the real info
        • Takedown: actively bringing down the phishing/pharming web site
        • Vishing scams: do not trust the caller ID, verify the caller on the other end
        • SMSishing scams, disable SMS if not required
        • Don’t trust and verify whenever in doubt
      • Separation of duties/privileges for privileged/sensitive data access

Missing Function Level Checks

  • Failed access control to privileged functions (forced access attacks)
    • Security through obscurity is helpless
  • Primary target: web pages with admin functions
  • Controls:
    • Complete mediation, least common mechanisms
    • RBAC: deny by default, instead of hard-coded logic, use entitlement for easier management
    • Whitelisting allowed functions
    • Validate parameters that contain URLs
    • Don’t rely on client based checks
    • Implement assess control in business layer
    • Don’t cache web pages that contains sensitive info
    • Utilise authorisation frameworks: JAAS, OWASP ESAPI

Cross-Site Request Forgery (CSRF)

  • Forges a malicious HTTP request as a legitimate one and tricks victim to send request
    • Due to browsers usually automatically include credentials to a domain in the request
    • Forged requests e.g: email links, zerobyte images, iFrames, Clickjacking, XSS redirects
    • Other names: XSRF, Session riding attack, sea surf attack, hostile linking, automation attack, Cross Site Reference Forgery
  • Primary targets: forms that invoke state changing functions
  • Flow:
    1. user auth to site, stores access token
    2. user tricked to click on forged link that sends req
    3. request sent with the token included
  • OWASP CSRF Tester tool can be used to generate test cases to demonstrate the dangers of CSRF flaws
  • Controls (user control/dev control):
    • Implement software not dependent on authenticated credentials
    • User controls:
      • Do not save username/password in the browser.
      • Do not use “remember me”
      • Do not use the same browser for business sensitive activities
      • Read standard emails in plain text
      • Log off after using a web application
      • Use client-side browser extensions that mitigate CSRF attacks
        • eg: Firefox CSRF Protector
    • Dev controls:
      • Nonce (one-off token)
      • CAPTCHAs (Completely Automated Public Turing test to tell Computers and Humans Apart)
      • Validate session token on server side
      • Use POST instead of GET for sensitive data and privileged functions
      • Double-submitted cookie: generate a random cookie on first visit, include this in both form and cookie
        • Attacker can change form value, but same-origin policy prevents attacker to modify cookie value
      • Check referrer before processing the request
        • Referrer could be used by proxy
        • Referrer can be spoofed
        • Need to be implemented in conjunction with other controls
      • Re-auth for sensitive functions
      • Use transaction signing to assure that the request is genuine
      • Implement auto-log-off
      • Leverage industry tools
        • OWASP CSRF guard, ESAPI session management control (anti-csrf packages)
        • Code Igniter (server side for PHP MVC)
      • Mitigate XSS

Using Known Vulnerable Components

  • Most software using open-source don’t have vulnerability patches to fix old versions, but release new versions to address them
  • Controls
    • Avoid using libraries with known vulnerabilities
    • Identify all dependencies and keep them updated
    • Monitor bug tracking databases
    • Establish policies that govern component use/re-use

Unvalidated Redirects and Forwards

  • Redirecting: external links
  • Forwarding (transfer): internal pages
  • Open Redirects: attacker redirects a user to a macilicous site
  • 3XX series HTTP response codes (300-307)
  • Controls:
    • Avoiding redirects and forwards (transfers)
    • Whitelist target URLS
    • Don’t allow the user to specify the target
      • If required, validate the URL parameter
    • Use indexing to map the URL
    • Using intermediate page to warn user for external redirects
    • Mitigate script attacks vulnerabilities

File Attacks

  • Malicious file execution
    • User supplied file names
    • Executable types
    • Uploading hostile data
    • Streaming without inspecting internal flags and settings
    • Input and data wrappers (such as php://input) that accept input from the request POST data instead of a file
    • Hostile Document Type Definitions (DTDs) that forces XML to load a remote DTD and parse/process the results
    • Controls
      • Whitelist allowed extensions
      • Allow only single extension
      • Using indirect object reference
      • Protect file names using hash, salt
      • Taint checking (feature in programming language protects against file execution attacks)
      • Automatically generated filenames
      • Using a staging environment before processing uploaded files
      • Inspect not only file type, size, mime type, attribute, but also file contents
      • Avoid using file functions and streaming API to construct filenames
      • Set app to demand proper file permissions
        • Java Security Manager, ASP.Net
  • Path traversals
    • Controls:
      • Whitelist acceptable file paths
      • Limit character sets
      • Server hardening, disallow directory/content browsing
      • Decode once and canonical file paths to internal representation
        • Built-in canonicalization functions
          • realpath() (C, Perl, PHP)
          • getCanonicalPath() (Java)
          • GetFullPath() (ASP.Net)
          • abs_path() (Perl)
      • Use generic value mapping to represent known internal filenames, reject values not configured explicitly
  • Improper file includes
    • Controls
      • Store library, include and utility files outside of the root or system directories
      • Restrict access to files within a specified directory
      • Limit the ability to include files from remote locations
  • Download of code without integrity check
    • Controls
      • Integrity check on downloads from remote locations
        • e.g: hashing, code signing and authenticode
      • Prevent DNS spoofing, perform both forward and reverse lookup
        • Doesn’t protect hosting site and when in transit
      • Use monitoring tools to examine interaction with OS and network

Race Condition

  • Race Condition Criteria:
    • Concurrency property: at least two threads running concurrently
    • Shared object property: both threads accessing the same object
    • Change state property: at least one alters the state of the object
  • Examples:
    • Deadlocks, DoS
    • Integrity issues
    • Total compromise
  • Controls:
    • Identify/eliminate race windows
    • Atomic operations on shared resources
    • Mutex operations
    • Synchronization primitives around critical code (avoid performance issues)
    • Multi-threading/thread-safe capabilities
    • Minimise use of shared resources and critical sections
    • Disabling interrupts or signals over critical code sections
    • Avoiding infinite loop
    • Economy of mechanisms
    • Error and exception handling
    • Performance testing

Side Channel Attacks

  • Predominantly in cryptographic systems
    • Controls:
      • Leverage proven cryptographic algorithms
  • Timing attacks: attacker measures how long each computational operation takes
    • A subset of timing attack is looking for delayed error messages which is a technique employed in blind SQL injection attacks.
    • Controls:
      • Use a system where the time to compute an operation is independent of the input data or key size
      • Avoid the usage of branching and conditional operational logic (IF-THEN-ELSE) in critical code sections
        • Use simpler and straightforward computational operations (AND, OR, XOR)
      • Standardise the time that each computation will take
  • Power Analysis attacks: attacker measures the varying degrees of power consumption
    • RSA key can be decoded using power analysis, which represent times when the algorithms use multiplications or not
    • Controls:
      • Balancing power consumption independent of the type of operation along with reducing the signal size are useful controls
  • TEMPEST attacks (van Eck or radiation monitoring attack): attacker uses leaked electromagnetic radiations to discover plaintexts and other pertinent information that are based on the emanations
    • Controls:
      • Physical shielding
  • Acoustic Cryptanalysis attacks: like power analysis attacks, in acoustic cryptanalysis attacks, the attacker uses the sound produced during the computation of operations
    • Controls:
      • Adding noise
  • Differential Fault Analysis attacks: aims at discovering secrets from the system by intentionally injecting faults into the computational operation and determining how the system responds to the faults
    • This is a form of fuzz testing, can be used to indicate the strength of the input validation controls in place
    • Controls:
      • Double encryption, which is characterized by running the encryption algorithm twice and outputting the results only if both the operations match, assumption: likelihood of a fault occurring twice is statistically small and insignificant
  • Distant Observation attacks: a shoulder surfing attack, attacker observes and discovers information of a system indirectly from a distance
    • eg: Observing through a telescope or using a reflected image off someone’s eye, eyeglasses, monitor or other reflective devices
  • Cold Boot attacks: attacker extract information by freezing the data contents of memory chips and boot up to recover the content due to data remanence in RAM. Need secure start up
    • Controls:
      • Physical protection of the memory chips
      • Preventing memory dumping software from execution
      • Not storing sensitive information in memory
      • Scrubbing and overwriting memory contents that are no longer needed periodically or at boot time
      • Trusted Platform Module (TPM), prevents key being loaded into memory, but doesn’t prevent from discovery if already loaded

Cryptographic Failures

  • Hard-Coded Credentials
    • Difficult to change
    • Insecure
  • Missing Encryption of Sensitive Data
    • Being ignorance
    • Operation issues: insecure backup, log, error reporting
  • Use of a Broken or Risky Cryptographic Algorithm
    • Using obsolete algorithms
    • Using self-created algorithms
    • Key being too short, RSA keys should be >2048 bits
    • Using an insufficient random number generator
      • MD-5 and SHA-1 are no longer considered secure
    • Plan for key length upgrade, e.g SHA-256 to SHA-512
  • Download of Code Without Integrity Check
    • Hash needs to be published to ensure it’s from a valid source
  • Use of a One-Way Hash Without a Salt
    • Rainbow table defeats hashtags
  • Not encrypting all of the sensitive data is a common failure mode

Input Validation Failures

  • Most important defensive mechanism
  • Consider all inputs to be hostile until properly validated
  • Output validation is also important
    • Output validation assures that a function’s output matches expectations before use as an input in another function or decision

Missing Defense Functions

  • Common issues
    • Missing Authentication for Critical Functions
    • Missing Authorization
    • Unrestricted Upload of File with Dangerous Type
    • Incorrect Authorization
    • Incorrect Permission Assignment for Critical Resource
    • Execution with Unnecessary Privileges
    • Improper Restriction of Excessive Authentication Attempts
    • URL Redirection to Untrusted Site (i.e Open Redirect)
    • Uncontrolled Format String

Virtualisation

  • Software may not necessarily running directly on hardware, should consider the virtualisation layer

Embedded Systems

  • Most attacks aimed at information disclosure
  • Consider for Denial of Service

Defensive Coding Practices – Concepts and Techniques

  • Foundational elements of defensive coding:
    • Attack surface reduction
      • Reducing the amount of code and services that are executed by default
      • Reducing the volume of code that can be accessed by untrusted users
      • Limiting the damage when the code is exploited
      • RASQ before/after code implementation can measure the effectiveness
    • An understanding of common coding vulnerabilities
    • Standard mitigations
  • Additional items:
    • Code analysis
    • Code review
    • Versioning
    • Cryptographic agility
    • Memory management
    • Exception handling
    • Interface coding
    • Managed code

Primary Mitigations

  • Lock down your environment.
  • Establish and maintain control over all of your inputs.
  • Establish and maintain control over all of your outputs.
  • Assume that external components can be subverted and your code can be read by anyone.
  • Use libraries and frameworks that make it easier to avoid introducing weaknesses.
  • Use industry-accepted security features instead of inventing your own.
  • Integrate security into the entire software development lifecycle.
  • Use a broad mix of methods to comprehensively find and prevent weaknesses.

Input Validation

  • While it is important to trust, it is even more important to verify
  • Input validation is to ensure the data that is supplied:
    • For processing is of the correct data type and format
    • Falls within the expected and allowed range of values
    • Is not interpreted as code as is the case with injection attacks
    • Does not masquerade in alternate forms that bypass security controls
  • How to Validate: regex, filtration (whitelist/blacklist)
  • Where to Validate: both client and server
  • What to Validate: data type, range, length, format, values, canonical forms

Canonicalization (C14N)

  • The process of converting data that has more than one representation to conform to a standard canonical form
  • Predominantly evident in Internet related software
  • In XML, canonicalization is used to ensure that the XML document adheres to the specified format
  • The canonical form is the most standard or simplest form.
  • Recommended to decode once and canonicalize inputs into the internal representation before validation
  • Examples:
    • URL encoding to IP address translations
    • internationalisation

Sanitization

  • The process of converting something that is considered dangerous into its innocuous form
    • On both input and output
  • Input:
    • Stripping: Removing harmful characters from user supplied input
    • Substitution: Replacing user supplied input with safer alternatives
    • Literalization: Using properties that render the user supplied input to be treated as a literal form
  • Output (usually by encoding):
    • HTML entity encoding (meta-characters, tags)
    • URL encoding (applied to params)
  • Need to maintain data integrity

Safe APIs

  • Top 10 threat to cloud
  • Threat modeling should identify APIs as potential entry points
  • Leveraging existing components
  • Avoid banned and deprecated APIs
  • Ascertain auth when accessing 3rd party components/admin features
  • Audit log on endpoints, admin features
  • CryptoAPI Next Generation (CNG) can be used for calls with credential
  • Legacy APIs, 3rd party APIs and privileged actions through API should be examined closely

Memory Management

  • Managed code (+intermediate code)
    • Better memory management
    • Type safety
    • Automatic lifetime control over all resources
  • Unmanaged code
    • Responsibility shared between application and OS
    • Developer responsibility: memory management, garbage collection, threading, memory overflow etc
  • Type Safety
    • Can be enforced statically at compile time or dynamically at runtime
    • Type safe code cannot access:
      • Arbitrary memory locations outside the range of memory address that belongs to the object’s publicly exposed fields
      • Memory location not authorised to
    • Buffer overflow is seen more in unmanaged non-type safe languages
    • Parametric polymorphism or Generics: allow function/data type to be written generically
    • Greatly reduced memory management issues
  • Locality of Reference (principle of locality)
    • The principlethat subsequent data locations that are referenced when a program is run areoften predictable and in proximity to previous locations based on time or space
    • Primarily to promote the reuse of recently used data and instructions
    • Temporal (or time based): the same memory locations that are recently accessed are more likely to be referenced again in the near future
    • Spatial(or space based): memory locations that are nearby recently accessed memory locations are more likely to be referenced in the near future
    • Branch: on the basis of the prediction of the memory manager, the processor uses branch predictors (such as conditional branching) to determine the location of the memory locations that will be accessed in the near future
    • Equidistant: halfway between spatial and branch locality and uses simple functions (usually linear) that look for equidistant locations of memory to predict which location will be accessed in the near future
    • Address Space Layout Randomization (ASLR): a specific memory management technique developed by Microsoft to defend against locality attacks
  • Dangling Pointers
    • Pointers which do not point to a valid object of the appropriate type in memory (memory leak)
      • References to memory locations of destroyed objects
    • Dangling pointers differ from wild pointers (used prior to being initialised)
  • Garbage Collection (de-allocate and reclaim)
    • Main goal: to reduce memory leaks
    • Non-deterministic in nature (does not mean GC will happen when it’s called, it just means GC must happen)
    • Latency issue due to lag time
      • On Apple iOS, GC is replaced by automatic reference counting (ARC)
        • Each object keeps a counter to counter how many pointers are referencing it
        • Guarantee destroyed and reclaimsed when unreachable
    • Fast death: system memory resources are exhausted due to GC going into overdrive
    • Slow death: attacker requests additional memory the GC has to invoke, but they do so at a rate that is not quite as severe to throw an out-of-memory exception
      • CPU cycles are stolen
  • Code Access Security
    • When a software is run, determine permissions, then the program will execute or throw an exception
      • Permissions determined by system setting
    • CAS prevents untrustworthy sources from having run time permissions for privileged operations
      • Also protects code from trusted sources from compromising security
    • Must be from a type-safe language
    • CAS concepts include the following:
      • Syntax Security (Declarative and Imperative)
      • Security Actions
      • Secure Class Libraries
  • Security Actions:
    • Permissions to be granted are evaluated by the runtime
    • Three categories of actions:
      • Request: to inform the runtime about the permissions that the code needs
      • Demands: to assert permissions and help protect resources from callers
      • Overrides: to override default security behavior
  • Secure Class Libraries:
    • Uses security demands to ascertain the permissions

Syntax Security (Declarative and Imperative, under CAS)

  • Declarative (what): permissions are defined as security attributes in the metadata of the code
    • Declarative security refers to defining security relations with respect to the container, such as metadata
    • Handled by a container, handled by operational team instead of development team
    • Scope (requests, demands and overrides), can be at the level of assembly, class or member
    • Main objective: make the software portable, flexible, cheaper to deploy
    • When security requests are made in the form of attributes (i.e metadata of the code)
    • Does not precisely define the steps as to how the security will be realized
    • Security rules defined outside the software code
    • All-or-nothing kind of security
    • Done by deployment, detached from development, hence design and security are independent
    • Declarative syntax actions can be evaluated without running the code
    • Declarative security actions are checks before a method is invoked and are placed at the class level, being applicable to all methods in that class
  • Imperative/Programmatic (how): implemented using new instance of the permission object inline in code
    • Programmatic security is where the security implementation is embedded into the code itself
    • Handled in the content, but makes code less portable
    • Security action of demands and overrides are possible
    • Cannot be used for requests
    • Handy when the runtime permissions are not known beforehand
    • A component managed, granular approach
    • When security requests are made through programming logic within a function or method body
    • Define security rules in componenet
    • Defined by developer
    • Not recommended if componenet re-use is a requirement (rules are customised for each components)
    • Imperative security actions are stored as Intermediary Language (IL)
    • Imperative security actions can be evaluated only when the code is running
    • Imperative security offers greater levels of granularity and control

Error Handling

  • Defines how the code should behave when errors occure
    • Exception management is the specific coding aspect of error handling
  • Two most basic/effective controls:
    • Input validation
    • Error handling
  • Controls:
    • Non-verbose error messages
    • Use an index of the value or reference map
    • Redirect errors and exceptions to a default error handling location
    • Fail secure

Exception Management

  • Exception management is the programmatic response to exceptions
    • Exception handlers: special functions in code that handles exceptions
    • e.g try-catch-finally
  • Prevent information disclosure
  • Exceptions may not necessarily be security issues, but unhandled exceptions may result in security issues
    • Unhandled issues that goes to the OS level may result in privilege escalation
  • Safe Security Exception Handler (/SAFESEH)
    • For compilation/linking
    • Provide safe exception handlers tables, write into Program Executabl (PE)
    • The table is used to verify safe exceptions by the OS
    • If the exception doesn’t match the table, process is terminated

Session Management

  • Session management: a security concept that aims at mitigating session hijacking or MITM attacks
  • Session hijacking (MITM): an attacker impersonates a valid user and interjects into the middle of an existing session, leads to:
    • Information disclosure (confidentiality threat)
    • Alteration (integrity threat)
    • Denial of Service (availability threat)

Configuration Parameters Management

  • Securing configuration parameters is an important issue when configuration can change programmatic behaviors
  • Two main configurable parameters:
    • Startup variables
    • Cryptographic keys

Secure Startup (Bootstrapping)

  • Variables and parameters need to be protected from disclosure, alteration or destruction threats
  • Secure startup prevents and mitigates side channel attacks such as the Cold Boot attack

Cryptography

  • Predominant flaws:
    • Lack of encryption of sensitive data
    • Using weak/non collision free algorithm
    • Using unproven cryptographic algorithm
    • Using older cryptographic APIs
    • Insecure and improper key management
    • Inadequate and improper storage of data
    • Insufficient access control
    • Violation of least privilege
TypeBannedAcceptable / Recommended
SymmetricDES, DESX, RC2, SKIPJACK, SEAL,
CYLINK_MEK, RC4 (<128bit)		3DES (2 or 3), RC4 (>=128bit), AES
AsymmetricRSA (<2048bit), DiffieHellman(<2048bit)RSA(>=2048bit), DiffieHellman(>=2048bit), ECC(>=256bit)
Hash (HMAC)SHA-0 (SHA), SHA-1, MD2, MD4, MD5>=SHA-2 (SHA-256, SHA-384, SHA-512)
  • Data at rest protection controls
    • Encrypting and storing the sensitive data as ciphertext
    • Storing salted ciphertext
    • Not allowing data that is deemed sensitive to cross trust boundaries
    • Separating sensitive from non-sensitive data
  • Appropriate algorithm
    • Algorithm is proven
    • Algorithm is a standard (such as the AES) and not a historically proven weak one (such as DES)
      • AES, three block ciphers, each of 128bits, key sizes 128, 192, 256
        • Rijndael cipher, the original publication of AES
      • The use of the Rijndael Managed class does not necessary comply with FIPS-197 specification for AES unless the block size and feedback size (when using the Cipher Feedback (CFB) mode) are both 128 bits
    • Older APIs (CryptoAPI) replaced with new ones (Cryptography API: Next Generation (CNG))
      • CNG can be used for non-secure environment (external internet):
        • A new cryptographic configuration system that supports better cryptographic agility.
        • Abstraction for key storage and separation of the storage from the algorithm operations.
        • Process isolation for operations with long-term keys.
        • Replaceable random number generators.
        • Better export signing support.
        • Thread-safety throughout the stack
        • Kernel-mode cryptographic API.
    • Design takes into account the ability to quickly swap cryptographic algorithms as needed
  • Cryptographic Agility
    • Cryptographic agility is the ability to manage the specifics of cryptographic function that are embodied in code without recompiling, typically through a configuration file, design level decision
    • Works better with non-persisted transient data than persisted data
      • Persisted data encrypted with an algorithm that is being replaced may not be recoverable, DoS
      • Stored the original hash as a meta data
      • Watch out for output ciphertext length
    • In some countries, certain cryptographic algorithms are not allowed to be used
  • Secure key management
    • Key is random or pseudo-random in nature
    • Exchange is done securely using out-of-band mechanisms or approved key infrastructure
    • Storage of keys is protected, preferably in a separate system
    • Rotation of the key follows appropriate process
    • Archival and escrowing of the key is protected with appropriate access control
    • Destruction of keys ensures that once the key is destroyed, it will never again be used
  • Adequate access control and auditing
    • Granted explicitly
    • Controlled and monitored using auditing and reviews.
    • Not inadvertently thwarted by weaknesses such as insecure permissions configurations
    • Contextually appropriate and protected, irrespective of whether the encryption is one-way or two-way
      • One-way: only the user or recipient needs to have access to the key, as in the case of PKI.
      • Two-way: encryption can be automatically performed on behalf of the user, but the key must be available so that plaintext can be automatically recoverable by that user

Concurrency

  • Concurrency is the process of two or more threads in a program executing concurrently
  • Concurrency is a primary property in TOC/TOU attacks
  • Controls:
    • Avoid race windows (critical sections)
      • The window of opportunity when two concurrent threads race against each other
      • Atomic operations can also help prevent race condition attacks
    • Atomic operations
      • Process is completed using a single flow of control, concurrency is disallowed
      • May impact performance
    • Mutual Exclusion (Mutex)
      • Resource locking (integrity assurance)

Tokenization

  • The process of maintaining the security of sensitive data with unique identification symbols
    • Aims at minimizing the amount a data a business needs to store while facilitating compliance with industry standards and regulations
    • e.g: credit card info protection
  • Tokenization is usually implemented as a service, provider issues the token and keep the data protected

Sandboxing

  • Security mechanism that prevents software running on a system from accessing the host OS
  • A principle of least privilege
  • Examples: Unix chroot jail, AppArmor, SELinux

Anti-Tampering (integrity protection)

  • Obfuscation
    • Making code obscure using an obfuscator so that the code is not easily readable (shrouded code)
    • Can also be used for object code, a deterrent measure to reverse engineering
  • Anti-Reversing Techniques
    • Removing symbolic information from PE
      • Remove symbolic information: class names, class member names, names of global instantiated objects
      • Remove textual information from PE by stripping them out before compilation
      • Using obfuscation to rename symbols into meaningless sequences of characters
    • Embedding anti-debugger code
      • A user or kernel level debugger detector is included as part of the code and it detects the presence of a debugger and terminates the process when one is found
      • e.g: IsDebuggerPresent API, SystemKernelDebuggerInformation API
  • Code Signing
    • Digitally signing the code with the digital signature of the code author
    • Mostly utilising public/private keys
    • Can be signed at develpment or deployment (delayed signing)
      • When signed, a hash of the code is generated and distributed together with the software
    • Important for mobile (code downloaded from a remote location)
      • eg: Java applets, ActiveX components, browser scripts, Adobe Flash, and other web controls
      • To assure proof of origin or its authenticity
      • Can also give runtime permission to access system resources
    • Avoid namespace conflicts
    • Provide version information
    • Assure the authenticity of published code

Secure Software Processes

  • Software assurance is a confluence of secure processes and technologies implemented by trained and skilled people who understand how to design, develop and deploy secure software.

Code Analysis

  • The process of inspecting the code for quality and weaknesses that can be exploited
    • Can be performed at any level, the higher level it’s done, the more complexity expected
    • Code should be inspected during development for weaknesses and vulnerabilities
  • Automated analysis has issues identifying clean, readable code. This is better done with code walkthroughs
  • Static:
    • Code inspection
    • No need to deploy
    • Source code analyzers
      • Predominantly use pattern matching against a known list of vulnerability syntax
      • Data flow/model analysis against known sets of data to detect vulnerabilities
    • Bytecode scanners
    • Binary analyzers
      • Similar to source code analyers, but use disassembly
      • Advantage: can detect vulnerabilities/inefficiencies introduced by the compiler
    • The best way to search code bases for disallowed functions in an application
  • Dynamic:
    • Dynamic analysis is performed while the software is executed.
    • To ascertain that the code is reliably functioning as expected and is not prone to errors or exploitation
    • Need a deployment environment

Code/Peer Review

  • Insecure code:
    • Injection flaws
      • Input validation
      • Dynamic queries
    • Non-repudiation Mechanisms
      • Code signing
      • Audits
    • Spoofing Attacks
      • Session identifiers are not predictable
      • Passwords are not hard-coded
      • Credentials are not cached
      • Code that allows changes to the impersonation context is not implemented
    • Errors and Exception Handling
      • Non verbose error
      • Using try-catch-finally
    • Cryptographic Strength
      • No use of weak algorithms
      • Consider agility
      • RNG and PRNG
      • No hard-coded keys
    • Unsafe and Unused Functions and Routines in Code
      • No use of deprecated APIs
      • Remove unused functions
      • Remove easter eggs, bells-and-whistles
      • Using requirements traceability matrix
    • Reversible Code
      • Debugger detectors
      • Any symbolic and textual information that can aid a reverse engineer should be removed
    • Privileged Code
      • Code that violates least privilege
      • Check for codes that require admin rights
    • Maintenance Hooks
      • Primarily provide for maintenance needs
      • A back door and allow developers access to privileged systems
    • Logic Bombs
      • Based on the logic (such as a condition or time)
      • By an insider, eg Disgruntled employees
      • It is also important to note that to deactivate a trial piece of software after a certain period of time has elapsed (the condition), which was communicated in advance, is not regarded as a logic bomb because it is nonmalicious and functions as intended.
  • Inefficient code
    • Timing and Synchronization Implementations
      • Race conditions
      • Mutex
    • Cyclomatic Complexity
      • A measure of the number of linearly independent paths in a program
      • Highly cohesive and loosely coupled code will have little to no circular dependencies
      • Economy of mechanisms and least common mechanisms
  • Code review manner:
    • Must be constructive
    • It is the code and not the coder that is being reviewed
  • Code walkthroughs are team events designed to find errors using human-led inspection of source code

Securing Build Environments

  • Important to ensure integrity
    • Physical access control
    • ACLs for logical access control
    • Version control
    • Build automation
  • Ensure legacy source code can be built without errors
  • Utilising features in the build tools to check security
  • Define safe libraries
  • Microsoft’s /GS: enables stack overflow protection in the form of a cookie to be checked at the end of the function, prior to the use of the return address
  • Libraries of safe function calls are used to address stack overflows
    • Stack overflows are best protected by compiler options that enable stack canaries or cookies
  • Packagers: Red Hat Package Manager (RPM), Microsoft Installer (MSI)
    • For easier distribution
    • Provide some degree of protection against reverse engineering
    • Obfuscate the contents of the executable
    • Malware also use this to evade signature-based malware detection

Integrated Development Environment (IDE)

  • Using IDE can eliminate a range of simple errors and allows tracking of significant metrics
  • Using IDE can help reducing time code in later SDLC

Antitampering Techniques

  • Code signing: the application of digital signature to code
    • Rests upon the established PKI
    • Provides a means of authenticating the source and integrity of code
    • Cannot ensure that code is free of bugs
    • Code signing depends upon hash functions and public key cryptography
  • Steps to Code Signing
    1. The code author uses a one-way hash of the code to produce a digest.
    2. The digest is encrypted with the signer’s private key.
    3. The code and the signed digest are transmitted to end users.
    4. The end user produces a digest of the code using the same hash function as the code author.
    5. The end user decrypts the signed digest with the signer’s public key.
    6. If the two digests match, the code is authenticated and integrity is assured.

Version (Configuration Management)

  • Ensure working with the right version of code
  • Track ownership and changes
  • Avoid regenerative bugs
  • Can use file locks to prevent two developers from making changes to the same section
    • Can also be achieved through version merge
  • eg: Visual SourceSafe (VSS), Concurrent Versions System (CVS), StarTeam, Team Foundation Server (TFS).