Attacks

• Attacks
  • Why this matters
  • The attack surfaces
  • Vulnerability classes you should expect
    • Credentials
    • Authentication logic
    • Update mechanisms
    • Debug and diagnostic interfaces
    • Memory corruption, and why it is worse here
    • Cryptographic failures
  • Physical attacks
    • Fault injection
    • Side channels
  • Evaluating against a baseline
  • Writing it up
    • Depth beats breadth
    • Report what you did not find
  • Coordinated disclosure
  • Key takeaways
  • References

Why this matters

The rest of this course teaches techniques one at a time: find the UART, decode the bus, dump the flash, load it in Ghidra. This page is about how they compose into an assessment, what vulnerability classes you should expect to find, and how to say something defensible about what you found.

It is also where the course connects to the standards a real report gets measured against — because “I got a root shell” is a demonstration, and “this device fails ETSI EN 303 645 provision 5.1-1” is a finding.

⚠️ Scope and authorization. Everything here applies to hardware you own or hardware the course provides. Attaching a logic analyzer to someone else’s device, decoding someone else’s radio traffic, or extracting firmware from a device you do not own ranges from a licence-agreement violation to a federal crime depending on the device and jurisdiction. Ask before you probe.

The attack surfaces

The OWASP IoT Security Testing Guide decomposes a device into surfaces, and its model maps almost one-to-one onto this course:

Structuring a report around these demonstrates coverage rather than asserting it, which is the difference between a finding list and an assessment.

Vulnerability classes you should expect

These are not exotic. They recur across vendors, price points, and decades.

Credentials

The last one is worth dwelling on. Vendors rotate what a password-policy audit checks. The hardcoded account is in the code, and nobody’s checklist covers it.

Authentication logic

• Comparison-length bugs — taking the length from the attacker-supplied string rather than the stored secret, so any prefix authenticates.
• Timing side channels — a comparison that returns on the first differing byte leaks the matching prefix length.
• Client-side enforcement — the web UI hides the admin page; the endpoint behind it does not check.
• Authentication that is not authorization — any logged-in user can call any endpoint.

Update mechanisms

The highest-value finding class in IoT, because it is remotely reachable and compromises every unit at once:

• Unencrypted transport. Firmware over plain HTTP.
• Unsigned images. No signature at all.
• Integrity mistaken for authenticity. A CRC32 or a SHA-256 in a manifest fetched over the same unprotected channel. An attacker who can modify the image modifies the digest too. This is the single most common conceptual error in student reports.
• Signature checked but ignored. Verification runs, failure is logged, boot continues.
• No rollback protection. Downgrade to a version with a known bug.

Debug and diagnostic interfaces

• Unlocked JTAG/SWD.
• A serial console with a root shell, or an interactive bootloader.
• Diagnostic commands left in shipping builds — an unbounded memory read, a shell escape, a hidden factory menu.
• telnetd started at boot “for support”.

Memory corruption, and why it is worse here

Stack overflows, off-by-ones, missing bounds checks, format strings — the classic set from Memory Corruption. What changes is the consequence.

On a no-MMU RTOS, any memory corruption bug is total compromise. There is no privilege boundary to cross, no ASLR, frequently no stack canaries, and the mitigations you rely on elsewhere simply do not exist. A stack overflow in a FreeRTOS network task is game over in a way it has not been on desktop Linux since roughly 2004.

Cryptographic failures

• Keys stored in flash you can read.
• A key derived from a device identifier the device broadcasts.
• ECB mode, revealing structure in ciphertext.
• Custom ciphers. Always a finding.
• No replay protection — see Radio.

Physical attacks

Beyond reading interfaces, two classes need dedicated hardware and are worth knowing even if you never perform them.

Fault injection

Deliberately inducing hardware faults — voltage glitches, clock glitches, electromagnetic pulses — to make a processor skip or corrupt an instruction at a chosen moment. It defeats software checks that are otherwise sound, which makes it the standard answer to a locked debug port or a signature check you cannot bypass logically.

The mechanism: a protection check is a branch. Glitch the supply rail during that branch and the comparison may produce the wrong result, or the branch may not execute at all. Success rates are typically low per attempt and it does not matter, because attempts are cheap and automatable.

The course kit has a ChipWhisperer Lite and a Faultier. This is the Project C final-project option.

Side channels

Recovering secrets from physical measurements rather than from the computation’s output:

• Power analysis. Simple (SPA) reads the trace directly; differential and correlation analysis (DPA/CPA) recover keys statistically across many traces. A software AES implementation with no countermeasures falls to CPA with a few thousand traces.
• Timing. Non-constant-time comparisons, exploitable remotely when the signal exceeds the noise.
• Electromagnetic emissions. Power analysis without touching the power rail.

Evaluating against a baseline

Findings are more useful when they are measured against something. Three documents define what “reasonably secure” means for consumer IoT, and any makes a defensible report structure.

