A Red Team Guide for a Hardware Penetration Test
Part 2: Using security risks from the Modern Open Web Application Security Project to help hack hardware
This blog serves as a guide to helping demystify some of the bugs and issues discovered during hardware assessments. I’ve shared some of the lessons learned from years of applied logic, and reason to find problems that do not exist. This blog maps loosely some OWASP web application risks to hardware vulnerabilities, from a red team perspective.
Some may find the guide below more useful, for IOT based controls, and not generalized hardware assessments.
I cover some other general ways to assess IOT devices , in my previous article:
1. Broken Authentication. Application functions related to authentication and session management are often implemented incorrectly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users’ identities temporarily or permanently.
By using the hash of another user, one could use that stored hash as a substitute for an admin’s password. After retrieving the admin hash, the user has “root” access to the device.
Broken Access Control Summary:
OWASP Top 10 Web Application Security Control: Broken Access Control
Red Team Technique: Leveraged: The Red team technique used was Pass the hash. The P-T-H technique is covered in my article below.
Any user could use the stored hash of an admin user — similar to the Windows attack. This thought pattern came from my days of a penetration testing Windows, since passing the hash is a common technique used, but not usually during the assessment of networking gear.
2. Injection. Injection flaws, such as SQL, NoSQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization.
By changing parameters passed to a cli program, you can often use diagnostic utilities; ifconfig, ping, or tcpdump to interact outside your jailed or sandboxed environment.
Injection Summary:
OWASP Top 10 Web Application Security Control: Injection
Red Team Technique: Leveraged: The Red team technique used was the same as any other assessor — lateral thinking. By fuzzing parameters it was possible to abuse diagnostic utilities, like ifconfig and tcpdump and “inject” commands to interact with the underlying operating system.
3. Forced Browsing is an attack where the aim is to enumerate and access resources that are not referenced by the application, but are still accessible.
An attacker can use Brute Force techniques to search for unlinked contents in the domain directory, such as temporary directories and files, and old backup and configuration files. These resources may store sensitive information about web applications and operational systems, such as source code, credentials, internal network addressing, and so on, thus being considered a valuable resource for intruders.
This attack is performed manually when the application index directories and pages are based on number generation or predictable values, or using automated tools for common files and directory names.
This attack is also known as Predictable Resource Location, File Enumeration, Directory Enumeration, and Resource Enumeration.
Forced Browsing Summary:
OWASP Top 10 Web Application Security Control: Injection
Red Team Technique: Leveraged: The Red team technique used was the same as any other assessor; attempt to leverage a known weakness, to access sensitive information.
Security Misconfigurations
This is the most commonly seen issue, across all devices and assets alike. This is commonly a result of insecure, or default configurations, incomplete or ad hoc configurations, open cloud storage, misconfigured HTTP headers, and verbose error messages containing sensitive information. Not only must all operating systems, frameworks, libraries, and applications be securely configured, but they must be patched/upgraded in a timely fashion.
Many “security” devices don’t follow best security practices.
TL;DR Sometimes you may not need to decap a chip; all you need is a keyboard, a monitor, and direct access to the underlying hardware.
