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.
CVE security vulnerability database. Security vulnerabilities, exploits, references and more
CVSS Score Number Of Vulnerabilities Percentage Total 121994 Weighted Average CVSS Score: 6.6 922 899 4793 4456 27009…
“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?
JTAG Explained (finally!): Why "IoT" Makers, Software Security Folks, and Device Manufacturers…
Imagine you are handed this device and asked to get root on it as quickly as possible. No further information is given…
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
Binwalk is a fast, easy to use tool for analyzing, reverse engineering, and extracting firmware images. More…
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.
How to break out of restricted shells with tcpdump
During security assessments we sometimes obtain access to a restricted shell on a target system. To advance further and…
- 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.
Pass the hash
In cryptanalysis and computer security, pass the hash is a hacking technique that allows an attacker to authenticate to…
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.