Secure Programs: Definition and Key Concepts

Secure Program - Definition of Secure Programs

• Secure programs are software applications designed and developed with security as a core principle
• They prioritize the CIA triad:
• Confidentiality: Preventing unauthorized access to sensitive data
• Integrity: Ensuring data is not altered or tampered with
• Availability: Ensuring systems and data are accessible when needed

Key Terminology

• Vulnerability: A weakness or flaw in a system
• Exploit: A technique that takes advantage of a vulnerability
• Threat: A potential for a malicious event to occur
• Risk: The potential impact of an exploit occurring

Defining Program Security

• Program Security includes design, development, and operational practices protecting software from vulnerabilities and attacks
• It includes protection against non-malicious errors and deliberate attacks like malware and viruses
• Program security is about preventing hacks, writing robust code to limit errors, and mitigating risk

Non-Malicious Program Errors

• Buffer Overflows: Occur when writing beyond allocated memory, potentially overwriting critical data like return addresses
• Incomplete Mediation/TOCTTOU Errors: Data is checked once, then used later without revalidation
• Logical/Boundary Errors: Small mistakes can lead to exploitable vulnerabilities
• These errors are unintentional but can be as dangerous as deliberate attacks if exploited

Deliberate Malicious Code

• Viruses: Self-replicating code that infects host files
• Worms: Stand-alone programs that replicate across networks
• Trojans: Disguised as legitimate software carrying hidden payloads
• Logic/Time Bombs: Code that triggers a payload under certain conditions

Why Program Security is Important

• It prevents unauthorized access, data breaches, and system failures
• It protects against financial losses, reputational damage, and legal consequences

Principles of Secure Programming - Least Privilege

• Programs should operate with the minimum necessary permissions
• Limits the potential damage if the program is compromised
• Reduces the attack surface by limiting access to sensitive resources
• Prevents privilege escalation attacks where attackers exploit a program to gain higher-level access
• Web servers should only access directories and files needed to serve content, not administrative privileges
• Database apps should use limited user accounts with read/write access only to necessary tables
• In Linux, the chmod command can restrict file permissions
• $ chmod 644 file.txt restricts file access to read-only for others
• In Windows, configure user accounts with specific roles (e.g., "Standard User" instead of "Administrator")

Principles of Secure Programming - Defense in Depth

• Multiple layers of security controls protect against various attack vectors
• If one layer fails, others can provide protection
• Layered defenses provide redundancy and resilience
• Firewalls block unauthorized network traffic
• Intrusion Detection Systems monitor for suspicious activity
• Encryption protects data at rest and in transit
• Access Controls restrict who can access sensitive resources
• Use firewalls, HTTPS, input validation, and software patching/updates for web applications

Principles of Secure Programming - Fail-Safe Defaults

• Default configurations should be secure, requiring explicit actions to enable less secure options
• Ensures systems are secure even if users do not change default settings
• Prevents accidental exposure of vulnerabilities from misconfigurations, encouraging secure practices
• Disable unnecessary services by default
• Enforce strong password policies by default
• Access controls should be restrictive by default
• Disable unused modules, set file permissions to 644, and disable remote access by default in web servers and databases

Principles of Secure Programming - Input Validation

• Validate all user inputs to ensure they conform to expected formats and ranges
• Prevents injection attacks like SQL injection, XSS, and command injection
• Prevents malicious inputs from being processed
• SQL Injection: Validate inputs to ensure they do not contain SQL commands
• Cross-Site Scripting (XSS): Sanitize inputs to prevent malicious scripts from being executed
• Command Injection: Validate inputs to prevent the execution of arbitrary commands
• Use regular expressions to validate input, such as in Python using the "re" module

Principles of Secure Programming - Secure Coding Practices

• Follow best practices to avoid common vulnerabilities like buffer overflows, race conditions, and insecure APIs
• Reduces the risk of exploitation
• Use safe functions like strncpy instead of strcpy in C to avoid buffer overflows
• Use synchronization mechanisms like mutexes to prevent concurrent access issues (race conditions)
• Avoid deprecated/insecure APIs in C
• Replace unsafe functions with safer alternatives
• To avoid performance problems and security concerns in Java, use StringBuilder instead of concatenating strings in loops

Non-Malicious Program Errors - Definition and Importance

• Unintentional flaws in software that can lead to security vulnerabilities
• Not caused by malicious intent but can still be exploited by attackers
• Even well-intentioned developers can introduce errors that compromise security
• These errors are often the root cause of major security breaches

Types of Non-Malicious Program Errors - Buffer Overflows

• A program writes data beyond the allocated memory space for a buffer
• This can overwrite adjacent memory, leading to crashes, data corruption, or even arbitrary code execution
• Using strcpy without checking input length is an example

