In short: The implementation of ScrambleSuit's replay protection is incomplete which means that an active adversary can circumvent it. All the credit for this discovery goes to Lasse Øverlier.
ScrambleSuit uses Uniform Diffie-Hellman as one of its authentication mechanisms. To defend against replay attacks, a sever caches the HMAC of a client's authentication message.
The attack works as follows. In the first step, an active adversary (e.g., a censor trying to detect ScrambleSuit) observes a client authenticate successfully towards a ScrambleSuit server and captures the server's Uniform Diffie-Hellman response. In the second step, the adversary replays the captured response to the very same server. Since the server did not cache the HMAC of its own response, it will interpret the replayed data as legitimate authentication message of a new client and respond with an authentication response. The adversary now successfully tricked the server into responding despite not knowing the shared secret. This creates a noteworthy distinguisher which can help identifying ScrambleSuit.
Luckily, it's easy to fix this problem. Introducing message types would be one option but it would break backwards compatibility. The easiest fix which retains backwards compatibility is to make the server also cache its own HMACs which are part of the response to a client's authentication message. The downside is that it doubles the size of the replay table but that's tolerable.
Note that obfs4 is not affected by this problem because a client's and a server's authentication message are different.
Cheers, Philipp