SMART CONTRACTS, DEFI & WEB3 SECURITY - Chapter 8, Exercise 1 Solution
==========================================================
Classifying the Poly Network Exploit

PROBLEM
-------
Using Chapter 7's own vulnerability taxonomy, explain specifically
which category the Poly Network exploit falls under, and describe in
your own words what the attacker's contract interaction must have
achieved to be treated as an authorized "keeper."

SOLUTION
--------
This is an ACCESS CONTROL vulnerability, the same category Chapter 7
used the real Parity library-freeze incident to illustrate. Both cases
share the same underlying shape: some function that should only ever
be callable by a specifically authorized, trusted party turned out to
be reachable by an ordinary, unauthorized caller instead.

In Poly Network's own real case, the protocol's cross-chain contract
logic maintained an internal concept of a "keeper" - a privileged role
authorized to direct real, cross-chain asset transfers. For the
attacker's interaction to succeed, they must have found a way to call
a function that let them change, or be recognized as, that keeper
role - functionally equivalent to Chapter 3's own onlyOwner pattern
having its underlying protection bypassed or missing on the specific
function that controlled who counted as the keeper.

Once the contract itself believed the attacker's own address was a
legitimately authorized keeper, every subsequent transfer instruction
coming from that address would pass whatever check the contract used
to verify authorization - not because the attacker had somehow forged
a valid signature or broken any cryptography (Course 1, Chapter 2), but
because the contract's own access-control logic had a genuine gap
letting an unauthorized party become recognized as authorized in the
first place.

ANSWER: This falls under Chapter 7's access control category - the
same class as the real Parity incident. The attacker's interaction must
have exploited a gap in the contract's own privileged-role logic,
letting them get recognized as an authorized "keeper" despite never
having been legitimately granted that role, after which the contract's
own authorization checks passed for every subsequent transfer they
directed, since it now genuinely believed they were authorized.

----
WHY THIS WORKS AS AN ANSWER

This correctly places the exploit within Chapter 7's own named taxonomy
rather than treating it as an unclassified novel attack, and explains
the underlying mechanism (gaining recognition as an authorized role)
in the same structural terms Chapter 7 already used for the Parity
case.