Skip Navigation

Lemmy.world (and some others) were hacked

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.

733 comments
  • IMPORTANT ANNOUNCEMENT: My account was not among those hacked. Any random bullshit appearing in my post/comment history was written by me.

  • So what happened:

    • Someone posted a post.
    • The post contained some instruction to display custom emoji.
    • So far so good.
    • There is a bug in JavaScript (TypeScript) that runs on client's machine (arbitrary code execution?).
    • The attacker leveraged the bug to grab victim's JWT (cookie) when the victim visited the page with that post.
    • The attacker used the grabbed JWTs to log-in as victim (some of them were admins) and do bad stuff on the server.

    Am I right?

    I'm old-school developer/programmer and it seems that web is peace of sheet. Basic security stuff violated:

    • User provided content (post using custom emojis) caused havoc when processing (doesn't matter if on server or on client). This is lack of sanitization of user-provided-data.
    • JavaScript (TypeScript) has access to cookies (and thus JWT). This should be handled by web browser, not JS. In case of log-in, in HTTPS POST request and in case of response of successful log-in, in HTTPS POST response. Then, in case of requesting web page, again, it should be handled in HTTPS GET request. This is lack of using least permissions as possible, JS should not have access to cookies.
    • How the attacker got those JWTs? JavaScript sent them to him? Web browser sent them to him when requesting resources form his server? This is lack of site isolation, one web page should not have access to other domains, requesting data form them or sending data to them.
    • The attacker logged-in as admin and caused havoc. Again, this should not be possible, admins should have normal level of access to the site, exactly the same as normal users do. Then, if they want to administer something, they should log-in using separate username + password into separate log-in form and display completely different web page, not allowing them to do the actions normal users can do. You know, separate UI/applications for users and for admins.

    Am I right? Correct me if I'm wrong.

    Again, web is peace of sheet. This would never happen in desktop/server application. Any of the bullet points above would prevent this from happening. Even if the previous bullet point failed to do its job. Am I too naïve? Maybe.

    Marek.

  • Can I ask some possibly dumb questions?

    1. What is JWT?
    2. Was any private user data compromised, and if so will users be informed?
    3. Is there anything regular users can do to avoid their data being compromised? For example, not accessing lemmy on certain web browsers?

    Thank you!

      1. JWT stands for JSON Web Token. It's basically a way for a server (lemmy's) to put a piece of information in your browser in a way that makes sure it come from the server. It (usually) uses some form of digital signature. You can think of it as a note someone gave you with their signature, assuming said signature is very hard/impossible to counterfeit. The next time you see that person, they don't have to remember you, they just have to check the signature. If it is valid, anything written on the note is taken at face value.

      When you connect to a site, there are a few steps to validate that you are who you say you are (identification and authentication). Something like inputing you login/password. Since it would be tedious to do that on every requests, the first time you give your login/password to the server (this is the simplified version, this exchange is a bit more complex usually) the server gives you that JWT. For every subsequent requests, your browser automatically send that JWT that is simple to handle but hard to counterfeit, and the server safely knows that you're whoever is written in that JWT.

      1. I assume there will be a post here when more details are known, or that this post itself will be updated. As with any online service, it's up to the service to decide if they want to communicate. (it may also be a legal requirements in some places to tell user when such an event occurs). Since we're talking about obtaining other user's authentication token including an admin, it is safe to assume that whatever an admin can see has leaked. This can range from basic user informations to more private stuff, although I am not familiar with the software behind lemmy. Note that this is a worst-case scenario; an admin impersonator could have access to anything an admin could see, it does not mean they immediately dumped everything. It depends on their motivation.
      2. Protection against this kind of stuff Compromission of the JWT can happen in many ways and I don't know which way was used. But if there's a flaw in the software used (the lemmy's client-side code, for example) there is not much you can do. JWT can leak through many things :
      • server compromission (out of your control)
      • client-side compromission (only happens when using a browser; applications that uses API should be less susceptible to that)
      • vulnerable extension: if you have browser extensions, they can easily peek into what's happening in any given page (that's their whole purpose). Malicious extensions, or extensions that allow outsider's some kind of control over them can leak data
      • browser vulnerability: keep your browser up-to-date, and (this is controversial) stick to a family of well-enough known browser. That obscure browser that have 20 users worldwide and is based on a three years old version of chromium is not the best thing to use
      • keep your data safe: only put the minimum required amount of data on any service. For lemmy, I assume an email address and your login/password is the bare minimum (well the email is already extra, but it's very convenient to have). Some services really likes to get everything they can out of you.

      Basically, stay up to date and don't use shady stuff. Easy to say, I know.

    • 1 - jwt is the authentication cookie u get when u sign in with ur password, ur browser stores the jwt and then any further interaction authenticates using it

      2 - yes, userscripts, extensions, custom frontends, apps, all apps have access to jwt

      • 2 - yes, userscripts, extensions, custom frontends, apps, all apps have access to jwt

        HttpOnly flag not being set? That would protect against userscript, web apps, and extensions without extended permissions being able to access it.

  • You guys really have my highest respect for spending so much time to keep this running, despite all the recent trouble and now even an attack.

    Thank you very much <3 You guys are awesome and I really appreciate how publicly you deal with this.

  • That was scary and exciting. Response seems competent and transparent. I ❤️ this place.

  • Despite the fact that Lemmy is a fairly new piece of software, which makes these issues more likely, I am really grateful for it being open source, and I really appreciate this level of transparency.

  • Good job. I don't understand very much of that, so that makes me all the more grateful. Thank you.

  • On Liftoff, I had to clear cache and storage in order to log back in. Still having issues with the website on Chrome, which keeps telling me I'm not logged in after clearing cache and logging back in.

  • That shit sucks, I'm so sorry. I'm glad you got it under control. Nothing but admiration from me for doing all this hard work.

    New code, new challenges. It's a new world out there and largely is pretty great. Thanks again.

  • That doesn't surprise me. Especially the "homemade" instances. The documentation is severely lacking and I had to fix lots of stuff in the instructions with try&despair to make my instance run.

    There's not a great focus in security if your application starts with "step 1: install docker"

733 comments