This is a good mindset in general, when working in AWS you are not supposed to use your root account unless it’s absolutely necessary even if you are the only user. Hosting a Lemmy instance should be no different.

I work with 2 factor, Oath, SAML, etc. all the time for work, and for the life of me I can’t get it working properly with Lemmy.

Yup. Basics of running a server for anything. Never use your admin account and make a default backup with 2 factor.

Whoops! Reddit spazzed out and couldn’t send your post because it hurts spez’s feelings!

Not at this stage.
Lemmy grew too fast, got many more eyes.
Step 1 is getting a security focus group selected from the people who contribute code to lemmy.

Just like the admins and coders volonteer their time, security specialists will too, money might be needed, but that is not in the the first steps.

Yeah, specifically why I mentioned “affordable”.

1. Set up a fake Nazi lemmy
2. Have it online during the next Chaos Communication Congress
3. ???
4. 50 CVEs.

Agreed. It might be hard to swing right now, but imo this is going to be a crucial step moving forward.

HTML injection / XSS vulnerabilities tend to be a sign of amateur hour to be honest. Made me a bit worried that I’m hitching my reddit escape wagon to the wrong technology. But sounds like this was due to instance-specific customizations rather than the core Lemmy tech, so hopefully we’re still on solid ground.

The way the hack was utilized is honest very creative and interesting;

That’s often the case with exploits.

No, Bobby Tables is really not that creative at all. It is the most basic, entry-level exploit.

Only Lemmy instances with custom emoticons were affected based on the Recap of the Lemmy XSS incident. So if Lemmy.ml doesn’t have these it should not have been affected.

Clear cache of the app

Try clearing cookies (or app cache, on app), that will most likely resolve the issue.

I had the same problem on the liftoff app. Had to delete the account then sign back in and everything worked perfectly again. Personally I also changed my password because it made me feel better.

I had to clear the app cache and local storage before it would work. Cache alone didn’t work.

sometimes just logging in again works. if you have it set to automatically log in, that happens sometimes.

I wonder which instances required logins. I had to relog into my .world account, but my .ee account was still logged in.

You’re on the lemmy.world instance, so you can reach the admins by emailing info@lemmy.world, or posting in the support forum !support@lemmy.world

Now to answer whether there’s a difference between being promoted and doing it yourself - In this case, it’s suspected that session tokens were compromised. You know how when you enter some events, they vet you/your ticket once at the door and then put a stamp on your hand? If you go out and want to get back in, you don’t have to do the whole verification song and dance again, just show them your stamp? Well, that’s pretty much what a session token is - Lemmy vets your password once when you log in, and gives an unique session token to whatever browser or app you used to log in. That way, when you reopen Lemmy, you don’t have to enter your password again.

Now that token is compromised, you have to assume a hacker has your unique token. When you logged yourself back in, Lemmy did the whole validation process again and gave your browser/app a new, unique session token - that’s just how logging in works. But the important question is, did it invalidate the old session token when you logged out? Otherwise the hacker can still show the old token and pretend to be you.

Now if your browser/app prompted you to log-in today, you can be sure that your browser/app tried to get into Lemmy and was denied access. That means you can be sure your old stamp/token is now invalid. Logging out and in yourself doesn’t give you the same guarantee - you will have to check Lemmy code (or run some experiments) to know if logout does actually invalidate the old token. I haven’t validated Lemmy’s code, but I will say most half decent software will invalidate your token when you log out. If you want an extra layer of protection, change your password as well - even the software devs that forget to invalidate tokens on logout usually remember to invalidate them on password changes.

Or if you’re on a small instance, you’re a lot less likely to be targeted in the first place.

Not sure that’s entirely true. Thankfully this attack vector required custom emojis, so it was limited to those specific Lemmy instances. Other attack vectors we may not be so lucky and it could spread through federation.

Good opsec

Honestly, I see it as a win.

The people that did this didn’t really act out in a coordinated attack. They were just kind of playing around, redirecting to lemonparty, changing page elements.

It could have been a lot worse. The site could have been redirecting to malicious websites, downloading trojans, doing a lot of bad things. Instead, we got direct attention to the security vulnerabilities in question, and they’re being worked on and patched out relatively quickly. Helps that a lot of those on these communities are focused in programming and cybersecurity.

thanks for the update

To add context to this. What I’ve been told is that a community running on a lemmy fork with 5 digit users had used this code for a while and backported(?) the code upstream when they federated back. I guessing there was an assumption of safety as they had been using the custom emojis code for quite a while without it being exploited.

Yeah it’ll be hard to regain my trust after this one. I mean I’ll still use Lemmy but for now I’ll assume mine or any other account could be hacked at any time and act accordingly. This is a really amateur mistake even by FOSS standards.

So if you dont have to resign-in?

No problems from me

I’d just log off lol

These aren’t demands, but I can definitely see how they can come off that way. These are industry standard post cybersecurity incident review questions by defined by NIST (NIST SP 800-61 Rev 2 Section 3.4.1) slightly rephrased.