While I was asleep, apparently the site was hacked. Luckily, (big) part of the lemmy.world team is in US, and some early birds in EU also helped mitigate this.
As I am told, this was the issue:
- There is an vulnerability which was exploited
- Several people had their JWT cookies leaked, including at least one admin
- Attackers started changing site settings and posting fake announcements etc
Our mitigations:
- We removed the vulnerability
- Deleted all comments and private messages that contained the exploit
- Rotated JWT secret which invalidated all existing cookies
The vulnerability will be fixed by the Lemmy devs.
Details of the vulnerability are here
Many thanks for all that helped, and sorry for any inconvenience caused!
Update While we believe the admins accounts were what they were after, it could be that other users accounts were compromised. Your cookie could have been ‘stolen’ and the hacker could have had access to your account, creating posts and comments under your name, and accessing/changing your settings (which shows your e-mail).
For this, you would have had to be using lemmy.world at that time, and load a page that had the vulnerability in it.
If I had to propose something, I’d suggest writing a spec and implementing an API for Lemmy servers that would allow one to submit signed actions, like posts, comments, likes, display name, etc. Then people will write clients that will allow generation of certificates to be used to sign those messages + add the ability to export/back up the key to be used by other apps too.
I think people who actually understood crypto used it correctly. It’s just that most people were there to speculate and gamble. And, tbh, I think crypto is here to stay.
Yup, I’d support an option to store the key on a server. Or just use an account tied to a server, just like now. Currently, servers sign all messages to other instances with their key, so all messages are tied to the identity of the instance!
100%. Also, while we’re at it, I just want to throw it out there that the front-end should also be split out imo. Let people mix and match backend/user/frontend according to a central api specification, so the best options for each can rise to the top, rather than relying on a single monolithic codebase.
I think it’s already split out!
Ahh well never mind then! For some reason I thought it was all together - maybe I was thinking about the docker-compose or something. Thanks for correcting!