🔄 Topic

A rule I trusted — a worker cannot certify its own attempt — turned out to be enforced by a string comparison that never normalized Unicode. A homoglyph lookalike of a worker’s identity could slip past it.

🎯 Goal

Trust the separation-of-duties rule as much as I claimed to, by finding out whether it actually held under an adversarial identity instead of just a mismatched one.

🛠 What I Did

I went looking for a way to break my own supervisor guard, on purpose.

Main areas covered:

reviewed the “cannot certify its own attempt” rule that keeps a worker from approving work it produced itself
found that the identity check compared worker strings directly, with no Unicode normalization
confirmed a Unicode-homoglyph lookalike of a legitimate worker identifier — visually near-identical, codepoint-different — passed the comparison as a distinct worker
that meant a worker could, in principle, “certify” its own attempt under a lookalike identity the guard treated as someone else
fixed it by normalizing identity comparisons before evaluating the guard, closing the exact gap
wrote a regression test using a real homoglyph pair, not a synthetic stand-in, so the fix is proven against the actual attack shape

🔗 Key Cybersecurity Connections

Homoglyph attacks exploit the gap between what a string looks like and what it is. Domain spoofing, phishing usernames, and typosquatting all live here — and so, it turns out, can an internal access-control check that assumes string equality means identity equality.

This was found during an independent review that was explicitly trying to break a passing result, not confirm it — the review verdict was “R0-R4 largely PASS,” and this bug is the “one real pre-existing finding” that surfaced only because the review kept pushing after the obvious checks succeeded.

🔍 Investigation Questions

Does every identity comparison in the codebase normalize Unicode first?
What other checks compare strings for identity without normalization?
Could two visually identical but codepoint-different identifiers ever be treated as different principals on purpose?
Did the regression test use a real attack shape, or a convenient placeholder?
What other “cannot X its own Y” rules exist, and are they equally exposed?

🚨 Detection Opportunities

Checks for identity-comparison logic:

string comparison used for identity without Unicode normalization
two near-identical identifiers treated as distinct principals
a “cannot self-certify” or similar separation-of-duties rule with no adversarial test
new identifiers accepted without a homoglyph or confusable-character check
audit logs recording an identity string without its normalized form alongside it

Example:

project=supervisor-identity-guard
signal=identity_comparison_without_normalization
risk_area=homoglyph_spoofing
triage=grep_for_raw_string_equality_on_identity_fields

🧭 MITRE ATT&CK Techniques

Possible mapping for the vulnerability class:

T1036 — Masquerading (homoglyph identity spoofing is a direct instance of this)

🗺 Visual Investigation Diagram

"Cannot certify its own attempt" rule
    ↓
Independent review tries to break it anyway
    ↓
Identity check = raw string comparison
    ↓
Homoglyph lookalike passes as a different worker
    ↓
Normalize before comparing
    ↓
Regression test uses a real homoglyph pair

⚠ Challenges

The uncomfortable part was that the rule had “passed” review right up until someone specifically went looking for a way around it using an attack class that has nothing to do with the rule’s original design. Good separation-of-duties logic and good string-comparison hygiene are different skills, and this rule only had one of them.

📚 What I Learned

I learned that any identity comparison written as plain string equality is a homoglyph bug waiting to be found. It does not matter how sound the surrounding access-control logic is if the thing being compared can be visually forged.

➡ Next Steps

Audit every identity comparison in the stack for missing normalization
Add homoglyph-pair test cases as a standard part of identity-guard testing
Extend the independent-review habit of “assume it’s broken, try to prove it” to every access-control rule
Document this as a reusable finding class for future reviews

🧠 Reflection

A rule can be logically correct and still be broken by the primitive it is built on. Checking the logic was not enough; the string comparison underneath needed the same scrutiny.

🧩 Lessons Learned

What worked

An independent review that kept attacking a rule after it had already “passed.”

What broke

Identity comparison via raw string equality, with no Unicode normalization.

Why it broke

The guard’s logic was sound; the primitive it relied on was not resistant to lookalike characters.

Fix / takeaway

Normalize before comparing identity, and test access-control rules against the specific attack classes that could forge their inputs — not just against obviously wrong inputs.

📈 Skill Progression Context

This supports my cybersecurity progression because Unicode confusable attacks, masquerading, and adversarial review of access controls are directly applicable to phishing defense, identity systems, and code review in any real environment.

😄 TL;DR

A rule said “you can’t certify your own work” — a lookalike character almost proved it wrong.