A Red Team Guide for a Hardware Penetration Test: Part 1
When looking at different routing and networking technology it’s easy to be overwhelmed, with how to assess an embedded device. I like many other penetration testers and red teamer’s, did not feel I was capable of finding any 0-days or bugs in such fortified devices. Well sometimes just because a device is made by a cyber security company, doesn’t guarantee it’s by any means it’s secure.
OSINT, read about the device. Find the https://fccid.io information and try to understand the devices basic makeup. Look at the devices model, and it’s software. Study the latest publicly disclosed vulnerabilities from that vendor, and products in the same category. Look at CVE information, and carefully read through previous release notes, etc.
“Quick smash and grab /what to look for”
What kind of cpu architecture — Is it ARMs, or MIPS? This becomes more important as you try and modify an actually binary itself…
Are there JTAG ports, COM, or SPI interfaces? Check the actual device itself : — can you connect some kind of display, a keyboard perhaps?
Firmware/Software — Most likely, you’ll find/get the firmware one way or another. Some companies encrypt, and obfuscate the firmware or required a vetted account. For a formal assessment you may ask the vendor for the code and manually review the code base for common deviations from security best practices
Firmware can be decompiled and analyzed manually or dynamically sometimes providing key insights into the nature of the device itself. Used in conjunction with active testing, this information may provide keen insights thar help an assessor find a bug in the code.
Common bugs to hunt for on hardware devices:
- Initial boot-up: — Does the device have a a recovery mode, or can you interrupt it’s initial boot up.
- Web based: Forced browsing/CSRF/SSRF/XSS: — You may as an admin have access to diagnostic information, that can be accessed by anyone on the WAN segment.
- CLI injection: Jail escapes from sandboxed environments
- Abuse of diagnostic utilities: tcpdump, etc.
- Improper delegation and handing of default admin/root credentials — Can you somehow get the default root password from a file on the device?
- Lack of proper user rights assignments — Can a non administrator gain access to parts of the system not intended?
- Lack of hardware proper device hardening — you may be able to connect a usb keyboard, or a third party
In closing, using the decades of experience many red team members have, it’s possible to use this very same information and lateral thinking to help one assess a hardware device.
Sometimes techniques used such as pass the hash, may work with a hashed password on a router, recovered from a configuration file.
The same lateral thinking, applies to hardware and software assessments just as it does during a penetration test — external, or red team.When where you’re given certain variables and scope: and must stay within the rules of engagement - the same is true with an IOT/embedded device.
