Harassment Campaign Using dynmap
MonkeySaint opened this issue · 40 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