ETSI EN 303 645 — the European consumer IoT baseline. Thirteen outcome-focused provisions: no universal default passwords, a vulnerability disclosure policy, keep software updated, securely store sensitive security parameters, minimise exposed attack surfaces. Outcome-focused means testable, which is what makes it useful to an assessor rather than only to a lawyer.

NIST IR 8259A — the US device-capability core baseline, aimed at manufacturers. Six capability areas: device identification, device configuration, data protection, logical access to interfaces, software update, and cybersecurity state awareness.

OWASP IoT Security Testing Guide — a testing methodology rather than a requirements list, decomposing the device into the surfaces tabulated above and specifying test cases per surface.

The older OWASP IoT Top 10 (2018) remains widely cited and is a reasonable vocabulary for describing findings, but it is a risk list rather than a methodology and has not been revised in some years. Prefer the ISTG for structuring actual testing.

Writing it up

A finding that cannot be reproduced is an anecdote. Each one needs:

1. What. One sentence, specific. Not “weak authentication” but “the password comparison uses the supplied string’s length, so any prefix authenticates”.
2. Where. File, offset, function, or interface. Address if you have it.
3. How to reproduce. Enough for a competent reader with the same hardware.
4. Impact, argued. What can an attacker do, from what position? “Remote unauthenticated” and “physical access plus an hour” are very different.
5. Severity, justified. Against stated criteria, not asserted.
6. Remediation, priced. What to change, and what it costs the vendor in engineering effort and field risk. Recommendations that ignore cost are not recommendations.

Depth beats breadth

Twelve superficial findings are weaker than four with one taken all the way down to the instruction that causes it. This is stated in the final project rubric and it reflects how assessment reports are actually read: a client skims the list and reads the one finding that proves you understood their device.

Report what you did not find

“Debug port present but locked; confirmed by X; did not pursue fault injection” is a finding about the device’s security posture. Silence is not. A stage that produced nothing still needs its method documented, or the reader cannot tell whether you looked.

Coordinated disclosure

If you find something real in a device you do not have permission to break:

1. Check for a published policy. A security.txt at /.well-known/, a bug-bounty page, a security contact in the manual.
2. Report privately first, with enough detail to reproduce.
3. Agree a timeline. 90 days is the common default.
4. Have a plan for non-response, because non-response is the common case for consumer IoT vendors. CERT/CC will coordinate on your behalf.

For anything found in this course, talk to the instructor before contacting a vendor. The technical work is the easy part; the rest benefits from institutional backing.

Key takeaways

• Structure assessments around the ISTG surfaces — it demonstrates coverage rather than asserting it.
• The recurring vulnerability classes are credentials, authentication logic, update mechanisms, debug interfaces, memory corruption, and crypto misuse.
• Integrity is not authenticity. A CRC or an unsigned hash over an unprotected channel stops corruption, not an attacker.
• On a no-MMU RTOS, memory corruption is immediate total compromise — the mitigations you rely on elsewhere are absent.
• Fault injection defeats logically sound checks, which is why a locked debug port is not the end of the story.
• Measure findings against ETSI EN 303 645 or NIST IR 8259A; “fails provision X” travels further than “I got a shell”.
• Depth beats breadth, and a documented negative result is a real result.

References

• OWASP IoT Security Testing Guide — https://owasp.org/www-project-iot-security-testing-guide/
• OWASP Internet of Things Project — https://owasp.org/www-project-internet-of-things/
• OWASP Firmware Security Testing Methodology — https://github.com/scriptingxss/owasp-fstm
• OWASP IoTGoat, deliberately vulnerable firmware — https://github.com/OWASP/IoTGoat
• ETSI EN 303 645, Cyber Security for Consumer IoT — https://www.etsi.org/deliver/etsi_en/303600_303699/303645/
• NIST IR 8259A, IoT Device Cybersecurity Capability Core Baseline — https://nvlpubs.nist.gov/nistpubs/ir/2020/NIST.IR.8259A.pdf
• NIST Cybersecurity for IoT Program — https://www.nist.gov/itl/applied-cybersecurity/nist-cybersecurity-iot-program/resources
• CERT Guide to Coordinated Vulnerability Disclosure — https://www.sei.cmu.edu/library/the-cert-guide-to-coordinated-vulnerability-disclosure/
• security.txt (RFC 9116) — https://www.rfc-editor.org/rfc/rfc9116.html
• ChipWhisperer documentation — https://chipwhisperer.readthedocs.io/
• Faultier — https://1bitsquared.com/products/faultier
• IACR CHES, hardware and embedded security research — https://ches.iacr.org/

Related course pages: Schedule · Final Project · Software RE · Dumping flash · Radio · JTAG and SWD · Threat Modeling · Memory Corruption

🛠️ Maintenance note: the baselines move slowly but they do move — ETSI EN 303 645 and the NIST IR 8259 series are both worth re-checking for revisions each offering, and the OWASP IoT Top 10 has been due an update for several years. The vulnerability classes themselves have been stable for a decade and are unlikely to need revision; the examples illustrating them will date faster than the classes do.