char buffer[10];
strcpy(buffer, "This string is too long!"); // Buffer overflow

• Caused by unsafe functions (strcpy, gets) or lack of bounds checking
• Can lead to crashes (memory corruption), exploitation (attackers overwrite return addresses/function pointers), or data corruption
• Prevention: use safer alternatives (strncpy, snprintf), perform bounds checking, use modern languages with automatic memory management

Types of Non-Malicious Program Errors - Race Conditions

• Program behavior depends on the timing/sequence of events, like multiple threads accessing shared resources simultaneously
• Can lead to unpredictable or incorrect behavior

int counter = 0;
void increment() {
    counter++; // Race condition
}

• Caused by lack of synchronization mechanisms (mutexes, semaphores) and improper handling of concurrent operations
• Impact: Data corruption, security vulnerabilities (attackers can exploit race conditions for unauthorized access), unpredictable behavior
• Prevention: use synchronization mechanisms, avoid shared resources where possible, use thread-safe data structures/libraries

Types of Non-Malicious Program Errors - Input Validation Errors

• Program fails to properly validate user input, allowing malicious/unexpected data to be processed
• Can lead to injection attacks (SQL injection, XSS, command injection)

username = input("Enter your username: ")
query = f"SELECT * FROM users WHERE username = '{username}';"
## If username is "admin' --", the query becomes:
## SELECT * FROM users WHERE username = 'admin' --';
## This bypasses authentication.

• Causes: trusting user input without validation/sanitization, using dynamic queries/commands without parameterization
• Can lead to data breaches, system compromise, or reputation damage
• Prevention: validate/sanitize all user inputs, use parameterized queries/prepared statements (to prevent SQL injection), and implement input whitelisting

Types of Non-Malicious Program Errors - Insecure Default Configurations

• Software is shipped with settings that leave systems vulnerable
• Defaults may include unnecessary services, weak passwords, or excessive permissions
• A web server with unnecessary services enabled by default is an example
• Database using default username/password is also vulnerable
• Caused by lack of security awareness during software development or prioritizing ease of use over security
• Can lead to unauthorized access, system compromise or data exposure
• Prevention: disable unnecessary services/features by default, enforce strong passwords/access controls, and provide clear documentation for securing the software

Impact of Non-Malicious Errors

• Exploitation by Attackers: like buffer overflows can be exploited to execute arbitrary code
• System Crashes: like race conditions can cause programs to crash or behave unpredictably
• Data Corruption or Loss: improper input validation can lead to data corruption or loss

Case Studies - Ariane 5 Rocket Failure (1996)

• A software error (integer overflow) in the guidance system caused the rocket to self-destruct 37 seconds after launch
• Root Cause: A 64-bit floating-point number was converted to a 16-bit signed integer
• Resulted in the loss of the rocket and its payload, costing over $370 million
• Lessons Learned: Importance of thorough testing/error handling and need to validate all inputs/handle edge cases

Case Studies - Heartbleed Vulnerability (2014)

• A bug in the OpenSSL library allowed attackers to steal sensitive data from servers
• Root Cause: Lack of input validation in the heartbeat extension
• Impact: Exposed sensitive data from millions of websites
• Lessons Learned: Importance of secure coding practices/third-party library management and thorough security testing

Identifying and Fixing a Buffer Overflow Vulnerability

• To identify and fix a buffer overflow vulnerability modify the C program

#include <stdio.h>
#include <string.h>

void vulnerable_function(char *input) {
    char buffer[10];
    strcpy(buffer, input); // Potential buffer overflow
    printf("Buffer: %s\n", buffer);
}

int main() {
    char input[20];
    printf("Enter input: ");
    gets(input); // Unsafe function
    vulnerable_function(input);
    return 0;
}

• Compile and run the program, entering longer than 10 characters triggers the buffer overflow
• Can be fixed by modifying the code to use strncpy instead of strcpy to prevent the overflow

strncpy(buffer, input, sizeof(buffer) - 1);
buffer[sizeof(buffer) - 1] = '\0'; // Ensure null termination

• Recompile and test the program to verify the fix

Malicious Code - Definition and Types

• Software designed to harm, exploit, or compromise systems like viruses, worms, trojans, ransomware, and spyware
• Understanding how it works is critical for developing effective defenses, because it can lead to data theft, system damage, financial losses, and privacy violations
• Viruses: Self-replicating programs that attach to legitimate files/programs, spread through user actions (opening infected email attachments)
• Worms: Self-replicating programs that spread over networks without user intervention, the ILOVEYOU worm spread via email in 2000
• Trojans: Malware disguised as legitimate software, e.g., a fake game installer that installs a backdoor
• Ransomware: Encrypts files and demands payment for decryption, WannaCry ransomware (2017) affected hundreds of thousands of systems
• Spyware: Collects user data without consent, e.g., keyloggers capture keystrokes to steal passwords

