Fedora wiki and trac spam and first DWF

As some people might have noticed, Fedora has had some issues with spam on our Wiki and Trac instances .

This spam attack is a targeted attack, since they had to create a lot of new users, and not only did they work with the Fedora Account System (FAS) ,

but they also worked with our Contributor Agreement signing process, and everytime I edited one small thing to stop them, they'd edit their stuff to work with it.

We had been doubting our captcha for a while now, but changing the captcha system entirely was quite hard since the obvious candidates all would not suit us because they're not open source or they don't offer a sound version of the CAPTCHA.

After writing lots of scripts to automatically detect and delete the spam (which I'll open source soon) since we hoped that if we'd do that they'd stop, they still didn't stop (if anything, they only increased their rate), I looked into why they were able to create hundreds of accounts per day.

When looking through the logs, I saw that they were creating the accounts in bursts.

So they would create lots of accounts within a few minutes, then wait a while, before again creating lots of accounts within a few minutes.

With this information I dove into our captcha system , and I discovered that what it does is it makes the client submit both the captcha value that the user entered, and an encrypted version of the correct captcha.

It would then decrypt the correct captcha and check whether it had the same plaintext value as the user just entered, and also whether the captcha hadn't expired yet, which happens 5 minutes after generation.

At this point I started thinking that they probably just stored an encrypted version and the correct answer, and just submitted them together, which means that it would match.

This also matches the bursts, because after 5 minutes the captcha would expire and they would need to solve a new captcha, and they were able to again create lots of accounts in a burst.

After adding some logging code, I discovered that this is indeed what they had been doing.

Since we now have Distributed Weakness Filing and I am a DWF Number Authority , I decided to issue to very first DWF from my block to this issue: DWF-2016-89000.

What I ended up doing to fix this was adding a nonce system to the captcha library, to make sure each captcha is only used once.

This also required patches to FAS, to make sure that the captcha is stored in the database so it works in multi-server setups, but those are now out: TGCaptcha2 0.3.0 and FAS2 0.11.0 have

come to be!

At this moment, this issue is fixed, and I'm hoping again that this will stop the spammers, but if not, we'll continue the arms race, and I get to look into things like machine learning...