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
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

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
Indirect observations/side channels
- 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).
Side channel attacks/power analysis
- Observations can be used to infer/derive crypto secrets
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 analysis
Undefined behavior sanitizer (UBSan, etc)
Fuzzing
Emulation

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