Are you a system administrator who managed to complete the Log4Shell mitigation measures in a timely manner before the US government’s cybersecurity deadline of December 24, 2021?
If so, you may have enjoyed the Christmas mini holiday with most people in other parts of the world…
… only returned to the battlefield this week and found that the Apache Log2j team had just launched Fourth patch In what you might call Log4Shell Vulnerability Legend.
The newly discovered bug is CVE-2021-44832, Repair Log4j 2.17.1, Announced on 2021-12-28 (yesterday at the time of writing).
“again,” Dear friends, in famous words Henry V Depend on Avon’s Bard.
Fortunately, although this fourth vulnerability has received all understandable publicity, and although we urge you to patch it in time anyway, this vulnerability is currently only called Ease.
This vulnerability does not seem to be as straightforward and easy to exploit as the original CVE-2021-44228 vulnerability that originally produced the name Log4Shell.
Legend so far
Summarizing the legend so far, starting around December 9, 2021:
- News about “features” in the Apache Log4j logging code that are prone to abuse. Most programmers dismiss simple variable substitutions in recorded data (for example, rotating
${java:version}To a text string describing the Java version), the result allows an attacker to hide dangerous commands in the data from the outside, such as injecting instructions that reveal secret data or download malicious code. - Organizations all over the world are aware that error codes are very common. Even businesses that don’t consider themselves Java stores find Java applications scattered across their networks. Log4j turned out to be Buried in many These applications.
- The news sinks because the vulnerability can even be exploited deep in the network. Running non-Java servers at the edge of the network does not eliminate the risk. Any internal server that sends untrusted data (such as phone numbers or zip codes) to it for processing may be at risk if the data is recorded. Many business logic applications create large amounts of logs, usually for good reasons, such as for auditing or compliance purposes.
- Apache quickly released Log4j 2.15.0, fixed Major security vulnerabilitiesFor servers where change control hinders the application of patches (obviously there is no irony, because the same change control process may have been wielded through vulnerable code years ago), Apache provides convenient runtime mitigation measures to suppress dangerous behavior.
- Attacks have proliferated, many of which come from self-styled researchers “trying to help.” Because this bug was originally a feature, it may be Easy to use, So anyone who wants to participate can give it a try. Thousands, even millions of people have done this, usually without obvious malice.However, in the unhelpful “research” of cybersecurity smoke, there are many real fires that are caused by cybercriminals stealing data or Implant malware Examples include crypto miners and ransomware.
- Apache dug into the code and found another flaw. Log4j quickly got one Second update To 2.16.0.
- Apache found the third flaw and brought us version 2.17.0. We recommend that system administrators who are upgrading to 2.16.0 or 2.15.0 simply continue to patch, but Use 2.17.0 For systems that they haven’t patched yet. It’s best to install all your systems on 2.15.0 or higher as soon as possible, and then go back to “recharge” 2.15.0 and 2.16.0 servers, instead of risking leaving some servers unpatched for a long time risk.
- The US government has set December 24, 2021 as the deadline for repairs. With the landing of Christmas and Boxing Day in 2021 on Saturday and Sunday respectively, creating a double game of weekends and family holidays in most parts of the world, CISA decided to set up the well-known Christmas Eve As deadline So that the U.S. public sector can issue a patch.
Defect fourth
This new fourth flaw is Reported just after Christmas weekend in 2021, On 2021-12-28.
Fortunately, in the words of Apache:
Apache Log4j2 versions 2.0-beta7 to 2.17.0 (excluding security fix versions 2.3.2 and 2.12.4) are vulnerable to remote code execution (RCE) attacks, where an attacker who has the right to modify the log configuration file can build a malicious configuration to connect JDBC Appender is used with data sources that reference JNDI URIs that can execute remote code. This issue has been resolved by restricting the JNDI data source name to the java protocol in Log4j2 versions 2.17.1, 2.12.4, and 2.3.2.
Of course, RCE is the most serious network security breach you will encounter, because it usually means that an outsider can insert an accidental program into your computer without asking for leave.
RCE attacks may inject untrusted applications, insert binary fragments of machine code into memory, or secretly provide unnecessary script files…
…If the attacker succeeds, you will unknowingly run their code without any official Are you sure (Y/N)? Prompt or This could harm your computer A dialog box will remind you.
But even though this bug mentions RCE, this is not what the jargon says Uncertified Remote execution, anyone who can interact with your network without first logging in (for example, by visiting a public-facing website) may trigger the error.
As Apache mentioned, to enable remote execution, an attacker first needs sufficient access rights to mess up the configuration settings of the vulnerable server or business logic application.
We suspect that any attacker who has sufficient access rights to change server-side configuration settings will have many other ways to compromise your internal applications, systems, or networks.
In other words, if you are directly at risk of CVE-2021-44832 now, then updating Log4j 2.17.0 to 2.17.1 may not be a necessary method to solve your security problem, nor a sufficient solution.
In short, don’t just patch to 2.17.1 and think, “Great. Now I can relax into the New Year.”
what to do?
- Patch to Log4j 2.17.1 as much as possible. It doesn’t make sense to skip this update altogether, because it’s just a rating Ease.
- If you think that CVE-2021-44832 poses a clear and existing danger to your network, Repairing is not enough. Systems that are truly vulnerable to malicious outsiders due to this vulnerability are almost certainly at risk of many other attacks.
- Check your Log4j configuration settings. Look for unauthorized or unwanted settings that you may not have considered before.
In a previous article, we recommend that you re-examine your own use of Log4j in the near future and determine whether you really need to use it in your own software.
If you inherited Log4j without realizing it, as part of the Java “supply chain” and can easily replace it with something simpler and less feature-rich, we think it would be a wise choice .
Some commenters stated that it is impractical or excessive for us to say this, claiming that we underestimated the complex logging requirements of ordinary business applications.
But we will again suggest that if you have recently discovered Log4j in your ecosystem, especially on a server where you don’t even know it’s there, you should ask yourself this question, “Do I really need a multi-megabyte logging toolkit consisting of nearly half a million lines of source code, or do I need at least something gentler and easier to review?”
This is not a criticism of Apache. This is just to remind you that inherited security issues such as Log4Shell are usually unexpected side effects of network security decisions made by outsiders in the company that you have never seen and will never encounter many years ago.
Although the original decision may not be made by you, it is now your responsibility, so reviewing it will hardly be considered controversial or ill-considered!
Understand how the LOG4SHELL vulnerability works
(If you can’t see the text here, please try full screen mode, or Watch directly On YouTube. Click the gear in the video player to speed up playback or turn on subtitles. )
