3290

Lemmy.world (and some others) were hacked (lemmy.world)

submitted 1 year ago* (last edited 1 year ago) by ruud@lemmy.world to c/lemmyworld@lemmy.world

724 comments fedilink hide all child comments

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.

you are viewing a single comment's thread
view the rest of the comments

[-] cantevencode@lemmy.world 13 points 1 year ago

Does an admin account have any permissions to view email addresses or data of registered users?

Did MichelleG not have 2FA enabled?

Now that this has happened, it's be worth pushing this issue through as high priority. If HttpOnly was enabled, then an admin takeover would not have been possible.

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

[-] nosut@lemmy.world 26 points 1 year ago

The JWT exploit bypasses 2FA requirements. It basically steals your active session and allows a third party to use it.

[-] cantevencode@lemmy.world 8 points 1 year ago

Good point. I suppose the only way to fix that particular issue to disallow cookie authentications from a new location

[-] sudneo@lemmy.world 2 points 1 year ago

Using proper cookie flags can also mitigate this. I am not sure there is a reason to have the session cookie accessible via JS. HttpOnly flag alone could have helped here.

[-] pazukaza@lemmy.ml 2 points 1 year ago* (last edited 1 year ago)

If by location you mean IP address, the XSS script could also send the IP address of the user to the attacker. Then the attacker could do write operations spoofing that IP. They wouldn't get a response but the write operation would be done anyways.

Maybe doing a 3 way handshake before every administrative action to ensure the IP wasn't spoofed? Idk, I'm not a security person.

User sends IP and JWT + administrative action. I mean, IP is extracted from src addr, not sent.
Server saves the command in a cache with a TTL of 10 seconds. Then sends a randomly generated string to the user. The random string is sent in A HTTP-only same-site cookie to avoid it being read by JS scripts or being sent to external domains.
The user sends it's JWT + randomly generated string cookie back to the server. The server checks the cache. If an action is found, it is executed.

Edit: actually, after thinking about it. If the XSS is not sending the JWT to a remote location but running the attack directly in the victim's browser, there's nothing that can be done. XSS is fucked up.

[-] ugh@lemm.ee 3 points 1 year ago

To answer one question, the admins are able to view email addresses I believe. My knowledge comes from "I read it in a comment awhile ago that sounded credible" so I could be wrong.