Harassment Campaign Using dynmap
MonkeySaint opened this issue · 46 comments
Dear the dynmap team
There is currently a harassment campaign against the group SSI and the people Funtimes909 aka Amy, damcraftde aka Dami.
The group doing this used to be advertising their Discord server by spamming servers using your chat!
After their Discord server got terminated, they realized they could enact a personal vendetta.
This doesn't just affect your users but also many other people.
This would be fixed by enabling require-player-login-ip by default, disabling chat or adding any kind of security to the chat so harassment bots cannot keep spamming servers.
Please look at #4027 which enables require-player-login-ip by default. At least as a temporary fix until there is some security added to the chat of dynmap
Thank you,
MonkeySaint
I can confirm this is an issue, me and dam have been harassed a lot today, maybe more people as well
Can confirm too. This is like the third time this is being done against me, happened multiple months ago already.
Yeah, can confirm that this currently being used and has been used to harass DAM and the members of Server Scanning Inc.
Question to those who have experience from this. Do they do actually anything or it this just spamming? And is there something I could do to not get those messages? I had been also harassed with this this morning.
They use scanning software to find servers with this config option set wrong where they can spam the servers console with messages, and usually spam links to people they do not like, telling the owners to go and harass people from whatever discord server thats completely unreleated, in attempt to get the owners of the discord server and other members harassed for something they never did
Question to those who have experience from this. Do they do actually anything or it this just spamming? And is there something I could do to not get those messages? I had been also harassed with this this morning.
open the dynmap config and change the setting
- class: org.dynmap.SimpleWebChatComponent
allowchat: true
# If true, web UI users can supply name for chat using 'playername' URL parameter. 'trustclientname' must also be set true.allowchat to "false"
Is there any other ways to do that. I mean, I wouldn't necessarily want to disable chat on the dynmap. If I remember correct, was there a some sort of auth system for it? If not Then i guess i have to disable it for now :(
Is there any other ways to do that. I mean, I wouldn't necessarily want to disable chat on the dynmap. If I remember correct, was there a some sort of auth system for it? If not Then i guess i have to disable it for now :(
@MrJuuq You can re-enable chat and under org.dynmap.InternalClientUpdateComponent, set require-player-login-ip to true.
Whoever enabled the chat functionality by default, and allow anonymous people spamming it, was drunk, in my opinion.
It shouldnt take place in ANY software. Even if they do not want to disable chat by default, they should at least implement authentication, so only people trusted by the server owner can chat there, and view messages
I agree, sending messages without authentication should not have been a default option. I have been a witness of this on both the server owner part and as a moderator of Funtimes' community.
This simple misconfiguration has caused several issues in many communities, such as moderator overload, a risk of having the server terminated via mass-report, and spamming welcome messages (and accompanying wave stickers, in some circumstances) in chats of these communities as well.
No level of harassment should be tolerated, and as such, require-player-login-ip should be set to true by default.
Pretty big issue. More sane and secure defaults should really be in order here to stop this from happening again in the future, when the feature is inevitably targeted once more.
It should be the responsibility of the developer of a software to provide safe default options.
Dynmap is indirectly enabling these kinds of smear campaigns by refusing to change the defaults despite the numerous cases of the feature in question being used in a malicious way
I also think this should be changed, I've seen many people be a victim of this and it hurts our community
It should be the responsibility of the developer of a software to provide safe default options.
This should be closed as it is the responsibility of the end user to lock down Dynmap appropriately.
most users don't change the defaults (unless instructed/forced to), so keeping the defaults insecure by default is an issue on the developer's side
Please do not clutter the issue. A lot of people also get notifications via email. It's not fair that we fill their inboxes.
They can unsubscribe
This should be closed as it is the responsibility of the end user to lock down Dynmap appropriately.
Switching to bluemap rn
Please do not clutter the issue. A lot of people also get notifications via email. It's not fair that we fill their inboxes.
migrated everything to bluemap and my ingame chat is now super clean - no more crypto scam advertisements which appeared when i was using dynmap :D
yeah.. seems like the devs behind this arent really listening
im switching to bluemap as we speak rn
Another time I am reminded why Bluemap is so much better
Please do not clutter the issue. A lot of people also get notifications via email. It's not fair that we fill their inboxes.
Users can unsubscribe if they wish. That doesn't mean users can't state new insights into why this should be disabled.
Please do not clutter the issue. A lot of people also get notifications via email. It's not fair that we fill their inboxes.
If the maintainers wish to not hear about those affected, they can fix the issue.
And as for cluttering the inboxes of those who are simply replying to this thread, that is unfortunate but I don’t believe the maintainers of dynmap will do anything about this issue unless we make our voices heard.
yeah.. seems like the devs behind this arent really listening im switching to bluemap as we speak rn
a lot of features that were good got closed or ignored. switched to bluemap a long time ago, never going back
Secure defaults should be the least a user can expect. I don't see why #4027 shouldn't be merged. It doesn't detract from functionality, and makes enabling an unsafe option a conscious process from the user's side.
No features are removed and your users want this, I can't think of why this hasn't been merged yet?
yeah.. seems like the devs behind this arent really listening im switching to bluemap as we speak rn
The devs have lives too, y'know. They do work on Dynmap WHEN they can, and that's a fact from issues/PR's before this.
This should be closed as it is the responsibility of the end user to lock down Dynmap appropriately.
most users don't change the defaults (unless instructed/forced to), so keeping the defaults insecure by default is an issue on the developer's side
It's a 2-way street:
- If you're a dev, you can't knowingly & willingly write insecure code, it's just a part of good practices.
- If you're a user/admin, you NEVER SETTLE ON DEFAULTS without checking them 1st, it's just a part of good practices. If you're attacked, or the system runs like coated in molasses due to not being a totally perfect fit for your use case, cuz you couldn't be fucked to check the damn settings, then you're also at fault and should look in the mirror.
In any case, let's just wait for an updated release and not act like kids.
yeah.. seems like the devs behind this arent really listening im switching to bluemap as we speak rn
The devs have lives too, y'know. They do work on Dynmap WHEN they can, and that's a fact from issues/PR's before this.
This should be closed as it is the responsibility of the end user to lock down Dynmap appropriately.
most users don't change the defaults (unless instructed/forced to), so keeping the defaults insecure by default is an issue on the developer's side
It's a 2-way street:
* If you're a dev, you can't knowingly & willingly write insecure code, it's just a part of good practices. * If you're a user/admin, you NEVER SETTLE ON DEFAULTS without checking them 1st, it's just a part of good practices. If you're attacked, or the system runs like coated in molasses due to not being a totally perfect fit for your use case, cuz you couldn't be fucked to check the damn settings, then you're also at fault and should look in the mirror.In any case, let's just wait for an updated release and not act like kids.
there already was a pullrequest to fix this and it was declined
It's a 2-way street:
- If you're a dev, you can't knowingly & willingly write insecure code, it's just a part of good practices.
- If you're a user/admin, you NEVER SETTLE ON DEFAULTS without checking them 1st, it's just a part of good practices. If you're attacked, or the system runs like coated in molasses due to not being a totally perfect fit for your use case, cuz you couldn't be fucked to check the damn settings, then you're also at fault and should look in the mirror.
In any case, let's just wait for an updated release and not act like kids.
You can say this about alot of things, but in this case the insecure default doesn't just effect the person who installs the software. It's like when windows had a huge security vulnerability that you had to configure your own firewall to fix that it was the end users fault that they got hacked, not windows default firewall not protecting SMB properly. (Refering to EternalBlue)
You cannot expect a kid to properly protect their first Minecraft server on their own.
This should be closed as it is the responsibility of the end user to lock down Dynmap appropriately.
it should be the developers responsibility to disable vulnerable features by default
Mod dev of Discord Integration here
I already made a PSA about this on my discord telling everyone to disable their webchat, or make it login only, and to not pay any ransom.
An update to the 12+ year old default is an option, but it would only apply to new installs, as there is no way to know whether an existing install is one of the tens of thousands of servers who have operated without issue for the last decade with public access web chat as a default. So, even with a code change, if your existing install wants this off - just turn it off.... or turn on login required... or disable chat entirely... lots of choices, so just make one...
Yes but the issue creator and its contributors clearly want this change for new installs so that people that are just getting into Dynmap do not have their servers spammed. This is not a solution to the existing installs. It's a prevention for new installs.
Understood - honestly, the preferences of the issue creator are (with all due respect) quite secondary. That said, I am good with a change to the new-install defaults - we just need to settle on whether that would be best served by which option.
require-player-login-ip: true is a nice thought, but will not work for servers behind a NAT firewall, since the source IP address observed by the web server will be that of the local NAT, and not the actual client (besides other potential IP-based spoofs, like privacy VPNs being used by legit and attackers at same time leading to shared source IPs) - 'trusted-proxies' can be used when someone is behind a firewall to tell server which proxies are trusted, but this cannot be set by default (beyond localhost, which is set), so X-Forwarded-For isn't something defaultable for making remote IPs default to being useful (and would only be provided by an HTTP/HTTPS proxy, not a port forwarder). Net result: new small server guy placed behind a NAT firewall with forwarded port (whether at home or at host) doesn't get any benefit from the change once anyone is logged in (since source IP will be same for all users).
I honestly think 'allowwebchat: false' is the only current global default option that properly would address this, as opposed to the proposed PR.
Other would be 'webchat-requires-login: true' AND 'login-enabled: true', which would limit webchat input to folks using web login (without specifically requiring weblogin in order to view map). Need to be sure login-enabled: true doesn't raise other issues.
require-player-login-ip: true is a nice thought, but will not work for servers behind a NAT firewall, since the source IP address observed by the web server will be that of the local NAT, and not the actual client
I know this issue is a few months old, but I just want to point out that's not how network address translation works. While my LAN IP is masked to the public internet, my server that's behind a NAT gateway with port forwarding can very much determine the public IP address of anyone connecting. I think you might be confusing NAT with a reverse proxy service like Cloudflare or just understanding it in reverse.
Although you're correct about different people sharing the same VPN or even being in the same household being able to connect due to the shared IP, I feel like setting require-player-login-ip: true by default dramatically reduces the attack surface. However even then, in my opinion the best option would probably be to just nuke the chat altogether by default so that the server owner has to explicitly enable it. Personally I'd set both require-player-login-ip: true and allowchat: false by default, although that could result in people submitting issues about the webchat not working.
@Funtimes909 I hate to say it, but as long as you're running that scraping project you're going to be a constant target. People running small private servers aren't going to appreciate being listed in a database and very few people are going to know how to use iptables or even the Windows firewall to block your IP. Honestly until I found your Github account through your NameMC profile I thought both you and your predecessor's accounts were doing drive-by Log4j exploit attacks.
The people attacking Funtimes909 aren't annoyed server owners. They're a group of griefers that just really hate people in this one Discord community that they happen to be a part of.
I've been thinking of a way to make server owners be able to prevent their servers from being scanned easily, probably something through an invisible character in the servers MOTD, but my scanning project has nothing to do with the Log4j exploit or this harassment campaign. I'm a target from these guys because I made a better version of their scanner and they're mad about it.