Home / Attacks & tests / Device application vulnerabilities
3 test cases
Device application vulnerabilities
This category examines the software running on the device as software: the services it exposes, the memory safety of the code handling input, and what a caller who reaches one of those services can become.
What an attacker is trying to achieve
The attacker wants code execution on the device, or the privilege the device's own software holds. Embedded software frequently runs with no privilege separation at all, so reaching any service often means reaching everything.
Test cases
3 test cases in this category. Each states what the test proves, how it is carried out, what has to be in place beforehand, what a positive result looks like, and whether the work is manual, automated or a mixture.
IOT-APP-01 Memory Corruption in Device Services
Objective — Determine whether the services the device exposes mishandle input in ways that corrupt memory, given that most embedded code is written in memory-unsafe languages without the mitigations desktop systems apply.
How it is tested — Enumerate the listening services and, for each, submit oversized and malformed input to every field the protocol defines, including length declarations inconsistent with content. Observe the device through a console for crashes and restarts rather than relying on the network response. Correlate any crash against the handling code recovered from the firmware, and establish whether mitigations are compiled in at all.
Prerequisites — A device on an isolated segment; console access for crash observation; the firmware image and a disassembler; authorisation to crash the device.
Indicators — A service crashing or restarting on malformed input; a declared length trusted without reconciliation; no stack protection or address randomisation in the binaries; the device rebooting under test.
Coverage — CWE-787CWE-120
Depth — Manual Confirmation depends on observing the device itself, since a crashed embedded service often simply stops answering.
IOT-APP-02 Vulnerable Exposed Services
Objective — Establish which services the device exposes, whether each is required, and whether any carries publicly known defects or default access.
How it is tested — Enumerate every listening port across every interface the device offers, including those active only during setup or after a reset. Identify the software and version behind each and compare against published advisories. Establish which services are needed for the device's function and which are present because the platform enabled them. Test each for unauthenticated access and default credentials.
Prerequisites — A device on an isolated segment; the firmware image for version identification; advisory data; the ability to observe the device in setup and post-reset states.
Indicators — Administrative or diagnostic services listening; a component version with a published advisory; a service reachable without authentication; services active that the device's function does not require.
Coverage — V14.2.1CWE-1104CWE-1327
Depth — Hybrid Port and version enumeration automate; judging which services the device actually needs does not.
IOT-APP-03 Privilege Escalation on the Device
Objective — Determine what a caller who reaches one service can become, and whether the device separates privilege at all.
How it is tested — Establish from the firmware which user each service runs as and how processes are separated. Where access to the device is obtained, attempt to reach the highest privilege through writable executables and configuration, unquoted or relative paths in startup scripts, permissive file permissions, and services running as the highest-privileged account unnecessarily. Establish whether any credential recovered from one service grants access to another.
Prerequisites — The firmware image; interactive access to the device, whether through a console or a service; authorisation to modify the device's state.
Indicators — Services running as the highest-privileged account; world-writable executables or configuration in the image; no separation between processes; a credential reused across services.
Coverage — CWE-250CWE-269
Depth — Manual Requires access to the device first; the finding is what that access becomes.
What we need from you
A device on an isolated network segment; the firmware image for correlating observed services against their implementations; a serial console or equivalent for observing crashes; and authorisation, since confirmation may render the device inoperable.
Standards this category maps to
Every identifier below is quoted from the published control list it belongs to. Where a test has no defensible mapping, none is given rather than an approximate one.
- CWE-787 — Out-of-bounds Write
- CWE-120 — Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
- V14.2.1 — Verify that all components are up to date, preferably using a dependency checker during build or compile time.
- CWE-1104 — Use of Unmaintained Third Party Components
- CWE-1327 — Binding to an Unrestricted IP Address
- CWE-250 — Execution with Unnecessary Privileges
- CWE-269 — Improper Privilege Management
Tell us what the system does and what worries you.
If a penetration test is not what you need yet, we will say so.