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.

Follow me @W00tock and please check out Part 2.

--

--

--

Adam is a offensive security engineer and red team operator with over 20 years of experience in IT

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

How A VPN Help Us to Protect Our Privacy?

In-Depth Analysis of SpaceDEX-Innovative Layer 2 Solution DEX Protocol

John Casper is the Co-Founder of TQZ and SpaceDEX

{UPDATE} Machine Operators Hack Free Resources Generator

Hacking the CSSLP part 2: Risk Management

FREEBITCO.IN MULTIPLY STRATEGY (Fast Earning)

Working Netflix Cookies #1 Hourly Updated

Weekly Development Update

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Adam Toscher

Adam Toscher

Adam is a offensive security engineer and red team operator with over 20 years of experience in IT

More from Medium

Reading Hackable Without a Background in Security

Deploy the ELK Stack (Part 1)

What is Apache Log4J Vulnerability and How to Prevent It?

Log4j Vulnerability

HackMyVM — Corrosion3