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:

  1. Remove custom emoji
DELETE FROM custom_emoji_keyword;
DELETE FROM custom_emoji;
  1. 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();
  1. 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:

https://github.com/LemmyNet/lemmy-ui/issues/1895

https://github.com/LemmyNet/lemmy-ui/pull/1897

    • devnill@lemmy.world
      link
      fedilink
      arrow-up
      0
      ·
      1 year ago

      🅴🆁🅶🆈 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.

  • db0@lemmy.dbzer0.com
    link
    fedilink
    arrow-up
    0
    ·
    1 year ago

    Thanks for posting. There really should be a button which allows the admins to log everyone out for crisis situations like there I think

    • MarcellusDrum@lemmy.ml
      link
      fedilink
      arrow-up
      1
      ·
      1 year ago

      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.

  • tko@tkohhh.social
    link
    fedilink
    arrow-up
    0
    ·
    edit-2
    1 year ago

    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.