Security and Exploitation

Secure boot, Chain of Trust

A secure boot architecture is a general concept with different implementations per chip vendor, platform requirements, etc based around the Chain of Trust methodology
- Without an HSM, a physical device cannot be truly secure. If HW cannot authenticate and control boot software, an attacker can create their own malicious boot software for the device.
eFuse
- Anti-rollback
- Efuse - Wikipedia
Standard/proper crypto practices
- Storage of secrets (eFuse, One Time Programmable memory (OTP), baked in silicon, hardware crypto engines + key store, etc)
- Key generation practices
- Physical Unclonable Function - Wikipedia
Secure initialization concepts (sensitive info clearing, lockdown of dangerous devices, etc)
- Each boot stage (BootROM, BootLoader 1, 2, etc) should clear any sensitive data that is not necessary for other stages and lock down/disable access to components/devices/HW that are not needed ASAP
Secure the Windows boot process - Windows security | Microsoft Docs
Secure Boot and Trusted Boot - Windows security | Microsoft Docs
Secure Boot and Chain of Trust - KOAN (koansoftware.com)

Exploit type heavily depends on the context of the buggy code
- Fault/DDoS
- Arbitrary read/write
- Code execution
Buffer overflows
- Different usage/vulnerabilities that usually result from heap vs stack
- Memory massaging
Integer bugs
- Usually results in buffer overflows or arbitrary read/write
- Overflow/underflow
- Off-by-one
Use After Free (UAF)
- Dangling Pointer - Wikipedia
Type confusion
- Understanding Type Confusion Vulnerabilities - CVE-2015-0336 - Microsoft
Race conditions

Insecure handling of key material
- Insecure key storage
- Reusing or constantly defining key parameters that are meant to be randomized
- Insecure RNG when generating key parameters
Insecure crypto operations
- Algorithms vulnerable to timing attacks or side channel analysis
- Rolling out custom encryption/authentication protocols/systems instead of using proven methodologies

Crypto keys/material
Authentication credentials/passwords
Pointer leak
- Can lead to ASLR defeat by revealing the randomized base address, allowing attackers to create ROP/JOP chains
DMA controllers
- Can read/write wherever it has access to. In other words, if the IO controller has unrestricted access (or poor restrictions), attackers can leverage it to read/leak sensitive information or inject data/code into other parts of the system.
Insecure data
- Unprotected/unsigned external input
  - User input
  - User files (images, documents, etc)
  - Serial bus
  - Network/socket
- Unencrypted memory
Side channel attacks
- Indirect observations can be used to infer/derive crypto secrets
- Insecure compare functions (memcmp, strcmp, etc) vs const time compare
  - Timing attack - Wikipedia
    The Wiki example (as of writing) for constant time compare uses boolean logic to update the result
    (result &= a == b)
    to return a true/false statement. You can, alternatively, use bitwise operations
    (result |= a ^ b)
    to test equality
    (equal if result == 0).
- Power analysis
  - Defenses:
    - CPU workload randonmness/noise
    - Internal shielding to prevent electric noise leakage
  - Youtube - RSA Power Analysis Side-Channel Attack - rhme2
  - Youtube - Breaking AES with ChipWhisperer - Piece of scake (Side Channel Analysis 100)
- Speculative execution attacks

Defenses
- (Reference: CFI)
- Software read/write and compare redundancy
- Software random delays and/or varying clock speed
- Prefer halt/fault/infinite loop instead of NOP/NULL for padding out chunks of code/text
- Default "closed" (locked out/unprivileged) state, reset/error out to closed/locked state
- Phase Locked Loops (PLL's) can detect faults when it causes it to come out of locked state
- Compare local clock to high frequency external clocks
- Optical/Light Sensors in package can detect decapsulation
- In-chip UVLO (undervoltage lockouts) or Brown-out Detection (BOD) circuitry
- Turnable Replica Circuits (TRC's)
- Dual CPU execution units and compare
Youtube - Hardware Power Glitch Attack (Fault Injection) - rhme2 Fiesta (FI 100)
Youtube - exide: Glitching For n00bs
Youtube - Implementing Practical Electrical Glitching Attacks
Youtube - REcon 2015 Glitching and Side Channel Analysis for All (Colin o Flynn)
Software-Based Fault Injection Countermeasures (Part 2/3) – NCC Group Research
Alternative Approaches for Fault Injection Countermeasures (Part 3/3) – NCC Group Research

Binary reversing
- Getting familiar with standard tools (Ghidra, IDA, Hopper, etc)
- Techniques/tricks/tools that help with reversing like decompiler, analysis, debugging, etc
- Obfuscation techniques
  - TODO...
Basic board design
- Component identification
- Identifying chips and what their role may be
Extracting binaries
- Exploit => injected code => serial/com channel
- Intercepting traffic from insecure com channel
- Dumping flash chips

Automation tooling is not a fast fix solution. While blindly throwing tools at software can yield some results, the best results come from consideration of threat models, high-risk software components, pros-cons of different automation tools, etc in order to precisely test the security promises and entry points of the system.
Static/dynamic analysis
- CodeQL
- Valgrind
Undefined behavior sanitizer (UBSAN, etc)
- gcc -f sanitize option (undefined, etc)
- Clang UndefinedBehaviorSanitizer
Fuzzing
CI/CD, build/automation pipelines
- Azure Pipelines
Emulation
- QEMU
- Unicorn
- Capstone

Identifying potential entry points
- Protocol/peripheral exploitation (USB, network stack, etc)
- Custom/patched firmware
  - Running custom/unsigned FW (non-secure boot, glitching, etc)
  - Runtime patching vs persistent file patching
- Malicious/crafted files/payloads
- User space application/web browser vulnerabilities
  - Insecure deserialization
  - XML External Entities (XXE)
- External web service vulnerabilities
  - XSS
  - Payloads/files from compromised services
Chaining vulnerabilities in different software components to traverse the system/elevate privileges