1) Subscription contract does not check for “deduction” in funds after calling the token contract.

Exploit mechanism: proxy contracts.

Since a contract’s address is based on the deployed ABI of the contract, but not the contract’s storage, an attack vector I’ve decided to exploit is creating a contract which adheres to the ERC20 interface but whose functionality can be changed to the Subscription contract’s direct disadvantage.

The Subscription contract uses the return value of ERC20.transferFrom to ascertain whether executeSubscription was successful. The token address of Subscription cannot be changed, but the underlying contract can.

The example attached is a proxy contract using delegate call. The first contract can function like a real ERC20 token, only later to be replaced with one which always returns true from transferFrom. 

Solutions: A possible fix would be to check the balance before and after, rather than relying on the value of transferFrom.

Example code for proxy contract is here.
https://gist.github.com/liamzebedee/5c2afd3a24bb840744ab9cf149055738```

Exploit mechanism: Re-entrancy attacks

If the ERC20.transferFrom call is re-entrant, meaning it will maliciously call back into the Subscription, it is possible to exploit some facts:

//increment the timestamp by the period so it wont be valid until then
        nextValidTimestamp[subscriptionHash] = block.timestamp.add(periodSeconds);

This is executed before transferFrom - so a malicious actor (who specifically has engineered their own proxy contract to with a valid nonce/sig for re-entrant calls) can effectively extend their subscription period by periodSeconds every call. Infinite Netflix anyone?

Exploit mechanism: Re-entrancy attacks

If the ERC20.transferFrom call is re-entrant, meaning it will maliciously call back into the Subscription, it is possible to exploit some facts:

//increment the timestamp by the period so it wont be valid until then
        nextValidTimestamp[subscriptionHash] = block.timestamp.add(periodSeconds);

This is executed before transferFrom - so a malicious actor (who specifically has engineered their own proxy contract to with a valid nonce/sig for re-entrant calls) can effectively extend their subscription period by periodSeconds every call. Infinite Netflix anyone?