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.
Looks like it's issuing a GET to https://zelensky.zip/save/{ENCODED_JWT_TOKEN_AND_NAV_FLAG}.
The ENCODED_JWT_TOKEN is from btoa(document.cookie+nav_flag) where nav_flag is 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 .zip TLD is just being used for malicious activity
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.
Google Domains, creating new ways to exploit users right before being sold off to Squarespace.
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:
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 to self if forms are actually used to send data to the server and not handled by Javascript.
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).
The encoded strings are https://zelensky(dot)zip/save/ and navAdmin
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.
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.
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 activityLemmy.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.
Google Domains, creating new ways to exploit users right before being sold off to Squarespace.
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:
To make it super strict, this set could be used:
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).
The encoded strings are
https://zelensky(dot)zip/save/andnavAdminso 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.