The Log4j security flaw could impact the entire internet. Here's what you should know:
A critical flaw in widely used software has cybersecurity experts raising alarms and big companies racing to fix the issue.
[...] Jen Easterly, head of the Department of Homeland Security's Cybersecurity and Infrastructure Security Agency (CISA), called it "one of the most serious flaws" seen in her career. In a statement on Saturday, Easterly said "a growing set" of hackers are activelyattempting to exploit the vulnerability.
[...] "It will take years to address this while attackers will be looking... on a daily basis [to exploit it]," said David Kennedy, CEO of cybersecurity firm TrustedSec. "This is a ticking time bomb for companies."
[...] "It's ubiquitous. Even if you're a developer who doesn't use Log4j directly, you might still be running the vulnerable code because one of the open source libraries you use depends on Log4j," Chris Eng, chief research officer at cybersecurity firm Veracode, told CNN Business. "This is the nature of software: It's turtles all the way down."
[...] It could [be] present in popular apps and websites, and hundreds of millions of devices around the world that access these services could be exposed to the vulnerability.
Attackers appear to have had more than a week's head start on exploiting the software flaw before it was publicly disclosed, according to cybersecurity firm Cloudflare. Now, with such a high number of hacking attempts happening each day, some worry the worst is to yet come.
"Sophisticated, more senior threat actors will figure out a way to really weaponize the vulnerability to get the biggest gain," Mark Ostrowski, Check Point's head of engineering, said Tuesday.
[...] There is concern that an increasing number of malicious actors will make use of the vulnerability in new ways, and while large technology companies may have the security teams in place to deal with these potential threats, many other organizations do not.
"What I'm most concerned about is the school districts, the hospitals, the places where there's a single IT person who does security who doesn't have time or the security budget or tooling," said Katie Nickels, Director of Intelligence at cybersecurity firm Red Canary. "Those are the organizations I'm most worried about -- small organizations with small security budgets."
Log4j attackers switch to injecting Monero miners via RMI:
Some threat actors exploiting the Apache Log4j vulnerability have switched from LDAP callback URLs to RMI or even used both in a single request for maximum chances of success.
This shift is a notable development in the ongoing attack and one that defenders need to be aware of when trying to secure all potential vectors.
For now, this trend was observed by threat actors looking to hijack resources for Monero mining, but others could adopt it at any time.
Related Stories
Java Code Repository Riddled with Hidden Log4j Bugs; Here's Where to Look:
About 17,000 Java packages in the Maven Central repository, the most significant collection of Java packages available to developers, are vulnerable to Log4j — and it will likely take "years" for it to be fixed across the ecosystem, according to Google security.
Following the CVE update that just Log4j-core was affected, eliminating vulnerable instances of the Log4j-api, Google Security determined that as of Dec. 19, more than 17,000 packages in Maven Central were vulnerable, about 4 percent of the entire repository. Of those, just 25 percent of the packages had updated versions available, Google added.
For comparison, the Google researchers explained in a Tuesday blog post that the average bug affects between 2 percent and less than .01 percent of such packages.
Sonatype, the organization which maintains Maven Central, has a dashboard that's updated several times a day with the latest on Log4j and reported that since Dec. 10, more than 40 percent of the packages being downloaded were still vulnerable, totaling nearly 5 million downloads.
[...] "The majority of affected artifacts come from indirect dependencies (that is, the dependencies of one's own dependencies), meaning Log4j is not explicitly defined as a dependency of the artifact, but gets pulled in as a transitive dependency," the Google team said.
Making these unpatched Log4j versions even sneakier to track down is "how far down the software supply chain it's typically deployed," the analysts added.
(Score: 0) by Anonymous Coward on Friday December 17 2021, @04:13AM
Give me some fucking information [nist.gov].
Bump the version in your POM to 2.16.0 [mvnrepository.com] and redeploy.
(Score: 4, Interesting) by JoeMerchant on Friday December 17 2021, @04:14AM (5 children)
Saw a story about a (proof of work) crypto mining hijack of an AWS server, the malware ran up $45K in AWS bills to generate: $800 "worth" of cryptocurrency.
Of course, when you're not paying the AWS bill - that's $800 of pure profit.
🌻🌻🌻 [google.com]
(Score: 0) by Anonymous Coward on Friday December 17 2021, @04:22AM (3 children)
criminal valuations often quote "street price". Just what are the margins on the
se AWS services?
(Score: 2) by JoeMerchant on Friday December 17 2021, @12:04PM (2 children)
Not as much as the margins for street drugs.
AWS / Azure / Google Cloud / et al are competitive not only with each other but also with corporate IT departments who could "roll their own" to save money, but very often choose not to.
There's overhead for physical location, power, management, backups, hardware age-out and maintenance, etc. but... those are true expenses for anyone running an IT operation, and the costs generally go up as you scale the size of the operation down.
Of course, dedicated mining rigs running bare metal mining apps are more efficient than malware on general purpose systems, but... they're also single purpose - good for nothing else.
🌻🌻🌻 [google.com]
(Score: 2) by legont on Saturday December 18 2021, @06:20AM (1 child)
No, they can't. Once on, cloud management fires their internal expertise. I'd take years to get it back, if ever. See, an infrastructure expert can move the plant on the cloud, but a cloud one can't build a new infrastructure.
"Wealth is the relentless enemy of understanding" - John Kenneth Galbraith.
(Score: 2) by JoeMerchant on Saturday December 18 2021, @03:22PM
That's the business model, and it works on large corporations. One of the few things giving me hope that the top will eat itself and the grass will get enough light to grow again.
🌻🌻🌻 [google.com]
(Score: 3, Interesting) by bradley13 on Friday December 17 2021, @10:07AM
What makes this more dangerous: AWS will not allow you to put a hard charge limit on your account. You can set warnings, but that's not going to help if someone spins up a zillion high-powered instances for mining - by the time you receive the warning, you could already have $thousands of damages. Of course, if it's your root account that gets hacked, all bets are off anyway, but if it's one of the lower-level accounts, a hard limit could prevent disaster.
Everyone is somebody else's weirdo.
(Score: 0) by Anonymous Coward on Friday December 17 2021, @04:33AM (4 children)
I block javascript. I am secure. Or, not. Are you all up in my bidness?
(Score: 5, Informative) by tangomargarine on Friday December 17 2021, @06:27AM (3 children)
The "J" in Log4J is Java, not JavaScript.
"Java:JavaScript::car:carpet"
"Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
(Score: 3, Funny) by Freeman on Friday December 17 2021, @02:38PM (1 child)
More like Java:JavaScript::Ford Mustang:Duck https://en.wikipedia.org/wiki/DUKW [wikipedia.org]
Joshua 1:9 "Be strong and of a good courage; be not afraid, neither be thou dismayed: for the Lord thy God is with thee"
(Score: 3, Interesting) by Gaaark on Friday December 17 2021, @03:26PM
https://en.wikipedia.org/wiki/Hobart%27s_Funnies [wikipedia.org]
--- Please remind me if I haven't been civil to you: I'm channeling MDC. I have always been here. ---Gaaark 2.0 --
(Score: 2) by DannyB on Friday December 17 2021, @05:29PM
Not only is this exploit for Java, if Log4J2 older versions are in use, it is for Servers. Typically Log4J2 (a logging framework) would be used on a server.
This SN article is old news at this point. Unless you haven't patched it yet.
The server will be down for replacement of vacuum tubes, belts, worn parts and lubrication of gears and bearings.
(Score: 3, Informative) by tangomargarine on Friday December 17 2021, @06:31AM (1 child)
I thought Java was sooooo passe and nobody was using it anymore /s
"Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
(Score: 2) by DannyB on Friday December 17 2021, @05:31PM
That is amusing. People who hate Java would say that. The numbers say otherwise. I wonder if they stay on top of exploits for whatever non-Java technology they are using instead?
The server will be down for replacement of vacuum tubes, belts, worn parts and lubrication of gears and bearings.
(Score: 3, Funny) by Anonymous Coward on Friday December 17 2021, @06:54AM (8 children)
Java is secure by design. It can't have remote exploits. C, the language of the dinosaurs, has those problems. Oh. Wait. What ?
(Score: 2, Funny) by Anonymous Coward on Friday December 17 2021, @07:06AM (4 children)
Gotta love it. For aeons the OOP ilk have bitched about printf being a security nightmare because of RCE potential when people are lazy, and then their own string formating logging lib of choice has the mother of all RCEs built right in as a feature.
(Score: 5, Touché) by choose another one on Friday December 17 2021, @09:28AM (3 children)
It's not really the "OOP ilk" - C++ is OOP after all - rather it is the "safe" programming ilk.
The ilk who decided that programming should be "safe", easy, not require any actual thinking about whether the gun was loaded or where it was pointing to avoid shooting yourself in the foot, instead of something that is (and actually should be) hard, dangerous, and requiring constant thought and attention to detail. Note that this wasn't done to enable the existing programmers to write better code by making less mistakes, it was done so that the existing programmers could be replaced with cheaper people who would make far more mistakes but in a "safe" environment.
Then having replaced the programmers with monkeys so they can pay peanuts, when the (nearly infinite) monkeys come up with a lithium battery device that has a hand-warmer mode and remote activation from anywhere because you never know when you might want to make someones hands really really warm from half a world away, then another monkey decides this thing will go down a bomb if we mail a free sample to half the world - it won't matter because we made it "safe".
(Score: 0) by Anonymous Coward on Friday December 17 2021, @05:49PM (1 child)
There are three responses to this:
1) This is absolutely correct. REAL programmers use butterflies. [xkcd.com]
2) Why would you put guard rails on a stairs? A good person would never fall off. Why would you put airbags in a car? A good driver would never be in a collision. Making a mistake sounds unpleasant. I don't think I know anybody like that.
3) It is mathematically possible to make "perfect code." However, it's horribly inefficient. As an example, try writing "Hello World" in a text editor. Now would you bet $1M that you had it perfect, with no syntax errors and typos? I'm sure you could do so, but how much slower is it than just trying it out in a compiler and runtime engine? And that's just "Hello World." I recall one of the big breakthroughs of Unix (or Linux or something) was the idea of having a core dump and just aborting if things go wrong. This basically is suggesting that everything cost 10x (conservative estimate) more expensive than it currently does.
(Score: 3, Insightful) by choose another one on Saturday December 18 2021, @12:10PM
1) Just use Emacs
2) Not the point, the point is that just because there is a guard rail in the stairs doesn't mean it's safe to run down backwards, airbags don't mean we can forget about replacing bald tyres because the car is now "safe".
But that is exactly what has happened in programming - people are doing things that were well known to be unsafe decades ago, because they are using a "safe" language so don't have to worry about any of that old crap the greybeards go on about.
3) The perfection, or otherwise, of the code is not the issue, the terminal insanity of the specification is. log4shell wasn't a bug. The code implemented the design perfectly.
(Score: 0) by Anonymous Coward on Sunday December 19 2021, @04:02AM
struct string { size_t length; char** data; } is better than depending on null termination. Null termination is a bad idea. And look, in order to safely process null-terminated strings, you still need to pass in length such as strncpy and snprintf. You can't get away from tracking length, so you might as well build strings to be safe from the ground-up.
(Score: 2, Funny) by Anonymous Coward on Friday December 17 2021, @01:01PM
No, it's not the Java part that makes Log4J a secure library; it's the fact that it's an Open Source project not affiliated with any commercial company that means millions of volunteer eyeballs are constantly scouring it for security vulnerabilities. So you see, it has always been perfectly safe.
(Score: 2) by DannyB on Friday December 17 2021, @05:34PM
It is better to use a language that makes it more difficult to make mistakes.
Any language can have remote exploits if you write your code to be exploitable. Java may not have the buffer and stack overflow problems of C, but you most certainly can write code that is remotely exploitable. Or put complex pieces together offering features that enable exploits. The one in this case is format strings that are just a wee bit too powerful in what they can do.
The server will be down for replacement of vacuum tubes, belts, worn parts and lubrication of gears and bearings.
(Score: 2) by darkfeline on Saturday December 18 2021, @01:26AM
That's an interesting point. The big problem of C, manual memory management, mostly doesn't cause security issue. Memory leaks cause crashes, but crashes aren't that bad security-wise. Dangling pointers can cause security issues, but you can't have dangling pointers if you don't free memory (insert big brain meme).
The remaining security issues come from asynchronous access and plain programmer error, and Rust can only save you from the former.
Join the SDF Public Access UNIX System today!
(Score: 4, Informative) by bradley13 on Friday December 17 2021, @10:29AM (5 children)
I still think the whole thing is being overblown, as a way of generating clicks. Yes, there is a well-intentioned-but-stupid hole in log4j. However, afaik, the hole can only be exploited on Java installations from 2018 or earlier. Even if you are using an older Java version - say, Java 8 - Oracle has issued regular updates. As of Java 8u191, Java sets "the JVM property com.sun.jndi.ldap.object.trustURLCodebase to false by default, which disables JNDI loading of classes from arbitrary URL code bases."
Any web-facing, commercial site that hasn't installed security-relevant updates for 3 years? Hear the sound of my tiny violin.
Everyone is somebody else's weirdo.
(Score: 2) by JoeMerchant on Friday December 17 2021, @12:15PM
Like the screech of a million cats being castrated without anaesthesia, using pliers.
Like java itself, the web-facing commercial world is run by an incredible collection of humans - most making terrible mistakes.
Brings to mind the company I started working for in 2013. They had developed a massive app in-house, complicated thing, started in 2005 and had probably 50 man-years invested in it. The code was stored in various git repositories, all properly backed up. It was strung together by a build server which has itself been collecting scripts, library installations, etc. and evolving since 2006. The build server was a critical component of the app, probably 5 man years invested in it alone. Everyone on the team accessed the build server via network connection. When I asked where the physical machine was, the manager pointed to a single desktop box sitting on a highly visible table at the entrance to the R&D offices. When I asked how the build server itself was backed up, the manager turned pale and left the room without a word. 5 minutes later, the IT maven was in the room prepping the physical machine for migration to a virtual machine on the backed up server system.
🌻🌻🌻 [google.com]
(Score: 4, Insightful) by choose another one on Friday December 17 2021, @04:02PM (1 child)
Because no Java software ever broke from updating the Java version, and no software that did would ever have log4j buried so deep within it that most admins would never know, and no software ever depends on or includes a particular java version...
(Score: 2) by DannyB on Friday December 17 2021, @05:36PM
If you're looking for perfection, I don't think you're going to find it. Look for tools that fit your particular needs.
The server will be down for replacement of vacuum tubes, belts, worn parts and lubrication of gears and bearings.
(Score: 2, Informative) by mjrider on Friday December 17 2021, @05:12PM
From what i understand the java version doesn't matter, and the env key isn't 100% working. upgrading is the only working solution, untill the next bug
(Score: 0) by Anonymous Coward on Friday December 17 2021, @06:56PM
The irony is that the bug only exists since 2.0 and we were still on 1.2 so our version was so old we were safe lol
(Score: 3, Touché) by rigrig on Friday December 17 2021, @10:31AM (2 children)
I mean, it would be nice if all hijacked devices started mining crypto instead of DDOSing the rest of the internet.
No one remembers the singer.
(Score: 4, Interesting) by JoeMerchant on Friday December 17 2021, @12:53PM
When the hijacked devices start mining crypto, they are essentially DOSing themselves.
You'd be surprised how many services would slow to a crawl if this was exploited everywhere, instantly.
🌻🌻🌻 [google.com]
(Score: 0) by Anonymous Coward on Friday December 17 2021, @01:42PM
(Score: 2) by crafoo on Friday December 17 2021, @02:55PM
From a related article on Jen Easterly:
Easterly was a managing director at Morgan Stanley, serving as global head of the firm’s Fusion Resilience Center, and a senior fellow at New America’s International Security program. After her NSA role from 2011-2013, she served on the National Security Council as special assistant to the president and senior director for counterterrorism.
Easterly served more than 20 years in the Army and was responsible for standing up the Army’s first cyber battalion. She was also instrumental in the creation of U.S. Cyber Command, and served as executive assistant to National Security Advisor Condoleezza Rice for a time.
New America's International Security: http://securitydata.newamerica.net/index.html [newamerica.net]
I was curious how someone became the head of DHS Cybersecurity.
(Score: 0) by Anonymous Coward on Saturday December 18 2021, @11:09AM (1 child)
i like the part where the tech it guy said "okay guys, i get you wanna use this java stuff. you know my opinion about this glow-in-dark pile of steaming shit. if you wanna use it, i will sign off only if you mention my objection to using it in the back-end application revision file" and then having that exploited and overwritten to "java ruleZ". :)
(Score: 0) by Anonymous Coward on Saturday December 18 2021, @05:03PM
You misspelled NodeJS. It's not spelled J a v a, It's spelled N o d e J S.