|
Royce Williams
Summary (Dan Goodin): Log4j takes a log message, interprets it as a URL and goes out and fetches it. It will even execute JavaScript in URLs with full privileges of the main program. Exploits are triggered inside log messages using the ${} syntax. Easy peasy.
Who is affected: - Servers and clients that run Java and also log anything using the log4j framework - log4j 2.x confirmed, and probably log4j 1.x also - Don't forget appliances that use Java server components - Downstream projects that include log4j, including Apache Struts, Solr, etc.
Required to fully mitigate: - Upgrade Log4j 2.15.0 - requires Java 8
Exploitation: active:
Mitigations - easiest:
- (@MalwareTechBlog): If you can't upgrade log4j, you can mitigate the RCE vulnerability by setting log4j2.formatMsgNoLookups to True (-Dlog4j2.formatMsgNoLookups=true in JVM command line).
>Users of Log4j 2.10 or greater may add -Dlog4j.formatMsgNoLookups=true as a command line option or add log4j.formatMsgNoLookups=true to a log4j2.component.properties file on the classpath to prevent lookups in log event messages.
>Users since Log4j 2.7 may specify %m{nolookups} in the PatternLayout configuration to prevent lookups in log event messages.
>Remove the JndiLookup and JndiManager classes from the log4j-core jar. Removal of the JndiManager will cause the JndiContextSelector and JMSAppender to no longer function.
Mitigations - harder: - WAF to limit exploit queries - egress filtering to block unexpected outbound traffic
Exploit detection:
Good threads and summaries: -- Royce Williams
Tech Solvency
|
|
|
Royce Williams
This one is developing quickly, so I'll push updates here as I discover them:
-- Royce Williams
Tech Solvency
On Fri, Dec 10, 2021 at 7:21 AM Royce Williams < royce@...> wrote: Summary (Dan Goodin): Log4j takes a log message, interprets it as a URL and goes out and fetches it. It will even execute JavaScript in URLs with full privileges of the main program. Exploits are triggered inside log messages using the ${} syntax. Easy peasy.
Who is affected: - Servers and clients that run Java and also log anything using the log4j framework - log4j 2.x confirmed, and probably log4j 1.x also - Don't forget appliances that use Java server components - Downstream projects that include log4j, including Apache Struts, Solr, etc.
Required to fully mitigate: - Upgrade Log4j 2.15.0 - requires Java 8
Exploitation: active:
Mitigations - easiest:
- (@MalwareTechBlog): If you can't upgrade log4j, you can mitigate the RCE vulnerability by setting log4j2.formatMsgNoLookups to True (-Dlog4j2.formatMsgNoLookups=true in JVM command line).
>Users of Log4j 2.10 or greater may add -Dlog4j.formatMsgNoLookups=true as a command line option or add log4j.formatMsgNoLookups=true to a log4j2.component.properties file on the classpath to prevent lookups in log event messages.
>Users since Log4j 2.7 may specify %m{nolookups} in the PatternLayout configuration to prevent lookups in log event messages.
>Remove the JndiLookup and JndiManager classes from the log4j-core jar. Removal of the JndiManager will cause the JndiContextSelector and JMSAppender to no longer function.
Mitigations - harder: - WAF to limit exploit queries - egress filtering to block unexpected outbound traffic
Exploit detection:
Good threads and summaries: -- Royce Williams
Tech Solvency
|
|
|
Thank you so much for the post Royce. Knowing how ubiquitous this logging package was, it really blew up big and is moving fast. I shared your notification with The Tech Tribe not long after your original post, it blew up the forums, even an out-of-band email alert was sent. About 8500 techs around the world owe you their thanks (and you made me look like a rockstar, lol). I was able to coordinate my systems, including patching unifi controllers, all before dinner.
Seriously though, many were caught totally flatfooted, some huge vendor names were affected, lots of really big MSPs shut down their PSA and RMM systems out of caution until the vendors could provide a fix or report their investigations. In many cases, we (the MSPs) were asking the vendors before they had released their findings. This was really fast action. It could have been like the Kaseya ransomware attack. You may have directly affected thousands of businesses. You are THE BEST!
Please let me buy you lunch! --- Book time with me here: https://calendly.com/jptechnical ___ _______
| | |
| | _ |
| | |_| |
___| | ___|
| | |
|_______|___| JP (Jesse Perry) voice/text: 907-748-2200
This one is developing quickly, so I'll push updates here as I discover them:
-- Royce Williams
Tech Solvency
On Fri, Dec 10, 2021 at 7:21 AM Royce Williams < royce@...> wrote: Summary (Dan Goodin): Log4j takes a log message, interprets it as a URL and goes out and fetches it. It will even execute JavaScript in URLs with full privileges of the main program. Exploits are triggered inside log messages using the ${} syntax. Easy peasy.
Who is affected: - Servers and clients that run Java and also log anything using the log4j framework - log4j 2.x confirmed, and probably log4j 1.x also - Don't forget appliances that use Java server components - Downstream projects that include log4j, including Apache Struts, Solr, etc.
Required to fully mitigate: - Upgrade Log4j 2.15.0 - requires Java 8
Exploitation: active:
Mitigations - easiest:
- (@MalwareTechBlog): If you can't upgrade log4j, you can mitigate the RCE vulnerability by setting log4j2.formatMsgNoLookups to True (-Dlog4j2.formatMsgNoLookups=true in JVM command line).
>Users of Log4j 2.10 or greater may add -Dlog4j.formatMsgNoLookups=true as a command line option or add log4j.formatMsgNoLookups=true to a log4j2.component.properties file on the classpath to prevent lookups in log event messages.
>Users since Log4j 2.7 may specify %m{nolookups} in the PatternLayout configuration to prevent lookups in log event messages.
>Remove the JndiLookup and JndiManager classes from the log4j-core jar. Removal of the JndiManager will cause the JndiContextSelector and JMSAppender to no longer function.
Mitigations - harder: - WAF to limit exploit queries - egress filtering to block unexpected outbound traffic
Exploit detection:
Good threads and summaries: -- Royce Williams
Tech Solvency
|
|
|
Royce Williams
JP -
Excellent - my hope was to make it forward-ready.
And no need for lunch - just please ask any of those folks send me any items that are missing or wrong. :D
On Sat, Dec 11, 2021 at 1:09 PM JP < jp@...> wrote: Thank you so much for the post Royce. Knowing how ubiquitous this logging package was, it really blew up big and is moving fast. I shared your notification with The Tech Tribe not long after your original post, it blew up the forums, even an out-of-band email alert was sent. About 8500 techs around the world owe you their thanks (and you made me look like a rockstar, lol). I was able to coordinate my systems, including patching unifi controllers, all before dinner.
Seriously though, many were caught totally flatfooted, some huge vendor names were affected, lots of really big MSPs shut down their PSA and RMM systems out of caution until the vendors could provide a fix or report their investigations. In many cases, we (the MSPs) were asking the vendors before they had released their findings. This was really fast action. It could have been like the Kaseya ransomware attack. You may have directly affected thousands of businesses. You are THE BEST!
Please let me buy you lunch! --- Book time with me here: https://calendly.com/jptechnical ___ _______
| | |
| | _ |
| | |_| |
___| | ___|
| | |
|_______|___| JP (Jesse Perry) voice/text: 907-748-2200
This one is developing quickly, so I'll push updates here as I discover them:
-- Royce Williams
Tech Solvency
On Fri, Dec 10, 2021 at 7:21 AM Royce Williams < royce@...> wrote: Summary (Dan Goodin): Log4j takes a log message, interprets it as a URL and goes out and fetches it. It will even execute JavaScript in URLs with full privileges of the main program. Exploits are triggered inside log messages using the ${} syntax. Easy peasy.
Who is affected: - Servers and clients that run Java and also log anything using the log4j framework - log4j 2.x confirmed, and probably log4j 1.x also - Don't forget appliances that use Java server components - Downstream projects that include log4j, including Apache Struts, Solr, etc.
Required to fully mitigate: - Upgrade Log4j 2.15.0 - requires Java 8
Exploitation: active:
Mitigations - easiest:
- (@MalwareTechBlog): If you can't upgrade log4j, you can mitigate the RCE vulnerability by setting log4j2.formatMsgNoLookups to True (-Dlog4j2.formatMsgNoLookups=true in JVM command line).
>Users of Log4j 2.10 or greater may add -Dlog4j.formatMsgNoLookups=true as a command line option or add log4j.formatMsgNoLookups=true to a log4j2.component.properties file on the classpath to prevent lookups in log event messages.
>Users since Log4j 2.7 may specify %m{nolookups} in the PatternLayout configuration to prevent lookups in log event messages.
>Remove the JndiLookup and JndiManager classes from the log4j-core jar. Removal of the JndiManager will cause the JndiContextSelector and JMSAppender to no longer function.
Mitigations - harder: - WAF to limit exploit queries - egress filtering to block unexpected outbound traffic
Exploit detection:
Good threads and summaries: -- Royce Williams
Tech Solvency
|
|
|
Royce,
From what I've been seeing, only version 2.x seems to be vulnerable, and 1.x is not, however nothing seems to be certain about that.
Have you seen any hard confirmation yet whether 1.x is vulnerable?
Thanks,
Mike
toggle quoted message
Show quoted text
On Fri, 10 Dec 2021, Royce Williams wrote: This one is developing quickly, so I'll push updates here as I discover them:
https://www.techsolvency.com/story-so-far/cve-2021-44228-log4j-log4shell/
--
Royce Williams
Tech Solvency
On Fri, Dec 10, 2021 at 7:21 AM Royce Williams <royce@...> wrote:
Summary (Dan Goodin):
Log4j takes a log message, interprets it as a URL and goes out and fetches it. It will even execute JavaScript in URLs
with full privileges of the main program. Exploits are triggered inside log messages using the ${} syntax. Easy peasy.
Who is affected:
- Servers and clients that run Java and also log anything using the log4j framework
- log4j 2.x confirmed, and probably log4j 1.x also
- Don't forget appliances that use Java server components
- Downstream projects that include log4j, including Apache Struts, Solr, etc.
Required to fully mitigate:
- Upgrade Log4j 2.15.0
- requires Java 8
Exploitation: active:
https://twitter.com/GreyNoiseIO/status/1469326260803416073
Mitigations - easiest:
- (@MalwareTechBlog): If you can't upgrade log4j, you can mitigate the RCE vulnerability by setting
log4j2.formatMsgNoLookups to True (-Dlog4j2.formatMsgNoLookups=true in JVM command line).
Mitigations - official project itself (https://logging.apache.org/log4j/2.x/)
Users of Log4j 2.10 or greater may add -Dlog4j.formatMsgNoLookups=true as a command line option or add log4j.formatMsgNoLookups=true to a log4j2.component.properties file on the classpath to prevent lookups in log event
messages.
Users since Log4j 2.7 may specify %m{nolookups} in the PatternLayout configuration to prevent lookups in log event messages.
Remove the JndiLookup and JndiManager classes from the log4j-core jar. Removal of the JndiManager will cause the JndiContextSelector and JMSAppender to no longer function.
Mitigations - harder:
- WAF to limit exploit queries
- egress filtering to block unexpected outbound traffic
Exploit detection:
https://gist.github.com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b
Good threads and summaries:
- https://twitter.com/GossiTheDog/status/1469248250670727169
- https://cert.at/de/warnungen/2021/12/kritische-0-day-sicherheitslucke-in-apache-log4j-bibliothek (German)
- https://github.com/YfryTchsGD/Log4jAttackSurface
--
Royce Williams
Tech Solvency
|
|
|
Royce Williams
Hi, Mike -
Good question. log4j 1.x is not vulnerable to the "Log4Shell" vulnerability itself, per its author. However, it is vulnerable to a number of other issues, and is no longer supported by the authors. So for any product with 1.x still integrated, that parent products' vendors should be asked questions about upgrade plans.
On Sun, Dec 12, 2021 at 7:25 PM Mike < tibor@...> wrote: Royce,
From what I've been seeing, only version 2.x seems to be vulnerable, and
1.x is not, however nothing seems to be certain about that.
Have you seen any hard confirmation yet whether 1.x is vulnerable?
Thanks,
Mike
On Fri, 10 Dec 2021, Royce Williams wrote:
> This one is developing quickly, so I'll push updates here as I discover them:
> https://www.techsolvency.com/story-so-far/cve-2021-44228-log4j-log4shell/
>
> --
> Royce Williams
> Tech Solvency
>
>
> On Fri, Dec 10, 2021 at 7:21 AM Royce Williams <royce@...> wrote:
> Summary (Dan Goodin):
> Log4j takes a log message, interprets it as a URL and goes out and fetches it. It will even execute JavaScript in URLs
> with full privileges of the main program. Exploits are triggered inside log messages using the ${} syntax. Easy peasy.
>
> Who is affected:
> - Servers and clients that run Java and also log anything using the log4j framework
> - log4j 2.x confirmed, and probably log4j 1.x also
> - Don't forget appliances that use Java server components
> - Downstream projects that include log4j, including Apache Struts, Solr, etc.
>
> Required to fully mitigate:
> - Upgrade Log4j 2.15.0
> - requires Java 8
>
> Exploitation: active:
> https://twitter.com/GreyNoiseIO/status/1469326260803416073
>
> Mitigations - easiest:
> - (@MalwareTechBlog): If you can't upgrade log4j, you can mitigate the RCE vulnerability by setting
> log4j2.formatMsgNoLookups to True (-Dlog4j2.formatMsgNoLookups=true in JVM command line).
>
> Mitigations - official project itself (https://logging.apache.org/log4j/2.x/)
> >Users of Log4j 2.10 or greater may add -Dlog4j.formatMsgNoLookups=true as a command line option or add
> log4j.formatMsgNoLookups=true to a log4j2.component.properties file on the classpath to prevent lookups in log event
> messages.
> >Users since Log4j 2.7 may specify %m{nolookups} in the PatternLayout configuration to prevent lookups in log event
> messages.
> >Remove the JndiLookup and JndiManager classes from the log4j-core jar. Removal of the JndiManager will cause the
> JndiContextSelector and JMSAppender to no longer function.
>
> Mitigations - harder:
> - WAF to limit exploit queries
> - egress filtering to block unexpected outbound traffic
>
> Exploit detection:
> https://gist.github.com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b
>
> Good threads and summaries:
> - https://twitter.com/GossiTheDog/status/1469248250670727169
> - https://cert.at/de/warnungen/2021/12/kritische-0-day-sicherheitslucke-in-apache-log4j-bibliothek (German)
> - https://github.com/YfryTchsGD/Log4jAttackSurface
>
> --
> Royce Williams
> Tech Solvency
>
>
>
>
|
|
|
https://www.youtube.com/watch?v=oC2PZB5D3Ys [youtube.com]
Thank you,
Dave
|
|
David Monroe
Consulting Engineer, Diversified Industrials
o: +1 907 261 4700 m: +1 907 360 0517
david.monroe@...
|
|
|
|
|
|
Transformation Accelerated
|
|
|
Great Place to Work®
Certified Jan 2021-2022
|
To request Hardware or software, please use the form, available as a Word document, located at
CTG
HW-SW Request Form. For account changes and file server access, please
use the form CTG User Access Request Form located in the same location. For support issues/requests you
are welcome to and encouraged to contact the CTG Help Desk @ 1-800-544-9071 (from inside the CTG office
x3556). If they are unable to help you solve the problem, they will escalate a Remedy ticket regarding your problem to someone that can assist you further. You may also contact the
Help Desk
via email. They are listed in the CTG Global Address List as "Helpdesk".
toggle quoted message
Show quoted text
From: nuga@groups.io <nuga@groups.io>
On Behalf Of Royce Williams
Sent: Sunday, December 12, 2021 7:33 PM
To: nuga@groups.io
Cc: AKLUG <aklug@...>
Subject: Re: [nuga] log4j trivial RCE (similar to ShellShock) - "Log4Shell" CVE-2021-44228
Hi, Mike -
Good question. log4j 1.x is not vulnerable to the "Log4Shell" vulnerability itself, per its author. However, it is vulnerable to a number of other issues, and is no longer supported by the authors. So for any product with 1.x still integrated,
that parent products' vendors should be asked questions about upgrade plans.
On Sun, Dec 12, 2021 at 7:25 PM Mike <tibor@...> wrote:
Royce,
From what I've been seeing, only version 2.x seems to be vulnerable, and
1.x is not, however nothing seems to be certain about that.
Have you seen any hard confirmation yet whether 1.x is vulnerable?
Thanks,
Mike
On Fri, 10 Dec 2021, Royce Williams wrote:
> This one is developing quickly, so I'll push updates here as I discover them:
>
https://www.techsolvency.com/story-so-far/cve-2021-44228-log4j-log4shell/ [techsolvency.com]
>
> --
> Royce Williams
> Tech Solvency
>
>
> On Fri, Dec 10, 2021 at 7:21 AM Royce Williams <royce@...> wrote:
> Summary (Dan Goodin):
> Log4j takes a log message, interprets it as a URL and goes out and fetches it. It will even execute JavaScript in URLs
> with full privileges of the main program. Exploits are triggered inside log messages using the ${} syntax. Easy peasy.
>
> Who is affected:
> - Servers and clients that run Java and also log anything using the log4j framework
> - log4j 2.x confirmed, and probably log4j 1.x also
> - Don't forget appliances that use Java server components
> - Downstream projects that include log4j, including Apache Struts, Solr, etc.
>
> Required to fully mitigate:
> - Upgrade Log4j 2.15.0
> - requires Java 8
>
> Exploitation: active:
>
https://twitter.com/GreyNoiseIO/status/1469326260803416073
>
> Mitigations - easiest:
> - (@MalwareTechBlog): If you can't upgrade log4j, you can mitigate the RCE vulnerability by setting
> log4j2.formatMsgNoLookups to True (-Dlog4j2.formatMsgNoLookups=true in JVM command line).
>
> Mitigations - official project itself (https://logging.apache.org/log4j/2.x/ [logging.apache.org])
> >Users of Log4j 2.10 or greater may add -Dlog4j.formatMsgNoLookups=true as a command line option or add
> log4j.formatMsgNoLookups=true to a log4j2.component.properties file on the classpath to prevent lookups in log event
> messages.
> >Users since Log4j 2.7 may specify %m{nolookups} in the PatternLayout configuration to prevent lookups in log event
> messages.
> >Remove the JndiLookup and JndiManager classes from the log4j-core jar. Removal of the JndiManager will cause the
> JndiContextSelector and JMSAppender to no longer function.
>
> Mitigations - harder:
> - WAF to limit exploit queries
> - egress filtering to block unexpected outbound traffic
>
> Exploit detection:
>
https://gist.github.com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b [gist.github.com]
>
> Good threads and summaries:
> -
https://twitter.com/GossiTheDog/status/1469248250670727169
> -
https://cert.at/de/warnungen/2021/12/kritische-0-day-sicherheitslucke-in-apache-log4j-bibliothek [cert.at] (German)
> -
https://github.com/YfryTchsGD/Log4jAttackSurface [github.com]
>
> --
> Royce Williams
> Tech Solvency
>
>
>
>
The information transmitted is intended only for the person or entity to which
it is addressed and may contain confidential and/or privileged material. Any
review, retransmission, dissemination or other use of, or taking of any action
in reliance upon, this information by persons or entities other than the
intended recipient is prohibited. If you are not the intended recipient of this
message, please contact the sender and delete this material from this computer.
Computer Task Group, Inc.’s privacy statements may be found via
www.ctg.com/privacy-policy and www.ctg.com/privacy-shield.
|
|
|
So far been pretty lucky, but turns out there’s a log4j vulnerability in CrashPlan – there was an update to it posted just yesterday, in case anyone’s using it.
Peter Barclay
toggle quoted message
Show quoted text
From: nuga@groups.io <nuga@groups.io>
On Behalf Of David W. Monroe
Sent: Monday, December 13, 2021 8:42 AM
To: nuga@groups.io
Cc: AKLUG <aklug@...>
Subject: Re: [nuga] log4j trivial RCE (similar to ShellShock) - "Log4Shell" CVE-2021-44228
https://www.youtube.com/watch?v=oC2PZB5D3Ys [youtube.com]
Thank you,
Dave
|
|
David Monroe
Consulting Engineer, Diversified Industrials
o: +1 907 261 4700 m: +1 907 360 0517
david.monroe@...
|
|
|
|
|
|
Transformation Accelerated
|
|
|
Great Place to Work®
Certified Jan 2021-2022
|
To request Hardware or software, please use the form, available as a Word document, located at
CTG
HW-SW Request Form. For account changes and file server access, please
use the form CTG User Access Request Form located in the same location. For support issues/requests you
are welcome to and encouraged to contact the CTG Help Desk @ 1-800-544-9071 (from inside the CTG office
x3556). If they are unable to help you solve the problem, they will escalate a Remedy ticket regarding your problem to someone that can assist you further. You may also contact the
Help Desk
via email. They are listed in the CTG Global Address List as "Helpdesk".
Hi, Mike -
Good question. log4j 1.x is not vulnerable to the "Log4Shell" vulnerability itself, per its author. However, it is vulnerable to a number of other issues, and is no longer supported by the authors. So for any product with 1.x still integrated,
that parent products' vendors should be asked questions about upgrade plans.
On Sun, Dec 12, 2021 at 7:25 PM Mike <tibor@...> wrote:
Royce,
From what I've been seeing, only version 2.x seems to be vulnerable, and
1.x is not, however nothing seems to be certain about that.
Have you seen any hard confirmation yet whether 1.x is vulnerable?
Thanks,
Mike
On Fri, 10 Dec 2021, Royce Williams wrote:
> This one is developing quickly, so I'll push updates here as I discover them:
>
https://www.techsolvency.com/story-so-far/cve-2021-44228-log4j-log4shell/ [techsolvency.com]
>
> --
> Royce Williams
> Tech Solvency
>
>
> On Fri, Dec 10, 2021 at 7:21 AM Royce Williams <royce@...> wrote:
> Summary (Dan Goodin):
> Log4j takes a log message, interprets it as a URL and goes out and fetches it. It will even execute JavaScript in URLs
> with full privileges of the main program. Exploits are triggered inside log messages using the ${} syntax. Easy peasy.
>
> Who is affected:
> - Servers and clients that run Java and also log anything using the log4j framework
> - log4j 2.x confirmed, and probably log4j 1.x also
> - Don't forget appliances that use Java server components
> - Downstream projects that include log4j, including Apache Struts, Solr, etc.
>
> Required to fully mitigate:
> - Upgrade Log4j 2.15.0
> - requires Java 8
>
> Exploitation: active:
>
https://twitter.com/GreyNoiseIO/status/1469326260803416073
>
> Mitigations - easiest:
> - (@MalwareTechBlog): If you can't upgrade log4j, you can mitigate the RCE vulnerability by setting
> log4j2.formatMsgNoLookups to True (-Dlog4j2.formatMsgNoLookups=true in JVM command line).
>
> Mitigations - official project itself (https://logging.apache.org/log4j/2.x/ [logging.apache.org])
> >Users of Log4j 2.10 or greater may add -Dlog4j.formatMsgNoLookups=true as a command line option or add
> log4j.formatMsgNoLookups=true to a log4j2.component.properties file on the classpath to prevent lookups in log event
> messages.
> >Users since Log4j 2.7 may specify %m{nolookups} in the PatternLayout configuration to prevent lookups in log event
> messages.
> >Remove the JndiLookup and JndiManager classes from the log4j-core jar. Removal of the JndiManager will cause the
> JndiContextSelector and JMSAppender to no longer function.
>
> Mitigations - harder:
> - WAF to limit exploit queries
> - egress filtering to block unexpected outbound traffic
>
> Exploit detection:
>
https://gist.github.com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b [gist.github.com]
>
> Good threads and summaries:
> -
https://twitter.com/GossiTheDog/status/1469248250670727169
> -
https://cert.at/de/warnungen/2021/12/kritische-0-day-sicherheitslucke-in-apache-log4j-bibliothek [cert.at] (German)
> -
https://github.com/YfryTchsGD/Log4jAttackSurface [github.com]
>
> --
> Royce Williams
> Tech Solvency
>
>
>
>
The information transmitted is intended only for the person or entity to which
it is addressed and may contain confidential and/or privileged material. Any
review, retransmission, dissemination or other use of, or taking of any action
in reliance upon, this information by persons or entities other than the
intended recipient is prohibited. If you are not the intended recipient of this
message, please contact the sender and delete this material from this computer.
Computer Task Group, Inc.’s privacy statements may be found via
www.ctg.com/privacy-policy and
www.ctg.com/privacy-shield.
|
|
|
Royce Williams
Important update:
All previous mitigations - based on anything other than upgrading to log4j 2.16 or entirely removing JndiLookup classes - are no longer effective mitigation.
If your vendors have not yet supplied patches that upgrade to 2.16, your best bet may be to remove the JndiLookup class.
For detection and mitigation on Unix-likes, this is a really good tool, based on pure shell (so highly portable), written by Yahoo's security team. By default it just detects. It has an optional flag that will make a zipped backup copy of a jar or war file, and then attempt to remove the affected class.
See my page for other mitigations - I'm updating best-effort in my spare time. My page also has other major lists you can check for your products if you haven't heard back from your vendor yet.
(Also for folks who play or have kids who do, update all Minecraft if you haven't already)
Royce -- Royce Williams
Tech Solvency
On Fri, Dec 10, 2021 at 7:42 AM Royce Williams < royce@...> wrote: This one is developing quickly, so I'll push updates here as I discover them:
-- Royce Williams
Tech Solvency
On Fri, Dec 10, 2021 at 7:21 AM Royce Williams < royce@...> wrote: Summary (Dan Goodin): Log4j takes a log message, interprets it as a URL and goes out and fetches it. It will even execute JavaScript in URLs with full privileges of the main program. Exploits are triggered inside log messages using the ${} syntax. Easy peasy.
Who is affected: - Servers and clients that run Java and also log anything using the log4j framework - log4j 2.x confirmed, and probably log4j 1.x also - Don't forget appliances that use Java server components - Downstream projects that include log4j, including Apache Struts, Solr, etc.
Required to fully mitigate: - Upgrade Log4j 2.15.0 - requires Java 8
Exploitation: active:
Mitigations - easiest:
- (@MalwareTechBlog): If you can't upgrade log4j, you can mitigate the RCE vulnerability by setting log4j2.formatMsgNoLookups to True (-Dlog4j2.formatMsgNoLookups=true in JVM command line).
>Users of Log4j 2.10 or greater may add -Dlog4j.formatMsgNoLookups=true as a command line option or add log4j.formatMsgNoLookups=true to a log4j2.component.properties file on the classpath to prevent lookups in log event messages.
>Users since Log4j 2.7 may specify %m{nolookups} in the PatternLayout configuration to prevent lookups in log event messages.
>Remove the JndiLookup and JndiManager classes from the log4j-core jar. Removal of the JndiManager will cause the JndiContextSelector and JMSAppender to no longer function.
Mitigations - harder: - WAF to limit exploit queries - egress filtering to block unexpected outbound traffic
Exploit detection:
Good threads and summaries: -- Royce Williams
Tech Solvency
|
|
|
