Approximately 1 year ago, the world learned of the SolarWinds exploit, which was then dubbed the largest and most catastrophic attack on the U.S. infrastructure. Since then, ransomware events escalated, taking hospitals and even pipelines hostage. Now, approximately a year later, bad actors are exploiting another widely used tool called Log4j, which the Cybersecurity and Infrastructure Sharing Agent (CISA) now deems the most terrifying cyber incident on record. The timing and chronology of these events is probably not a coincidence.
So, the natural question: WTF is Log4j?
What is Log4j?
Log4j is a Java-based (programming language) logging library and Apache product. Logging libraries are portions of an application – like Adobe Acrobat – that record events as the application runs to prevent repeated errors. Remember those pop-up windows when an application would freeze that say: “Please click yes to send a report of this error to [Application Name]?” Similarly, logging libraries automatically make notes of each error in the software code to allow the program and/or programmers to fix those errors. The logging libraries are running with the applications behind the scenes, so whenever you open Adobe, the logging library is recording the events as the application is being used.
Another analogy: In court proceedings like a hearing, trial, or deposition, you probably noticed someone transcribing the events, often referred to as a court reporter/stenographer. A logging library is very similar to the court reporter in terms of capturing live events as they occur.
Logging libraries like Log4j are extremely popular because they are adaptable, work with any type of programming language and application, and work quickly with minimal (if any) impact to the actual devices themselves.
What’s the problem?
Cyber criminals learned of a gap in the Log4j code that allows them to inject new code into the logging library that gives the criminal the ability to remotely control the user’s applications, devices, and larger scale networks. Apparently, Log4j includes a feature that allows it to look up and transmit information to remote servers. Therefore, a cyber criminal can use the Log4j code to find victim servers (that use Log4j), and then with the regular Log4j features, send malicious code to those servers. The servers then respond to the malicious code by either sending back proprietary data or allowing the cyber criminal remote access to whatever and however the attacker requested through Log4j.
Why do I care?
Initial reaction upon hearing about Log4j was “sucks for the applications using it.” Then at 10 p.m. at night, the reality hit: almost every application uses Log4j.
Log4J is part of Java, a 20+ year old programming language that is embedded in almost all applications, whether the applications are Java or python based. Even if an application is written with Python (another programming language), it likely contains Java building blocks like Jenga.
In fact, the following applications use Log4j and became extremely vulnerable as a result: Amazon Web Services, Adobe, Cloud Vision, certain Cisco Programs, Twitter, Webex, IBM Analytics, Microsoft, Mimecast, and VMware, Splunk, and, of course, SolarWinds. CISA continues to issue almost daily updates on this vulnerability to its agencies and contractors.
So, what do I do?
Right now, consumers need to ensure that when your device prompts an update, the update is executed, and the computer is restarted. Backing-up to an off-network hard-drive is also strongly recommended. For businesses, ensure your tech personnel are watching for CISA updates to watch the firewall activity and constantly update applications.
Unfortunately, the scope of the damage from this flaw will also take years to the determine. As for the responsible parties, the heavy money is on whoever orchestrated the original SolarWinds attack and had a year to study potential vulnerabilities.
Comments