__veast - Indefinite Ban Appeal

Please Note: The TotalFreedom Forum has now been put into a read-only mode. Total Freedom has now closed down and will not be returning in any way, shape or form. It has been a pleasure to lead this community and I wish you all the best for your futures.
  • 1. Minecraft name: __veast

    2. Discord username and discriminator: veast#4100

    3. Approximate date of indefinite ban: Unknown

    4. Reason for an indefinite ban: I was banned for "Use of an exploit in Plan to create fake hostnames". I do not believe I should have been banned. If you wanted to you could limit these hostnames you could connect with. Also I do not believe this has caused any trouble to the server and this did not disrupt any connections during the playtime of TF.

    5. Do you agree to follow our community guidelines (https://forum.totalfreedom.me/d/2961) and all the conditions stated above?
    Yes

  • I Object.

    You were found to be one of the abusers of the fake hostnames thing (and were not found to be wrongly banned after a subsequent review of UUIDs associated) and as such have been rightfully banned for 2 months. Your ban is set to expire on December 9th, 17 days from now so I find it pretty pointless to appeal when the ban is expiring in 3 weeks...

    javaw_VqNRNZdU6Q.png
    image.png
    image.png

    Edited once, last by Alco_Rs11 (November 23, 2022 at 2:53 AM).

  • I Object.

    You were found to be one of the abusers of the fake hostnames thing (and were not found to be wrongly banned after a subsequent review of UUIDs associated) and as such have been rightfully banned for 2 months. Your ban is set to expire on December 9th, 17 days from now so I find it pretty pointless to appeal when the ban is expiring in 3 weeks...

    Unfortunately, my ban does not expire in 3 weeks (image atteched below). Also what part is there to abuse? It doesn't cause any disruption to the server nor gameplay.image.png

  • I Object.

    You were found to be one of the abusers of the fake hostnames thing (and were not found to be wrongly banned after a subsequent review of UUIDs associated) and as such have been rightfully banned for 2 months. Your ban is set to expire on December 9th, 17 days from now so I find it pretty pointless to appeal when the ban is expiring in 3 weeks...

    Unfortunately, my ban does not expire in 3 weeks (image atteched below). Also what part is there to abuse? It doesn't cause any disruption to the server nor gameplay.image.png

    Indefinite Bans were converted to "Long-Term" bans and as part of the stipulations of your ban, it is set to expire 2 months from its issuance on October 9th, so yes, it is expiring 3 weeks from now.

    You still abused an exploit which is still bannable. The exploit in question abused a vulnerability in Plan which clogged it up with bogus data, making legitimate data harder to access, so yes, it did have 'harmful' effects on the server.

    You would have been spared from being banned if you reported the vulnerability in Plan but you didn't which is a violation of both the old and new conduct policies so a ban was rightfully issued.

    javaw_VqNRNZdU6Q.png
    image.png
    image.png

    Edited 5 times, last by Alco_Rs11 (November 23, 2022 at 3:02 AM).

  • You still abused an exploit which is still bannable. The exploit in question abused a vulnerability in Plan which clogged it up with bogus data

    Except it's not an exploit. It's a feature. Mojang allows specifying hostnames in their protocol. If this was not allowed by Ryan, there was no way Veast could know.

    The only way this could be changed is:

    1. Installing a plugin that allows connections from only TotalFreedom domains

    This would make it annoying for people to set up domains that lead to TF, such as tf.fo and others.

    2. Trying to resolve hostnames for people who connect with different hostnames

    While this would patch connecting with nonexistent domains, this would lead to another exploit: Lagging the server by connecting tons of accounts with random domains. It also wouldn't really fix anything, because people can just register domains and join with them.

    3. Completely turning off the Plan feature that allows people to see the hostnames used to connect to the server

    This is likely the best solution. It would harm no one, and it would make connecting with custom hostnames do absolutely nothing.

  • The exploit in question abused a vulnerability in Plan which clogged it up with bogus data,

    "Vulnerabillity"
    It's an intended feature in Plan. Both Minecraft and Plan have this feature to be intended. Either Ryan could've disabled it, or just do some SQL queries. Besides, it does absolutely NO HARM to the server.

  • You still abused an exploit which is still bannable. The exploit in question abused a vulnerability in Plan which clogged it up with bogus data, making legitimate data harder to access, so yes, it did have 'harmful' effects on the server.


    You would have been spared from being banned if you reported the vulnerability in Plan but you didn't which is a violation of both the old and new conduct policies so a ban was rightfully issued.

    Sorry to break it to you but there is NO vulnerability/exploits or anything similar in Plan, the server's software (Scissors/Paper) or Minecraft's Java protocol.

    Host names that you saw in Plan is all information that Plan grabs from the Bukkit/Spigot API including but not limited to hostnames or join addresses,

    A quick run down of how this works,

    So you connect with an IP and a Port, when you are using a domain whatever is inputted into Minecraft's server address field in the Multiplayer menu is passed when the client and the server do a handshake, on the serverbound side minecraft sends the follwing information:

    Protocol Version (The client's Protocol Version)

    Server Address (Inputted in the server address bar)

    Server Port (defaults to 25565 unless a port is specified)

    Next State (Status or Login)

    "Hostname or IP, e.g. localhost or 127.0.0.1, that was used to connect. The Notchian server does not use this information. Note that SRV records are a simple redirect, e.g. if _minecraft._tcp.example.com points to mc.example.org, users connecting to example.com will provide example.org as server address in addition to connecting to it. " - http://wiki.vg/Protocol. You may view the packet and data it is sending to the server here. (Serverbound side)

    So theoretically if you make a host name of your choosing and redirect it over to the IP address of TotalFreedom and that host name was inputted in the Minecraft server address bar it is sent by the client to the server in the handshake packets. In this case what is happening is the Bukkit/Spigot API is storing this inside the player's data.

    After this data is sent it is stored in the player's data by the Bukkit/Spigot API, which every Bukkit/Spigot/Paper plugin uses including but not limited to the Plan plugin. Essentially Plan is grabbing this stored data value and saving it to the 'Join Addresses' database, thus it is not an issue or vulnerability with Plan or anything else, simply it is the way it was designed and it is working as it was intended to by the developers, Minecraft does not check the legitimacy of a domain and hence the host name in question can be anything you want it to, doing so would be very impractical and in most cases with games imposing a similar multiplayer structure do the same if they have a reason to send the join address.

    In addition there is no proper way to fix this without some consequences, if you are going to check every domain or limit them to TotalFreedom domains it will require some extra things like pinging the host name to see if it resolves which could create problems and delay connection times and custom legitimate domains hosted by people that do lead to the TotalFreedom server will not work anymore, there are also some more issues stated in a few replies above this one and the only way to resolve this problem is you either hide the 'Join Addresses' analytics or remove the Plan plugin which either of won't happen.

    So calling this a vulnerability in Plan is a bit of a misconception as there is no vulnerability to begin with, it's simply how the Minecraft protocol works and that is the hard truth, the only people you can really blame are Mojang/Microsoft but this is not an issue with other servers out there, either way this itself is a dilemma.

    Mojang/Microsoft won't fix this, there is nothing to fix to begin with as it is working as it was designed to unless you try and push them to change which requires a lot of community attention seeking. Most of the Minecraft community will see this as not a huge problem and nothing will be changed, sorry to say but I didn't write the protocol so I can't be put to blame for this data being sent by the client in the first place.

    Fixing this on the server-side may create complications with connections but I'm not saying it will, if you do decide to ping addresses what if the address is legitimate but the packet is dropped? In return the connection request instigated by the player would be dropped which would be problematic. Simply put every Plugin is using the information provided by the Bukkit/Spigot API in which said information about the player used by the Bukkit/Spigot API is provided by the Minecraft protocol itself in the handshake and other packets.

    The following ban reasoning "Abuse of an exploit in Plan to create fake host names." does not make a whole pile of sense when you are provided with all of this context, I'd personally paraphrase this to "Manipulation of analytics displayed by Plan to display non-legitimate host names."

    At the end of the day there is no exploit we abused. Not a vulnerability in a plugin or anything else, everything is simply working as intended by the developers of the protocol (Mojang/Microsoft), there is no other way for plugins or the server to grab host names other than the one that the Minecraft client provides to the server in the handshake packet, what you are persecuting us for is partial damage to a database in which said method used can not be resolved. Unless you want to compromise the functionality of connecting to the server or not allow people to make custom FQDNs which are legitimate that do route to TotalFreedom there is no way this can be solved.

    I know what I am talking about, I've been working with the Minecraft protocol for a long time, I know the ins and outs of it and additionally I also have great experience in programming software using Java and I know what is going on in Plan's source code when it is getting the host names to store them. I've coded a handful of Minecraft plugins myself and I have projects that I still maintain to this day that are using the Minecraft protocol, I also even made mods that are utilizing the Minecraft protocol.

    meow-upscaled.png

  • Except it's not an exploit.

    The reason it's been classed as one is because these weren't legitimate hostnames, they weren't cases of people buying a domain and pointing it to TF, those individuals were un-banned and apologies issued. In these cases individuals went out of their way to spoof hostnames locally and pass false information to the server, which is why it's been classed as an exploit, and quite clearly is not the behaviour we intend. Due to the amount of time it then took to remove these (In some cases quite offensive) hostnames, bans were issued accordingly.

    Wild1145

    Network Owner at TotalFreedom

    Managing Director at ATLAS Media Group Ltd.

    Founder & Owner at MastodonApp.UK

  • Except it's not an exploit.

    The reason it's been classed as one is because these weren't legitimate hostnames, they weren't cases of people buying a domain and pointing it to TF, those individuals were un-banned and apologies issued. In these cases individuals went out of their way to spoof hostnames locally and pass false information to the server, which is why it's been classed as an exploit, and quite clearly is not the behaviour we intend. Due to the amount of time it then took to remove these (In some cases quite offensive) hostnames, bans were issued accordingly.

    So we did not use an exploit in the sense of a software having a vulnerability but in the context of abusing said software to create fake host names resulting in bans issued because of the inconvenience to clear said host names from the database?

    meow-upscaled.png

  • The reason it's been classed as one is because these weren't legitimate hostnames, they weren't cases of people buying a domain and pointing it to TF, those individuals were un-banned and apologies issued. In these cases individuals went out of their way to spoof hostnames locally and pass false information to the server, which is why it's been classed as an exploit, and quite clearly is not the behaviour we intend. Due to the amount of time it then took to remove these (In some cases quite offensive) hostnames, bans were issued accordingly.

    So we did not use an exploit in the sense of a software having a vulnerability but in the context of abusing said software to create fake host names resulting in bans issued because of the inconvenience to clear said host names from the database?

    You (and others) went out your way to create fake and in a lot of cases offensive hostnames that were in no way shape or for real or possible to be real. It creates false information and is abusing the way in which the system works to create a non-intended result (Hence an exploit). Bans were issued because they were often offensive and because you were doing something that was not the intended function of the system.

  • So we did not use an exploit in the sense of a software having a vulnerability but in the context of abusing said software to create fake host names resulting in bans issued because of the inconvenience to clear said host names from the database?

    You (and others) went out your way to create fake and in a lot of cases offensive hostnames that were in no way shape or for real or possible to be real. It creates false information and is abusing the way in which the system works to create a non-intended result (Hence an exploit). Bans were issued because they were often offensive and because you were doing something that was not the intended function of the system.

    Yes I'll admit to the fake host names but I was banned for extra months for attempting a non-functional whatsoever CVE that was patched months prior, by the time all of this happened in April there should have been no parts of the network to be vulnerable to such attacks and also the lookup is really strict, I provided "get_balls" however it will not attempt to resolve anything other than that, which means it does not append .com, .net etc. There's also no components of any server using Log4J to log host-names so if the server was vulnerable to such string at that time nothing would've happened and if something were to do it there would simply be a resource resolution error, Video referenced all this and provided stack traces in his latest reply on my other thread showing that if the server was in a scenario to be vulnerable to this that it would have simply just not have done anything except create a stack trace. I'd like this to be looked into since I don't think I'm in the wrong for this as I am completely aware about the workings of this and have watched this CVE closely, I wouldn't be so naive regarding this considering I have experience with Java and it is one of my top used daily on the go programming languages.

    meow-upscaled.png

  • You (and others) went out your way to create fake and in a lot of cases offensive hostnames that were in no way shape or for real or possible to be real. It creates false information and is abusing the way in which the system works to create a non-intended result (Hence an exploit). Bans were issued because they were often offensive and because you were doing something that was not the intended function of the system.

    Yes I'll admit to the fake host names but I was banned for extra months for attempting a non-functional whatsoever CVE that was patched months prior, by the time all of this happened in April there should have been no parts of the network to be vulnerable to such attacks and also the lookup is really strict, I provided "get_balls" however it will not attempt to resolve anything other than that, which means it does not append .com, .net etc. There's also no components of any server using Log4J to log host-names so if the server was vulnerable to such string at that time nothing would've happened and if something were to do it there would simply be a resource resolution error, Video referenced all this and provided stack traces in his latest reply on my other thread showing that if the server was in a scenario to be vulnerable to this that it would have simply just not have done anything except create a stack trace. I'd like this to be looked into since I don't think I'm in the wrong for this as I am completely aware about the workings of this and have watched this CVE closely, I wouldn't be so naive regarding this considering I have experience with Java and it is one of my top used daily on the go programming languages.

    None of this has anything to do with the Indef ban appeal here though.

    Wild1145

    Network Owner at TotalFreedom

    Managing Director at ATLAS Media Group Ltd.

    Founder & Owner at MastodonApp.UK

  • You (and others) went out your way to create fake and in a lot of cases offensive hostnames that were in no way shape or for real or possible to be real.

    If they were offensive I wish to request the hostnames that I used.

    I'd also like to receive a copy privately of the host names I used to reference them against my list of ones I think I used for comparison purposes.

    meow-upscaled.png

  • Alco_Rs11 December 3, 2022 at 7:26 AM

    Closed the thread.