Well I don't expect AI's such as this to be totally clean and perfect, at the end of the day it is a trained model on lots of resources and it is incapable of knowing the ins and outs of things leading to inaccurate results. Overall I think the whole thing is decent enough despite its inaccuracies and flaws, this is also the first public free AI model I think relating to GPT?
Posts by eva
-
-
-
video game smash 12 arg?!
-
I honestly wish these bans were more transparent with the people who are affected by them, more transparency with bans needs to be brought up including the community guidelines. It is super vague at times and really inconsistent in my eyes.
-
To be honest I get where people are coming from, it would be much more simplistic to just have upvotes and downvotes but why exactly is my ban appeal being used as a reasoning to add it?
-
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.
-
I'd like to ask of anybody who wants to fight the ban for me to step down and leave it be for now as there has been some developments,
Sorry but I don't think it is feasible to continue fighting against this thing anymore. I am formally also stepping down from my argument as it is getting me nowhere.
Thanks,
Eva. -
I retract this statement for recent turns of events
I'll make an update thread -
I don't get why I should still be persecuted for this. It's not an exploit anymore and it would not have affected anything at that time, I am denying that I intentionally attempted this, let me repeat again, I intended for it to be a joke not an attempt, I am not your average naive person who would try something to cause disrupt and I knew how patched it was regardless of the patch statuses on the network itself. Point is that most of the stuff TotalFreedom uses come from third parties (Paper/Scissors fork of paper so falls under same umbrella) and plugins, mainly if Paper patched it it'd have been fixed on all plugins which if they used Log4J separately would've patched it themselves nearly instantaneous when it publicly surfaced and made headlines. Any person running a server would also follow suit if appropriate but newer Java versions did not feel the brute of the CVE as it was mostly targeted at older versions, the patches in December only fixed the remaining issues. Nothing would have been affected regardless since it was quite clear that it had been all fixed on everything back in December and I have never ONCE abused an actual CVE to ever to harm a service or do anything with it regardless, I only manipulate CVEs locally on test machines (VMs and other stuff like that), not on Minecraft servers, not on public services, not outside my local network. It's simply not my thing and I have never broken any rules technically speaking.
-
Vouch, nya.
-
A patched CVE loses its status as a critical vulnerability/exploit, attempts don't even matter after the official patch of the software, I thought I also said that I intended it to be a joke and not an attempt? I did this because of how funny and ridiculous Log4J was and I wanted to make a joke reference about it, not to directly target the server.
-
I'll once again state, you attempted (unsuccessfully) to exploit Log4J on the network. Everything beyond that is ultimately irrelevant, just because we had patched it / put things in place to stop it, doesn't mean you didn't attempt it.
Ignoring all of that even if I did invalidate the log4j bit and review your ban, the duration would likely get extended due to the number of offences you committed compared to others (As I said, being the 2nd largest offender)
Yes but as a whole by the time I have attempted this the entire CVE was well-patched in the Log4J library officially, the resource name "get_balls" had no intents of ever reaching a destination in the first place unless I specified a domain name extension or it internally routed to somewhere, There's nothing written in the Log4J library routes it to anywhere else other than what's specified (does not append .com or anything of the sort) and it needs to be a functional LDAP server which was not plausible in my case, why should this specifically on it's own be considered a primary reason of extension onto the duration? I intended this to be a simple joke alongside with the other fake addresses such as the "|||||||||||||||||||" one and I wasn't even directly intending for it to cause stuff to occur on any part of the network, Log4J never intended for LDAP to be accessible in any string and Join Addresses aren't even parsed using Log4J per code investigation on my end. Nothing would have happened in a scenario where I was to log in and the network was vulnerable since it would need to be logged via Log4J, it's simply illogical to have join addresses being logged to a log other than for debug purposes but debug code generally gets removed/disabled in releases of any software so nothing should've had a reason to pass it to Log4J. I personally considered it to be harmless as at that point in the time it was patched to be not accessible whatsoever.
-
Why would she even attempt to exploit a vulnerability that she knew was already patched and (for reasons I've stated before) wouldn't have worked anyways?
Exactly, I thought it was already known that I develop software and use Java a ton?
As I've mentioned in the ban appeal thread for veast I've been following this closely myself as I already had my own infrastructure to keep clean from it since I had services utilizing Log4J running, I don't try stuff if it is vulnerable and I most certainly do not use these exploits on vulnerable services as I am aware of the impact it could cause. I assure that I wouldn't have connected with it while this CVE was active and I don't see further as to why it could've caused damages, only thing it would cause at most was a stack trace but I expected all of TF's infrastructure to be updated at this period in time or else that'd just be bad security practice. Most plugins and builds of paper were patched shortly after its surfacing.
-
None of this has anything to do with the Indef ban appeal here though.
Sure I'll move further discussion about it to that thread then
-
Why would she even attempt to exploit a vulnerability that she knew was already patched and (for reasons I've stated before) wouldn't have worked anyways?
Exactly, I thought it was already known that I develop software and use Java a ton?
-
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.
-
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?
-
I'd also like to cross-reference another issue with my and many others' ban for "Abusing an exploit in Plan to create fake hostnames" in this response reply post
-
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.
-
I've never seen anything of such happen it tries to resolve "get_balls" but not anything with .com when tested, the domain extension had to be appended before it was passed to log4j.
No further comments, goodbye
