Hacking Fediverse servers?

2022-11-20 @yojimbo@hackers.town

TL;DR only 5% of fediverse servers publish security.txt

Introduction

There's a continuing influx of new users to the Fediverse at the moment (Oct/Nov 2022), and with them came a fair number of new infosec people.

Some of them started kicking at the tyres of the services that they were on, which has caused some concern – because of the current growth rate of users, many servers are running very tight on resources, and the admins are working hard enough just keeping things running; they don't want to have to also deal with potential outages caused by 'testing'.

There are now a few servers being set aside for testing, and this is a great resource, but they're not necessarily easy to discover.

So if you're a white-hat hacker, you should be trying to co-operate with the servers you are working on. One of the ways to do that is to consult SECURITY.TXT, an informational page described by RFC9116, and informally specified for many years before that.

This tells you who to contact with potential security issues, and can be used to describe any bounty program in place, as well as overall policies (and perhaps pleas for being left alone?)

So, I thought I'd survey how many fediverse sites actually have a SECURITY.TXT page in the first place.

Data Sources

I took lists of known servers from three different resources, * https://instances.social/ * https://fediverse.observer/ * https://fediverse.party/ combined the results to come up with a list of just over 28k domain names, and then requested /.well-known/security.txt from each one of them.

Detailed Results

Many sites didn't respond at all. This probably reflects on the “timeliness” of the list data maintained by the sources I chose; some of them actively re-survey and curate their data to make sure it is current, and others view it more as a record of servers that have been seen at some point.

Many of the sites responded with a clean 404 status code, indicating that they simply don't have the page at all.

Some of the sites responded with content (a 200 status code), but the content wasn't security.txt, it was some other default content from the site instead.

On my initial run through the servers, I ran out of inodes as I got to sites starting with 'm' :–) and had to quickly pause the job, clean up, and resume. And curl was refusing to connect to sites with 'invalid' certificates. So I'm sure I missed a few original data points. Sadly this doesn't seem to matter because the overall picture is pretty sad ...

28805 queries made, 20526 did not provide a response.

Of the 1617 “200 OK” responses, only 664 provided a Contact value ... although 217 of those were 'info@frendi.ca', so I'm excluding them to leave only 447. It's notable that 208 of these were actually PeerTube instances, too, with what looks like an automatically-generated file containing the site admin's address as well as the project's central reporting details, so well done PeerTube.

My final result therefore is that only 447 valid security.txt files were found in over 8000 servers, which is an approximately 5% hit rate.

Perhaps we should clean this up before complaining about white-hat activity?