Skip to content

Latest commit

 

History

History
92 lines (58 loc) · 6.11 KB

uuid-insecurities.md

File metadata and controls

92 lines (58 loc) · 6.11 KB
Raw

UUID Insecurities

{% hint style="success" %} Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks
{% endhint %}

Basic Information

Universally Unique Identifiers (UUIDs) are 128-bit numbers used to uniquely identify information in computer systems. UUIDs are essential in applications where unique identifiers are necessary without central coordination. They are commonly used as database keys and can refer to various elements like documents and sessions.

UUIDs are designed to be unique and hard to guess. They are structured in a specific format, divided into five groups represented as 32 hexadecimal digits. There are different versions of UUIDs, each serving different purposes:

  • UUID v1 is time-based, incorporating the timestamp, clock sequence, and node ID (MAC address), but it can potentially expose system information.
  • UUID v2 is similar to v1 but includes modifications for local domains (not widely used).
  • UUID v3 and v5 generate UUIDs using hash values from namespace and name, with v3 using MD5 and v5 using SHA-1.
  • UUID v4 is generated almost entirely randomly, providing a high level of anonymity but with a slight risk of duplicates.

{% hint style="success" %} Note that the version and subversion of the UUID usually appears in the same possition inside the UUID. For example in:
12345678 - abcd - 1a56 - a539 - 103755193864
xxxxxxxx - xxxx - Mxxx - Nxxx - xxxxxxxxxxxx

  • The position of the M Indicates the UUID version. In the example above, it’s UUID v1.
  • The position of the N Indicates the UUID variant. {% endhint %}

Sandwich attack

The "Sandwich Attack" is a specific type of attack that exploits the predictability of UUID v1 generation in web applications, particularly in features like password resets. UUID v1 is generated based on time, clock sequence, and the node's MAC address, which can make it somewhat predictable if an attacker can obtain some of these UUIDs generated close in time.

Example

Imagine a web application that uses UUID v1 for generating password reset links. Here’s how an attacker might exploit this to gain unauthorized access:

  1. Initial Setup:
  1. Execution:
  • The attacker triggers a password reset for their first account (`[email protected]`) and receives a password reset link with a UUID, say `99874128-7592-11e9-8201-bb2f15014a14`.
  • Immediately after, the attacker triggers a password reset for the victim's account (`[email protected]`) and then quickly for the second attacker-controlled account (`[email protected]`).
  • The attacker receives a reset link for the second account with a UUID, say `998796b4-7592-11e9-8201-bb2f15014a14`.
  1. Analysis:
  • The attacker now has two UUIDs generated close in time (`99874128` and `998796b4`). Given the sequential nature of time-based UUIDs, the UUID for the victim's account will likely fall between these two values.
  1. Brute Force Attack:
  • The attacker uses a tool to generate UUIDs between these two values and tests each generated UUID by attempting to access the password reset link (e.g., `https://www.acme.com/reset/\`).
  • If the web application does not adequately rate limit or block such attempts, the attacker can quickly test all possible UUIDs in the range.
  1. Access Gained:
  • Once the correct UUID for the victim's password reset link is discovered, the attacker can reset the victim's password and gain unauthorized access to their account.

Tools

References

{% hint style="success" %} Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks
{% endhint %}