There’s a lot going on with the Log4j vulnerabiliy … cve-2021-44228, referred to as Log4Shell … and a lot of confusion regarding the nature of the risk it presents.  It is considerd 10 out of 10 on the CVSS scoring system, and is extrodinarily easy to exploit.  It is so dangerous because it enables both direct and indirect (secondary, post-exploit and/or lateral movement) attack vectors.  Many are currently focused on vetting and closing off against direct attack – ie. detectable instances of the vulnerability directly embedded in production applications/network environment – but the potential for secondary effects is likely going to be seen as the more devistating aspect of this vulnerability over time.

This Laconic post from yesterday has a blurb which pretty much covers the simplicity…

“… anyone can make a Log4Shell exploit, and there’s a large attack surface to play with. A six-year-old can craft one of these ${ jndi:…} strings herself, having read the above text. She can then submit it to a targeted server as part of a username, a password, a phone number, a TCP packet, any sort of input the server processes. If the Java on the victim end logs this input using a vulnerable instance of log4j2, the attack succeeds.”

I’ve sketched out a brief example of customer (WVLS in this case) with external service relationships between two vendors (OverDrive and Bywater in this case) to try to illustrate what the indirect secondary or lateral post-exploit effects might look like.  These are hypothetical abstracts, and ARE NOT indicitive of any known compromise of particular vendors.

NOTE: this sketch up has not yet been narrated or captioned for more thorough explanation of the concepts it attempts to reprsent but I intend to update it with narration, or at least some strategic captioning to do just that ASAP.

Also, please note that at the time this page was published, both Bywater (Aspen Discovery Layer) and Overdrive (Wisconsin Digital Library) have responded to RFIs, indicating that their application service layers at least are not known to be directly vulnerable to cve-2021-44228.