The bad news is that most copier/printer vendors do not know today if the are effected by Log4J. Toshiba is vigorously working to test its product against this potential vulnerability and may have to issue a firmware update.
Tech Solvency - The Story So Far
Log4Shell log4j vulnerability (CVE-2021-44228 / CVE-2021-45046) - cheat-sheet reference guide
Last updated: $Date: 2021/12/16 17:25:22 $ UTC - best effort, validate all for your environment/model before use, unofficial sources may be wrong
by @TychoTithonus (Royce Williams), standing on the shoulders of many giants
Send updates or suggestions (please include category / context / public (or support-walled) links if you can)
Contents
- Context - who is affected
- Summaries
- Technical analysis
- Remediation
- Affected (and unaffected) products
- Other product and tool lists - see especially new CISA list on GitHub (but only has public info)
- Detection and testers
- Exploitation
- News and posts
NOTE: All previous mitigations - based on anything other than upgrade to log4j 2.16 or entirely removing JndiLookup classes - are likely not full mitigation
(but still useful coverage while waiting for later vendor guidance)
Context - who (and what) is affected
- Impact: arbitrary code execution as the user the parent process is running as (code fetched from the public Internet, or lolbins already present on system, or just fetching shared secrets or environment variables and returning them to the attacker)
- Targets: Servers and clients that run Java and also log anything using the log4j framework - primarily a server-side concern, but any vulnerable endpoint could be a target or a pivot point
- Downstream projects: until proven otherwise, assume anything that includes log4j, or depends on something that does, is affected in a way that requires mitigation; see below
- Affected versions: log4j 2.x confirmed - log4j 1.x only indirectly (previous information disclosure vulns, harder to exploit) (in some configurations). Also, presence of 1.x is not good - 1.x went EOL in August 2015!
- Appliances: Don't forget appliances and other opaque or third-party systems that may be using Java server components, but won't be detected by un-credentialed vulnerability scanning or simple exploitation tests
- Log forwarding: logging infrastructure often has many "northbound" (send my logs to someone) and "southbound" (receiving logs from someone) forwarding/relaying topologies. Chaining them together for exploitation must also be considered. (For those not familiar, these are terms of art in the NMS/logging space - ref, ref, ref)
- Cloud: Multiple large providers also affected (but this guide focuses mostly on customer-managed side)
- Deadlines: CISA orders federal agencies to patch Log4Shell by December 24th
Scope / seriousness
- "hearing folks compare #log4shell is "as bad as heartbleed" - imo it's much, much worse. aside from having RCE as the impact, the number of interdependencies around log4j (and particularly the age of them) is orders of magnitude higher" -@caseyjohnellis
- "What people seem to miss: The #Log4Shell vulnerability isn't just a RCE 0day. It's a vulnerability that causes hundreds and thousands of 0days in all kinds of software products. It's a 0day cluster bomb." -@cyb3rops@rakyll (AWS)
- "The Log4j vulnerability is the most serious vulnerability that I've seen in my decades-long career." - CIA Director Jen Easterly, in interview
- The Wikipedia article on log4j is informative to understand usage and scope
- Earliest detection known: 2021-12-01 04:36:50 UTC
- Misnomers: No, it is not also called LogJam. That name is already taken. (Initial LunaSec post used that name, then picked a new one once they found out.)
- Pronunciation: its main author pronounces it "log 4 jay", not "logforge"
back to top
Summaries
- CVEs: CVE-2021-44228, CVE-2021-45046 (not quite as bad). Note also unrelated (but also bad) CVE-2021-4104, announced 2021-12-13 and affecting 1.2 JMSAppender behavior (not the default)
"Apache Log4j2 2.0-beta9 through 2.12.1 and 2.13.0 through 2.15.0 JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. From log4j 2.15.0, this behavior has been disabled by default. From version 2.16.0, this functionality has been completely removed. Note that this vulnerability is specific to log4j-core and does not affect log4net, log4cxx, or other Apache Logging Services projects."
Leave a comment: