Changing the JWT secret does this. So instead of a button, its a line of code, making it less likely to be done by mistake.

In crisis situations like this, the last thing you want is to rely on some portion of the application UI working.

This bug also needs to be fixed so that a user logging out / changing password actually correctly invalidates their JWT token: https://github.com/LemmyNet/lemmy/issues/3364

Okay it is insane that that issue is 2 weeks old and was not prioritized and because of that the hacker was gifted 2 weeks to prepare an attack.

I love Lemmy and am grateful for the work of the devs. But I see huge issues with the LemmyNet governance.

Previously it was captchas that were removed because one of the two main devs had a strong personal belief that captchas are "useless" and wanted to impose that belief upon everyone, which then led to an enormous wave of bots with the 0.18.0 as captchas were removed. I'm glad he was then convinced that he was wrong to remove them and then took steps to revert that decision, but it took too long and many instances suffered performance problems by being forced to stay with the 0.17.6 version because it had captchas.

Right now the same thing happens again with issues about security being left unanswered for two weeks. I believe right now all feature developments should be paused and a security audit of the whole code base should be the #1 priority.

This is just very bad. Proper governance and prioritization would have avoided exposing minors to lemon party porn and other disgusting content.

I can only imagine how helpless the admin whose account was compromised felt if she didn't have access to the database to invalidate those tokens, and it could have been prevented if that issue was properly prioritized.

Changing password does invalidate tokens, but the rest of that is accurate.

Welp, that is some simple lapse of separation-of-duties principles that shouldn't have been.

Yes and no. Admin accounts often remain logged in as a practical matter. They can't see incoming reports, registration applications, etc. if the account isn't logged in. And there is no "middle tier"/sitemod or customizable permissions allowing for anything between community mod and instance admin that would mitigate the need to use admin accounts day to day.

This does not mean your instance was affected. You're just cleaning up comments which may or may not have successfully worked on other instances by abusing the emoji bug there.

My post predates the new versions, but I am editing the post now!

We'll likely do a lemmy release tomorrow with this fix included.

Under normal circumstances, they are only visible to:

• sender (and whoever has DB access on the sender's instance)
• recipient (and whoever has DB access on the recipient's instance)
• in case a private message is reported, all admins of the reporter's instance

It is still considered a breach of user data if such messages are leaked.

"private" messages are not private anywhere.

🅴🆁🅶🆈 1•

How did the hackers get the cookies in the first place? Compromised devices on the clients?

I'm not affiliated with lemmy.world or any other instance but I do software and can explain some of the jargon above. XSS is the abbreviation of one of the most common attacks we see on websites, cross-site scripting. This attack works by having some vulnerable code which arbitrarily executes some javascript on a users browser.

In this case, the attacker seems to have found a vulnerability where a specially crafted character is executed when users read posts or comments containing it. In this case, it was especially bad because of how passwords are stored. When you log in to pretty much any website, passwords are stored in the form of cookies; small pieces of data that are passed back and forth to the web server and the client automatically. Usually, these cookies are set to not be readable by javascript, but in this case, it appears that that flag was not set. This allowed the XSS exploit to be sent back to a computer which was set up to grab these cookies.

One thing to note is that although the cookies were stolen, our passwords wouldn't have immediately been compromised. Our login cookies store jwt tokens; a cryptographically signed message proving that we provided a password previously. That's not to say that further escalation isn't possible, but its hard to say for certain how far the hack went before being noticed.