How Malicious Code Spreads

• Social Engineering: Tricking users into executing malicious code (e.g., phishing emails)
• Exploiting Vulnerabilities: Using software flaws to gain access (e.g., buffer overflows, unpatched systems)
• Network Propagation: Spreading through shared drives, email, or network vulnerabilities
• Removable Media: Infecting systems via USB drives or external devices

Targeted Malicious Code - Definition

• Software designed to exploit vulnerabilities in a particular system, organization, or user
• Focuses on specific environments, often with the intent to cause maximum disruption or extract sensitive information without detection
• Attacks are usually well-researched, customized, and difficult to defend against due to their specialized nature

Characteristics of Targeted Malicious Code

• Precision: Specifically designed to target certain hardware, software, or networks
• Advanced Evasion Techniques: Uses sophisticated methods to bypass security measures
• Minimal Collateral Damage: Limits its spread to avoid detection and minimize unintended consequences
• Complex Payloads: Often includes payloads designed to steal data, disrupt processes, or create backdoors for future access

Examples of Targeted Malicious Code - Stuxnet

• Targeted Siemens PLCs used in Iran's uranium enrichment facilities
• Spread via infected USB drives and propagated within isolated networks
• Caused physical damage by altering centrifuge rotation speeds, delaying Iran's nuclear program
• Highlighted the potential of cyberattacks to cause real-world physical damage

Examples of Targeted Malicious Code - Pegasus

• Targeted iPhones and Android devices, particularly high-profile individuals
• Exploited vulnerabilities in Apple's WebKit engine and messaging apps to gain unauthorized access
• Allowed remote surveillance of calls, messages, location, and encrypted apps like WhatsApp and Signal

Examples of Targeted Malicious Code - Code Red II Worm

• Targeted Microsoft IIS web servers
• Exploited buffer overflow vulnerabilities to gain remote control of infected systems
• Created backdoors, enabling attackers to access and control servers, disrupting websites and data services

Examples of Targeted Malicious Code - APT (Advanced Persistent Threats)

• Targeted government agencies, corporations, and critical infrastructure
• Prolonged, stealthy attacks using malware, social engineering, and zero-day exploits
• Compromised sensitive data, disrupted operations, and enabled long-term surveillance

Control Against Program Threats - Data and Instructions Separation

• Separating data from executable instructions prevents unauthorized code execution
• Malicious code embedded in data files cannot be executed
• LOCK System: Programs are treated as "data" after compilation and cannot be executed until certified, modification reclassifies it as data
• UNIX Variant: Files with execute permissions are treated as executable, modifying an executable file removes its permissions
• Reduces the risk of malware infection

Control Against Program Threats - Containment

• Limits the objects and resources accessible to a process
• Reduces the potential damage if malicious code is executed
• Confining processes to specific environments prevents unauthorized access to sensitive data
• Sandboxing: Runs programs in isolated environments, limiting access to system resources/applications, limits impact if code is executed within a sandbox
• Virtual Machines (VMs): Isolate operating systems, preventing malware from affecting the host system, cannot escape to compromise other systems

Control Against Program Threats - Mandatory Access Controls (MAC)

• Enforces strict control over system resources, ensuring that users/processes can only access permitted objects
• Prevents unauthorized modification of system components, reducing malware risks
• Multilevel Security Policies: Programs are placed at the lowest possible security level, and users cannot access/alter system files unless explicitly authorized
• Trusted Solaris Model: Ensures that executables cannot be modified by user applications, maintaining system integrity
• Effective against malware that attempts to modify system files or gain elevated privileges

Control Against Program Threats - Proof-Carrying Code (PCC)

• Ensures that only code proven to adhere to specific safety properties is executed
• Process: The code producer includes a formal proof that the code complies with predefined security policies, the code consumer verifies this. This method prevents unauthorized/unsafe code from running
• Eliminates runtime checks, improves performance, ensures code cannot violate safety properties
• Effective for systems requiring high assurance of code safety (embedded systems and critical infrastructure)

Control Against Program Threats - Statistical Analysis

• Identifies anomalies that may indicate malicious code by monitoring system behavior and comparing it to established baselines
• Identifies unexpected increases in file size/writes to executable files, unusual patterns of system calls/network activity or conditional branches/code blocks not in the source code
• Machine learning models can identify deviations that indicate malware and statistical models can detect patterns associated with specific types of malware
• Essential for detecting zero-day exploits and targeted malicious code