Is there an "internal secured application" scenario where software is more vulnerable because of earlier Log4J versions than it would be without it?
I've outlined some detail about this question below.
I'm doing some work to mitigate the risks from the recent Log4J vulnerability. I am aware of approaches that involve removing all traces of earlier Log4J jar files from all the organisation's computers, servers, remote desktops, everything, with the organisation considered "at risk" until this has been done. However, I'm also wondering if such a large expenditure of effort across the board is proportionate [edit 22-Dec-21 12:15 - apologies: to be clear what I'm trying to understand by "proportionate" is whether we will get better outcomes by focusing a lot of effort towards some Log4J code uses with less effort into others, considering that there may be other non-Log4J vulnerabilities that we can address during this same organisational workload].
I have a basic understanding of the vulnerability, for example from https://www.microsoft.com/security/blog/2021/12/11/guidance-for-preventing-detecting-and-hunting-for-cve-2021-44228-log4j-2-exploitation/ where a bad actor sends an HTTP message containing a JNDI command, which then gets executed when the program next attempts to write to the log. The risks there seem obvious for public-facing applications and put me in mind of well-understood SQL Injection attacks (the classic surname: SMITH;DROP TABLE CUSTOMERS comes to mind).
But an "across the board" solution is seeking to mitigate risks to software such as
- internal Java web applications that are protected from the outside world (both in and out) by techniques such as firewalls and DMZs
- internal Java batch programs that I'd expect to be immune to tampering with anyway during execution
- Citrix virtual desktops that can indeed run in administrator mode, depending on the user, but that I would expect to be totally inaccessible from the outside world.
The only justification I've heard so far for "across the board" is that a bad actor might be able to tunnel into the network and cause the Log4J vulnerability to be executed, but in that scenario it seems that a bad actor tunnelling into a network could just go right ahead and execute malware themselves and not bother trying to find programs that use earlier versions of Log4J.
CodePudding user response：
Having considered the comments from @f1sh and @hfontanez and spoken to a couple more people, I'm happy that I have an understanding of the distinctive aspects of this vulnerability that suggest internal apps should be considered vulnerable despite running in a secured environment.
I think the significant feature of this vulnerability is that the problems are manifested during the act of logging, and logging is ubiquitous. Logging even takes place in code that is itself trying to deal with attempted intrusions and this aspect potentially opens up new lines of attack from bad actors.
With regard to running internal code in a secure organisation, I understand there is the prospect of a chain of events starting outside the organisation that might eventually lead to the Log4J vulnerability being exploited inside the organisation. At this point in time, this is maybe more a possibility than a reality, but given the unique nature of this vulnerability then it may make such an attack easier to execute.
One point to take away from this vulnerability is the importance of ensuring that internal applications cannot make network calls outside the organisation if they have no need to do so, and any valid calls to outside are restricted to what is needed.