Posted on 01/25/2022 11:03:55 AM PST by ShadowAce
Anti-malware outfit Sophos has weighed in on Log4Shell, saying that the galvanization of the IT world to avert disaster would be familiar to those who lived through the Y2K era.
The Log4Shell vulnerability turned up in the common-as-muck Apache Log4j logging library late last year. As a remote code execution (RCE) flaw, miscreants wasted no time in exploiting it following its disclosure.
However, the IT community promptly responded by patching it. "As soon as details of the Log4Shell bug became clear," explained Sophos, "the world's biggest and most important cloud services, software packages and enterprises took action to steer away from the iceberg."
The company noted that Log4Shell attacks blocked by its firewalls peaked between 20 and 23 December, then tailed off during January. Sophos put the high numbers down to people trying to gauge how bad things were by looking for exposed systems and redundant scans trying different ways to exploit different applications.
The infosec firm noted:
In the first few days, the volume of scans was moderate, reflecting the early development of Proof-of-Concept exploits and preliminary online scanning for exploitable systems.
Within a week, there was a significant increase in scan detections, with numbers peaking between December 20 and December 23, 2021.
As January wore on, Sophos noted that only a "handful" of its customers were subject to attempted Log4j intrusions. "The majority of these were cryptominers."
There are a few parallels that can be drawn with the Y2K panic. The action of engineers to deal with the problem undoubtedly saved the day for many organisations in both cases. The absence of a total IT meltdown left the rest of the world wondering, "well, was it as bad as all that?"
However, as Sophos observed, "just because we've steered round the immediate iceberg, that doesn't mean we're clear of the risk" with attempted exploits rumbling along "for years."
Where the Y2K incident shone a light on coding practices of decades previous, the Log4Shell vulnerability has made it clear just how dependent some companies are on open-source components they don't even know about, don't contribute to or don't have a support contract for.
The issue was summarised neatly by curl creator Daniel Stenberg with both a tweet and a later blog post detailing an email he'd received from a large company with a number of questions aimed at gauging how vulnerable his components might be. The company had no support contract with Stenberg and he correctly suggested that one would be a good idea before he slogged through the questionnaire.
"The level of ignorance and incompetence shown in this single email is mind-boggling," he said of the request.
"I think maybe this serves as a good example of the open source pyramid and users in the upper layers not at all thinking of how the lower layers are maintained. Building a house without a care about the ground the house stands on."
Stenberg also said: "No code I've ever been involved with or have my copyright use log4j and any rookie or better engineer could easily verify that."
Sophos concluded that the threat was not yet over and "the urgency of identifying where it is used in applications and updating the software with the patch remains as critical as ever."
While the danger from the Log4j vulnerability may have ebbed in the weeks since its disclosure, thanks in large part to an almost Y2K-esque mobilisation of engineers, some good might come of the RCE.
Companies are waking up to the open-source components they are using in their estate and hopefully understanding that just because something can be downloaded for free, ensuring it is supported and maintained means somebody must get paid. ®
He must not get out much. That's IT circa 2022.
Y2K was more hype than real, Log4Shell was a security vulnerability in many platforms. If Y2K had gone unfixed stuff a few things would have quit working (including a few critical things to be sure). If Log4Shell had gone unchecked then so many, many things would be held hostage by ransomware and unable to bring back to line with a few code fixes (like the few things overlooked in Y2K).
Y2K did have some real problems. But fixing them was more than just running some upgrade patches (like Log4Shell). Fixing them usually required changing older program code in many, many places (my early programming days). It required lots of tedious searches in program code, often with no documentation, for anything to do with dates. Especially if dates were converted to or from strings (either to or from the user interface or to or from data files).
But, hey! It wasn't bad money for someone who'd just finished a BS in computer science, a field that Y2K along with Algore's internet created tons of demand. LOL
Log4j intrusions - “The majority of these were cryptominers.”
That’s very interesting. In the past, intrusions were looking for machines to use for spambots, opportunities for denial of service, ransomware, storing darknet data, , identify theft, and IP theft. Now they want to use your machine cycles for crypto mining.
uhh--no.
I was heavily involved with the Y2K remediation. It was a real danger. Obviously, most systems are not vital, nor life supporting. But some are. They were also threatened.
Y2K was real.
and you're welcome.
I worked on mainly ACH processes (a very necessary component, though not one that would have cause global thermonuclear war on Jan 1, 2000 or Sep 9, 1999) and many of them had the 2 year digits in ACH processing date fields. Plus there were back-end calculations made against dates stored in string variables (a problem with the 2-year date formats), though those were rare (mainly in database queries sorting records by date if it was stored as a string and processing records in the wrong sequence, perhaps halting operation). Most of what I worked on was string-to-date conversions to and from data files (mainly ACH files).
Does that sound like what you worked on?
Most were routine, but quite a few were life-threatening. While banks probably wouldn't lose your account balances, they could very well have frozen accounts, transferred wrong amounts, thinking there was an overdue amount, or transferred not enough thinking that it had already been done. The economy could have been ruined.
No hype - real deal. Thank an older programmer. A COBOL programmer would be best. We used many of them.
A one or two day pause fixing the things that weren't ironed out correctly the first time doesn't sound to me like an event that would have ruined the economy any more than, say, the Sep 11 attacks forcing the NYSE to close at 10 AM on Sep 11, 2001 and not open again until Sep 17. Yes the stock market dropped a lot that day, but no one says it destroyed the economy or the stock market. (The market had been dropping since March 2000 anyway.)
I was a junior programmer in those days and I cut my teeth on Y2K working on ACH data files. I had plenty of work, don't get me wrong. And I'm sure there were a few seasoned programmers who worked on life critical systems that couldn't quit working for a day or two after Jan 1, 2000. But for the most part, all businesses would have been fine for a day or two if a few things had to be ironed out that were missed before the new year.
That's unlike Log4Shell which allows ransomware to bring your company to its knees and shut you down permanently unless you pay. (And also unlike Y2K, Log4Shell didn't required thousands of programmers to pour through old program code, only a few programmers made bug fixes for Log4Shell and many people employ security updates.)
Yeah--most people think Y2K in terms of consumer-level economics. When you start talking business-level, or bank-to-bank, or gov't-level money, you are talking about real money and that can tank the economy much faster than people would like to believe.
Many of the predictions were hyped.
Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.