-
Notifications
You must be signed in to change notification settings - Fork 0
Security and Exploitation
DJShepherd edited this page Mar 12, 2024
·
21 revisions
- 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 (PUF) - 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)
- Control Flow Integrity - Wikipedia
- Pointer signing
- Canaries/cookies - Wikipedia
- Checkpoint systems
- Shadow stack - Wikipedia
- Valid jump/code flow lookup tables
- Defenses: (Reference: CFI)
- Return-oriented programming - Wikipedia
- Return-to-libc attack - Wikipedia
- Return to libc - Geeks for Geeks
- Jump-Oriented Programming - Grades Fixer
- NOP Slide
- 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)
- Type confusion
- 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
- Unprotected/unsigned external input
- 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 ifresult == 0).
-
Timing attack - Wikipedia
- 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)
- Defenses:
- 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
- Tunable 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
- Undefined behavior sanitizer (UBSAN, etc)
- Fuzzing
- CI/CD, build/automation pipelines
- 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
- Attestation concepts
- Evading detections/forging attestation responses
Different products have different security objectives and you should understand how to analyze what areas to focus on hardening (or attacking). For example here are some objectives that hackers may attempt:
- Video game console:
- Custom firmware
- Game and content/DLC piracy
- Game cheating
- Generic IoT/Smart device:
- Use as entry to traverse the network and compromise other devices
- Network monitoring, data stealing
- Botnet/crypto mining
- End user GPU:
- (user) Use locked features or use device in unintended ways
- (user) Bypass anticheat engines
- (malware) Backdoor I/O to elevate privilege
- Cloud GPU:
- Compromise user data
- Compromise confidential compute environments