UPDATE: The latest RC version of Lemmy-ui (0.18.2-rc.2) contains fixes for the issue, but if you believe you were vulnerable, you should still rotate your JWT secret after upgrading! Read below for instructions. Removing custom emoji is no longer necessary after upgrading.
Original post follows:
This post is intended as a central place that admins can reference regarding the XSS incident from this morning.
What happened?
A couple of the bigger Lemmy instances had several user accounts compromised through stolen authentication cookies. Some of these cookies belonged to admins, these admin cookies were used to deface instances. Only users that opened pages with malicious content during the incident were vulnerable. The malicious content was possible due to a bug with rendering custom emojis.
Stolen cookies gave attackers access to all private messages and e-mail addresses of affected users.
Am I vulnerable?
If your instance has ANY custom emojis, you are vulnerable. Note that it appears only local custom emojis are affected, so federated content with custom emojis from other instances should be safe.
I had custom emojis on my instance, what should I do?
This should be enough to mitigate now:
- Remove custom emoji
DELETE FROM custom_emoji_keyword;
DELETE FROM custom_emoji;
- Rotate your JWT secret (invalidates all current login sessions)
-- back up your secret first, just in case
SELECT * FROM secret;
-- generate a new secret
UPDATE secret SET jwt_secret = gen_random_uuid();
- Restart Lemmy server
If you need help with any of this, you can reach out to me on Matrix (@sunaurus:matrix.org) or on Discord (@sunaurus)
Legal
If your instance was affected, you may have some legal obligations. Please check this comment for more info: https://lemmy.world/comment/1064402
More context:
It seems to me that the scope of this could have been mitigated with a simple privilege separation policy for admin server accounts but I see a lot of (what looks like) server admins using that account as their daily driver.
Also, lemmy-ui should post a security advisory to their github.
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.
I still wouldn’t use the admin account as my daily driver. Leave it open in another browser/private tab specifically to perform admin actions (as noted) but not for browsing/posting/community modding. I understand how that’s a pain but given how early days we are with this platform and the high probability of more issues surfacing, it’s a necessary pain.
I’d really like to see the devs add some tools to mitigate future risk and further protect admin accounts. The least of which being that admin actions require stronger validation than a browser side cookie, and frequent re-validation to perform admin actions.
that wouldn’t have necessarily stopped this attack I don’t think, but yeah, probably a good idea on multiple levels.
If the separate admin window was open, and a tagged reply or PM was sent to the admin account I think that would render the emote in the notification and trigger the exploit
Fair point. I know that I don’t have the answers. I do think that admin actions need to be more stringently scrutinized. Maybe something like a “sudo” model where your a normal acct 99% of the time and admin actions require a temporary elevation.
How did the hackers get the cookies in the first place? Compromised devices on the clients?
🅴🆁🅶🆈 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.
Stolen cookies gave attackers access to all private messages
Aren’t “private messages” not really private on lemmy anyway?
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.
unless they’re E2EE
I’m curious why the UI update to 0.18.2-rc.1 isn’t mentioned anywhere in this thread. I understood that updating the UI was a fix for this exploit.
Thanks for posting. There really should be a button which allows the admins to log everyone out for crisis situations like there I think
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.
